ݺߣ

ݺߣShare a Scribd company logo

Модуль 12. Лекция 51-52. Управление изменениями проекта

•
•
Yana Brodetski
Yana Brodetski

Управление изменениями проекта ● Планирование управления изменениями на проекте ● Составление плана управления изменениями ● Разница между изменением и багом ● Методы оценки влияния изменения на проект ● Утверждение и внесение изменений на всех этапах проекта

1 of 17
Download to read offline
Управление проектами. Модуль 12
Лекция 51-52 Управление изменениями проекта ● Планирование управления изменениями на проекте ● Составление плана управления изменениями ● Разница между изменением и багом ● Методы оценки влияния изменения на проект ● Утверждение и внесение изменений на всех этапах проекта
Что такое управление изменениями? ● Основная цель системы управления изменениями заключается в предоставлении стандартного процесса для представления, документирования и анализа изменений в подготовке к приоритезации этих исправлений / улучшений. ● В нем определяются изменения, полномочия для одобрения изменений, поддержка для осуществления изменений и процесс формальных отклонений и отказ от первоначальных согласованных требований. ● Процесс управления изменениями устанавливает упорядоченную и эффективную процедуру отслеживания представления, координации, обзора, оценки, категоризации и утверждения для выпуска всех изменений в базовые показатели проекта. ● Система управления изменениями определяет руководящие принципы управления изменениями проекта и подробно описывает, как будут документированы, организованы и управляются изменения ● При управлении конкурирующими требованиями необходимо оценить, как изменение одного ограничения влияет на одно или оба из оставшихся двух. Также необходимо проанализировать объем, время и стоимость, чтобы понять затраты и преимущества принятия требуемого изменения. ● Каждый запрос на изменение уникален, и надлежащая оценка каждого запроса на изменение является важной практикой управления.
Что такое управление изменениями? Способ оценки запросов зависит от их важности и срочности с целью: ● Понимание влияния изменений на все затронутые стороны ● Обеспечение учета всех возможных ситуаций ● Консолидация всех индивидуальных анализов воздействия для принятия обоснованного управленческого решения ● Обеспечение должной осмотрительности при оценке запроса на изменение ● Обеспечение консультаций с заинтересованными сторонами ● Оценка влияния рассматриваемого изменения и взвешивание стоимости с учетом преимуществ первоначального запроса на изменение Существует два типа изменений, которые необходимо учитывать в течение всего проекта: изменение продукта и изменение проекта. В рамках каждой из этих двух категорий необходимо учитывать время, продолжительность, стоимость, ресурс, конечный результат, продукт, процесс и качество при оценке запроса на изменение. ● Изменение продукта. PMI PMBOK определяет продукт в качестве артефакта, который производится, поддается количественному определению и может быть либо конечным элементом, либо самим элементом компонента. Изменение продукта влияет на конечные результаты продукта, его функциональность, качество и т. д. Изменение продукта может быть достаточно большим, чтобы также повлиять на изменение проекта. ● Изменение проекта. PMI PMBOK определяет проект как временную попытку создать уникальный продукт, услугу или результат. Изменение проекта влияет на масштаб проекта, время, продолжительность, стоимость, ресурсы, процессы и т. д.
Управление изменениями проекта Чтобы легче управлять изменениями в рамках проекта, особенно крупными сложными проектами, общепринятой практикой является установление пороговых значений в системе управления изменениями, которые определяют, кто имеет полномочия утверждать, какой уровень изменений. Изменения, связанные с увеличением размера или масштаба, требуют одобрения на более высоком уровне. Например, менеджер проекта может быть уполномочен лично одобрить изменения с воздействием проекта менее 5000 долларов. Изменения с воздействием на проект более 5000 долл. требуют одобрения Советом по контролю за изменениями (CCB). CCB (Change Control Board) является официально сформированной группой заинтересованных сторон, отвечающих за рассмотрение, оценку, утверждение, отсрочку или отклонение изменений в проекте. Все решения и рекомендации, связанные с запросами на изменение, записываются. Команда проекта часто работает с CCB, чтобы сообщить подробности о запрошенных изменениях и помочь оценить наиболее подходящий ответ.
План управления изменениями ● Время, затрачиваемое на управление изменениями, начинается, прежде чем они даже произойдут, конечно, во время группы процессов планирования. Это время, когда вы должны создать план управления изменениями, чтобы вы знали, как обрабатывать изменения, когда они происходят. Основные элементы Плана управления изменениями ID Элемент плана Пояснение 1 Процедуры управления изменениями (Change Control Procedures) Общие правила и процедуры, посредством которых изменения утверждаются, проверяются и выполняются 2 План управления изменениями (Change Control Plan) В котором описывается, как изменения будут контролироваться и контролироваться в зависимости от того, происходят ли они во время процесса выполнения или в процессе мониторинга и контроля. 3 Совещания для обсуждения изменений (Change Control Meetings) Совет по контролю изменений отвечает за утверждение или отклонение изменений; Совещания по контролю за изменениями предназначены для оценки изменений, создания вариантов и подготовки запросов на изменение для представления тому, кто имеет полномочия одобрять эти изменения (PM, Control Control Board или спонсор). 4 Совет по контролю изменений (Change Control Board) Правила создания CCB для утверждения изменений (кто сидит на борту, у кого есть полномочия на утверждение и т. Д.), 5 Процедура авторизации измений (Change Authorization Procedures) Уровни полномочий для авторизации изменений (т. е. Изменения могут быть разрешены PM, CCB или спонсором в зависимости от степени изменения 6 Система управления изменениями (Change Control System) Это часть Информационной системы управления проектами и включает в себя стандартные шаблоны для отслеживания и контроля изменений
План управления изменениями
Требования к фиксации запроса на изменение Все проекты, независимо от типа или размера, должны вести журнал изменений и регулярно управлять запрошенными изменениями. По мере того, как запросы изменений отправляются и разрешаются, журнал изменений обновляется и, таким образом, служит исторической записью запрошенных изменений, которые были рассмотрены на протяжении всей жизни проекта. Журнал изменений содержит информацию, такую как: ● ID ● Тип изменения ● Описание изменения ● Инициатор ● Дата инициации ● Дата согласования ● Статус ● Комментарии Change Log Project: <Project Name> Change No. Change Type Description of Change Requestor Date Submitted Date Approved Status Comments Each change request is assigned a reference number. This may be a design, scope, schedule or other type of change. The change request should be described in detail. Who initiated the change request? When was the request submitted? When was the request approved? Is the change request open, closed or pending? Has it been approved, denied or deferred? This section may describe why the change request was rejected, deferred or provide any other useful information.
Процесс контроля изменений Step Executor Description [Шаг 1] Определите необходимость изменения Project Stakeholders Соберите всю необходимую информацию от подателя заявки. Сообщать информацию об изменении Менеджеру проекта [Шаг 2] Фиксация изменения Project Manager Менеджер проектов вводит CR в форму CR и журнал. (CR = Change Request) Статус CR обновляется по всему процессу CR по мере необходимости [Шаг 3] Оценить изменения Project Manager and Project Team Руководитель проекта проводит предварительный анализ воздействия изменения на риски, стоимость, график и содержание и запросит разъяснений у членов команды и инициатора запроса на изменения [Шаг 4] Отправка запроса на изменение в CCB Project Manager Менеджер проекта должен предоставить CR, а также предварительный анализ в CCB для рассмотрения [Шаг 5] Получение решения о запросе на изменение CCB CCB обсудит предлагаемое изменение и примет решение о том, будет ли оно одобрено на основе всей представленной информации [Шаг 6] Внедрение изменений Project Manager Если изменение одобрено CCB, менеджер проекта обновляет проектную документацию по мере необходимости. Смещает baseline
Основные требования
Типы изменений. ● Изменение расписания - может повлиять на уже утвержденное расписание проекта. Стратегия: Эти изменения могут потребовать быстрого отслеживания, сбоя или повторной базовой настройки графика в зависимости от значимости воздействия. ● Изменение бюджета – может повлиять на уже утвержденный бюджет проекта. Стратегия: этим изменениям могут потребовать дополнительное финансирование, высвобождение финансирования, которое больше не требуется, или добавление резервов к проекту или менеджементу. ● Изменение содержания (требовний)- изменения, которые необходимы и влияют на содержание проекта, которые могут быть результатом не выявленных требований , которые изначально не планировались для проекта. Стратегия: Эти изменения могут потребовать пересмотра WBS, устава проект, содержания проекта и другой проектной документации по мере необходимости
Почему изменяются требования? ● Внешние факторы- это те источники изменений, которые команда проекта не может контролировать и возникают по следующим причинам: ● Произошли изменения проблемы, которую мы пытались решить с помощью новой системы. ● Пользователи изменили свое мнение о том, чего они хотят от системы, или свои предпочтения. ● Изменилась внешняя среда, что привело к появлению новых ограничений и/или новых возможностей ● Вошла в строй новая система. Одним из самых неожиданных внешних факторов возникновения изменений (и главной причиной возникновения синдрома “да, но…”) является то, что само появление новой системы приводит к тому, что меняются требования к ней.
Почему изменяются требования? ● Внутренние факторы: ● При первоначальном выявлении требований нам не удалось задать правильные вопросы нужным людям и в нужное время. ● Нам не удалось создать практический процесс, позволяющий справиться с изменениями требований, которые являются нормой при пошаговой разработке. ● “Просачивание требований”= неофициальные требования: ● Упомянутые дистрибьюторами улучшения, о которых программисты случайно услышали на переговорах ● Прямые запросы клиентов, обращенные к программистам ● Ошибки, оставшиеся в отгруженной версии продукта, которые теперь нуждаются в сопровождении ● Аппаратные функции, которые в итоге не вошли в продукт или не работают. ● Функции, включенные программистом из “лучших побуждений” (в расчете, что это понравится клиенту) ● Изменение масштаба в ответ на действия конкурентов ● Сюрпризы” программистов
Модуль 12. Лекция 51-52. Управление изменениями проекта
Best Practices для управления изменениями ● Документирование. Запросы на изменение должны быть централизованно документированы с использованием некоторого типа журнала. Шаблон журнала запросов на изменение предоставляется в конце этого руководства и должен использоваться в отсутствие чего-то более сложного, доступного для команды проекта. ● Уникальные записи. Каждый запрос на изменение должен записываться как одна позиция. Не объединяйте несколько запросов под одним идентификатором запроса на изменение. ● Итеративность - Управление изменениями - это непрерывный итеративный процесс, проводимый на протяжении всего жизненного цикла проекта. ● Обзор. Регулярный обзор запросов на изменение - это хорошая практика управления проектами. В зависимости от сложности проекта процесс рассмотрения может происходить ежедневно, но должен выполняться как минимум еженедельно даже для самых простых проектов. ● Система управления изменениями. Формально определенная система управления изменениями должна быть документирована и передана команде проекта
Best Practices для управления изменениями ● Определить ответственных - установить согласованные пороговые значения, указанные в системе управления изменениями, которая определяет, кто имеет право утверждать, какие виды изменений. ● Анализ. Анализ влияния одобрения запроса на изменение продукта, проекта и программы, а также влияния не одобрения запроса на изменение. ● Тройные ограничения. Анализ запросов на изменение в зависимости от объема, времени и затрат. При управлении конкурирующими требованиями оценивайте, как изменение одного ограничения влияет на одно или оба из оставшихся двух. Эта оценка поможет проекту понять затраты и преимущества принятия требуемого изменения. ● Критерии приемки. Определите и задокументируйте критерии для принятия результатов, указанных в функциональных спецификациях для одобренного запроса на изменение. ● Back Out Plan - определение и документирование критериев для поддержки функциональности одобренного запроса на изменение в случае неожиданных последствий.
Best Practices для управления изменениями ● План тестирования. Цель плана тестирования - сообщить намерение тестируемых действий для одобренного запроса на изменение. Крайне важно, чтобы этот документ был создан как можно раньше после того, как изменение было одобрено. ● Оценка риска. При определении рисков, связанных с внесением требуемого изменения, подумайте о том, что может пойти не так. Определите потенциальные препятствия для успеха, чтобы риск можно было уменьшить или устранить. Определите события, которые могут произойти, что может снизить вероятность доставки запроса на изменение. ● Организационные изменения. При оценке запросов на изменение укажите влияние организационных изменений, которое может разрешить это изменение проекту, клиенту или организации. ● Производство, операции и техническое обслуживание. При переходе на этап эксплуатации и технического обслуживания жизненного цикла проекта управление изменениями может осуществляться иначе, чем во время разработки. Переоцените план управления изменениями задолго до этого и, при необходимости, внесите обновления, чтобы учитывать любые различия в подходах, процессах, управлении и т. Д

More Related Content

Модуль 12. Лекция 51-52. Управление изменениями проекта

  • 2. Лекция 51-52 Управление изменениями проекта ● Планирование управления изменениями на проекте ● Составление плана управления изменениями ● Разница между изменением и багом ● Методы оценки влияния изменения на проект ● Утверждение и внесение изменений на всех этапах проекта
  • 3. Что такое управление изменениями? ● Основная цель системы управления изменениями заключается в предоставлении стандартного процесса для представления, документирования и анализа изменений в подготовке к приоритезации этих исправлений / улучшений. ● В нем определяются изменения, полномочия для одобрения изменений, поддержка для осуществления изменений и процесс формальных отклонений и отказ от первоначальных согласованных требований. ● Процесс управления изменениями устанавливает упорядоченную и эффективную процедуру отслеживания представления, координации, обзора, оценки, категоризации и утверждения для выпуска всех изменений в базовые показатели проекта. ● Система управления изменениями определяет руководящие принципы управления изменениями проекта и подробно описывает, как будут документированы, организованы и управляются изменения ● При управлении конкурирующими требованиями необходимо оценить, как изменение одного ограничения влияет на одно или оба из оставшихся двух. Также необходимо проанализировать объем, время и стоимость, чтобы понять затраты и преимущества принятия требуемого изменения. ● Каждый запрос на изменение уникален, и надлежащая оценка каждого запроса на изменение является важной практикой управления.
  • 4. Что такое управление изменениями? Способ оценки запросов зависит от их важности и срочности с целью: ● Понимание влияния изменений на все затронутые стороны ● Обеспечение учета всех возможных ситуаций ● Консолидация всех индивидуальных анализов воздействия для принятия обоснованного управленческого решения ● Обеспечение должной осмотрительности при оценке запроса на изменение ● Обеспечение консультаций с заинтересованными сторонами ● Оценка влияния рассматриваемого изменения и взвешивание стоимости с учетом преимуществ первоначального запроса на изменение Существует два типа изменений, которые необходимо учитывать в течение всего проекта: изменение продукта и изменение проекта. В рамках каждой из этих двух категорий необходимо учитывать время, продолжительность, стоимость, ресурс, конечный результат, продукт, процесс и качество при оценке запроса на изменение. ● Изменение продукта. PMI PMBOK определяет продукт в качестве артефакта, который производится, поддается количественному определению и может быть либо конечным элементом, либо самим элементом компонента. Изменение продукта влияет на конечные результаты продукта, его функциональность, качество и т. д. Изменение продукта может быть достаточно большим, чтобы также повлиять на изменение проекта. ● Изменение проекта. PMI PMBOK определяет проект как временную попытку создать уникальный продукт, услугу или результат. Изменение проекта влияет на масштаб проекта, время, продолжительность, стоимость, ресурсы, процессы и т. д.
  • 5. Управление изменениями проекта Чтобы легче управлять изменениями в рамках проекта, особенно крупными сложными проектами, общепринятой практикой является установление пороговых значений в системе управления изменениями, которые определяют, кто имеет полномочия утверждать, какой уровень изменений. Изменения, связанные с увеличением размера или масштаба, требуют одобрения на более высоком уровне. Например, менеджер проекта может быть уполномочен лично одобрить изменения с воздействием проекта менее 5000 долларов. Изменения с воздействием на проект более 5000 долл. требуют одобрения Советом по контролю за изменениями (CCB). CCB (Change Control Board) является официально сформированной группой заинтересованных сторон, отвечающих за рассмотрение, оценку, утверждение, отсрочку или отклонение изменений в проекте. Все решения и рекомендации, связанные с запросами на изменение, записываются. Команда проекта часто работает с CCB, чтобы сообщить подробности о запрошенных изменениях и помочь оценить наиболее подходящий ответ.
  • 6. План управления изменениями ● Время, затрачиваемое на управление изменениями, начинается, прежде чем они даже произойдут, конечно, во время группы процессов планирования. Это время, когда вы должны создать план управления изменениями, чтобы вы знали, как обрабатывать изменения, когда они происходят. Основные элементы Плана управления изменениями ID Элемент плана Пояснение 1 Процедуры управления изменениями (Change Control Procedures) Общие правила и процедуры, посредством которых изменения утверждаются, проверяются и выполняются 2 План управления изменениями (Change Control Plan) В котором описывается, как изменения будут контролироваться и контролироваться в зависимости от того, происходят ли они во время процесса выполнения или в процессе мониторинга и контроля. 3 Совещания для обсуждения изменений (Change Control Meetings) Совет по контролю изменений отвечает за утверждение или отклонение изменений; Совещания по контролю за изменениями предназначены для оценки изменений, создания вариантов и подготовки запросов на изменение для представления тому, кто имеет полномочия одобрять эти изменения (PM, Control Control Board или спонсор). 4 Совет по контролю изменений (Change Control Board) Правила создания CCB для утверждения изменений (кто сидит на борту, у кого есть полномочия на утверждение и т. Д.), 5 Процедура авторизации измений (Change Authorization Procedures) Уровни полномочий для авторизации изменений (т. е. Изменения могут быть разрешены PM, CCB или спонсором в зависимости от степени изменения 6 Система управления изменениями (Change Control System) Это часть Информационной системы управления проектами и включает в себя стандартные шаблоны для отслеживания и контроля изменений
  • 8. Требования к фиксации запроса на изменение Все проекты, независимо от типа или размера, должны вести журнал изменений и регулярно управлять запрошенными изменениями. По мере того, как запросы изменений отправляются и разрешаются, журнал изменений обновляется и, таким образом, служит исторической записью запрошенных изменений, которые были рассмотрены на протяжении всей жизни проекта. Журнал изменений содержит информацию, такую как: ● ID ● Тип изменения ● Описание изменения ● Инициатор ● Дата инициации ● Дата согласования ● Статус ● Комментарии Change Log Project: <Project Name> Change No. Change Type Description of Change Requestor Date Submitted Date Approved Status Comments Each change request is assigned a reference number. This may be a design, scope, schedule or other type of change. The change request should be described in detail. Who initiated the change request? When was the request submitted? When was the request approved? Is the change request open, closed or pending? Has it been approved, denied or deferred? This section may describe why the change request was rejected, deferred or provide any other useful information.
  • 9. Процесс контроля изменений Step Executor Description [Шаг 1] Определите необходимость изменения Project Stakeholders Соберите всю необходимую информацию от подателя заявки. Сообщать информацию об изменении Менеджеру проекта [Шаг 2] Фиксация изменения Project Manager Менеджер проектов вводит CR в форму CR и журнал. (CR = Change Request) Статус CR обновляется по всему процессу CR по мере необходимости [Шаг 3] Оценить изменения Project Manager and Project Team Руководитель проекта проводит предварительный анализ воздействия изменения на риски, стоимость, график и содержание и запросит разъяснений у членов команды и инициатора запроса на изменения [Шаг 4] Отправка запроса на изменение в CCB Project Manager Менеджер проекта должен предоставить CR, а также предварительный анализ в CCB для рассмотрения [Шаг 5] Получение решения о запросе на изменение CCB CCB обсудит предлагаемое изменение и примет решение о том, будет ли оно одобрено на основе всей представленной информации [Шаг 6] Внедрение изменений Project Manager Если изменение одобрено CCB, менеджер проекта обновляет проектную документацию по мере необходимости. Смещает baseline
  • 11. Типы изменений. ● Изменение расписания - может повлиять на уже утвержденное расписание проекта. Стратегия: Эти изменения могут потребовать быстрого отслеживания, сбоя или повторной базовой настройки графика в зависимости от значимости воздействия. ● Изменение бюджета – может повлиять на уже утвержденный бюджет проекта. Стратегия: этим изменениям могут потребовать дополнительное финансирование, высвобождение финансирования, которое больше не требуется, или добавление резервов к проекту или менеджементу. ● Изменение содержания (требовний)- изменения, которые необходимы и влияют на содержание проекта, которые могут быть результатом не выявленных требований , которые изначально не планировались для проекта. Стратегия: Эти изменения могут потребовать пересмотра WBS, устава проект, содержания проекта и другой проектной документации по мере необходимости
  • 12. Почему изменяются требования? ● Внешние факторы- это те источники изменений, которые команда проекта не может контролировать и возникают по следующим причинам: ● Произошли изменения проблемы, которую мы пытались решить с помощью новой системы. ● Пользователи изменили свое мнение о том, чего они хотят от системы, или свои предпочтения. ● Изменилась внешняя среда, что привело к появлению новых ограничений и/или новых возможностей ● Вошла в строй новая система. Одним из самых неожиданных внешних факторов возникновения изменений (и главной причиной возникновения синдрома “да, но…”) является то, что само появление новой системы приводит к тому, что меняются требования к ней.
  • 13. Почему изменяются требования? ● Внутренние факторы: ● При первоначальном выявлении требований нам не удалось задать правильные вопросы нужным людям и в нужное время. ● Нам не удалось создать практический процесс, позволяющий справиться с изменениями требований, которые являются нормой при пошаговой разработке. ● “Просачивание требований”= неофициальные требования: ● Упомянутые дистрибьюторами улучшения, о которых программисты случайно услышали на переговорах ● Прямые запросы клиентов, обращенные к программистам ● Ошибки, оставшиеся в отгруженной версии продукта, которые теперь нуждаются в сопровождении ● Аппаратные функции, которые в итоге не вошли в продукт или не работают. ● Функции, включенные программистом из “лучших побуждений” (в расчете, что это понравится клиенту) ● Изменение масштаба в ответ на действия конкурентов ● Сюрпризы” программистов
  • 15. Best Practices для управления изменениями ● Документирование. Запросы на изменение должны быть централизованно документированы с использованием некоторого типа журнала. Шаблон журнала запросов на изменение предоставляется в конце этого руководства и должен использоваться в отсутствие чего-то более сложного, доступного для команды проекта. ● Уникальные записи. Каждый запрос на изменение должен записываться как одна позиция. Не объединяйте несколько запросов под одним идентификатором запроса на изменение. ● Итеративность - Управление изменениями - это непрерывный итеративный процесс, проводимый на протяжении всего жизненного цикла проекта. ● Обзор. Регулярный обзор запросов на изменение - это хорошая практика управления проектами. В зависимости от сложности проекта процесс рассмотрения может происходить ежедневно, но должен выполняться как минимум еженедельно даже для самых простых проектов. ● Система управления изменениями. Формально определенная система управления изменениями должна быть документирована и передана команде проекта
  • 16. Best Practices для управления изменениями ● Определить ответственных - установить согласованные пороговые значения, указанные в системе управления изменениями, которая определяет, кто имеет право утверждать, какие виды изменений. ● Анализ. Анализ влияния одобрения запроса на изменение продукта, проекта и программы, а также влияния не одобрения запроса на изменение. ● Тройные ограничения. Анализ запросов на изменение в зависимости от объема, времени и затрат. При управлении конкурирующими требованиями оценивайте, как изменение одного ограничения влияет на одно или оба из оставшихся двух. Эта оценка поможет проекту понять затраты и преимущества принятия требуемого изменения. ● Критерии приемки. Определите и задокументируйте критерии для принятия результатов, указанных в функциональных спецификациях для одобренного запроса на изменение. ● Back Out Plan - определение и документирование критериев для поддержки функциональности одобренного запроса на изменение в случае неожиданных последствий.
  • 17. Best Practices для управления изменениями ● План тестирования. Цель плана тестирования - сообщить намерение тестируемых действий для одобренного запроса на изменение. Крайне важно, чтобы этот документ был создан как можно раньше после того, как изменение было одобрено. ● Оценка риска. При определении рисков, связанных с внесением требуемого изменения, подумайте о том, что может пойти не так. Определите потенциальные препятствия для успеха, чтобы риск можно было уменьшить или устранить. Определите события, которые могут произойти, что может снизить вероятность доставки запроса на изменение. ● Организационные изменения. При оценке запросов на изменение укажите влияние организационных изменений, которое может разрешить это изменение проекту, клиенту или организации. ● Производство, операции и техническое обслуживание. При переходе на этап эксплуатации и технического обслуживания жизненного цикла проекта управление изменениями может осуществляться иначе, чем во время разработки. Переоцените план управления изменениями задолго до этого и, при необходимости, внесите обновления, чтобы учитывать любые различия в подходах, процессах, управлении и т. Д