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