Детали процесса изменений

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

1. Устраняем корневую причину проблем. РМ фокусируется не только на управлении изменениями, он должен проактивно устранять саму причину изменений.
2. Определить необходимость изменения. Изменения приходят от самого РМ, как результат измерения исполнения проекта против базовых значений, или от стейкхолдеров - спонсора, команды, клиентов, менеджмента и т.д. РМ должен всегда быть на страже изменений, поскольку открытие изменения на ранней фазе обычно положительно сказывается на его стоимости.
3. Оцениваем влияние изменения за пределами изменяемой области знания. Если это изменение содержания, то как оно повлияет на остальное содержание проекта? Если расписания, то как повлияет на остальное расписание?
4. Создаем Запрос на изменение. Изменения могут быть в содержании, в любой части плана управления проектом, в контрактах, уставе, процедурах и политиках, и даже в базовых значениях. Процесс внесения изменений должен соответствовать плану управления изменениями.
5. Проводим интегрированный контроль изменений. Как изменение скажется на иных ограничениях проекта?
1. Оцениваем изменение. Оно попадает в Устав проекта? Если нет, то это не изменение данного проекта, это отдельный проект! Если изменение невыгодно проекту, его не следует согласовывать. Оценить влияние изменения можно с помощью техник альтернатив или cost-benefit анализа. Также имеем ввиду, что изменение, под которое был создан резерв (то есть это свершившийся, ранее идентифицированный риск) надо расценивать как часть управления рисками. Это часть Плана реагирования на риски, а не часть Интегрированного контроля изменений.
2. Понимаем варианты. Действия, уменьшающие вред, или повышающие возможности, включают: сжатие расписания, изменение исполнения работ, улучшение качества, или сокращение содержания, так, чтобы эффект изменения был минимален. Иногда, необходимо принять местные негативные последствия изменений, если их итоговый эффект будет полезен проекту. Это вопрос балансировки ограничений проекта. Например, польза от добавления нового содержания в проект может уравновесить удлинение расписания вследствие этого добавления.
3. Изменение согласуем, отказываем, или откладываем. Еще раз, РМ может утвердить многие изменения. Но те, что касаются плана управления проектом, базовых значений, устава и так далее, предположительно будут требовать утверждения спонсором или советом по контролю изменений. Тут помогут техники принятия решения. Согласованные изменения затем включаются в процессы Ведения проекта, Контроля качества, и Контроля закупок.
4. Обновляем статус изменения в реестре изменений. Это позволит каждому понимать статус. Если изменений отклоняется, то причины отклонения документируются.
5. Корректируем план управления проектом, проектные документы, и базовые значения если необходимо. Некоторые одобренные изменения надо включить в базовые значения. Изменения могут повлиять и на иные части плана управления проектом, или проектную документацию, или могут изменить подход, в соответствии с которым РМ управляет проектом. Документация на проект должна быть обновлена, чтобы отразить эти изменения. Это означает необходимость перепланирования для отражения влияния изменения в новых версиях проектной документации, прежде чем команда начнет работу над ним. Например, если изменилось содержание, то нужно это учесть в базовых значениях содержания (ИСР, словарь ИСР, и описание содержания), в плане управления проектом, и матрице требований. Если это изменение проекта затрагивает иные области проекта, то всю ассоциированную документацию также надо обновить.
6. Управляем ожиданиями заинтересованных сторон, через коммуникацию об изменениях тем, кого оно затрагивает. Об этом можно думать как о части управления конфигурациями, что каждый работает с последней версией.
7. Управляем проектом в соответствии с обновленным планом и иной документацией.