По статистике средний ИТ-проект за месяц прирастает изменениям на 5%. Несложно посчитать, что за полгода проект изменяется практически на треть, а за год проект становится больше чем на половину. Более того, одной из основных причин неудачных ИТ-проектов является неуправляемый поток изменений, приводящий к провалу проекта. Предлагаю использовать системный подход к управлению изменениям.

Процедура управления изменениями

Эта процедура основана на рекомендациях PMI PMBOK. Однако, это не теория, а выжимки из практики управления крупными ИТ-проектами с бюджетами 7-ого и 8-ого порядков (десятки и сотни миллионов рублей).
Вначале будет рассказано об общей схеме управления изменениями. В последующих частях будут более детально описаны аспекты управления изменениями и как адаптировать эту процедуру к различным изменениям.(см. содержание внизу статьи).

Для сравнения, в большинстве проектов это выглядит так:

1. Запрос на изменение

Инициатор высказывает требование, которое выходит за рамки проекта и является изменением. Это еще не сигнал к действию, а пока что только запрос.

2. Фиксация запроса в реестре изменений

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

3. Анализ изменения

Этот процесс позволяет понять, как предлагаемое изменение повлияет на проект. Также на этапе анализа проводится оценка последствий, что будет, если изменение принять и что проект потеряет, если отказаться от изменения.
Подробнее этот процесс будет рассмотрен в части 2.

4. Переговоры

Как правило, одна из сторон настаивает на внесение изменения в проект, а другая противится этому. Поэтому нужно провести переговоры, обсудить варианты реализации и отклонения предлагаемого изменения и принять решение по нему.
Подробнее этот процесс будет рассмотрен в части 2.

5. Решение

По результатам обсуждения предлагаемого изменения должно быть принято одно из трех решений:
— Принять
— Отклонить
— Отложить.

6. Внесение изменений в план

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

7. Выполнение работ

Так как изменение внесено в план, то оно является частью проекта. Работаем с ним, как с обычными задачами проекта.
Здесь все просто. Нужно выполнить работы.

8. Проверка результатов

И сдать на проверку.
Если работы приняты, то работы по реализации изменения считаются завершенными.

Содержание

Часть 1. Общая схема управления изменениями
Часть 2. Реестр изменений, анализ изменения, переговоры
Часть 3. Категоризация изменений и адаптация процедуры управления ими
Часть 4. Управление изменениями в Scrum

Автор: Kirilkin

Источник