Стандартные ошибки управления проектами: плохое управление изменениями

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

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

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

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

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

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

Стратегии предотвращения

Начинайте ваш проект с хорошего плана управления изменениями. Хороший план управления изменениями должен содержать в себе любое изменение, вероятность появления которого есть в вашем проекте. План должен поддерживать все лучшие методы, описанные в PMBOK, но быть приспособленным к размеру, сложности и отрасли проекта. Вы должны определить как минимум два процесса - так называемые "Легкое управление изменениями" и "Полное управление изменениями". Полное управление изменениями должно подходить для масштабных изменений, вплоть до и включая те, относительно которых принимать решения будет ваш заказчик, спонсор или исполнительный управляющий комитет. Легкое управление изменениями подходит для минимальных изменений. Убедитесь, что административные накладные расходы, вызванные каждым процессом, пропорциональны размеру изменения.

Хороший план определяет действия и задачи, которые должны быть выполнены в ходе процесса, назначает людей на эти задачи и задает любые сроки завершения, которые должны выполняться. Выделите в вашем графике достаточно времени на выполнение задач. Поскольку вы не можете предсказать число запросов на изменения, которое вы получите, или то, насколько сложными будут эти запросы, для каждой стадии проекта вам нужно задать резервное время. Задайте резервное время для каждого повторения, если вы используете итерационный метод разработки. Один из способов борьбы с неопределенностью, окружающей число и сложность запросов на изменения, - это поднять тревогу, когда буфер будет приближаться к полному исчерпанию (скажем, 90%). У вас будет два варианта действий, когда вы достигнете этой точки: вы можете завершить процесс изменений (нормально, если вы почти закончили проект), или вы можете запросить предоставление большего количества времени для рассмотрения запросов на изменения. Это изменение потребует больших ресурсов (увеличение бюджета) или сокращения масштаба.

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

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