Вопрос 4: Построение иерархической структуры работ

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

Создание ИСР в начале работ по планированию предоставляет менеджеру возможность:

· объяснить, за счет каких работ будет достигнута каждая из определенных в проекте целей;

· проверить, все ли цели отражены в плане проекта а Создать эффективную структуру отчетности;

· указать на соответствующем уровне детализации ключевые результаты, которые должны быть ясно отражены в сети и календарном плане;

· указать менеджеров, ответственных за достижение ключевых результатов, и тем самым гарантировать, что достижение всех результатов будет контролироваться

· обеспечить членам команды понимание их роли в контексте общей работы по выполнению проекта.

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

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

Определение основы для структуризации проекта

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

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

Существует несколько подходов к построению ИСР. Применительно к реальным проектам, структура разбивки проекта должна сочетать разделение на:

· компоненты продукции проекта;

· функциональные элементы деятельности;

· этапы жизненного цикла проекта;

· элементы организационной структуры.

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

Возможно существование задач, которые не попадают под контроль менеджера проекта - например, задачи, обеспечивающиеся и контролируемые заказчиком. Такие задачи, хотя и являются внешними по отношению к проекту, но могут накладывать определенные ограничения на его задачи. Для учета подобных ограничений внешние задачи также могут быть включены в ИСР в качестве определенной категории внешних работ.

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

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

Рис. 3.3. Пример ИСР, построенной с использованием смешанного подхода к структуризации.

Правила для построения иерархии

Несколько простых правил применяются при формировании ИСР:

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

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

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

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

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

Наиболее распространенными ошибками, допускаемыми в процессе структуризации проекта, являются:

· пропуск стадии структуризации проекта и переход непосредственно к поиску и решению проблем проекта;

· использование только функций, фаз, или организационных подразделений вместо конечных продуктов или используемых ресурсов;

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

· не учет того, что элементы структуры не должны повторяться;

· отсутствие интеграции структуры проекта с системой ведения бухгалтерских счетов в компании;

· излишняя или недостаточная детализация;

· невозможность компьютерной обработки результатов структуризации -планов проекта из-за ошибок формального характера (каждый уровень или элемент плана должен быть определенным образом закодирован);

· не учет «неосязаемых» конечных продуктов, таких как услуги, информационное, или программное обеспечение.