Трансформация: особенности управления проектами преобразований. МВА-библиотека

В классическом проектном менеджменте бюджеты могут покрыть все проблемы с ресурсами. Т.е., как говорят: «Если проблему можно решить за деньги, то это не проблема, а расходы». Вы можете купить производительный труд (например программистов для программы), можете купить дороже или дешевле любые материалы (например кирпич для постройки зданий).

Почему целесообразно выделять ресурсы отдельно? Есть ряд проектов: от опытно-исследовательских в прикладных инженерно-естественных науках до системообразующих в социально-экономических системах – и, в частности, к ним относятся трансформационные проекты / проекты преобразований. И вот тут появляется необходимость доступа к уникальным знаниям, компетенциям (часто даже на стыке дисциплин) и ресурсам, которые так просто не достать.

Вот в таких ограничениях в результате проекта и получается тот самый уникальный продукт, услуга, бизнес-функция, прототип, новые знания, компания… Так, каждый стартап по своей сути является проектом.

А управление проектом – это комплекс мер и методов, направленных на то, чтобы получить ожидаемый проектом результат.

Набор проектов, связанных между собой общим замыслом и нацеленных на единую большую цель, называют программой. Программа всегда состоит из нескольких проектов.

И есть большая разница, когда предприятие запускает отдельный трансформационный проект или целую программу преобразования/ трансформации.

Хочу развенчать один миф: многие менеджеры думают, что управление программами это почти то же, что управление несколькими проектами. И многие преподаватели, инструкторы и тренера поддерживают эту веру.

Но это не так. Вспомните фразу Канта о том, что количество перерастает в качество. Пустыня Сахара и детская песочница отличаются только объемами песка. Равно как стакан воды и океан объемами воды. Но по мере увеличения количества они приобретают совершенно иных качеств.

Тем не менее, в защиту схожести все говорят, что и там и там требуется держать фокус на взаимозависимости и оптимальности/ эффективности. Да, в управлении программами много внимания потребуют взаимозависимости проектов и поиск оптимального подхода к управлению ими – но это отнюдь не то же самое что взаимозависимости между работами и эффективность отдельных работ в рамках конкретного проекта.

Отличия между проектами и программами есть на лицо даже поверху (рис.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 в том, что мы:

· Во-первых, изначально закладываем возможность что-то переделать по итогам полученной обратной связи по ходу проекта (от клиента\заказчика, от Спонсора, от ситуации, от оценки хода проекта или полученного промежуточного результата и т.д.);

· Во-вторых, постоянно контролируем нет ли изменений и делаем при необходимости перепланировку проекта

При инкрементном подходе Вы разбиваете проект на набор результатов (инкрементов), которые необходимо получить в ходе проекта (возможно, потом еще и увязать друг с другом, так как порознь они могут являть «запчастями», а не собранным «автомобилем»).

Каждый инкремент Вы запускаете «по кругу» (анализ-проектирование-разработка-тестирование-…) и «допиливаете» так, пока не будет достигнут необходимый результат. Это как «кушать слона по кусочку».

Именно при инкрементном подходе зачастую сначала создается минимально жизнеспособный продукт (MVP), который по мере прохождения итераций доделывается до целевого.

Глобально можно сказать, что если итеративный подход фокусируется на разработке целевого продукта путем выполнения ряда повторяющихся циклов, то инкрементный подход фокусируется на последовательном наращивании функциональности итогового продукта (вплоть до сборки из запчастей).

Сразу скажу, что деление на итеративный и инкрементный подходы теоретически-условное – на практике они оба используются одномоментно, потому в среде практиков можно просто говорить об адаптивном жизненном цикле как таковом.

Проектная документация

Проектная документация – это вещь, которая более всего заботит умы проектных менеджеров, работающих внутри компании. Многие пытаются найти «правильные шаблоны» документов – но их в природе не существует.

Даже тот же РМВoК описывает требования и содержание документов, но не дает шаблонов.

Каждая организация имеет свои стандарты и требования. Если их нет – то менеджер проекта волен руководствоваться здоровой логикой и целесообразностью документации. Вообще задайте в поисковике «шаблоны проектных документов» – и выбирайте в свободном доступе любой формат и варианты. Но Вы все равно будете адаптировать их под себя, организацию или проект.

Много книг по проектному менеджменту предлагают наборы шаблонов проектной документации (некоторые только из этих шаблонов и состоят). Я по ходу в книге также продемонстрирую внешний вид ряда документов для конкретного проекта. Но не буду выдавать списочный набор готовых шаблонов. Предпочтительнее, когда Вы уловите суть документа и сможете создать его под конкретный проект, а не «потирая руки» заполнить типовые бумаги как бухгалтер или кадровик.