Документирование проекта на старте

Запуская новые проекты, мы часто задаёмся вопросом – С чего начать? На самом деле всё просто. Существует отличное правило: «Хочешь разобраться со своими мыслями – впиши их в бумагу». Так и с проектами, хочешь запустить новый проект – начни выражать свои идеи о проекте буквенно-цифровым и графическим способом, на бумаге, на компьютере – не важно!
Чтобы понять последовательность записи этих мыслей «на бумаге», нужно понимать технологию зарождения проекта. Всё начинается с замысла. Замысел может быть выражен на бумаге или не выражен, но его главное отличие от идеи в том, что им можно делиться. Замысел – это идея, одинаково понимаемая всеми участниками проекта. В замысле мы должны чётко сформулировать проблематику, вызвавшую проект, и задачу которую предстоит решить. Проверить грамотность формулировки замысла можно вопросом «Что и для чего мы делаем?», и если участники проекта однозначно на него отвечают, то первый этап пройдён – у нас есть ЗАМЫСЕЛ.

На основе замысла формируются цели проекта. Главная характеристика целей – они должны быть измеримыми. Невозможно достичь того, что нельзя измерить! Поэтому формулируя каждую цель, нужно спрашивать себя «Чем мерять буду?» и если формулировка цели даёт ответ на этот вопрос, то у тебя есть ЦЕЛИ. Хотя, конечно, измеримость цели – это не единственная её характеристика. В идеале нужно иметь SMART-цели. «SMART» (от английского «толковый; умный») – это аббревиатура слов Specific (конкретный; объясняется, что именно необходимо достигнуть), Measurable (измеримый; объясняется, чем будет измеряться результат), Attainable (достижимый; объясняется, за счёт чего планируется достигнуть цели), Relevant (значимый; определение, действительно ли выполнение данной задачи позволит достичь желаемой цели?) и Time-bound (ограниченный во времени; определение временного промежутка по наступлению которого должна быть достигнута цель). Если потрудиться и описать цели в таком контектсте, то всем участникам будет однозначно понятно что, когда и зачем будет появляться в результате проекта.
Ну, а следующим этапом будет определение средств реализации и описание решений, т.е. определение того, с помощью чего и как будем достигать описанные цели и реализовывать проект.

Устав проекта

В каком документе всё это отобразить? Практически все методологии и стандарты управления проектами определяют, в качестве первого документа, Устав проекта. Но здесь есть одна зарытая собака! Дело в том, что тот Устав, который описан, например, в PMBOK, нормально работает только в достаточно зрелых системах управления проектами. А попытки натянуть этот Устав на менее зрелые подходы приводит к тому, что документ становится бессмысленной бумажкой, филькиной грамотой, которая отнимает драгоценное время на заполнение и оформление, но не несёт никакой практической ценности.
Для создания действующих Уставов нужно понимать суть данного документа и смысл его использования в проектах. Что говорит нам PMBOK об Уставе проекта? Это «документ, выпущенный инициатором или спонсором проекта, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта». Вчитайся и вдумайся в каждое слово! «Документ, выпущенный инициатором или спонсором проекта» - это некая бумага, изданная людьми, имеющими власть для запуска проекта и имеющими ресурсы для обеспечения проекта, т.е. ТОПами, первыми лицами компании. «Формально авторизует существование проекта» - т.е. как минимум подписью, а может ещё и печатью, узаконивает существование самого проекта, да ещё и определяет источник этого узаконивания. «Предоставляет руководителю проекта полномочия использовать ресурсы» - т.е. передаёт руководителю проекта "кусочек" власти над ресурсами компании. Да, да! Именно часть власти первых лиц организации должна быть передана руководителю проекта, чтоб от мог нормально выполнять проект.
Итак, если процессы управления проектами в компании только зарождаются, достаточно будет некого письменного Приказа о начале проекта, изданного первым лицом организации. В этом Приказе указать, какие цели нужно достичь, и кто имеет полномочия и ответственность по их достижению. Если система достаточно зрелая, то, не мудрствуя лукаво, берём Устав описанный в PMBOK или в ISO21500 и заполняем следующие разделы:

1. Назначение или обоснование проекта, т.е. для чего и зачем инициируется данный проект. Проект запускается если есть: потребность рынка; производственная необходимость; потребность заказчика; технический прогресс; юридические ограничения или нормы; общественная потребность; или подобное. Эти пункты можно назвать проблемами, благоприятными возможностями или требованиями бизнеса. Главная идея заключается в том, что руководство должно решать, какой должна быть ответная реакция компании и какие проекты следует авторизовать, зафиксировав их в Уставах.
2. Измеримые цели проекта и соответствующие критерии успеха. Как уже упоминалось выше, это как раз тот раздел, в котором описывается, как и чем будем измерять результаты проекта. Критериями оценки могут быть стандарты, правила или тесты, на которых может основываться решение или суждение, или с помощью которых можно оценить продукт, услугу, результат или процесс. Также в данном разделе указывается, что составляет успех проекта, кто решает, что проект оказался успешным, и его критерии приёмки результатов проекта.
3. Высокоуровневые требования, удовлетворяющие потребности, пожелания и ожидания Заказчика, Спонсора и других участников проекта. На что должны быть направлены работы; какую стратегическая позиция следует занять; какую задачу следует решить; какой результат нужно достичь; какой требуется произвести продукт; или какую услугу необходимо оказать. Здесь нужно обратить внимание, что в Уставе проекта указываются только высокоуровневые требования. Полный перечень требований должен быть отображён в специальном документе по требованиям, например, в Матрице отслеживания требований.
4. Допущения, ограничения и исключения проекта, способные оказать воздействие на реализацию проекта. Допущения – это факторы, которые для целей планирования считаются верными, реальными или определёнными без предоставления доказательств или демонстрации. Ограничения – это сдерживающие факторы, влияющих на ход исполнения проекта, программы, портфеля или процесса. Исключения – это пакеты работ, которые в данном проекте выполняться точно не будут, чтоб не раздувать объёмы работ проекта. Следует обратить внимание, что в Уставе проекта указываются только высокоуровневые допущения, ограничения и исключения. Полный перечень должен быть представлен в Описании содержания проекта во время планирования содержания.
5. Высокоуровневые риски, где указывается насколько компания готова рисковать (т.е. уровни толерантности Спонсора и Заказчика проекта к рискам); что или кто может помешать реализации проекта; как это повлияет на сроки, бюджет, качество и объёмы работ проекта; а также даётся краткое описание, каким образом будет осуществляться управление рисками проекта. Также как и с прошлыми двумя пунктами, полный перечень рисков должен быть отображён в специальном документе Реестре рисков (на этапе планирования рисков).
6. Сводное расписание контрольных событий (вех), как правило задаваемое контрактом или другими требованиями указывающими, в какие именно сроки должны произойти те или иные вехи проекта, и кто ответственен за их происхождение. Здесь тоже указываются только высокоуровневые вехи. Полный перечень вех должен быть отображён в Графике проекта. Для самопроверки, отвечают ли вехи, описанные в данном разделе, требованиям высокоуровневости разделов Устава, можно задать себе три простых вопроса, на которые должен быть получен положительный ответ:
   • Это действительно важные моменты или события проекта?
   • Имеется необходимое и достаточное количество вех, чтобы контролировать последовательный (т.е. без авралов и длительных простоев) ход проекта?
   • Известно кто и когда должен достичь вехи?
7. Сводный бюджет, указывающий во сколько обойдётся проект и сколько денег спонсор проекта готов предоставлять ежемесячно (или ежеквартально, еженедельно, ...). Детальный бюджет, на основе этих данных, будет потом отображён в Базовом плане по стоимости.
8. Руководитель проекта. Как говорилось выше, это самый важный раздел Устава, который содержит информацию о назначенном Руководителе проекта, его уровне ответственности и полномочий, т.е. кто отвечает за успешную реализацию проекта и что ему для этого необходимо. Конечно же, рекомендуется, чтобы Руководитель проекта участвовал в разработке Устава проекта, так как данный документ наделяет его полномочиями использовать ресурсы организации для выполнения проекта и ответственностью за достижение целей проекта.

Шаблон Устава проекта можно полистать здесь: Устав проекта.

Исходная информация

Исходной информацией для запуска проекта может быть:

• Контракт с заказчиком.
• Бизнес-план или ТЭО разработанные некими стратегами в компании, где отображается не только финансовый анализ затрат и выгод, но также и соответствие проекта стратегиям, целям и задачам бизнеса.
• Описание работ проекта, которое было разработано в программе или проекте более высокого уровня, для которых данный запускаемый проект лишь небольшая часть.

Шаблоны всех этих документов можно полистать здесь: ОСУП.Инициация.Комплект.

Эта информация и документы могут применяться как все вместе, так и всего один из них. А вот Информация о доступности ресурсов, является жизненно необходимой для проекта. Проект-менеджер без команды как один в поле воин; как тренер футбольной команды, который сам, в одиночку выбежал на поле защищать честь клуба.

Назначение команды

Итак, проектному менеджеру (ПМ) нужно получить человеческие ресурсы, требуемые для выполнения проекта. Если в компании проекты идут на потоке, то уже на этапе инициации проекта, ПМ может определить, кого и когда нужно привлечь к работе по проекту, а также как и когда они будут высвобождены из проекта. Если это новый проект, который в компании ни кто ранее не делал, то ПМ-у следует сформировать команду хотя бы на этап планирования проекта, во время которого прояснится, какие ещё люди понадобятся.
Когда требуемых специалистов нет внутри компании, следует рассмотреть возможность найма дополнительных трудовых ресурсов на рынке труда или проведения субподрядных работ силами другой организации. Если всё-таки принимается решение по найму дополнительного персонала на время планирования и реализации, то должны быть определены их место работы, обязательства, роли и ответственность, порядок предоставления отчётности и внутри командного взаимодействия. Данная информация отражается в Трудовом контракте.
В процессе выбора членов команды проекта, при формировании и утверждении команды проекта, менеджер проекта должен принимать во внимание такие факторы, как навыки и компетентность, различные личностные характеристики и групповые взаимодействия в коллективе.
Когда в команду будут назначены соответствующие лица, можно переходить к планированию проекта. Документ по данным назначениям, назовём его «Приказ о назначении персонала проекта», может включать в себя справочник команды проекта, памятки для членов команды и имена членов команды.

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

Команда проекта, конечно же, оказывает огромное влияние на проект, а управление проектами было бы приятным и увлекательным занятием, если бы не спонсоры и заказчики…

Реестр заинтересованных сторон

Уже не для кого не секрет, что мы живём в VUCA-мире. Если для кого-то это ещё секрет, то как раз по секрету рассказываю: VUCA - это аббревиатура слов volatility, uncertainty, complexity и ambiguity (нестабильность, неопределённость, сложность и неоднозначность) используемых для описания неких условий и ситуаций. Термин VUCA начал применяться в 1990-е годы среди англоговорящих военных, у которых исчез один единственных враг и «мир» вокруг них изменился до критической неузнаваемости. Чуть позже, процессы, технологии и события на планете Земля стали тоже подходить под VUCA-описание, а многие военные повыходили на свою раннюю пенсию и продолжили свои карьеры в бизнесе. Вот тогда-то данный термин и перекочевал в корпоративный и консалтинговый сектор.
Проекты и сами по себе являются временными, сложными и нестабильными по своей сути, а тут ещё и проектное VUCA-окружение. Поэтому успех проекта сегодня определяется не столько в умении реализовать проект в рамках ограничений по содержанию, срокам, стоимости, качеству, ресурсам и риска, сколько в умении согласовывать изменения с заказчиком и вышестоящим руководством. Даже последний PMBOK заявляет, что «Успех проекта должен связываться с последними базовыми планами, одобренными уполномоченными заинтересованными сторонами».
Вот для того, чтоб знать, кто из этих заинтересованных сторон заинтересован в успехе проекта, а кто в провале, и создаётся Реестр заинтересованных сторон (или стейкхолдеров). Причём создаётся он на самой ранней стадии, а именно на этапе инициации проекта. Реестр стейкхолдеров включает определение, оценку и классификацию заинтересованных сторон проекта. В Реестре содержатся:

1. Идентификационная информация: фамилия, имя и отчество, должность в организации, местоположение, роль в проекте, контактная информация;
2. Оценочная информация: основные требования и ожидания, потенциальное влияние в проекте, наиболее интересующая фаза в жизненном цикле проекта;
3. Классификация заинтересованных сторон: внутренние/внешние, поддерживают/ нейтральны/сопротивляются и т.д.

В Реестре стейкхолдеров также отражается анализ заинтересованных сторон проекта. Анализ проще всего проводить по матрице власти/интересов, группируя сейкхолдеров на основе их уровня полномочий («власти») и уровня заинтересованности («интереса») в отношении результатов проекта. Данный метод позволяет «загнать» стейкхолдеров в кластеры и сформировать стратегию отношений с каждым кластером ЗС. Табличная часть Реестра заинтересованных сторон выглядит примерно так:

Последовательность заполнения таблицы и анализа ЗС:

1. Определить все потенциальные заинтересованные стороны проекта и существенную информацию о них, такую как роли, отделы, интересы, знания, ожидания и уровни влияния. Таким образом заполняются первые 5 колонок указанной выше таблицы. Ключевые ЗС, такие как спонсор или заказчик, выявляются легко. Остальные обычно определяются во время общения с выявленными стейкхолдерами. Желательно в Реестре ЗС указать всех потенциальных заинтересованных сторон.
2. Заполняем колонку «Власть». Отрицательной власти не бывает, поэтому выбираем ЗС с максимальной властью и ставим ему 100% (как правило это спонсор проекта). Просматриваем список ЗС находим человека с минимальными возможностями влияния на наш проект и ставим ему 0% власти. Градуировав таким образом шкалу власти, расставляем остальным стейкхолдерам процентовки по власти, просто попарно сравнивая их друг с другом.
3. Заполняем колонку «Интерес». Имеется ввиду интерес к успеху проекта, который может быть, как положительным, так и отрицательным. Как правило максимальная заинтересованность в успехе проекта у руководителя, ему и ставим 100%. Максимальная заинтересованность в провале проекта может быть у конкурента, или у некого врага нашего ПМа, всё зависит от частной ситуации. Находим этого человека и ставим ему -100%. Градуировали шкалу интереса, расставляем проценты остальным ЗС.
4. Затем в MS Excel (или в чём ты там составлял Реестр ЗС?) по колонкам «Ф.И.О.», «Власть» и «Интерес» строим матрицу. И получаем примерно вид, представленный на рисунке ниже.
5. Визуально объединяем ЗС в кластера и формируем для них стратегии управления:
   • У кого интерес от -50% до +50%, и власть от 0% до 50% - на того тратим минимум усилий. Наша стратегия – «Наблюдать».
   • У кого интерес от -50% до +50%, и власть от 50% до 100% - как правило, это какие-то надзорные или регламентирующие органы, которым всё равно что будет с результатом нашего проекта, но им важно чтобы в проекте были выполнены определённые законами и нормативами процессы. Наша стратегия – «Удовлетворять», т.е. выполнить то что они требуют или убедить, что в нашем проекте этого выполнять не нужно.
   • У кого интерес от +50% до +100%, но власть от 0% до 50% - это класс людей, которые постоянно отвлекают команду безобидными, на первый взгляд вопросами, типа «Как там у вас дела в проекте?», но которые назойливо отжирают огромное количество драгоценного времени команды. Наша стратегия – «Информировать». Причём желательно информировать пассивно. Создайте какую-нибуть рассылку, или подобие соцсети для этих людей, или повесьте большой монитор над входом в комнату команды проекта, и забрасывайте информацию туда.
   • Наоборот, у кого интерес от -100% до -50%, но власть от 0% до 50% - это класс людей, которые пытаются сделать мелкую пакость проекту или просто «сглазить» наш проект. Стратегия – «Скрывать информацию» или «Дезинформировать».
   • У кого интерес от +50% до +100%, и власть от 50% до 100% - это те самые ключевые заинтересованные стороны проекта, о которых пишут все книги и стандарты по УП, и с которыми руководителю проекта нужно работать плотно и всегда. Это именно те люди, которые в итоге решат был ли проект успешен или нет. Наша стратегия – «Активно вовлекать». И не нужно бояться излишнего участия этих стейкхолдеров в делах проекта. Есть отличное правило в УП – «Чем больнее контроль процесса, тем легче сдавать результат».
   • Ну, и последняя (в прямом и переносном смысле) группа это те, у кого интерес от -100% до -50%, а власть тоже большая от 50% до 100% - это класс людей, с которыми руководителю проекта тоже придётся очень тесно работать. Более того, активно привлекая людей из прошлого пункта, как ресурс для «борьбы» с этими. Стратегия – «Активно обороняться» или даже «Нападать».

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

Шаблон Реестра заинтересованных сторон проекта можно полистать здесь: Реестр заинтересованных сторон проекта.

Итого

С точки зрения документирования, итог запуска проекта выглядит так:

1. Устав проекта, который определяет цели проекта и предоставляет руководителю проекта власть над ресурсами.
2. Приказ о назначение персонала и, при необходимости, Трудовые контракты с людьми - документы, которые определяют первоначальный состав команды для планирования проекта и наделяют команду полномочиями и ответственностью.
3. Реестр заинтересованных сторон, определяющий перечень людей, на интересы которых повлияет проект или его результат; а также определяющий стратегию поведения команды по отношению к каждому классу ЗС.

---

• Шаблоны всех этих документов можно полистать здесь: ОСУП.Инициация.Комплект.
• Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5.
• Пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект.