Профессиональное управление изменениями. Часть 1
По статистике средний ИТ-проект за месяц прирастает изменениям на 5%. Несложно посчитать, что за полгода проект изменяется практически на треть, а за год проект становится больше чем на половину. Более того, одной из основных причин неудачных ИТ-проектов является неуправляемый поток изменений, приводящий к провалу проекта. Предлагаю использовать системный подход к управлению изменениям.Процедура управления изменениями
Эта процедура основана на рекомендациях PMI PMBOK. Однако, это не теория, а выжимки из практики управления крупными ИТ-проектами с бюджетами 7-ого и 8-ого порядков (десятки и сотни миллионов рублей).Вначале будет рассказано об общей схеме управления изменениями. В последующих частях будут более детально описаны аспекты управления изменениями и как адаптировать эту процедуру к различным изменениям.(см. содержание внизу статьи).
Для сравнения, в большинстве проектов это выглядит так: 
1. Запрос на изменение Инициатор высказывает требование, которое выходит за рамки проекта и является изменением. Это еще не сигнал к действию, а пока что только запрос. 2. Фиксация запроса в реестре изменений Любые запросы на изменение нужно фиксировать в специальном документе «Реестр запросов на изменение» (или Реестр изменений), где содержится список всех запросов на изменения.Подробнее этот процесс будет рассмотрен в части 2.3. Анализ изменения Этот процесс позволяет понять, как предлагаемое изменение повлияет на проект. Также на этапе анализа проводится оценка последствий, что будет, если изменение принять и что проект потеряет, если отказаться от изменения.Подробнее этот процесс будет рассмотрен в части 2.4. Переговоры Как правило, одна из сторон настаивает на внесение изменения в проект, а другая противится этому. Поэтому нужно провести переговоры, обсудить варианты реализации и отклонения предлагаемого изменения и принять решение по нему.Подробнее этот процесс будет рассмотрен в части 2.5. Решение По результатам обсуждения предлагаемого изменения должно быть принято одно из трех решений: — Принять— Отклонить— Отложить.6. Внесение изменений в план 1) Внести изменения в базовый план (первоначальный план проекта), так как изначально работа над проектом планировалась по одному сценарию, а теперь этот сценарий изменился.2) В рабочий план, который должен являться вашим навигатором по проекту.7. Выполнение работ Так как изменение внесено в план, то оно является частью проекта. Работаем с ним, как с обычными задачами проекта.Здесь все просто. Нужно выполнить работы.8. Проверка результатов И сдать на проверку.Если работы приняты, то работы по реализации изменения считаются завершенными.Содержание Часть 1. Общая схема управления изменениямиЧасть 2. Реестр изменений, анализ изменения, переговорыЧасть 3. Категоризация изменений и адаптация процедуры управления имиЧасть 4. Управление изменениями в Scrum
