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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Персонально для меня в любом крупном трансформационном проекте всегда есть еще один требующий внимания документ – бизнес-кейс.

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

Почему-то внутри компаний принято на все крупные инвестиционные проекты (даже простые по своей природе, например, когда 99% огромного бюджета составляют материалы и стандартное оборудование) готовить и рьяно обсуждать бизнес-кейсы. А на порядок сложнее проекты, но не выражающиеся прямо в денежных величинах – никто «не заморачивается»…

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

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

Несомненно, для инициации проекта бизнес-кейс, конечно, штука незаменимая, а вроде как для управления проектом уже и не нужна….

С коллегами по цеху (консультантами) мы иногда горячо дискутируем о необходимости этого документа для управления проектом. Основная масса коллег воздерживается от комментариев, а некоторые говорят, что он не нужен, ибо это проблема заказчика: «Он же заказывает, значит у него бизнес-кейс сходится, он проект утвердил. А нам только сделать надо». Да и во многих компаниях бизнес-кейсы (особенно на проекты преобразований) не готовятся в принципе.