Разнесу два понятия.
- “Стадия” жизненного цикла (ЖЦ) продукта (системы), характеризуется заметной сменой состояния описания либо воплощения системы. Находится в логическом времени.
- “Фаза” ЖЦ проекта (обеспечивающей системы) как временной промежуток, на котором команде проекта выделено целевое финансирование для выполнения определенных работ или реализации требований стейкхолдеров. Факт выполнения работ и удовлетворения требований демонстрируется в конце фазы. Находится в физическом времени.
И стадии и фазы используются при обсуждении проекта как системными инженерами таки проектными менеджерами (ПМ). Основная путаница у ПМ между стадиями и фазами происходит из-за подмены логического времени физическим (1) и слабого разделения описания и воплощения системы (2).
Наиболее распространенное современное понимание проекта подразумевает, что он существует только в рамках программы или портфеля и его цель (продукт проекта) задаются вне проекта, приходят либо в рамках бизнес-кейса программы либо каскадируются от стратегии (описания портфеля активностей) предприятия.
В соответствии с законом Конвея, архитектурные решения по организации проекта, тоже задаются снаружи, см. Устав/Паспорт/Бриф и т.п. и идут от описания проблемы и целевого состояния предприятия.
В соответствии с обратным законом Конвея, “жесткая инфраструктура проекта”, такие как ИТ-ландшафт предприятия, обязательные регламенты по комплаенс и т.д., будут диктовать как оргструктуру проекта и структуру его фаз и предметов поставки (результатов проекта, deliverables).
***
Вставка
Что почитать про закон Конвея?
Проекты в непроектных организациях предназначены для создания новой коммуникационной структуры, чтобы произвести что-то такое, чего стандартная оргструктура не может (об этом молчит ПМБОК и это одна из проблем).
В проектах оргразвития это чаще всего новый бизнес-процесс (на самом деле практика), со всеми поддерживающими его ИТ-решениями (технологией) и обученным персоналом (дисциплиной). Выглядит это так. Делается проект-оргмодуль, который после стабилизации архитектуры, модульного дизайна и интерфейсов становится процессом-оргмодулем. В реальности вместо процессного менеджмента используется кейс менеджмент и это тоже надо признать и переходить в адаптивный кейс-менеджмент. Часто проект оргразвития сопровождается реинжинирингом процессов-оргмодулей.
Системный менеджмент и инженерия предприятия объясняют, как спроектировать такую организацию, которая сможет произвести продукт, востребованный рынком и при этом соблюсти множественные интересы людей вокруг.
Системное лидерство объясняет, как наполнить дизайн организации, пришедший от инженера предприятия, живыми людьми, уговорить их стать винтиками большой машины предприятия, потом уговорить стать шестеренками другой машины другого предприятия. Другими словами, лидерство - это про, как без нарушения законодательства и общественных норм создать такую обстановку и окружение, чтобы люди работали на общую цель.
ПМБОК неявно подразумевает, что проектный менеджер является как инженером предпринятия, так и лидером.
В эту же копилку попадает т.н. “Ориентация на процесс” и “ориентация на результат”. Ориентация на процесс - это когда новый дизайн пытаются сделать в неподходящей коммуникационной структуре. Ориентация на результат часто трактуется как “достижение целевых показателей KPI” или “достижение целей организации”, так любимой другим популярным стандартом БАБОК.
Для меня есть лидерские практики, в которых гораздо важнее ориентация на процесс - риск-менеджмент, принятие решений, выявление требований. Они применяются к системам систем. И есть инженерные и управленческие практики, где применима логика и строятся алгоритмы достижения результата. Это и есть ориентированность на результат в моем понимании.
Отсюда вытекает объяснение, почему алгоритмы (проектные планы) неэффективны тогда, когда эффективны циклы (Шухарта, например). И здесь же пролегает еще одна граница между процессами и проектами, помимо стабильности модульной структуры и интерфейсов. Оргпроцессы-кейсы более эффективны с мягкими системами, чем проектно-алгоритмический подход. Отсюда все эти Эджайл проекты, которые своими итерациями крайне напоминают процессные циклы. Мягкие системы.
В общем и целом, границы размываются и надо уходить от всех этих проектных-процессных подходов в адаптивный кейс-менеджмент с холистической платформой как в части технологий, так и в части команды.
***
Это понимание не самое оптимальное с точки зрения организации работ и описательных схем. В этой заметке я кратко опишу как пришли к такой картине мире и какой следующий шаг.
Поколение ПУ
|
Проект
|
Программа
|
1-ое поколение.
ПМ приходят из инженеров, подразумевается отличное знание предметной области. Сшивка целевой и обеспечивающей системы происходит в голове ПМ. Смерть подхода связана с превышением размера проекта предела, когда он помещается в голове одного человека.
|
Ориентирован на достижение запланированного результата в рамках тройных ограничений.
Запланированный результат задается вне проекта, сам проект покрывает только стадию жизненного цикла “Производство/Поставка”. Речь идет только об организации работ, ведущая дисциплина - исследование операций.
Т.к. люди бизнеса не понимали внутренностей проекта, единственный способ контроля за инвестициями была модель “стадия-гейт”.
|
Это такой большой проект, разве что из-за величины гораздо более важными становятся такие вещи, как контроль изменений и управление информацией.
Гейты еще более строгие, еще более длительные (до нескольких месяцев), происходит сшивка и согласование многих целевых и обеспечивающих систем.
|
2-ое поколение. Расцвет методологий и проектных офисов (офисов управления проектами, project management office, не путайте с офисом проекта project office).
Связаны с массовой компьютеризацией и второй промышленной революцией. Открытие процессного подхода в области управления качеством и рисками (мягкими системами) позволило сделать прорыв сложности. Получилось создавать успешные сложные системы для массового производства - автомобили, компьютеры, самолеты, бытовая и офисная техника. Смерть подхода связана с насыщением рынка, см. Современный Китай, где выпуск промпроизводства падает который год подряд и норма прибыли около ноля.
По иронии, государство сейчас внедряет гибрид между первым и вторым поколением.
|
Возникает четкое разделение между проектом, который нацелен на получение продукта, и программой, которая отвечает за получение эффекта.
Бизнес-кейс и архитектура целевой системы в классике приходит от уровня программы, но есть варианты, см. например PRINCE2 и MSP.
Управление представителями стейкхолдеров происходит здесь, есть разделение работ между ПМ, который работает с представителями стейкхолдеров в разрезе системы и ограничений проекта и бизнес-аналитика, который работает с логической архитектурой, требованиями и дизайном целевой системы.
К трем стандартным viewpoint добавляются еще качество, риски и многие другие.
Появляется separation of concerns и управление интеграцией, единственное, что эти рассмотрения происходят скопом как для целевой системы, так и для обеспечивающей, из-за чего возникает много путаницы.
Вводится понятие ЖЦ системы и появляются проекты управления системой на всем ЖЦ, см., например CDC UP https://www2a.cdc.gov/cdcup/library/pmg/default.htm
Но чаще всего проект захватывает либо стадию ЖЦ системы, либо ее часть, редко выходя за границы стадии. Слабо стыкуется с ЖЦ 2.0 как набора практик.
Операционный менеджмент уходит из критического пути в критическую цепь, идет переход оценок из “классического” бета-распределения в байесовскую статистику , поощряется их уточнение по ходу выполнения работ. Становление системы канбан и управления узким местом прохода системы.
Успехом проекта начинает считаться удовлетворенность заказчика, повышается роль бизнес-кейса при управлении изменениями.
|
В рамках программного менеджмента определяется логическая и физическая архитектура обеспечивающей системы, решаются вопросы модульности и интерфейсов (контракт + сервис) внутри программы для проектных команд и снаружи программы для стейкхолдеров программы. Управление стейкхолдерами в аспекте интересов и работа с viewpoints происходит здесь.
ЖЦ системы как правило эволюционный, система становится, а не проектируется, соответственно программный менеджер часто меняет обеспечивающую систему - открывает новые проекты и закрывает текущие, меняет скоуп. Системные инженеры обитают на уровне программы, обеспечивают склейку
|
3-е поколение, развивающееся.
Уход проектных офисов, массовое их отмирание, переход методологической функции на проектные команды (ситуационная инженерия методов, временные методологии, становление метода в проекте, см. Блог Эдисона).
Связано со смертью массового производства в пользу кастомизированных продуктов с гораздо более коротким ЖЦ.
Один из основных профитов проектных офисов 2-го поколения - базы знаний и оценок теряют в современных проектах свое значение, т.к. и знание и оценки в силу изменения технологий теряют смысл.
|
Проекты из набора процессов-оргмодулей становятся наборами кейсов-оргмодулей, для каждого кейса проектируется метод. Целевая система рассматривается как холархия подсистем, для каждой из которых есть свои ЖЦ и метод разработки и производства. Склейка ЖЦ подсистем происходит в PLM.
Микрокоманды работают по раздельности внутри своих систем. Пример - Spotify https://www.youtube.com/watch?v=Mpsn3WaI_4k
Проекты разбиваются на контрольные точки (КТ), которые являются требованиями стейкхолдеров, привязанными к сроку их реализации и приемки. Каждая такая КТ есть мини-проект, по отношению к ней применяется стандартное проектное управление.
Окончательный уход от гейтов, выделение ресурсов под реализацию требований, бюджет и сроки проекта постоянно уточняются по модели предпринятия на уровне программы.
Бизнес-кейс проекта направляет все работы.
|
На уровне программы определяется платформа целевой и обеспечивающей системы, с особым упором на модульность и стандарты интерфейсов, т.к. именно интерфейсы и их качество определяют успех системы и проекта.
На этом уровне существуют основные модели предпринятия.
Управление ресурсами проектов уходит на уровень программы, выделение динамическое, по Hyper Kanban или TameFlow.
Управление инфраструктурой проектов делится на две части - архитектурная (ERP, PLM, EAM и прочие ИТ-системы с высоким КАПЕКСом) остается на уровне программы, динамическая уходит в проекты и ее никто не контролирует.
|
3-е поколение вкратце и есть адаптивный кейс-менеджмент:
- Системный подход позволяет разбивать целевую систему на маленькие кусочки, которые можно отдать 2-pizza team и без проблем сшить итоговый результат
- Есть IT platform и people platform (я про нее писал недавно, пост про ПЛАС)
- Есть управленческая платформа - это архитектура предприятия и руководящие микропринципы (в моей терминологии это СОП, стандартные операционные процедуры, SOP, standard operating procedures).
А теперь перечитайте 100 правил руководителей проектов в НАСА, http://www.oliverlehmann.com/project-management-sources/Nasa-Hundred-Rules-for-Project-Managers.pdf
Стало ли яснее, о чем они и что надо в них менять для современных проектов?
Комментариев нет:
Отправить комментарий