Трансформация: особенности управления проектами преобразований. МВА-библиотека
- -
- 100%
- +
Но это не так. Вспомните фразу Канта о том, что количество перерастает в качество. Пустыня Сахара и детская песочница отличаются только объемами песка. Равно как стакан воды и океан объемами воды. Но по мере увеличения количества они приобретают совершенно иных качеств.
Тем не менее, в защиту схожести все говорят, что и там и там требуется держать фокус на взаимозависимости и оптимальности/ эффективности. Да, в управлении программами много внимания потребуют взаимозависимости проектов и поиск оптимального подхода к управлению ими – но это отнюдь не то же самое что взаимозависимости между работами и эффективность отдельных работ в рамках конкретного проекта.
Отличия между проектами и программами есть на лицо даже поверху (рис.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 итераций. Даже если проект условно типовой, но просто внедряется в другой организации – планы будут отличаться и надо будет учесть ряд ограничений и особенностей новой организации. А это потребует нескольких итераций.
(Не) проектная документация: бизнес-кейс
Персонально для меня в любом крупном трансформационном проекте всегда есть еще один требующий внимания документ – бизнес-кейс.
Причем в нем не обязательно (да и не всегда) отражаются только инвестиционно-финансово-экономические показатели, сколько и другие вещи. Например, управление более укрупненным бюджетом, ускорение процессов, снижение числа взаимосвязей между элементами системы, улучшение репутации, узнаваемость, соответствие современным стандартам или рыночным практикам, повышение мотивации и лояльности сотрудников, стратегические выгоды и т. д.
Почему-то внутри компаний принято на все крупные инвестиционные проекты (даже простые по своей природе, например, когда 99% огромного бюджета составляют материалы и стандартное оборудование) готовить и рьяно обсуждать бизнес-кейсы. А на порядок сложнее проекты, но не выражающиеся прямо в денежных величинах – никто «не заморачивается»…
В части именно трансформационных проектов (проектов преобразований) бизнес-кейс освещает проблематику и причины, по которым запускается проект. И в них часто речь не просто о некой сумме денег – речь о более фундаментальных вещах, связанных с эффективностью организации и бизнеса.
Именно в бизнес-кейсе содержатся бизнес-потребности и выгоды от проекта, прослеживается его окружение и следуемые из него ограничения. Ведь бизнес-кейс – это то, что создается или под требования рынка (клиенты, конкуренты), или организации, или технологический прогресс, или требования госрегулятора…
Несомненно, для инициации проекта бизнес-кейс, конечно, штука незаменимая, а вроде как для управления проектом уже и не нужна….
С коллегами по цеху (консультантами) мы иногда горячо дискутируем о необходимости этого документа для управления проектом. Основная масса коллег воздерживается от комментариев, а некоторые говорят, что он не нужен, ибо это проблема заказчика: «Он же заказывает, значит у него бизнес-кейс сходится, он проект утвердил. А нам только сделать надо». Да и во многих компаниях бизнес-кейсы (особенно на проекты преобразований) не готовятся в принципе.
Но с моей точки зрения для консультанта погружение в бизнес-кейс по потенциальному проекту часто имеет кроме упрощения управления проектом еще и очень прикладную (читай денежную) выгоду.
В одном проекте я сам когда-то нарисовал бизнес-кейс для компании, чтобы продать необходимость интересного мне проекта. Меня же провайдером выбрали. Сам же потом проектом управлял.
Однозначно, конечно, делать бизнес-кейс точно не обязанность менеджера проекта. Менеджер проекта – это тот, кто «исполняет» пожелание заказчика. Но считаю, что его надо иметь. Если у заказчика бизнес-кейса нет (такое очень часто бывает) – то менеджеру проекта стоит сделать хотя бы наброски бизнес-кейса что называется «на пальцах» для себя и проектной команды на основании беседы с заказчиком и спонсором проекта.
Интересный документ, о котором стоит знать…
Последняя версия РМВоК в сравнении с предыдущими намного больше внимания уделила бизнес-вопросам проектного управления (предыдущие более технически и процессно-ориентированы).
И помимо отдельного прицельного фокуса на бизнес-кейсе в РМВоК ввели понятие нового документа – «ПЛАН УПРАВЛЕНИЯ ВЫГОДАМИ ПРОЕКТА».
Аргументация необходимости этого документа в том, что после завершения проекта возникают ситуации, когда полученные результаты не используются или используются не так, как задумано. Соответственно компания не имеет выгод, ради достижения которых запустили и реализовали проект. При этом высшее руководство не знает об этом, т.к. после завершения проекта бывает о истинном назначении результатов все забывают, в том числе и Спонсор, и Заказчик. А бывает забывают (или видоизменяют) специально…
Как с этим явлением борются из того, что я встречал на практике. Здесь мне нравится метод и подход некоторых системных консалтинговых компаний в Москве (правда в основном их просят клиенты-заказчики уровня набсоветов или акционеры – от них «ноги растут»). Они предлагают в качестве услуги не только дизайн проекта, а и периодические аудиты внедрения и использования результатов проекта (Внедрили ли то, что согласовали или по ходу внедрения «нагенерировали отсебятину»? Используются\функционируют ли результаты проекта как предписано проектом?).