2. Основные и вспомогательные процессы планирования проекта

Состав и соотношения между процессами планирования проекта представлены на рисунке 4.2.

Основные процессы планирования могут повторяться несколько раз, в тече­ние, как всего проекта, так и его отдельных фаз.

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

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

Рисунок 4.2. Процессы планирования проекта

3. Проведение структурной разбивки работ и назначение ответственных за их выполнение. Установление основных вех

3.1. Построение структуры разбиения работ по проекту

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

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

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

2. проверить, все ли цели отражены в плане проекта;

3. создать эффективную структуру отчетности;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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