«Ни один план не выдерживает встречи с реальностью», – так говорил еще Наполен. И не удивительно, что даже самое грамотное техническое задание (ТЗ) по разработке и внедрению системы электронного документооборота (СЭД) или иной информационной системы (ИС) не может все предусмотреть заранее. Изменения неизбежны, просто не нужно их бояться, а лучше продумать, как вы будете ими управлять, чтобы снежный ком не превратился в лавину, которая вас снесет: как фиксировать запросы на изменения; далее – разным типам изменений нужно уделять разную долю внимания (процедура их согласования будет отличаться); какую стратегию «подкручивания гаек» в ходе опытной эксплуатации СЭД лучше выбрать; как отслеживать версии документов и продуктов проекта.
Проектный менеджмент об изменениях
Сначала немного возможно скучной теории. Начнем с выяснения, что считать изменением. Для этого, сначала обратимся к терминологии отечественных стандартов по управлению проектами:
Фрагмент документа
ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом»
3.6. Изменение в проекте:
Модификация утвержденного ранее содержания, сроков, ресурсов в проекте, а также установленных процедур...
5.3.8. Процесс планирования управления изменениями в проекте
Цель процесса: определение порядка работы с изменениями в проекте.
Выходы процесса: определен и документирован процесс работы с изменениями в проекте, а именно:
1) выявление изменений;
2) согласование и утверждение изменений;
3) организация учета версий документов и продуктов проекта;
4) доведение информации об изменениях до заинтересованных сторон.
Здесь процесс управления изменениями описан очень кратко и сухо, предполагается, видимо, что организации сами для себя определят порядок работы с изменениями, включая их документирование.
Теперь обратимся к популярному зарубежному источнику по проектному менеджменту – PMBoK, который дает свои определения:
Фрагмент документа
Руководство к Своду знаний по управлению проектами (Руководство PMBоK).
Четвертое издание. 2008 (Рroject Management Institute, Four Campus Boulevard, Newton Square, PA 19073-3299 USA/США)
Руководство к Своду знаний по управлению проектами (Руководство PMBоK).
Четвертое издание. 2008 (Рroject Management Institute, Four Campus Boulevard, Newton Square, PA 19073-3299 USA/США)
Изменение содержания – любое изменение содержания проекта. Изменение содержания практически всегда влечет за собой пересмотр расписания и стоимости проекта.
Запрос на изменение – формальное предложение внести изменения в какой-либо документ, поставляемый результат или базовый план.
Иными словами, авторы PMBoK изменениями в проекте считают лишь корректировку содержания, расписания или стоимости.
В PMBoK выделен процесс «Интегрированный контроль изменений». Его суть заключается в анализе всех запросов на изменение, их одобрении или отклонении, документировании этих изменений и т.д. Иными словами, речь идет об управлении изменениями, причем на протяжении всего проекта. PMBoK рекомендует при необходимости создавать специальную группу для анализа изменений, их одобрения / отклонения, а также фиксации и информирования о принятых решениях. Запомним этот нюанс, т.к. о нем речь пойдет далее в статье. Что касается документирования изменений в проекте, то авторы PMBoK рекомендуют делать это как минимум в двух документах:
- запросе на изменение (показан в Примерах 1 и 2) и
- журнале регистрации изменений (Пример 4).
С теорией покончено, теперь переходим к практике.
Способы управления разными типами изменений
Прежде всего, необходимо типизировать изменения. Например, с точки зрения критичности разделить их на 2 большие группы (существенные и несущественные) и в зависимости от этого выстраивать процесс согласования.
Несущественными изменениями в проекте являются все изменения, которые не влияют на 3 базовых аспекта:
- стоимость,
- сроки,
- результат проекта,
т.е. какие-либо организационные изменения.
Например, произошли замены в Управляющем комитете проекта, т.е. роль его члена осталась без изменений, а вот работник, ее выполняющий поменялся. Здесь речь идет о «смене Ф.И.О.». С точки зрения воздействия на проект это несущественно. Ниже приведен пример того, как в запросе можно изложить данное изменение.
Пример 1. Запрос на несущественное изменение
Что происходит дальше? Если изменение не согласовано, то все остается как прежде. А вот если запрос согласован, то сначала необходимо отразить это в специальном журнале регистрации (Пример 4), затем внести изменения в действующий приказ о составе Проектного комитета.
Очевидно, что согласование несущественных изменений можно «запустить» по очень простому пути: достаточно будет решения коллегиального органа проекта, в зону компетенции которого входит согласование организационных изменений (в приведенном примере – это Проектный комитет). Кроме того, заседания Проектного комитета по подобным вопросам можно проводить в заочной форме, направив проект протокола членам комитета, например, по электронной почте. Может возникнуть вопрос: «А зачем вообще затевать согласование несущественных изменений, тем более, когда этот процесс достаточно бюрократичный? Зачем терять на это...
