Сколько изменений нужно для того, чтобы запустить процесс? Существуют ли изменения, которые недостаточно значительны для того, чтобы заполнять на них форму, получать чьи-то подписи и вообще тратить на них время и усилия? Это важные вопросы для руководителя проекта, и они порождают необходимость подумать о порогах изменений. Большинство проектов требуют от управляющих хороших менеджерских и бизнес-навыков. Если какое-то изменение рассматривается как незначительное, а план проекта может «поглотить» его без заметных последствий, просто сделайте необходимые корректировки и двигайтесь дальше (см. пример 1). Однако если при имплементации изменения превышен «порог чувствительности», это должно вызвать соответствующие действия и ваши, и вашей команды, направленные на «включение» процесса контроля изменений (см. пример 2).
Пример 1
Если проект стоимостью $5 000 000 вполне может выдержать изменение в $10, то запускать по нему процесс контроля изменений – неправильное решение. Адекватным порогом здесь может быть сумма в $500 (разумеется, в зависимости от ограничений по бюджету и стандартам отрасли).
Пример 2
Если дата завершения проекта на четыре месяца отстоит от даты запроса на изменение, а реализация этого изменения может вызвать задержку окончания проекта на неделю, нужно запускать процесс контроля изменения. Пороги изменений, связанных с расписанием проекта, требуют тщательного анализа их влияния на критические пути (или отсутствия такого влияния) на сроки проекта вообще. Как всегда, руководитель проекта при принятии решения должен ориентироваться на состояние среды, окружающей проект.
Поскольку эта среда в большинстве проектов постоянно меняется, пороги изменений часто очень изменчивы, и руководителю проекта необходимо серьезно рассчитывать на информацию и подсказки членов своей команды и заинтересованных сторон в том, что касается возможного влияния изменения на проект. Если у руководителя уже есть опыт управления процессами жизненного цикла других проектов, он сможет гораздо лучше понимать ценность информации при принятии решений в отношении изменений.
Журнал контроля изменений
Итак, журнал контроля изменений вступает в действие уже на шаге 1 процесса контроля изменений. Как вы, наверное, уже догадались, этот журнал также предназначен для идентификации предлагаемых изменений и отслеживания тех из них, которые принимаются.
В таблице 11.1 представлен шаблон, который вы можете либо использовать в данном виде, либо заузить или расширить в зависимости от того, что считаете необходимым. Если в вашей организации нет стандарта такого журнала, можете выбрать подходящий вариант. Руководитель проекта волен добавлять или опускать какую-то информацию в той степени, которую сочтет уместной.
Таблица 11.1.
Журнал контроля изменений проектовКак и другие шаблоны проектного менеджмента, этот журнал может показаться простым. Однако использовать его не всегда легко. Здесь ключевой элемент – дисциплина. В условиях, когда множатся изменения, риски и проблемы критического пути, необходима внутренняя дисциплина, чтобы отложить текущее дело и заняться журналом контроля изменений. Значительная часть заносимой в журнал информации может показаться самоочевидной и даже тривиальной. Однако какая-нибудь простейшая деталь или мелочь способны вырасти в большую проблему по мере развития проекта.
Номер, дата изменения и сокращенное описание изменения – это стандартная информация, заносимая в журнал. В шаблоне содержится колонка с данными лица, запрашивающего изменение и статус изменения. Бывают ситуации, когда изменение принимается, однако соображения по бюджету, расписанию, технологиям и чему-то еще затягивают завершение проекта или вообще делают невозможной реализацию изменений. Я предпочитаю понятия «Открыто/Закрыто» для обозначения статуса изменения. После принятия изменения данные о его влиянии на расписание и бюджет следует перенести в обновленный план. Некоторые руководители проектов добавляют в шаблон столбец «Возможное влияние изменения на содержание и задачи проекта» (перед столбцом «Примечания»). Что касается примечаний, они могут отражать несогласие с изменением заинтересованных сторон, технические проблемы и замечания по другим аспектам проекта.
Побочные результаты изменений проектов