Миф о контроле над изменениями

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

Прежде всего, нет такой вещи, как контроль над изменениями - вы наверняка не совсем верно поняли. Контролировать изменения – само по себе миф.

Мы уже второе десятилетие имеем сертификаты PMP, и почти такое же время мы обучаем управлению проектами, поэтому мы довольно хорошо знакомы с тем, что Институт управления проектами (PMI) пишет в руководстве "Совокупность знаний по управлению проектами (PMBOK)". Книга наполнена словами "контроль над изменениями", эта фраза появляется в большинстве глав. Если вы читали описание контроля над изменениями, например, в разделе 4.3 (Общий контроль над изменениями), вы увидите, что там на самом деле говорится об управлении изменениями.

Хотя это звучит придирчиво, но различие между словами "контроль" и "управление" очень важно: используемое вами слово может повлиять на ваше мышление и служить побуждением к различным действиям.

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

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

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

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

Управление изменениями может выполняться различными способами, и есть много инструментов, которые были разработаны, чтобы помочь в этом. Традиционные подходы к управлению изменениями обсуждаются в руководстве PMBOK, включая наличие системы формальных, документированных методов, описывающих, как оценивать и одобрять изменение внутри проекта, обычно с помощью "Совета по контролю над изменениями". Другие подходы, используемые в методах гибкого управления, включают в себя наличие ранжированного по очередности списка элементов масштаба проекта, которые можно легко обновить и изменить их приоритеты перед любым шагом цикла проекта, обеспечивая то, что группа всегда работает над следующими наиболее важными невыполненными заданиями. Конечно, обычно присутствует формальное утверждение этого измененного списка масштаба, но основная идея состоит в том, что масштаб может изменяться во время проекта, и в предоставлении формальных механизмов управления динамическим масштабом, которые весьма полезны для сильно подверженных изменениям проектов.

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

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

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

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