План управления проектом, содержащий согласованное всеми участниками документально зафиксированное представление о проекте, - это основополагающий документ "точка опоры" для всего последующего развития проекта.

Григорий Львович Ципес, ведущий системный аналитик компании IBS, GTsipes@ibs.ru
Александр Самуилович Товб, руководитель проектов компании IBS, A_Tovb@ibs.ru

План управления проектом, содержащий согласованное всеми участниками документально зафиксированное представление о проекте, - это основополагающий документ "точка опоры" для всего последующего развития проекта.

Покажем, как могут выглядеть некоторые разделы специализированного шаблона Плана управления проектом. Используем в качестве примера проект создания филиала банка, приведенный в предыдущей заметке (см. Директор ИС, 2001, №2). Рассмотрим подпроект создания ИТ-инфраструктуры филиала банка.

Содержание и границы проекта

При построении специализированного микрошаблона "Содержание и границы проекта" мы использовали рекомендации PMBoK PMI (первые два столбца в таблице).

В этом шаблоне остается менять только названия программного обеспечения и сроки выполнения этапов работ.

Сопоставив приведенные в примере разделы Продукт проекта и Результаты проекта, можно заметить, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании Плана (а следовательно, и при формировании шаблона Плана) часто используют структуру декомпозиции работ (WBS - Work Breakdown Structure), а многие ведущие компании включают в свои методологии и стандарты типовые WBS как в явном виде (Andersen Consulting), так и неявно (IBM).

Структура декомпозиции работ

Провести декомпозицию и составить структуру декомпозиции работ (WBS - Work Breakdown Structure), по утверждению М. Ньюэлла, очень легко: "Прежде всего следует разбить проект на несколько подпроектов. Каждый из подпроектов в свою очередь может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации" (цитируется по статье "Структура декомпозиции работ". Директор ИС, 2001, №3).

На самом деле все не так однозначно, причем (обнадежим читателя) речь пойдет не только о сложностях создания WBS, но и об открывающихся возможностях. Рассмотрим проблему на примере проекта создания информационной системы (ИС).

На стадии инициализации проекта руководитель проекта должен ответить на целый ряд вопросов:

  • что нужно сделать (определить продукты проекта);
  • как это нужно делать (определить технологические этапы проекта);
  • кто это будет делать (определить исполнителей, соисполнителей, субподрядчиков);
  • кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты).

На самом деле вопросов, конечно, бывает гораздо больше, но мы ограничимся вышеприведенными.

На какие же подпроекты следует разбить исходный проект? Что будет удобнее видеть на первом уровне декомпозиции - компоненты ИС (программные, технические, информационные) или технологические этапы (концепция, техническое задание, проектирование и т. д.)? А может быть, удобнее сгруппировать работы по исполнителям или по заказчикам?

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

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

Следовательно, первое, что должно быть отражено в специализированном шаблоне WBS, - какие альтернативные взгляды на структуру декомпозиции работ должны поддерживаться в проекте (взгляд руководителя проекта, взгляд куратора, взгляд инвестора и т. д.).

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

План управления проектом и рамочные стандарты

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

Проиллюстрируем это на примере не самого сложного раздела плана "Организационная структура проекта". В PMBoK необходимая информация разбросана по нескольким разделам (2.2.; 2.3.; 2;4.; 4.1.3.; 9), а в ISO 10006:1997(Е) - сосредоточена в разделе 5.8. Но и в том и в другом случае для создания специализированного шаблона этой информации недостаточно!

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

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