Управління змінами в проекті

Метою зміни є правильно задокументувати зміни до проекту. Документація служить основою для обґрунтування наслідків зміни, як правило, зміни терміну завершення, ціни та обсягу виконання.

Об'єкт Зміна проекту підтримує облік та аналіз управління змінами відповідно до стандартів проекту. Входить до реєстру проекту в проектному офісі. На робочому столі є зміни у спільному відсіку з підпроектами.

Типи змін

Зміни бувають декількох основних типів.

Внутрішні зміни

Йдеться про зміни в проектному плані, які не впливають на клієнта. Зміна, як правило, не підлягає затвердженню Керівним комітетом проекту, замовником або іншим подібним органом. Прикладом зміни може бути перерозподіл компетенцій всередині команди.

Зміни, викликані клієнтом

Зміна включає зміни з впливом на (графік), обсяг робіт, робочі процедури або будь-яку іншу область договірних зобов'язань перед замовником. Ключовою характеристикою цієї зміни є те, що вступним стимулом було або прохання / вказівка врахувати в проекті рішення про зміну, або вплив зовнішніх обставин, які вимагають змін, і це обставини, що відповідають вимогам замовника.

Прикладами змін є:

• Нові вимоги до проектної доставки
• Повідомлення про зміну узгодженої дати важливого входу в проект (наприклад, затвердженого завдання та бюджету)
• Зміна умов будівництва, де за умови відповідальність несе замовник / інвестор (наприклад, археологічні знахідки в розкопі)

Зміни, викликані проблемою

Якщо при вирішенні проекту виникає проблема, яка перешкоджає дотриманню тематики та зобов'язань, необхідно створити процедуру зміни, викликану проблемою. В принципі, цей процес зміни заснований незалежно від того, чия відповідальність за проблему і хто буде відповідати за витрати, пов'язані з проблемою, в будь-якому випадку.

Попередження: Не плутайте запис проблеми та зміни. Проблема, на якій ґрунтуються зміни, повинна бути записана між проблемами, які вирішуються в проекті. На його основі потім будуються проектні зміни.

#Новий етап проекту
В рамках проекту за домовленістю учасників проект може бути вирішено збільшити його масштаби і здійснювати нові види діяльності, які не були включені в поточний план. Це рішення фактично також призводить до змін, і повинно бути опрацьовано як зміни. Записано як новий етап.

Обробка змін

Окремі розділи описують ключові кроки зміни. Методологія може готувати для окремих кроків окремі завдання, пов'язані зв'язками. Таким чином, управління змінами можна запустити безпосередньо за допомогою команди Нове завдання в деталях змін. Кнопка запропонує завдання для реалізації змін.

Ідентифікація та опис змін

На першому етапі потрібно описати, що насправді змінюється. Як правило, це будуть нові або змінені вимоги до роботи, плану часу або бюджету. Всі змінені об'єкти (у версії, що діє до початку процедури внесення змін) зберігаються в AyMINE і включені до зміни між об'єктами, на які вплине зміна. Об'єкти – типовий вхід від замовника – можуть бути описані окремою інформацією і прикріплені до зміни кнопкою Причини.

Сама зміна може бути детально розібрана на вкладці Опис змін.

Аналіз змін

Мета аналізу – знайти всі наслідки, які спричинять зміни в проекті. Аналіз полягає в пошуку і документуванні всіх наслідків зміни. Типовими наслідками є:
**Необхідність переробити те, що вже зроблено.

• Необхідність розробки нової версії
• Змінити вже створені виходи – аналіз, дизайн, тести
  Залежно від масштабів змін необхідно
• Редагувати розклад
• Редагування ризиків проекту

Усі об'єкти, на які вплине зміна, додаються до зміни кнопкою Додати у розділі Об'єкти, пов'язані зі зміною. До кожного об'єкта, що додається, в рамках аналізу слід додати опис того, як він буде впливати. (За допомогою кнопки До запису).

Затвердження змін

Зміна готує підстави і документує аналіз. Саме рішення буде прийматися як рішення, як правило, на нараді.

Зміни будуть пов'язані з рішенням, яке має бути включено до порядку денного. Результат рішення документується як безпосередньо в рішенні, так і шляхом зміни статусу в самій зміні.

Впровадження змін

Після затвердження змін необхідно внести зміни. Для окремих об'єктів, ідентифікованих у зміні, створюються завдання для змін, або, якщо зміни невеликі, вони можуть бути реалізовані в рамках кроків і завдань безпосередньо при зміні. Конкретне рішення залежить від використовуваної методології.

Відповідальність за зміни

З внесенням змін до проекту пов'язано багато обов'язків:

• За правильне процесуальне опрацювання змін завжди відповідає керівник проекту. Керівник проекту також вносить зміни в офіс проекту.
• Аналіз змін керівник проекту може доручити будь-кому з проектної команди. Правильно має доручити того, хто найкраще розуміє наслідки змін. Він також може створити цілу команду розв'язування в рамках завдання з аналізу змін.
• Відповідальність за рішення про те, чи буде внесена зміна, визначається договором, методом проектного управління або іншим способом. Як правило, це управлінський комітет або потрібна згода клієнта.
• Планування проекту з урахуванням змін завжди повинен робити керівник проекту, оскільки він відповідає за дотримання графіка (і ніколи інший навіть не може планувати проект).
• Реалізацію зміни – тобто здійснення всіх впливів – веде керівник проекту, як і будь-яка інша проектна діяльність.

Бажано знати

Чому зміни відбуваються разом з підпроектами

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

Підсумкові проекти часто є новими етапами проекту. Тому між підпроектом і зміною, здійсненою з метою нового етапу, є дуже маленька різниця. Спільне розташування на робочому столі дозволяє обом думати разом.