Устав проекта: договариваться о правилах
Попадая в проект любому человеку нужно разобраться, а в чем же смысл и цель проекта? С какими вызовами приходится сталкиваться команде проекта для достижения намеченных конечных результатов? Как новому PM принять проект и сделать это максимально быстро?
Ответы на эти вопросы может дать устав проекта. Любой проект должен обладать уставом - сводом правил, по которым реализуется проект. Именно по этим правилам в конечном итоге будут оценивать руководителя проектов.
Без устава проекта тяжело направлять работы проекта в нужное русло. Не важно какой используется жизненный цикл - все равно без правил не возможно попасть в главные ожидания главных заказчиков. А это неминуемо приведет к конфликтам и раздражению.
Определение
Устав проекта - это документ, выпущенный инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в целях операций проекта.
Состав устава проекта
Устав - это 3-5 страничный документ, который пишет руководитель проекта, а подписывает спонсор. Очень важно, чтобы спонсор или инициатор проекта (может быть группа лиц) видели и согласились с содержанием устава.
Название
Любой устав должен начинаться с названия. Название должно быть такое, чтобы и команда проекта, пользователи и все заинтересованные стороны должны сразу понимать о чем идет речь.
Цель проекта
Устав должен содержать конечную цель того, что хочется достичь в результате поставки конечных результатов. Для формирования целей проекта можно использовать различные инструменты, такие как SMART постановка целей, но делать. Но делать этого вполне не обязательно. Достаточно понятно донести мысль, зачем нужен проект.
Конечность проекта
Устав обязан содержать информацию о конечности проекта - ограничениях по срокам, стоимости и содержанию работ.
В составлении устава главные помощники PM:
Сроки в уставе проекта указываются в виде дедлайнов. Точность оценок +50%, если фаза инициации - короткая. Если для проекта характерен риск невозвратных потерь, то в этом случае устав создается продолжительное время, но и точность оценок повышается в разы.
Если проект содержит фазы/вехи, то такие даты ("вороты фаз" или майлстоны) должны быть указаны в уставе.
Если на проект выделен бюджет, то он должен быть указан в уставе. При этом, если ритм получения материальных средств, то этот ритм обязательно должен быть явно прописан в документе.
Требуемые нематериальные ресурсы (оборудование, инструменты, техника, подписки) также должны быть указаны в уставе. В случае, если нематериальные ресурсы нужны согласно какому-то графику, то этот график также должен быть указа в документе.
Человеческие ресурсы указываются в уставе в виде требуемых ролей и команд, которые нужны для реализации проекта. Например, для реализации проекта может потребоваться команда, состоящая из архитектора, трех старших разработчиков, пяти middl разработчиков, двух DevOps-инженеров, системного аналитика, продуктового менеджера и четырех инженеров по тестированию.
Если на проекте важно наличие узкого специалиста, эксперта в предметной области, то в этом случае такой специалист указывается явно. Например, Петров Петр Петрович - эксперт в области управления базами данных.
Самый большой раздел в уставе - это содержание работ. Обычно это несколько абзацев текста с описанием того, что же в конечном итоге требуется сделать.
Важно отметить, что содержание в уставе - это не детальные требования, а это именно некоторое видение конечного результата, который необходимо достичь. Например, для сервиса, который осуществляет обслуживание и поддержку пользователей, описание может быть следующим:
Веб-сервис для обслуживания конечного продукта X и поддержки пользователей, выполняющий следующие функции:
- Периодическое резервирование пользовательских данных;
- Мониторинг состояния продукта Х;
- Позволяющий выполнять произвольные операции обслуживания на конечных ресурсах продукта Х;
- Позволяющий выполнять операции обновления ресурсов продукта Х;
Дополнительные разделы устава проекта
В уставе можно перечислить главных заинтересованных лиц. Минимально указывается спонсор и проектный руководитель.
Если в проекте меняется PM или спонсор, то проект "перезапускается", а устав - переписывается и согласуется заново.
Заказчика в устав включают, но сам устав ему не показывают. Причины в том, что в уставе указываются реальные бюджеты и цели. Эти бюджеты и цели могут отличаться как в большую, так и в меньшую сторону по сравнению с контрактом (если есть).
Устав может содержать терминирующие риски - это те, которые если срабатывают, то если срабатывают, то хоронят проект. Данные риски являются неснижаемыми.
Поставки проекта включаются в устав, если они должны быть. В случае наличия поставок, то должны быть акты приёмо-передачи из которых понятно что и когда должны поставить.
Ключевые показатели эффективности
Показатели если есть, то включаются в устав. Должны быть выражены численно.
Неизменность устава
Главным свойством устава является его неизменность в течение жизни проекта. Желательно, чтобы устав был в печатном виде, и его точно видел спонсор или инициатор проекта. Если меняется устав, то такой проект перезапускается.
Изменение устава проекта - это означает, что проект провален!
При закрытии проекта - сравнивают конечный результат с тем, что написано в уставе. Таким образом можно сделать вывод о качестве руководителя проектов. Поэтому, написание устава - это главный первый шаг в управлении проектами.