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

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

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

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

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

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

Информация полезна? Поддержи развитие проекта!

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

• Несмотря на то, что план управления проектом кажется сложным – нужно попробовать, чтобы понять, что он не содержит ничего лишнего, и что один раз сделав эту работу, вы значительно облегчаете дальнейший ход проекта.
• В плане прописывается, кто и в каком порядке предлагает, учитывает и авторизует изменения.
• Принимаются решения о том, что именно будет приобретаться (в том числе какие работы “как сервис”), а что – делаться силами команды 1.
• Это делается для того, чтобы ограничить круг задач, которые должен интегрировать РМ.

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

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

Принимаются решения о том, что именно будет приобретаться (в том числе какие работы “как сервис”), а что – делаться силами команды 1. Создается WBS (ИСР) проекта, декомпозирующая результат проекта на управляемые куски. Это наш будущий базовый план содержания проекта. Все грамотно объяснено. Видно, что план действительно нужен.

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

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

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