По статистике средний ИТ-проект за месяц прирастает изменениям на 5%. Несложно посчитать, что за полгода проект изменяется практически на треть, а за год проект становится больше чем на половину. Более того, одной из основных причин неудачных ИТ-проектов является неуправляемый поток изменений, приводящий к провалу проекта. Предлагаю использовать системный подход к управлению изменениям.
Эта процедура основана на рекомендациях PMI PMBOK. Однако, это не теория, а выжимки из практики управления крупными ИТ-проектами с бюджетами 7-ого и 8-ого порядков (десятки и сотни миллионов рублей).
Вначале будет рассказано об общей схеме управления изменениями. В последующих частях будут более детально описаны аспекты управления изменениями и как адаптировать эту процедуру к различным изменениям.(см. содержание внизу статьи).
Инициатор высказывает требование, которое выходит за рамки проекта и является изменением. Это еще не сигнал к действию, а пока что только запрос.
Любые запросы на изменение нужно фиксировать в специальном документе «Реестр запросов на изменение» (или Реестр изменений), где содержится список всех запросов на изменения.
Подробнее этот процесс будет рассмотрен в части 2.
Этот процесс позволяет понять, как предлагаемое изменение повлияет на проект. Также на этапе анализа проводится оценка последствий, что будет, если изменение принять и что проект потеряет, если отказаться от изменения.
Подробнее этот процесс будет рассмотрен в части 2.
Как правило, одна из сторон настаивает на внесение изменения в проект, а другая противится этому. Поэтому нужно провести переговоры, обсудить варианты реализации и отклонения предлагаемого изменения и принять решение по нему.
Подробнее этот процесс будет рассмотрен в части 2.
По результатам обсуждения предлагаемого изменения должно быть принято одно из трех решений:
— Принять
— Отклонить
— Отложить.
1) Внести изменения в базовый план (первоначальный план проекта), так как изначально работа над проектом планировалась по одному сценарию, а теперь этот сценарий изменился.
2) В рабочий план, который должен являться вашим навигатором по проекту.
Так как изменение внесено в план, то оно является частью проекта. Работаем с ним, как с обычными задачами проекта.
Здесь все просто. Нужно выполнить работы.
И сдать на проверку.
Если работы приняты, то работы по реализации изменения считаются завершенными.
Часть 1. Общая схема управления изменениями
Часть 2. Реестр изменений, анализ изменения, переговоры
Часть 3. Категоризация изменений и адаптация процедуры управления ими
Часть 4. Управление изменениями в Scrum
Процедура управления изменениями
Эта процедура основана на рекомендациях PMI PMBOK. Однако, это не теория, а выжимки из практики управления крупными ИТ-проектами с бюджетами 7-ого и 8-ого порядков (десятки и сотни миллионов рублей).
Вначале будет рассказано об общей схеме управления изменениями. В последующих частях будут более детально описаны аспекты управления изменениями и как адаптировать эту процедуру к различным изменениям.(см. содержание внизу статьи).
Для сравнения, в большинстве проектов это выглядит так:
1. Запрос на изменение
Инициатор высказывает требование, которое выходит за рамки проекта и является изменением. Это еще не сигнал к действию, а пока что только запрос.
2. Фиксация запроса в реестре изменений
Любые запросы на изменение нужно фиксировать в специальном документе «Реестр запросов на изменение» (или Реестр изменений), где содержится список всех запросов на изменения.
Подробнее этот процесс будет рассмотрен в части 2.
3. Анализ изменения
Этот процесс позволяет понять, как предлагаемое изменение повлияет на проект. Также на этапе анализа проводится оценка последствий, что будет, если изменение принять и что проект потеряет, если отказаться от изменения.
Подробнее этот процесс будет рассмотрен в части 2.
4. Переговоры
Как правило, одна из сторон настаивает на внесение изменения в проект, а другая противится этому. Поэтому нужно провести переговоры, обсудить варианты реализации и отклонения предлагаемого изменения и принять решение по нему.
Подробнее этот процесс будет рассмотрен в части 2.
5. Решение
По результатам обсуждения предлагаемого изменения должно быть принято одно из трех решений:
— Принять
— Отклонить
— Отложить.
6. Внесение изменений в план
1) Внести изменения в базовый план (первоначальный план проекта), так как изначально работа над проектом планировалась по одному сценарию, а теперь этот сценарий изменился.
2) В рабочий план, который должен являться вашим навигатором по проекту.
7. Выполнение работ
Так как изменение внесено в план, то оно является частью проекта. Работаем с ним, как с обычными задачами проекта.
Здесь все просто. Нужно выполнить работы.
8. Проверка результатов
И сдать на проверку.
Если работы приняты, то работы по реализации изменения считаются завершенными.
Содержание
Часть 1. Общая схема управления изменениями
Часть 2. Реестр изменений, анализ изменения, переговоры
Часть 3. Категоризация изменений и адаптация процедуры управления ими
Часть 4. Управление изменениями в Scrum
This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий