Запуск проекта: устав, содержание и заинтересованные стороны

Устав: откуда берутся полномочия

Устав отвечает, зачем проект нужен компании, кто спонсор, где проходят границы проекта и какими полномочиями обладает руководитель. Одного-двух листов достаточно: объём здесь ничего не решает, решает подпись спонсора.

Этим содержимое устава не исчерпывается. Запишите измеримые критерии успеха — по ним потом будут судить, удался проект или нет. Перечислите допущения, на которых построен план, и ограничения, которые изменить нельзя: срок по договору, выделенный бюджет, доступный состав команды. Укрупнённый бюджет и ключевые вехи тоже относятся к уставу, хотя детализировать их на этом шаге не нужно.

Допущения важнее, чем кажется: каждое из них — заготовка риска. Запись «считаем, что смежная система будет готова к марту» становится строкой реестра рисков ровно в тот момент, когда её сделали, поэтому пройдите по списку допущений сразу после подписания устава.

Без устава руководитель проекта управляет только уговорами. Когда потребуется вывести человека из проекта, изменить приоритет или отказать смежному отделу, окажется, что формального основания нет, а есть только договорённость, о которой все помнят по-разному.

Самый важный и самый пропускаемый пункт — границы полномочий: до какой суммы руководитель принимает решения сам, какие изменения проводит без согласования, кого может привлекать. Формулировка «руководитель проекта управляет проектом» полномочий не даёт.

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

Спонсор: что он обязан делать

Спонсор — не почётная роль и не тот, кто подписал устав и ушёл. Он обеспечивает проекту финансирование, разрешает конфликты приоритетов с линейными руководителями, принимает решения по изменениям, которые выходят за полномочия руководителя проекта, и распоряжается управленческим резервом. Без этого проект встаёт.

Практический признак работающего спонсора — регулярная встреча раз в две-четыре недели, на которую он приходит и на которой принимает решения. Если встречи переносятся третий раз подряд, у проекта фактически нет спонсора, каким бы ни было содержание устава.

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

Содержание: что входит и что не входит

Содержание описывает результат проекта и работы по его получению. Практически всегда его пишут в одну сторону — перечисляют, что делается. Раздел «что не входит» пишут редко, и именно он снимает большую часть споров на приёмке.

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

Второй элемент — критерии приёмки, сформулированные так, что по ним можно принять однозначное решение. «Система работает корректно» приёмке не подлежит; «сценарии из перечня выполняются, время отклика не превышает N секунд, передан комплект документации по списку» — подлежит.

Заинтересованные стороны: кто и чего хочет

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

Чаще всего забывают тех, кто не заказывает проект, но кого он затрагивает: смежные подразделения, чьи процессы изменятся, служба поддержки, которой достанется результат, безопасность и юристы, чьё согласование потребуется. Их требования всплывают поздно и стоят дорого именно потому, что о них не спросили вовремя.

Полезно сразу договориться о форме взаимодействия: кто получает отчёт и в каком виде, кто участвует в приёмке, кто согласовывает изменения. Приоритет расставляйте по двум осям: сколько у стороны влияния на проект и насколько ей самой интересен результат. Отдельного внимания требует квадрант «влияние высокое, интерес низкий» — такие люди не ходят на статусы и появляются на приёмке с новыми требованиями.

Матрица ответственности: кто должен был

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

У каждого блока ровно один отвечающий: два ответственных означают ноль. Отвечающим назначают того, кто принимает результат блока; должность здесь роли не играет, и начальник отдела попадает в эту клетку далеко не всегда.

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

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

Не расписывайте матрицу до отдельных задач. Достаточно уровня блоков работ и ключевых решений: приёмка, согласование изменений, взаимодействие с заказчиком, эксплуатация после сдачи.

Совещание по запуску

Запуск проекта завершается общей встречей с командой, спонсором и ключевыми заинтересованными сторонами. Её задача — добиться, чтобы цель, границы и роли все понимали одинаково; пересказ плана сам по себе этого не даёт.

Практичный формат: спонсор объясняет, зачем компании этот проект и что будет считаться успехом; руководитель проекта показывает содержание, исключения и вехи; отдельно проговаривают процедуру изменений и порядок отчётности. Вопросы участников на этой встрече — самый дешёвый способ найти несогласованность.

Если после совещания у команды остаётся ощущение «непонятно, зачем мы это делаем», проект стартовал с проблемой, которая проявится на первом же конфликте приоритетов.

Документы запуска и что ломается без каждого

Чек-лист готовности к старту

Всё это стоит недорого на старте и дорого — на приёмке. Список короткий, а закрывает он большую часть будущих споров о том, кто что имел в виду.

Как собрать проект в Shtab

Устав и содержание лежат страницами внутри проекта и не теряются при смене состава команды: искать их в переписке не приходится.

Частые вопросы