План управления проектом – что включает и как его разработать

Есть хорошее выражение, о котором нужно помнить при сдаче PMP: первое, что делает руководитель проекта при возникновении риска, изменения или любой мало-мальски нештатной ситуации – это открывает план управления проектов и смотрит, что ему делать (там он уже точно это написал, если это хороший РМ). Утопия, конечно, но концепцию описывает хорошо. Итак, что такое план управления проектом и как его составить?

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

Что включает план управления проектом

Итак, на этапе планирования проекта вы формируете единый документ или пакет документации, в который включаете следующую информацию:

  1. Какие именно процессы управления проектом будут именно в вашем проекте? Будете вы в нем вообще системно заниматься вопросом, например, вовлечения стейкхолдеров? Или у вас внутренний проект без денег и вопросы управления стоимостью тут неприменимы? Это делается для того, чтобы ограничить круг задач, которые должен интегрировать РМ.
  2. Планы управления по всем областям знаний, которые вы включили в проект – как вы будете управлять сроками, деньгами, людями, закупками и проч.?
  3. Базовые планы по срокам (календарный план), бюджету (бюджетный план) и содержанию (WBS) проекта – то, как вы спланировали это все изначально, до старта работ (вы же не начали работы без плана, правда?), и против чего будет меряться прогресс проекта на этапе выполнения.
  4. План управления требованиями – описание того, как вы будете собирать, приоритезировать и управлять требованиями заказчика и стейкхолдеров. Эту часть, почему-то, часто оставляют за бортом, если проект не связан с ИТ (как-то сложилось, что требования – это про ИТ проекты), но это ошибка. Например, если вы строите луноход – то к луноходу тоже будут требования, и ими тоже нужно будет управлять.
  5. План управления изменениями – формализованный процесс того, что вы будете делать в случае, если в проекте появилось какое-то изменение со стороны (например, Заказчик сказал сделать быстрее) или  вы запросили это изменение сами (например, хотите заменить один функционал другим из-за возникновения какого-то риска). В плане прописывается, кто и в каком порядке предлагает, учитывает и авторизует изменения.
  6. План управления конфигурацией – замечательная вещь, про которую часто забывают. В плане управления конфигурацией описывается то, как вы будете работать с инфраструктурой проекта, то есть с тем, что используется в процессе выполнения проекта для обеспечения взаимодействия. Сюда может относиться система контроля кода, баг-трекер, библиотека проектной документации, используемое программное обеспечение и многое другое. Цель этого плана – описать, как именно это использовать, чтобы избежать ситуации, когда, например, Заказчик подписал одну версию ТЗ, разработчик разработал по другой, а тестировщик проверил по третьей, да еще и на другой версии Windows. Вот чтобы такого не случилось, не были потрачены ресурсы и не было мучительно больно – и нужен план управления конфигурацией.
  7. План улучшения процессов – самый неочевидный из всех и наиболее редко используемый, в основном потому, что мало кто понимает, зачем он нужен. Но, если задуматься, мало какие проекты включают в себя только уникальные и не повторяющиеся задачи. Например, в проекте строительства дома будет многократно повторенная задача по вставке окон, а в проекте разработки  CRM-системы – задача по установке очередной версии для тестирования на сервера. Цель плана улучшения процессов – заранее обдумать и спланировать, как мы будем (и будем ли) анализировать выполнение таких повторяющихся задач, чтобы оптимизировать сроки, бюджет или другие ресурсы. К слову, сюда же могут относиться не только задачи по созданию продукта проекта, но и задачи по управлению проектом. Например, в какой-то момент, после 5й встречи по скайпу всей командой, мы соберемся и обсудим, как сделать эту встречу эффективнее.

Наверняка после того, как вы прочитали весь этот список, ваша главная мысль – “я так и знал, что управление проектами – это про написание кучи никому не нужно макулатуры”. Если так, то вернитесь и перечитайте п.1. В плане управления проектом совсем необязательно а) должны быть все эти планы б) все эти планы должны быть на бумаге.

Если вы уверены в том, что вашего понимания того, как вы будете управлять изменениями “в голове” будет достаточно – значит, не нужно тратить время и писать этот план.

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

Как разработать план управления проектом

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

  1. Определяется, как вы будете планировать (один, с другом, с командой, где, как, когда и проч.)
  2. Определяется список требований к результату проекта и к управлению проектом (с указанием приоритетов)
  3. На основе требований разрабатывается описание содержания проекта или видение проекта (что будет в итоге на выходе проекта?)
  4. Принимаются решения о том, что именно будет приобретаться (в том числе какие работы “как сервис”), а что – делаться силами команды
    1. Создается WBS (ИСР) проекта, декомпозирующая результат проекта на управляемые куски. Это наш будущий базовый план содержания проекта.
  5. Для каждой работы в WBS определяется набор задач для ее выполнения (что нужно сделать, чтобы получить данный конкретный результат?)
  6. Строятся зависимости между задачами (для выполнения задачи 5 должны быть выполнены задачи 2 и 4)
  7. Определяется, какие знания и навыки нужны для выполнения каждой задачи (обратите внимание, что пока речь не о членах команды, а о компетенциях!)
  8. Оцениваются длительность и стоимость выполнения каждой задачи (наконец-то началась знакомая всем часть, правда?)
  9. Определяется критический путь проекта (теперь мы знаем, сколько всего времени нужно на весь проект)
  10. Разрабатывается календарный план проекта (если на предыдущих шагах все сделано верно – то достаточно будет задать начальную или конечную дату и получить результат). Это наш будущий базовый календарный план проекта.
  11. Определяется стоимость проекта (во сколько же обойдется этот конечный результат). Это наш будущий базовый план стоимости проекта.
  12. Уточняются требования к качеству (как поймем, что то, что мы сделали в проекте, мы сделали хорошо?)
  13. Разрабатывается план улучшения процессов (см.выше)
  14. На задачи назначаются конкретные люди (тут мы пытаемся связать требуемые компетенции для конкретных задач с компетенциями конкретных членов команды)
  15. Планируются коммуникации и работа со стейкхолдерами (как будем работать с окружающими людьми в проекте и вне него)
  16. Производится анализ рисков на основе всего, что мы напланировали раньше (и тут нас ждет множество сюрпризов)
  17. Посмотрев на все это и поняв, что ничего ни с чем не сходится – возвращаемся в самое начало и пытаемся последовательно достичь баланса, учитывая ограничения проекта.
  18. После того, как после N итераций мы достигли какого-то баланса – разрабатывается план управления изменениями, доводится до ума перечень закупок и требований к ним, все написанное выше складывается в одну кучку и согласуется с заинтересованными лицами – и наш план управления проектом готов.

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

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

Удачи!

Давайте не теряться - подпишитесь прямо сейчас!

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

А также
И не забудьте оставить комментарий :) мне важно ваше мнение!
Комментарии (4)
  1. Сергей Б

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

    1. Yulia Bazhanova

      Рада, что полезно=))

  2. Екатерина

    Действительно, важность формирования ПУП на ранних стадиях проекта критично недооценена.
    А это, по сути, “карта” нашего проекта.
    Но только чтобы составить ее, нужно понимать все важные и неважные его координаты, что мы имеем и в принципе иметь можем.
    Юля, как всегда пост максимально полезный/интересный.
    А План улучшения процессов – для меня маленькое открытие. Мы пока такое не практиковали.

    1. Yulia Bazhanova

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

Оставьте комментарий