Вот в таких ограничениях в результате проекта и получается тот самый уникальный продукт, услуга, бизнес-функция, прототип, новые знания, компания… Так, каждый стартап по своей сути является проектом.
А управление проектом – это комплекс мер и методов, направленных на то, чтобы получить ожидаемый проектом результат.
Набор проектов, связанных между собой общим замыслом и нацеленных на единую большую цель, называют программой. Программа всегда состоит из нескольких проектов.
И есть большая разница, когда предприятие запускает отдельный трансформационный проект или целую программу преобразования/ трансформации.
Хочу развенчать один миф: многие менеджеры думают, что управление программами это почти то же, что управление несколькими проектами. И многие преподаватели, инструкторы и тренера поддерживают эту веру.
Но это не так. Вспомните фразу Канта о том, что количество перерастает в качество. Пустыня Сахара и детская песочница отличаются только объемами песка. Равно как стакан воды и океан объемами воды. Но по мере увеличения количества они приобретают совершенно иных качеств.
Тем не менее, в защиту схожести все говорят, что и там и там требуется держать фокус на взаимозависимости и оптимальности/ эффективности. Да, в управлении программами много внимания потребуют взаимозависимости проектов и поиск оптимального подхода к управлению ими – но это отнюдь не то же самое что взаимозависимости между работами и эффективность отдельных работ в рамках конкретного проекта.
Отличия между проектами и программами есть на лицо даже поверху (рис.1.2):
Рис. 1.2. Отличия между проектами и программами
И эти отличия обуславливают особенности управления проектами и программами. Для примера, возьмем программу организационных преобразований, в которой в рамках одного проекта получена экономия (допустим за счет уплощения организации и сокращения числа линейных менеджеров с одномоментным повышением ответственности исполнителей), а в рамках второго проекта нехватка ресурсов для полноценного функционирования нового оргэлемента. Каждый из менеджеров проектов будет мыслить только рамками своего проекта. Но менеджер программы, несомненно, примет решение, которое будет наилучшим для программы в целом: и возможно, часть сэкономленных ресурсов в первом проекте перебросит на второй, чтобы получить общие выгоды от программы.
В общем, как есть отличия между проектами и программами, так и есть отличия между управлением проектами и программами. Однозначно согласен только с тем, что для управления программами необходимо понимать управление частными проектами, чтобы адекватно взаимодействовать с менеджерами этих самых проектов.
И когда Вам будут говорить: «Нет разницы между управление одним и управлением несколькими связанными проектами» – вспоминайте Канта с его мыслью о том, что количество перерастает в качество. Пустыня и песочница тоже отличаются только объемами песка. Равно как отличаются только объемами H2O стакан воды и океан. Но с увеличением количества (песка или воды) приобретают совершенно иных качеств.
На этой ноте в завершение главы я сделаю акцент, что данная книга только об управлении проектами. Разбор особенностей управления программами в нее не входит, хотя по программам в ней немного пройдемся при рассмотрении конкретного примера.
Жизненный цикл проекта
Концепция жизненного цикла (продукта, услуги, фирмы, сотрудника, оборудования и рассматриваемого нами в книге проекта) – очень в принципе полезная штука в менеджменте, да и в любой дисциплине. Жизненный цикл подразумевает прохождение последовательных стадий или фаз.
Если брать аналогию из биологии, то это цикл от яйца до гусеницы и бабочки.
В проектном управлении жизненный цикл проекта – это набор фаз от инициации до завершения проекта. Т.е., это фазы, которые связывают начало проекта с его завершением.
В классике проектного менеджмента Вы увидите что-то такое (рис.1.3):
Рис.1.3. Классический жизненный цикл проекта
На самом деле это деление на практике условное – каждая организация может детализировать или укрупнять стадии на свое усмотрение. И для одного проекта их можно сделать 4, для другого понадобится четко выделить 6 или более.
Например, вот так классический 4-фазный жизненный цикл может стать 6-фазным или более (рис.1.4):
Рис.1.4. Преобразование 4-фазного жизненного цикла в 6-фазный
Вокруг стадий жизненного цикла очень удобно привязывать результаты (или работы, или документы или другие моменты) которые должны быть сделаны в проекте. Результаты Вы показываете заказчику, документы держите для себя, работы предоставляете в разные службы (закупки, исполнители) и т. д. Пример «привязки» документов к фазам на рис.1.5.
Рис.1.5. «Привязка» проектных документов к фазам
Если говорить о проектах преобразований, то настоятельно рекомендую запомнить две крупные их фазы:
1. Дизайна/проектирования
2. Внедрения.
При чем первая фаза более важна – именно она высоковариантивная и определяет максимальное качество проекта. Мы об этом в книге поговорим отдельно чуть позже.
Теперь, раз уж затронул вариативность, перейду к более сложной для новичков классификации жизненных циклов проектов (если не все уловите – не беда, я далее еще немного расскажу об этом в методологиях, а также разберу на практическом проекте).
Выше был описан самый что ни есть классический жизненный цикл. Но он является предиктивным (или Waterfall – Водопад – линейный, каскадный) – т.е. таким, при котором содержание, сроки, стоимость проекта и т. д. определяются на ранних фазах. Т.о., его краеугольный камень – тщательное планирование на ранних этапах с низким уровнем изменений требований по ходу проекта. А далее мы последовательно двигаемся по стадиям, внося при необходимости в проект изменения – и делаем поставку результата в конце.
Но есть еще один жизненный цикл, которым издавна пользуются практики (и в последней версии РМВоК его наконец-то удосужились канонизировать наравне с Waterfall) – это адаптивный жизненный цикл. Это тот самый модный Agile (гибкие методологии управления проектами).
Адаптивный жизненный цикл используется практиками уже давно (я сам с необходимостью его использования столкнулся еще в 2005 году, хотя никто из проектной команды ничего не слышал о Agile-методологиях как Scrum или Kanban). Но умело «вписывались» ими в предиктивный (последовательный) жизненный цикл ввиду его каноничности в проектном менеджменте.
Адаптивный жизненный цикл используется для проектов с высокой вариативностью и неопределенностью. Он может быть итеративным или инкрементным.
При итеративном Вы повторяете каждый этап до того момента, пока не получите требуемого результата. Да, при таком жизненном цикле каждый этап может повторяться такое количество раз, которое необходимо для достижения желаемого результата.
В итеративном подходе в отличии от предиктивного (waterfall) мы не делаем планирование вначале, а осуществляем планирование в течение всего проекта. Мы начинаем что-то делать – и если вдруг что-либо сделали не так или поменялась ситуация – мы приводим все в соответствие.
Принципиальное отличие и значение этого подхода от Waterfall в том, что мы:
· Во-первых, изначально закладываем возможность что-то переделать по итогам полученной обратной связи по ходу проекта (от клиента\заказчика, от Спонсора, от ситуации, от оценки хода проекта или полученного промежуточного результата и т.д.);