Управление услугами и проектами в IT
Поиск
Авторизация

PMI, PMBoK. Группа  процессов  планирования

Группа  процессов  планирования  состоит  из  процессов,  осуществляемых  для  определения  общего  содержания работ,  постановки  и  уточнения  целей  и  разработки  последовательности  действий,  требуемых  для  достижения данных  целей.  В  процессах  планирования  разрабатываются  план  управления  проектом  и  документация  проекта, которые  будут  использованы  для  выполнения  проекта.  Комплексный  характер  управления  проектами  порождает цепочки  обратной  связи  для  дополнительного  анализа.  По  мере  поступления  и  осмысления  большего  объема информации  или  характеристик  проекта  может  потребоваться  дополнительное  планирование.  Значительные изменения,  происходящие  на  протяжении  жизненного  цикла  проекта,  приводят  к  необходимости  вновь вернуться  к  одному  или  нескольким  процессам  планирования,  а,  возможно,  и  к  процессам  инициации.  Эта последовательная  детализация  плана  управления  проектом  часто  называется  «планированием  набегающей волной»  (“rolling  wave  planning”),  что  указывает  на  то,  что  планирование  и  документирование  –  повторяющиеся и постоянно идущие процессы.

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

Разработка плана управления проектом: входы

Устав проекта

Описан ранее

Выходы процессов планирования

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

Блок-схема данных при разработке плана управления проектом

Блок-схема данных при разработке плана управления проектом

Возможный состав плана управления проектом:

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

Корректировка «плана управления проектом» – осуществляется в течение всего проекта, в ответ на изменившиеся внешние условия, реализовавшиеся риски и т.д. Предсказать, где и когда понадобятся изменения заранее невозможно, посему их не планируют заранее, а осуществляют при помощи механизма «контроля изменений».

Процесс первоначальной разработки плана может быть точно регламентирован и предполагает четкую последовательность шагов. Один из вариантов «лучшей практики»:

      • Определение самой процедуры планирования
      • Собрать и финализировать требования
      • Сформировать концепцию (scope)
      • Принять решение «что закупаем»?
      • Определить команду
      • Создать ИСР (иерархическую структуру работ) (WBS)
      • Создать перечень действий (activity list)
      • Создать сетевую диаграмму (network diagram)
      • Оценить требуемые ресурсы
      • Оценить продолжительность действий и стоимость
      • Сформировать расписание
      • Создать бюджет
      • Планировать качество – создать метрики
      • Создать план улучшения процессов
      • Распределить роли и ответственности
      • Создать план коммуникаций

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

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

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

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

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

Планирование содержания

Входы:

  • устав проекта
  • состав «плана управления проектом»

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

Для описания всех необходимых работ по проекту нужно: определиться с требованиями и ожиданиями заказчика, разобраться, какие из них реально выполнимы, и что для этого понадобится, то-есть:

  1. Собрать и финализировать требования
  2. Сформировать концепцию
  3. Создать ИСР (WBS)

Формирование концепции и создание ИСР (WBS) разделены еще двумя этапами из других областей знаний.

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

Собрать и финализировать требования – один из наиболее трудоемких и плохо формализуемых процессов. Все что известно сейчас – крупноуровневые требования, зафиксированные в уставе.

Чтобы конкретизировать их необходимо понять, кто является источником требований на проекте и что он конкретно хочет получить по окончании работ.

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

Лучшие проектные практики гласят:

  • проект с неудовлетворенными ожиданиями заказчика не является успешным
  • проект, результаты которого не используются конечными пользователями, не является успешным

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

Реестр заинтересованных лиц

Даже на небольшом проекте (с бюджетом в несколько миллионов рублей и командой порядка 10 человек) такой реестр должен содержать десятки (хорошо, если сотни) фамилий.

По какому принципу можно отнести того или иного человека к «заинтересованным лицам»:

  1. Это каждый, кто прямо вовлечен в проект (заказчик, спонсор, команда).
  2. Заинтересованным лицом всегда являются конечные пользователи продукта (ни в коем случае нельзя пренебрегать их интересами в проекте!).
  3. Начальники членов вашей команды.
  4. Те, кто напрямую не связан с проектом, но, так или иначе, оказывает на него влияние.
  5. Последняя группа заинтересованных лиц – наиболее трудна к выявлению, однако порой вклад таких «серых кардиналов» очень велик. В качестве примера можно привести гипотетическую ситуацию, когда сын заказчика является в его глазах авторитетом в сфере информационных технологий и привлекается отцом к принятию принципиальных решений о внедряемых системах. При этом сын не является сотрудником ни одной из участвующих в проекте организаций (или, допустим, вообще еще школьник). Однако высказанные им советы имеют для папы больший вес, чем экспертные заключения его же сотрудников. Возможно, «добраться» до такого «заинтересованного лица» в ходе проекта вам и не удастся, но, знать (или, хотя бы, предполагать его существование) – достаточно важно.

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

Далее предстоит выбрать один или несколько методов «вытягивания» из заинтересованных лиц их ожиданий и требований .

Выбирая методы, необходимо тщательно взвесить потребности в информации и способности второй стороны ее предоставить.

Из наиболее распространенных можно выделить:

  • Интервью
  • Опросники
  • Мозговые штурмы (в различных вариациях)
  • Прототипирование

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

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

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

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

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

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

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

Проектные практики призывают собрать все требования, которые могут относиться к проекту и только после этого двигаться дальше.

Многие методологии разработки ПО обосновано считают строгую последовательность «спланировал» – «сделал» – «показал» – «сдал» (без демонстрации промежуточных результатов заинтересованным лицам и регулярной корректировки исходных планов) злом, повышающим риски провала.

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

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

Факторы среды предприятия

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

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

Балансировка требований – отбор требований, реализация которых предполагается в рамках проекта.

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

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

Позже, когда себестоимость и продолжительность работ будет оценена, можно вернуться к этой части плана и скорректировать ее (возможно, от каких-то требований придется отказаться или пересмотреть). Однако важно понимать – процесс балансировки требований не должен противоречить уставу проекта. Если в уставе, прописано как одно из главных требований к продукту – скорость реакции интерфейса не более чем за 0,5 секунды, то нельзя выбросить подобное требование из реестра (его невыполнение похоронит проект).

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

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

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

Активы процессов организации

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

  • типовые руководящие указания, рабочие инструкции, критерии оценки предложений и критерии измерения исполнения;
  • шаблон плана управления проектом – элементы плана управления проектом, которые могут быть обновлены, включают, среди прочего:

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

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

Разработка плана управления проектом: инструменты и методы

Экспертные оценки

При разработке плана управления проектом экспертные оценки используются для:

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

Разработка плана управления проектом: выходы

 План управления проектом

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

  • выбранный для проекта жизненный цикл и процессы, которые будут применяться в каждой фазе;
  • результаты адаптации, полученные от команды управления проектом, а именно:

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

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

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

Базовые планы проекта включают в себя, среди прочего:

  • базовое расписание;
  • базовый план выполнения стоимости;
  • базовый план по содержанию.

Вспомогательные планы включают в себя, среди прочего:

  • план управления содержанием;
  • план управления требованиями;
  • план управления расписанием;
  • план управления стоимостью;
  • план управления качеством;
  • план усовершенствования процессов;
  • план управления человеческими ресурсами;
  • план управления коммуникациями;
  • план управления рисками;
  • план управления закупками.

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