Мы приходим к Заказчику и говорим ему: вот так мы будем планировать проект, вот так будем управлять изменениями, вот так будем управлять рисками, вот так будем проводить совещания, вот так будем эскалировать проблемы и принимать решения, вот такие сроки будут у нас на согласование, вот такая периодичность будет статусных совещаний и т.д. И приносим ему это в виде объемного документа этак страниц на 30-50 регламентирующего текста. Заказчик смотрит на это «широко закрытыми глазами» и говорит: «Круто!». То, что не соотносится с практикой, принятой у Заказчика, он предложит исправить, но в остальном документ будет принят.

А дальше началась жизнь и процессы прошли своим путем, принятия решений своим путем, а документ остался на полке. Иногда РП достает его чтобы показать, что Заказчик не соблюдает установленные сроки, либо нарушает другие договоренности. Но это делается, когда на проекте нарастает напряжение и сторонам нужно защищаться. Есть ситуации, когда РП пытается актуализировать процессы, но часто на него смотрят «косо» как на бюрократа, который вместо результата занимается «бумажками».

В итоге такой документ выполняет функцию защиты РП-ника или Подрядчика, либо маркетинговую функцию для Подрядчика: «Круто! Вы работаете по проектной технологии!». А хотелось бы, чтобы документ работал.

Во-первых, давайте разберемся с понятиями. В отрасли ИТ-проектов, я часто наблюдаю как два документа Устав и План управления проектом объединяют в один документ, называя его «Устав проекта». Наверное, в этом нет ничего страшного, особенно когда этот «Устав», созданный в начале проекта, больше не используют при выполнении проекта. Но если надо получить работающие документы, то надо обратиться к истокам.

Согласно PMBoK: «Устав проекта — это документ, выпускаемый инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Он документирует бизнес-потребности, допущения, ограничения, понимание потребностей заказчика, высокоуровневые требования, а также новый продукт, услугу или результат, который планируется создать.» «План управления проектом — это документ, описывающий, как проект будет исполняться, как будет происходить его мониторинг и контроль. Он интегрирует и консолидирует все вспомогательные и базовые планы, полученные в результате процессов планирования.»

Итак, Устав проекта более статичен, чем План управления проектом. Он определяет суть самого проекта, он есть распоряжение от Заказчика (или Спонсора) к Руководителю проекта (далее «РП»): необходимо сделать проект вот в таких определенных рамках. Если необходимо изменить зафиксированное в Уставе, значит для РП или Исполнителя это повод к пересмотру договорных отношений с Заказчиком. Соответственно этот документ делает Заказчик или Спонсор, а не РП или Исполнитель. Это важно! Не будем акцентировать внимание на том, что План управления проектом — это не план-график, как некоторые его воспринимают. Тут, наверное, сказывается история использования слова «план» в русском языке. План управления проектом говорит о том, как РП и команда проекта будут исполнять и контролировать этот проект, чтобы добиться результатов в границах и параметрах, описанных в Уставе. Этот документ более динамичен, он изменчив по ходу проекта, так как сразу определить все процессы не удастся.

Проект — это уникальное предприятие, а соответственно он имеет уникальный набор процессов. Можно в начале проекта предположить, спланировать одни варианты процессов, но походу проекта будут выявляться нюансы корректирующие их и это нормально. Как говорил Дуайт Эйзенхауэр: «План — ничто, планирование – все. Любой план устаревает в тот момент, когда вы завершили его разработку. Но в процессе планирования вы и ваши подчиненные приобретаете один взгляд на ситуацию и критерии принятия решения, следовательно, в момент неожиданности они выберут правильное решение». Поэтому на схеме процессов PMBoK План управления проектом является выходом нескольких различных процессов, чего не происходит с Уставом проекта. Таким образом, первая причина разнесения этих двух документов — их различное назначение. Вторая причина — динамика их изменений. Если вы управляете изменения, то поймете важность этой причины. Есть еще третья причина. В момент инициации проекта невозможно достаточно точно определить то как будет исполняться проект. После назначения (с помощью Устава) РП надо сформировать команду, определить подрядчиков, выстроить орг структуру проекта, декомпозировать содержание, продумать эффективные процессы. На это могут уходить иногда месяцы. Поэтому План управления проектом рождается позже Устава.

После того как разобрались с понятиями, поговорим почему не работают Планы управления проектами, которые многие называют «Уставами». Я много видел таких «Уставов», которые создавались в начале проекта, некоторые были очень объемными, были даже красивые, с четким содержанием, описанием процессов, но большинство процессов на проекте так и не выполнялись. И это не значило что на проекте все плохо! Просто фактические процессы на проекте не соответствовали формализованным в документе. Я не сторонник этого расхождения, но проекты ведь идут и результаты на таких проектах получаются.

Почему так происходит?

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

Существует несколько стандартов, описывающих модели зрелости проектного управления.

Самые известные из них это:

• P3M3 — Portfolio, Programme and Project Management Maturity Model — Модель зрелости управления портфелями, программами и проектами;
• OPM3 — Organizational Project Management Maturity Model — Модель зрелости организационного управления проектами.

Ознакомьтесь, например, с таблицей «Система измерения уровня зрелости управления» в Википедии, там представлены типовые уровни зрелости и их признаки.

Мы видим, что только на 2 уровне "«Управляемый» («Повторяемый»)" появляется проектный подход в начальном виде. Поэтому если вы хотите чтобы ваши действия на бумаге соответствовали вашим реальным действиям на проекте, оцените уровень зрелости проектного управления Заказчика, перед тем как составлять План управления проектом. Мои рекомендации при этом следующие:

1. Для уровня 0 «Отсутствующий». Нет смысла делать План управления проектом, его никто не будет выполнять. Сделайте Устав, занесите в него основные параметры проекта: Спонсор, Заказчик, РП, цели, задачи, критерии успешности, основные этапы и их результаты, состав рабочей группы. Если вы Подрядчик, то отразите это прямо в договоре или приложении.
2. Для уровня 1 «Начальный». Кроме Устава, у вас появятся зачатки Плана управления проектом: можно прописать Организационную структуру проекта, правила документооборота на проекте со сроками согласования документов.
3. Для уровня 2 «Управляемый» («Повторяемый»). Скорей всего у Заказчика есть уже некий пример регламентирующего документа, который он применял на других проектах. Желательно понять насколько он выполняется на этих других проектах. Можно посетить их и проанализировать. Удалите сразу, что не выполняется и возьмите этот документ за основу. Но точно нет смысла на этом уровне описывать процессы управления рисками, управления коммуникациями, управления содержанием.
4. Для Уровня 3 «Определяемый» («Стандартизуемый»). Скорей всего у Заказчика есть уже некий формат Плана управления проектом. Также желательно понять насколько он выполняется на примере других проектов. Но точно нет смысла на этом уровне описывать процессы управления рисками.
5. Для Уровня 4 «Измеряемый» и 5 «Оптимизируемый». На этом уровне зрелости у Заказчика в принципе есть все процессы для полноценного управления проектами и их рисками. План управления проектом будет полным. Сотрудники уже работают в соответствии с прописанными процессами и наработали необходимые навыки.

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