Введение

Документация по инициации проекта (PID) является одним из важнейших артефактов в управлении проектами, закладывающим основу для бизнес-проекта. Документация по инициации проекта объединяет информацию, полученную в ходе процессов запуска проекта (SU) и инициирования проекта (IP) в контролируемой среде PRINCE2. Переименование PRINCE2 в 2009 году "document" в "documentation" указывает на то, что это собрание документов, сформированное в процессе создания проекта, а не вся информация в системе. Документация по инициации проекта служит ориентиром на протяжении всего проекта как для заказчика, так и для проектной команды. Документация по инициации проекта обычно содержит следующее:

Цели проекта
Объем
Организация проекта
Бизнес-обоснование
Ограничения
Заинтересованные стороны
Риски
Управление проектом
Рамки отчетности
Утверждение PID
Краткое содержание

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

Документация по инициативе проекта в терминах PRINCE2

Документация по инициированию проекта – это термин PRINCE2, обозначающий план подхода к управлению проектом. Она формируется из ряда других документов, включая бизнес-кейс, техническое задание, план коммуникаций, реестр рисков, допустимые отклонения проекта, план проекта, а также любые специфические контрольные процедуры или проверки в рамках плана обеспечения качества подразделения или общепринятого подхода к проекту. Документация по инициированию проекта представляет собой детализированную версию базового документа о старте проекта, называемого проектным обоснованием. Документация по инициированию проекта объединяет различные документы в единый логичный документ, содержащий всю ключевую информацию, необходимую для начала и управления проектом на прочной основе. Она должна быть доведена до сведения всех заинтересованных сторон, согласована и утверждена бизнес-заказчиками. Проще говоря, это часть проекта, отвечающая на вопросы "кто, зачем и что". Она определяет все основные аспекты проекта и служит основой для его управления и оценки общего успеха. Документация по инициированию проекта основывается на бизнес-кейсе (если он существует), используя информацию и аналитические данные, полученные в ходе инициации. Являясь частью стандартных методологий управления проектами, таких как PRINCE2, этот документ является важной вехой в процессе инициирования проекта (IP). Он представляется проектному комитету для утверждения и начала проекта. Документация по инициированию проекта служит ориентиром на протяжении всего проекта как для заказчика, так и для проектной команды.

Цель

Целью документа о начале проекта является сбор и фиксация основной информации, необходимой для корректного определения и планирования проекта. Документ о начале проекта должен расширять мандат проекта и четко указывать, чего проект намерен достичь, а также обосновывать важность достижения этих целей. Он также содержит список участников проекта, вовлеченных с самого начала и до завершения, с указанием их ролей и обязанностей. В документе о начале проекта указывается дата утверждения документации о начале проекта проектным комитетом. Документ о начале проекта не подлежит регулярному обновлению в ходе реализации проекта. Любые необходимые изменения или обновления вносятся в конце каждого этапа для включения детализированных вех дальнейшей работы. Документ о начале проекта является основой для принятия решений по проекту, и его оспаривание или изменение на более поздних этапах без указания причины, ответственного лица и даты затрудняет работу.

Заявление о масштабе проекта

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

Описание проекта

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

Предположения, зависимости и ограничения

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

Организация и управление

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

План коммуникаций

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

План качества

План качества проекта обычно разрабатывается отделом ИТ-обеспечения качества (ITQA) и определяет, какие артефакты будут созданы в рамках проекта (зафиксированный план проекта, бизнес-требования (BRS), варианты использования, высокоуровневый дизайн (HLD), спецификация требований к программному обеспечению (SRS), тестовые сценарии, отчет о тестировании, обзор после разработки (PDR), оценки этапов в плане качества проекта). ITQA также определяет сроки проведения оценки конечного этапа (ESA). По сути, это контрольные точки на протяжении всего жизненного цикла проекта, обеспечивающие поставку качественного продукта. ESA подразумевает проведение совещания, на котором рассматривается зафиксированный план проекта для подтверждения его актуальности и соответствия графику, отчеты по управлению проектом, отчеты о контрольных точках рабочих потоков проекта, протоколы совещаний команды, список задач и повестка дня, журнал рисков и проблем проекта, а также рекомендации по плану качества.

Первоначальный план проекта

Составление первоначального плана для документации по инициированию проекта подразумевает тщательное переосмысление предложенных сроков и детализацию этапов в соответствии с этим. Зачастую представители бизнеса просят реализовать проекты к нереалистичным срокам, что требует указания на этот факт. В таких случаях большинство заинтересованных сторон проявляют гибкость и готовы пересмотреть дату запуска или сократить объем работ. Необходимость переноса даты запуска или сокращения объема работ должна быть подкреплена обоснованиями, на основе которых заинтересованные стороны принимают решение о переносе сроков. Чем раньше исполнитель начнет выстраивать такие отношения с заинтересованными сторонами, тем проще будет в дальнейшем, когда возникнут более острые вопросы, касающиеся объема проекта.

Контроль проекта

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

Первоначальные риски и проблемы

Правило гласит: чем больше мы планируем сделать, тем больше нам предстоит реализовать. Этапы проекта включают: инициацию, определение требований, проектирование, разработку, тестирование, запуск и завершение, а также этап обработки исключений. Последний этап – наиболее нестабильный, поскольку определяет пределы увеличения бюджета, сроков и объема проекта, не приводящие к переходу в режим обработки исключений. Если заинтересованные стороны принимают решение о переводе проекта в режим обработки исключений, необходимо разработать подробный план обработки исключений, который заменит действующие планы проекта или этапов. Помимо дополнительной документации, руководителю проекта необходимо поддерживать динамику проекта и обеспечивать мотивацию команды. После официального утверждения документа по инициации проекта появляется дополнительный резерв, который можно использовать до перехода в режим обработки исключений. Это может существенно повлиять на успешную реализацию проекта, подобно тому, как положительный денежный поток является ключевым фактором успеха любого развивающегося бизнеса. Боэм выделил шесть этапов управления рисками: идентификация, оценка, приоритизация, планирование управления, разрешение и мониторинг, которые реализуются на этапе инициации проекта.

Одобрение документа о начале проекта

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

Характеристики документа о начале проекта

В документации по инициированию проекта подчеркивается его важность и определяется, что она является соглашением между управлением проектом и спонсором. Целью документации по инициированию проекта является понимание обоснования проекта. Правильно оформленная документация по инициированию проекта демонстрирует понимание предыстории, целей и выгод. Хороший руководитель проекта заинтересован не только в предоставлении результата или функциональности заказчику, но и в более широком контексте и выгодах, которые эта функциональность принесет в конечном итоге. Документация по инициированию проекта определяет границы проекта с помощью блок-схем и декомпозиции продукта. Ключевую роль играет определение ролей и ответственности, включая роли руководителя проекта, руководителя группы, спонсора, поставщика, представителя пользователей, заинтересованных сторон и членов управляющего комитета.