Модулі

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

Типи змін

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

Це зміна в проектному плані, яка не має (не повинна) впливати на клієнта. Зміна, як правило, не підлягає затвердженню Керівним комітетом проекту, замовником або іншим подібним органом. (Приклад: перерозподіл компетенції в команді.)

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

Зміни з впливом на декількох партнерів проекту

Зміни, що впливають на

Графік,
Сфера робіт (нові вимоги, новий етап),
Робочі процеси, що включають взаємодію, ...
Ключова характеристика полягає в тому, що зміна повинна бути відображена в графіку і попередньо обговорена представниками всіх зацікавлених команд.

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

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

Попередження: Важливо не плутати запис питання і зміни. Проблема повинна бути зафіксована між проблемами, як тільки вона виникає. Зміна за замовчуванням планується тільки після аналізу масштабу і виявлення необхідності перепланування.

Обробка змін

В рамках проектної методології готуються процедури для обробки аналізу і проектування етапу для реалізації самих змін.

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

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

Аналіз змін

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

Редагувати запити і на їх основі оброблений аналіз. Поради
У рамках огляду вимог скористайтеся видом аналізу, який покаже вам всі пов'язані об'єкти
Відображення всіх похідних об'єктів у списку. З них можна легко зробити звіт (PDF), а ще краще перенести його в протокол аналізу.
Необхідність розробки нової версії

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

#Відповідальність за зміни
Зі зміною в проекті пов'язано багато обов'язків (стандартно вони визначені методологією):

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