План управления проектом собирает все части проекта в единое целое, создает централизованный документ, который раскрывает, что именно вовлечено в проект. Рассмотрим ключевые компоненты плана управления проектом.
Жизненный цикл проекта. Это фазы работы над проектом, нужные, чтобы поставить продукт (например требования, проектирование, разработка, тестирование, имплементация). Будет отличаться для plan driven и change driven проектов.
Подход к разработке. Plan driven или change driven.
Управленческие ревью. Нужно предусматривать вехи в плане управления проектом, для обозначения моментов, когда менеджмент и заинтересованные стороны будут сравнивать факт проекта с планом, и решать, нужно ли вносить какие-то изменения в план управления проектом.
Процесс управления проектом, который будет использован. Не следует использовать PMBOK в чистом виде. Всегда надо адаптироваться под данный конкретный проект.
План управления областями знаний. Нужны плана на:
- содержание
- расписание
- бюджет
- качество
- ресурсы
- коммуникации
- риски
- закупки
- заинтересованные стороны
- + требования
- + изменения
- + конфигурации
Базовые значения и их измерение. План управления проектом подразумевает базовые содержание, расписание и бюджет, против которых РМ будет измерять исполнение проекта. Эти базовые значения разрабатываются в ходе планирования. Ниже элементы каждой из базовых величин:
- базовый план по содержанию - это содержание проекта, ИСР, и словарь ИСР
- базовый план по расписанию - это согласованное расписание, с датами начала и конца каждой задачи, и запланированные вехи проекта
- базовый план по бюджету - затраты по фазам проекта (сколько денег надо на проект, и когда каждый транш должен быть получен)
Все вместе эти базовые планы именуются базовыми значениями измерения исполнения.
Что эти бэйслайны означают для РМ и команды? РМ должен явно, полно, и реалистично определить содержание, расписание и бюджет для разработки базовых значений. И это еще не все. Исполнение проекта, как и перфоманс самого РМ, буду измеряться против этих базовых значений. Отклонения от них должны анализироваться РМ и командой, по ним должно приниматься решение, нужна ли корректировка или исправление проблемы. Сами базовые значения при этом можно менять, а можно и нет. Если отклонение небольшое, то оставляем их как есть. Если отклонение существенно, и не лечится мелкой поправкой, до должен быть инициирован запрос на изменение базовых значений.
Важная часть контроля и мониторинга проекта - это проверка, что базовые значения достигнуты, что в свою очередь дает понять спонсору и заинтересованным сторонам о достижении запланированных выгод от проекта. Так что, обязанность РМ - это не только спланировать проект, но и добиться его исполнения так, как планировалось.
Запрошенные изменения базовых значений оцениваются и утверждаются в ходе Интегрированного контроля изменений. Изменение базовых значений это столь серьезный шаг, что всегда надо документировать, когда и почему это произошло.
Надо понимать, что отклонения от базовых значений происходят часто вследствие плохого выявления рисков и управления ими. Так что, если экзамен спрашивает, что делать, если у нас серьезные отклонения от базовых значений - правильный ответ будет в области ревью процесса управления рисками проекта.
План управления требованиями. Это часть управления содержанием, включает определение потребностей, пожеланий, ожиданий, предположений заинтересованных сторон, и управление ими так, чтобы они оформились в четкие требования к проекту. План управления требованиями определяет, как требования будут собираться, анализироваться, ранжироваться, оцениваться, документироваться, и контролироваться в ходе проекта.
План управления изменениями. Контроль соответствия проекта базовым значениям, и прочим планам управления проектом, настолько важен, что РМ должен думать наперед о том, где могут возникнуть изменения, и что сделать, чтобы элиминировать их негативный эффект. Роль РМ далеко не в том, чтобы продвигать изменения. Напротив, нужен план, как минимизировать изменения на проекте. Также надо проактивно наблюдать за требуемыми изменениями, и предотвращать ненужные изменения. Надо заранее решать проблемы, имеющие негативное влияние на проект. Поскольку внесение изменений в проект это занятие намного более дорогое, чем включение соответствующих требований на старте, изменения не следует принимать без должного обоснования.
План управления изменениями раскрывает, как изменения буду управляться и контролироваться, и может включать:
- процедуры контроля изменений (кто и как)
- уровни авторизации изменений
- создание совета по контролю изменений, чтобы их централизованно утверждать, включая роли и ответственности на этом совете
- план, обозначающий, как изменения буду управляться и контролироваться
- кто должен организовывать встречи для обсуждения изменений
- инструменты для трекинга и контроля изменений
- отчетность по запросам на изменения
- процесс внесения изменений по внештатным ситуациям
Нужно иметь ввиду, что план управления изменениями может иметь отдельные процессы, адресованные каждой области знаний, с учетом особенностей этих областей.
Система контроля изменений. Во многих компаниях есть такая, как часть информационной системы по управлению проектами. Она подразумевает стандартные формы, отчеты, процессы, процедуры, и софт, чтобы тречить и контролировать изменения. Это - часть факторов среды компании.
План управления конфигурациями. Вместе с остальной документацией на проект и продукт, это часть управления проектом. Важно создать план того, как до каждого будет доводиться номер последней версии содержания, расписания, и иных компонентов плана управления проектом. План управления конфигурациями определяет конвенции по наименованию, систему контроля версий, систему хранения документации, и детали того, как мы документацией управляем, включая используемые для этого инструменты.
Система управления конфигурациями. Как и система контроля изменений, это часть информационной системы по управлению проектами. Включает стандарты компании по инструментам, процессам и процедурам, которые используются для трекинга и контроля эволюции проектной документации.
