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

Управление изменениями - это совокупность заранее оговоренных процедур и правил, в соответствии с которыми изменения вносятся в проект. Любое изменение, прежде чем оно будет внесено в план проекта, вначале рассматривается лицами, имеющими соответствующие полномочия, которые ответственны за внесение изменений. После рассмотрения изменение либо принимается, либо отвергается (или откладывается до выяснения обстоятельств).

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

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

Рассмотрим типичную схему внесения измений в проект. В этой схеме участвуют все ответственные структуры - как заказчика, так и исполнителя

clip_image002


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

Помимо очевидной стороны управления изменениями - снижение рисков предъявления претензии заказчиком - существует и не столь очевидная:

В случае прохождения изменений по пути, обозначенному черной стрелкой, для их включения в проект необходимо приложить определенные усилия. Если изменения действительно важны, и без них потребительские свойства продукта сильно страдают, инженер и менеджер заказчика решатся побеспокоить свое высокое руководство на предмет подписания допсоглашения к контракту. Если же это произойдет в 10-й раз за месяц, вряд ли они получат с такой же легкостью одобрение своего руководства, как и в первый раз.
Если говорить о практике, то каждое изменение, включая действительно необходимые, таким способом проводить слишком дорого. Поэтому на практике это выглядит так: участникам команды проекта исполнителя на совещаниях разъясняется вся важность контроля изменений и категорически запрещается внесение изменений без согласования с руководителем проекта. В первый раз все изменения делаются по согласованию между средним менеджментом исполнителя и заказчика, а затем, через определенный период (обычно это месяц), предъявляются к оплате и подписанию дополнительного соглашения о переносе сроков. Если заказчик соглашается оплатить изменения и перенести сроки, эта схема продолжает работать до конца проекта. Если же нет – немедленно собирается совещание представителей заказчика и исполнителя, где детально прописывается содержание каждого пункта технического задания и в дальнейшем работы ведутся строго по ТЗ. Либо контракт разрывается, если стороны не смогли прийти к соглашению. Конечно, это очень неприятно, но лучше сделать это в начале проекта, чем в конце, когда уже истрачены деньги и потеряно время.

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

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

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