0,0
рейтинг
15 мая 2014 в 12:23

Управление → Профессиональное управление изменениями

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

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


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



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


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

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

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

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

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

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

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

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

5. Решение

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

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

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

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

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

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

И сдать на проверку.
Если работы приняты, то работы по реализации изменения считаются завершенными.
Дмитрий Кирилкин @Kirilkin
карма
2,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Управление

Комментарии (6)

  • +2
    Не черновичок, часом, опубликовали?..
  • 0
    <= отклонить, и => отклонить
    а где же отложить? Каковы детали этой ветки? Когда и в киких условиях принимаем, и когда возвращаемся к рассмотру изменения?
    • 0
      Спасибо за замечание.
      Поправил схему.
      В идеале должно быть так.
      1. Принято решение «Отложить»
      2. Нужно уточнить до какой даты. И потом когда наступит дата, то снова обсудить изменение…
      Процедура может повторится еще 2 раза.
      3. Если 3 раза принимается решение «Отложить», то изменение автоматически принимает статус «Отклонено». (Это должно быть закреплено в регламенте управления изменения или аналогичными документами. Либо на словах то это звучит так: «Коллеги, мы уже третий раз по этому изменению никак не можем принять решение. Давайте его отклоним раз в нем нет такой ценности». Подобная фраза заставляет серьезнее отнестись к изменению и все-таки принять решение.)

      На практике все зависит от вашей настойчивости и вашей способности заставить заказчика принять решение по изменениям. Может он готов запустить изменение в работу, но он боится попросить у своего шефа дополнительный бюджет, поэтому все откладывает на потом. А без бюджета вы не запустите изменение в проект.
      • 0
        Стало яснее, но есть еще одно замечание:
        Если 3 раза отложено
        на блок-схеме изображен как if. Нужно бы добавить описанную Вами ветку возврата.
        5. Решение
        на блок-схеме изображен как if, а нужно бы как switch.

        Думаю более правильное будет вот так
        Скрытый текст



        P.S.
        Управление изменениями в Scrum
        десятки и сотни миллионов рублей
        Довольно высокий уровень. Завидую если владеете достоверной информацией. Но можете ли сравнить подход scrum и допустим waterfall (я лично с ним только и сталкивался). Очень интересно было бы.
        • 0
          waterfall — каскадная модель управления проектами (содержащая 1 итерацию), scrum — итеративная модель.
          Большинство проектов во всех сферах жизни (ИТ, строительство, организационные проекты ) реализуются по каскадной модели.
          Итеративная модель имеет преимущество в том, что последовательность этапов (анализ — разработка — тестирование и т.д.) повторяется много раз, а каскадная модель предполагает прохождение точек невозврата (один этап завершился — начался новый, без возврата назад). Поэтому и управлять изменениями в скрам можно более гибко, чем в водопаде.

          Но описанный выше подход применяется и к scrum. Просто он более универсальный, чем scrum. Об этом будет описано в следующих частях.
  • –1
    del

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.