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

Автор книги: Никита Сергеев

Раздел: О бизнесе популярно, Бизнес-книги

Что такое проект (а заодно программа) и управление ими

В отличие от операционной деятельности, которая носит постоянный характер, проекты представляют собой некие временные предприятия.

Проект – это временное (т.е., имеющее начало и осязаемое окончание) предприятие, направленное на создание уникального продукта, услуги или результата.

Классически проект для объяснения представляют в виде «проектного треугольника», но для понимания полноты проекта (в т.ч. с учетом особенностей проектов преобразований) я использую представление в виде квадрата. Уникальный результат в ограничении ресурсами (люди и материалы), временем, качеством и бюджетами (рис.1.1).

Рис. 1.1. Традиционное и расширенное представление проекта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее в нескольких последующих пунктах прицельно пройдемся по каждому из этих документов.

Устав проекта – это документ, который обычно готовит руководитель проекта после получения вводных о проекте. Это будет Вашей Альфа и Омегой весь проект. Это то, о чем Вы договариваетесь «на берегу».

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

В уставе обычно включаются (рис.1.6)

Рис.1.6. Составные части Устава Проекта

· Предпосылки (бэкграунд, исходная ситуация, проблематика, которая привела к инициации проекта)

· Цели проекта

· Описание результата проекта – то, что должно получиться в итоге на выходе.

· Скоуп (масштаб и границы) проекта – не только то, на что он распространяется, а и что в проект не входит. Например, Вы разворачиваете CRM систему – покрывающую все подразделения продаж, кроме розничной сети компании. И вот это (что в проект не входит) надо обязательно указать! Надо указывать вообще все что не входит в проект (особенно то, что кому-то из числа власть имущих в организации вдруг может показаться частью проекта). Но об этом мы еще отдельно будем говорить.

· Ключевые требования и метрики (если такие есть), по которым будут приниматься результаты проекта

· Любые предположения, ограничения и риски. Тут остановлюсь поподробнее, потому что из моего опыта даже опытные менеджеры проектов опускают эти моменты (рис. 1.7).

Рис.1.7. Предположения, ограничения и риски

С ограничениями обычно всем понятно – это данность в организации или ее внешней среде, с которой нужно смириться, так как за время существования проекта она не изменится (например, есть законодательный акт, который требует согласование поставки такого оборудования с 3 госслужбами каждая из которых рассматривает их не менее чем 1 месяц; или на рынке нет локальных поставщиков необходимых услуг). Ограничения напрямую закладываются в план управления проектом.

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

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

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

Или заказчик гарантирует, что «у этого проекта вообще не будет никаких бюрократических преград внутри компании: сказали или е-мейл написали – и тут же получили», а потом оказывается, что «любой чих» – это действительно отсутствие преград кроме 100500 служебок.

В одном проекте я вообще основные предположения (ибо очень сладко мне «продавали» тот проект – вплоть до того, как госструктура все будет даже закупаться без тендеров) после первого общения (даже не готовя еще устава) выписал в табличку. Две колонки: в первой предположение, в соседней колонке – что будет если предположение ложное (тут затянутся сроки проекта, тут не будет вообще сделан функционал и т. д.). Так «прыти» у заказчиков сразу быстро поубавилось, посговорчивей стали и попрактичнее в части сроков, цены проекта, оплаты для команды и т.д..

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

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

И вообще вопрос детализации устава очень часто возникает ку слушателей: нет стандартов к объему устава, зависит от проекта и компании, от длительности и прошлого опыта сотрудничества с организацией…

Устав вообще может выглядеть брифом на 1 страничку (рис.1.8).

Рис.1.8. Устав в виде 1-страничного брифа в Excel

Но в любом случае Вы должны ощущать достаточность детализации для управления.

Задача этого документа – более детально описать что входит в проект и из чего он состоит. Это расширение устава проекта в части его объема и границ (не забываем, что явно не входит в проект также необходимо учесть), работ и промежуточных результатов. В общем все то, что необходимо сделать, чтобы достичь целей/получить результат проекта.

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

На самом деле в реальности у Вас никогда не получится сделать идеальное содержание с первого раза – оно будет потом уточняться и дополняться (даже видоизменяться) по ходу проекта.

В содержании обычно находится 3 детализированных пункта устава проекта (рис.1.9):

· Описание ожидаемых результатов

· Критерии приемки (требования и метрики), по которым будут принимать результаты проекта

· Границы проекта – и что входит, и обязательно что точно ни при каких раскладах в проект не входит. Второе даже важнее чем первое.

Рис.1.9. Фокус Содержания проекта

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

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

Более того, если Вы опишите детальное содержание – Вам будет не только проще достичь результата (ибо он станет понятнее). Плюс Вы сразу из него получите перечень работ для подготовки плана проекта, как указано на рис.1.9.

Вроде простая штука (ну кто же не сталкивался с календарным планом или не видел диаграмму Ганта даже не будучи менеджером проекта?), но пару слов о нем скажу.

План проекта – это главный документ, по которому Вы будете управлять проектом и вокруг которого будете применять различные методы для «разруливания» его отклонений.

Не имея детального содержания проекта, о котором я говорил в предыдущем пункте, Вам будет тяжело его составить реалистичным.

В плане все работы выписываются и связываются между собой так, чтобы было понятна (рис.1.10):

а) Их последовательность (что может делать параллельно/ одновременно, а что только после завершения какой-то работы или нескольких работ)

б) Необходимые ресурсы (навыки/компетенции (неважно сотрудников организации или внешних поставщиков), материалы, оборудование, деньги…)

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

Рис.1.10. Содержимое качественного Плана проекта

Если это все было сделано в специализированном ПО (например, MS Project или Primavera), то уже задав начало проекта – Вы получите сразу и календарный план с датами, и план финансирования/стоимости проекта, и ресурсы и т. д.

Но отмечу, что проект преобразований необходимо планировать не только от даты начала, а и обратно – от даты конца. Пока и так, и так не сойдется.

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

Еще учитывайте, что будь Вы даже трижды опытным менеджером проекта, у Вас никогда не получится сделать план проекта с первого и даже со второго раза. Скорее всего понадобится 3—5 итераций. Даже если проект условно типовой, но просто внедряется в другой организации – планы будут отличаться и надо будет учесть ряд ограничений и особенностей новой организации. А это потребует нескольких итераций.