Использование управления изменениями и контроля над изменениями в рамках проекта

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

Здесь необходим систематичный и единый подход. Как только план проекта и связанные с ним ключевые документы были одобрены, они становятся целевыми планами проекта и могут быть изменены только после одобрения соответствующими органами управления, обычно советом директоров. Контроль изменений нужен не для предотвращения изменений, а для обеспечения того, чтобы каждое изменение было согласовано с соответствующим органом управления перед его реализацией.

Проекты используют управление конфигурацией (CM) как важный элемент. Управление конфигурацией может предоставляться как постоянный организационный сервис или обеспечиваться Отделом поддержки проектов (PSO). Все, что производит проект, является объектом для управления конфигурацией, это включает управление документацией, а также профильными продуктами и предоставляемыми результатами. Поэтому важно интегрировать использование процедур контроля изменений с системой управления конфигурацией, используемой проектом.

Система, установленная для управления изменениями, также должна включать управление основными проблемами. Журнал проблем должен быть создан в начале проекта, чтобы записывать данные и помогать в управлении изменениями и проблемами. Документ стратегии управления конфигурацией должен быть создан как часть плана и должен определять способ, с помощью которого изменения и проблемы управляются и решаются в течение всего времени работы над проектом.

Различие между проблемой и риском состоит в том, что проблема уже возникла, тогда как риск – это что-то, что может произойти или не произойти в какой-то момент в будущем.

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

Изменения происходят из двух источников:

Запрос о внесении изменения (RFC). Он исходит от клиента или пользователя и является запросом о каком-либо изменении одного из целевых планов проекта. Если реализация изменения требует любых дополнительных расходов, то обычно их оплачивает клиент. Поскольку все изменения связаны с тем, что было согласовано изначально, то обычно совет директоров имеет право на одобрение таких изменений.

Изменения, не отвечающие техническим требованиям. Они обычно исходят со стороны результатов проекта и уточняют некоторые аспекты, которые должны быть предоставлены проектом, но в данный момент их нет, или они не будут предоставлены согласно прогнозу. Сюда могут входить продукты или предоставляемые результаты, которые были упущены, или продукт, не соответствующий своей спецификации или критерию качества.

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

Также нужно решить, будет или нет совет директоров или старшее руководство участвовать в рассмотрении всех изменений проекта. Если предполагается много изменений, то совет директоров может назначить ответственное за изменения лицо, которое будет принимать решения относительно таких изменений от имени совета директоров. В таких случаях нужно определить правила назначения.

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

Далее описывается сама процедура контроля над изменениями.

Шаг 1. Когда появляется изменение или проблема, она должна быть классифицирована и записана в журнал проблем/изменений.

Шаг 2. Должен быть выполнен анализ влияния факторов, и обычно он должен включать компетентных специалистов из членов группы.

Анализ влияния факторов должен учитывать влияние изменения или проблемы (которое может быть положительным или отрицательным) на множество аспектов проекта, таких как:

• Время
• Стоимость
• Качество
• Масштаб
• Экономическое обоснование проекта
• Выгоды
• Риск

Очередность изменения или проблемы сначала должна быть определена инициатором, и повторно - после анализа влияния факторов. При выполнении анализа влияния факторов важно, чтобы представители из сферы деятельности проекта, пользователи конечных продуктов и те, кто поставляет ресурсы для проекта, были полностью вовлечены, чтобы было принято обоснованное решение.

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

Шаг 4. Теперь нужно решить - внедрять изменение или нет. Для запроса об изменении обычно требуется решение совета директоров проекта, тогда как несоответствие спецификации может потребовать решения только руководителя проекта, если он имеет достаточные полномочия.

Если проект использует управление по отклонениям, где были установлены границы допусков, то относительно внедрения любого предлагаемого изменения, выходящего за рамки допустимого отклонения, должен принимать решение совет директоров.

Во время внедрения руководитель проекта должен обеспечить, чтобы о состоянии проекта докладывалось совету директоров до того момента, когда проблема или изменение будут полностью внедрены.