Створюючи план проекту, команда робить кілька припущень, які ґрунтуються на їхньому досвіді та розумінні. Ці припущення випливають з хорошого розуміння ефекту, який повинен мати проект, його масштабу та очікувань зацікавлених сторін. На цьому етапі створюється статут проекту, який найчастіше є невід’ємною частиною плану проекту. У проектах, що повторюються, план проекту часто є більш досконалим, ніж у проектах, які організація реалізує вперше. Це, безсумнівно, пов’язано з попереднім досвідом організації. Звичайно, кожен проектний план – це певне припущення про те, як ми хочемо, щоб все вийшло. Однак передбачити все неможливо, і часто нерозумно намагатися зробити це за будь-яку ціну. Тому варто прийняти організаційні принципи, які описують управління змінами в проектному плані. Потреба у змінах може виникнути з найрізноманітніших причин, досить поширеними з яких є: зміна цін, затримки постачальників, зміна очікувань зацікавлених сторін, що впливають на обсяг та результати проекту, тощо, або недостатня компетентність керівника проекту.
Керувати змінами в проектному плані варто за допомогою практичних інструментів. Безсумнівно, ми повинні мати можливість показати, як виглядає поточний план проекту, які зміни ми пропонуємо, і як він буде виглядати після змін. Що стосується графіка проекту, то діаграми Ганта є ключовими для чіткого відображення поточних і майбутніх версій. На малюнку нижче показано поточний і майбутній план проекту – така функціональність доступна, зокрема, в програмному забезпеченні для управління проектами FlexiProject:
На практиці організації рекомендується мати спеціальний запит на внесення змін до плану проекту (так званий “Запит на зміну”). Якщо керівник проекту вважає за доцільне подати запит на зміну плану проекту – у зв’язку з непереборними обставинами – йому варто зробити це за допомогою Запиту на зміну. У такому запиті менеджер описує, наприклад, причину зміни, розглянуті альтернативи та вплив зміни на графік проекту, бюджет, цілі та обсяг проекту. Приклад запиту на внесення змін до плану проекту показаний на ілюстрації нижче:
Особливо в складних проектах слід докласти зусиль для розробки найкращого плану проекту. На практиці це часто трапляється лише іноді. Багато команд починають проект з поганим планом. Дійсно, такий підхід означає, що зміни до плану проекту відбуватимуться досить швидко. Навіть маючи хороший план проекту, варто розробити надійний реєстр ризиків. Чим більше ризиків проекту ми визначимо на самому початку, тим точніше ми побудуємо план проекту. Багато ризиків можна усунути вже на етапі планування. Початковий план проекту має бути офіційно затверджений. Той факт, що план проекту має бути поданий на затвердження, змушує вас забезпечити його високу якість. Дійсно, лише деякі речі можна передбачити. Тому графік проекту та бюджетні прогнози повинні враховувати всі відповідні нові обставини. Якщо прогнози значно відхиляються від поточного плану, слід запросити поправку.
Безумовно, не всі нові обставини на проекті змусять змінити план проекту. Багато нових обставин, що виникають у проекті, є або ризиками, або так званими проектними проблемами. Тому, безумовно, варто вести реєстр проектних ризиків, а також реєстр тем. Хороше програмне забезпечення для управління проектами зазвичай має обидва реєстри. Додаткова цінність реєстру ризиків і проблем в додатку для управління проектами полягає в тому, що всі зацікавлені сторони мають паралельний погляд на них. Якщо деякі ризики проекту неможливо адекватно пом’якшити, корисно застосувати проактивний підхід і передбачити їхній вплив на графік і бюджет проекту у вигляді прогнозів. Це готує команду до можливих відхилень і дає їм відчуття контролю. Безумовно, якщо ці прогнози суттєво відрізняються від поточного плану проекту і здаються неминучими, слід вимагати внесення змін до плану проекту.
Управління змінами в проектному плані має вирішальне значення для реалізації будь-якого проекту. Такі зміни повинні бути добре обґрунтовані в запиті, а потім офіційно затверджені. Лише непереборні обставини виправдовують зміну плану проекту. Хороша програма управління проектами повинна мати готовий “запит на зміну” і можливість його формального затвердження.