<<
>>

3.5. Организация формирования календарного плана

Хотя планирование и является итеративным процессом, существует логическая последовательность шагов разработки плана программы, которая составляет цикл планирования [35].

Основные шаги цикла приведены в табл.

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

Таблица 3.5. Последовательность шагов календарного планирования Шаг Содержател ьная сущность шага Разработка концепции и целей программы Почему? Построение структуры разбиения работ (СРР) Что? Назначение ответственных Кто? Разработка стратегии реализации Определение основных событий Как? Разработка сетевых моделей Как? Расчет календарного графика по методу практического пути (МКП) Когда? Идеаль-ные сроки Расчет календарного графика с учетом ограничений на ресурсы Когда? Реальные сроки Анализ стоимостной информации Разработка финансового плана Сколько это бу-дет стоить?

В действительности процесс планирования не является та-ким строго последовательным, как это было только что показано.

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

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

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

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

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

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

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

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

0 проверить, все ли цели отражены в плане программы;

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

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

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

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

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

Уровень детализации спецификаций может различаться достаточно широко.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Назначение ответственных исполнителей.

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

ССО является описанием организационной структуры, необходимой для выполнения работ, определенных в СРР. Целью

ССО является определение комплекса исполнителей для работ детального уровня СРР. Таким образом, состав работ во многом определяет форму организационной структуры.

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

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

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

В табл. 3.6 показан пример матрицы ответственности. Роли в примере указывают на вид участия подразделения в работе: О — Ответственный исполнитель, И — Исполнитель, П — Приемка работ, К - Консультации.

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

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

Таблица 3.6. Матрица ответственности Задачи Исполнители Менеджер программы Админи-стратор программы Планово - финансовый отдел Отдел сбыта Согласование целей О К План по вехам О И К Бюджет программы О И К План программы п О Утверждение плана О К К

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

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

<< | >>
Источник: Ю.П. Морозов. ИННОВАЦИОННЫЙ МЕНЕДЖМЕНТ. 2000

Еще по теме 3.5. Организация формирования календарного плана:

  1. Тема 8. Организационная культура и ее роль в формировании организаций
  2. 4.3. Аудит операций по формированию уставного капитала акционерной торговой организации
  3. Начало счета сталии. Нотисы о прибытии судна. Календарные, рабочие и «чистые» дни в нотисах.Нотис о готовности судна к погрузке (выгрузке). Льготное время
  4. Разработка бизнес-плана
  5. Глава 4. РАЗРАБОТКА БИЗНЕС-ПЛАНА
  6. 11.7. Создание плана счетов
  7. Погорелый С.А. Разработка бизнес-плана, 2005
  8. Глава 2. В поисках совершенного бизнес-плана
  9. Презентация бизнес-плана
  10. 3. Составление плана курсовой работы
  11. 13.7. Методика составления кассового плана
  12. Составьте резюме бизнес-плана
  13. 1.6. РАСЧЕТ БИЗНЕС-ПЛАНА
  14. Резюме — квинтэссенция бизнес-плана
  15. Вопросы для проверки бизнес-плана
  16. Принципы реализации плана РR-активности
  17. 3.2. Разработка плана стимулирования сбыта
  18. 3.2. Разработка плана стимулирования сбыта