Главная Библиотека Статьи Управление изменениями в Microsoft Project

Управление изменениями в Microsoft Project

Алексей Просницкий, РМР, MVP

1.1 МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ИЗМЕНЕНИЯМИ

План — это не священная корова, изменяйте его и помните, что у проекта только одно ограничение – это удовлетворение Заказчика проекта результатами проекта


Проекты часто отстают от первоначальных планов. Причины могут быть разными. Например, некачественное планирование, когда про часть работы просто забыли, или неконтролируемое, часто остающееся незамеченным увеличение содержания и объема выполняемой работы по сравнению с запланированными параметрами. Людям свойственно стремиться получить как можно лучшие результаты независимо от согласованной цели. При отсутствии должного руководства инженеры часто продолжают совершенствовать разработки, выходя за рамки требований спецификаций. Представители заказчика нередко оказывают давление на исполнителей, пытаясь заставить их взяться за дополнительную работу, дабы исправить недочеты, допущенные исполнителем, реализовать изменившиеся пожелания или усовершенствовать продукт сверх требуемого по контракту. Для контроля и регулирования объема/содержания работ необходимы постоянный мониторинг и дисциплина как на уровне проекта, так и на уровне отдельных задач.

Ключевая роль здесь принадлежит руководителю проекта, который выполняет в этой области следующие функции:

  • Настаивает на надлежащем оформлении констатации работ, календарных планов и бюджетов по каждой задаче в виде письменного документа, скрепленного подписями.
  • Осуществляет мониторинг результатов вместе с функциональными лидерами проекта, чтобы обеспечить точное (не в меньшей, но и не в большей степени) выполнение условий контракта и технических спецификаций.
  • Осуществляет мониторинг отклонений от календарных планов и бюджета вместе с функциональными лидерами проекта, чтобы своевременно определить задачи, объем работ, по которым мог увеличиться, и предпринять соответствующие корректирующие действия.

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

Инцидент – это важное, но незапланированное событие, которое уже произошло, и которое требует каких-то управленческих действий.
Под изменением понимается изменение утвержденной версии, где утвержденная версия – это контрольный уровень, по которому отслеживается и контролируется объект. Следовательно, изменение по определению – это разновидность инцидента.
Например, в методе PRINCE2 выделяется три типа инцидентов:

  • Запрос на изменение – предложение внести изменение в утвержденную версию.
  • Отклонение от спецификации – нечто, что проект должен был предоставить, но на данный момент этого не сделал или есть прогноз, что не сделает.
  • Проблема / сомнение – любой другой инцидент, который менеджер проекта должен решить самостоятельно или передать на следующий за ним уровень управления.

Для определения приоритетности запросов на изменение может использоваться шкала MoSCoW:

  • «Должен сделать» (Must have).
  • «Должен бы сделать» (Should have).
  • «Мог бы сделать» (Could have).
  • «Сейчас не надо делать» (Won’t have for now).

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

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

01 prince2 changemanagement
Рисунок 1. Процесс контроля инцидентов и изменений (PRINCE2)

 

1.2 ИЗМЕНЕНИЕ ПЛАНА ПРОЕКТА В MICROSOFT PROJECT

После анализа исполнения проекта вам, возможно, на основании имеющихся отклонений необходимо внести изменения в план проекта.
Все действия, которые менеджер проекта будет делать с планом его проекта, должны исходить из анализа «что если», т.е. что произойдет с планом, если он сделает, например, следующее:

  • Добавит ресурсы на задачи с фиксированными трудозатратами или на задачи с фиксированным объем ресурсов. Здесь нужно понимать, что при этом увеличатся трудозатраты проекта, и как правило его стоимость, а также увеличится то время, которые участники одной задачи тратят на коммуникацию между друг другом.
  • Попросит команду персонала работать сверхурочно или в выходные, естественно, за хороший пряник. Аналогично, данное решение может привести к последствиям, указанным выше.
  • Изменит зависимости между задачами (уменьшит задержки, сделать параллельными задачи через связи «Начало-Начало»). Обычно запараллеливание задач увеличивает риск некачественного выполнения работ.
  • Пересмотрит содержание проекта, если так разрешит заказчик или инвестор.
  • Пересмотрит план проекта на предмет контрольных дат и даты его окончания, тоже в том случае, если ему разрешат это сделать сверху.


Кроме того, что необходимо отслеживать отклонения в самом календарном плане, важно постоянно отслеживать внешнюю среду проекта на предмет того, например, нужен ли он вообще.

 

1.2.1 Сохранение нового базового плана

 

В компании должна быть принята политика управления изменениями (управление исключениями). Так, если новые задачи увеличивают менее чем на, например, 3% или сроки или бюджет, или трудозатраты, то новый базовый план не сохраняется. Если любой показатель будет увеличен более чем на 3%, то сохраняется новый базовый план

 

После проведения необходимых изменений с планом проекта, следующий шаг — это обновление базового плана и сохранение имеющегося.

Обновление должно идти по следующему сценарию:
1. Копируете основной базовый план в номерной базовый план (1…10), Рисунок 2.

02 copybl
Рисунок 2. Копирование базового плана


2. Выделяете измененные и/или новые задачи, которые прошли процесс утверждения, и добавляете их в базовый план. Для этого переходите на закладку «Проект» и на ней выбираете «Задать базовый план – Задать базовый план - Базовый план – Для выбранных задачи», Рисунок 3.

03 changebl

Рисунок 3. Изменение базового плана


В данном случае предлагается четыре варианта, Рисунок 3:
1. Флажки не выбираются. В этом случае новые задачи будут показывать отклонения по сравнению с оригинальным базовым планом.
2. «С сведением базового плана во все суммарные задачи», т.е. если устанавливается данный флажок, то обновленные базовые данные для выбранных задач сводятся в соответствующие суммарные задачи. В противном случае базовые данные для суммарных задач могут неточно отражать базовые данные подзадач.
3. «С сведением базового плана из подчиненных в выбранные суммарные задачи», т.е. если устанавливается этот флажок, то при обновлении базовых данных для выбранных суммарных задач учитываются удаленные подзадачи и добавленные задачи, для которых ранее сохранялись базовые значения.
4. Выбор обоих вышеприведенных флажков, если выбираются суммарные задачи и их подзадачи, т.е. вложенные в них. В этом случае базовые значения суммарных задач будут обновлены.

 

1.2.2 Сохранение нового базового плана целого проекта

В случае если вам просто нужно пересохранить базовый план проекта, в котором нет фактической информации, необходимо на закладке «Проект - Задать базовый план – Задать базовый план» выбрать «Базовый план» для «Всего проекта» и сохранить «поверх» существующего базового плана, Рисунок 4.

04 setnewbl
Рисунок 4. Задание нового базового плана всего проекта

 

1.2.3 Визуализация нескольких базовых планов

Для того чтобы визуально посмотреть разницу между планами, вы можете на диаграмме Ганта вывести две визуализации плана проекта. Для этого вам надо в представлении «Диаграмма Ганта с отслеживанием» на закладке «Формат» в области «Стили отрезков», выбрать «Базовый план», Рисунок 5.

05 seebl
Рисунок 5. Диаграмма Ганта с отслеживанием с сравнением планов проекта

 

Если вам необходимо вывести более двух базовых планов, вы можете на закладке «Вид», в области «Представление задач», выбрать «Диаграмма Ганта – Другие представления – Диаграмма Ганта с несколькими планами», и на диаграмме Ганта будут отображаться все имеющиеся на данный момент базовые планы, Рисунок 6.

06 allbl
Рисунок 6. Диаграмма Ганта с несколькими планами

 

1.2.4 Перемещение проекта

Бывают такие ситуации, когда вы планировали начать проект в одни даты, но жизнь внесла коррективы и нужно перенести начало проекта на новую дату. Для запуска данного сценария существует кнопка «Переместить проект» на закладке «Проект». После нажатия на кнопку «Переместить проект» вам будет предложена новая дата начала проекта и возможность выбора перемещения крайних сроков, Рисунок 6. Однако, данный сценарий следует применять только в том случае, если в проект не внесены фактические даты.


07 moveproject
Рисунок 6. Перемещение проекта

 

В случае если в проекте уже есть внесенные фактические данные, можно переместить задачи, требующие перепланирования.
Для перемещения задач нужно на закладке «Задача» нажать на кнопке «Переместить» и выбрать один из предложенных вариантов по перемещению задач вперед или назад от даты начала или окончания задачи.


08 movetask
Рисунок 7. Перемещение задач в проекте

 

1.2.5 Разрыв задач

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

09 razrivtask
Рисунок 8. Разрыв и перемещение задачи

 

С помощью полей «Остановка» и «Возобновление» вы сможете воспользоваться немного другим сценарием разрыва задач. Так в поле «Остановка» вы можете внести дату, на которую вы выполнили часть работы, а в поле «Возобновление» ввести дату будущего начала продолжения работы.

10 stop and go
Рисунок 9. Остановка и возобновление задачи

 

1.2.6 Неактивные задачи


Кроме возможности использовать два типа планирования в задачах, можно применять функционал, появившийся в 2010 версии Microsoft Project, а именно разделение задач на активные и неактивные для проведения анализа «что-если», Рисунок 10.
Для проведения данного анализа необходимо создание нескольких путей развития событий в проекте, а потом выделять один или другой фрагмент и с помощью пиктограммы «Сделать неактивным» исключать из проекта сроки, трудозатраты и стоимость альтернативного пути развития проекта, Рисунок 10.

 

Анализ «что-если» лучше всего проводить на задачах с автоматическим типом планирования, чтобы было видно в проекте изменение сроков от исключения той или иной ветки

 

При деактивации суммарной задачи становятся неактивными все вложенные в нее задачи.


11 nonactive
Рисунок 10. Анализ «что-если» с помощью активных и неактивных задач

LEO Consulting

Украина, 02121, г. Киев, ул. Декабристов, 3, оф. 602
Тел.: (044) 228-76-99
E-mail: Написать письмо
Skype: alexvipro
Facebook: https://www.facebook.com/LEO.Consulting.ua

Мы партнеры

LEO Silver LOGO        Nintex Logo 

Конференции по управлению проектами

LEO Consulting совместно с Microsoft Ukraine инициировали проведение ежегодных конференций, объединивших ведущих специалистов в области управления проектами из Украины и стран СНГ.

http://www.project-conference.com.ua

Форум

Мы создали форум, на котором все желающие могут найти ответы на свои вопросы, связанные с Microsoft Project и управлением проектами.

http://microsoft-project.com.ua

Copyright «LEO Consulting» 2009-2013. Все права соблюдены.