У видавництві «Фабула» виходить український переклад книги Джозефа Хiґнi «Основи управління проєктами». У ній автор розповідає як закласти підґрунтя для управління проєктами та отримати статус досвідченого професіонала. AIN.Business публікує уривок з книги.
Процес контролю змін
Найбільш повний та ефективний план проєкту буде абсолютно марним, якщо не буде запроваджено певний метод контролю змін. Установлення процесу контролю змін впливає на успіх або провал проєкту так само, як і ваші старанність та здатність вкладати зусилля в планування. PMBOK® Guide, PMI зазначає про процес змін таке: «Коли виникають проблеми під час роботи над проєктом, то формуються запити на зміну політики або процедури проєкту, його змісту, вартості або бюджету, графіка або якості». Якщо ви не узгоджуєте план із поточними подіями, то у вас немає плану взагалі. Початковий базовий план (основа) більше не буде дієвим і втратить свою ефективність у роботі з поточними сценаріями проєкту.
Контроль змін не є простим. Він містить багато змінних та суджень, порогів та компромісів. Процес контролю змін забезпечує стабільність, необхідну вам для управління безліччю змін, які впливають на проєкт протягом його життєвого циклу.
Якщо не звертати уваги на зміни, то вони можуть спричинити суттєвий дисбаланс між змістом, графіком та бюджетом. Менеджер проєкту, який зосереджується на управлінні та контролі змін, отримує потужну зброю для боротьби з розповзанням проєкту. Відповідно до появи змін ви матимете можливість оцінювати їхній загальний вплив на проєкт й адекватно реагувати.
Процес контролю змін забезпечує стабільність, необхідну вам для управління безліччю змін, які впливають на проєкт протягом його життєвого циклу
Контроль змін неможливо здійснити у вакуумі. Коли ви реагуєте та вносите корективи, план проєкту потрібно переглянути та передати оновлену версію заздалегідь визначеним зацікавленим сторонам. Ці зацікавлені сторони часто вказують у плані комунікацій проєкту. Крім ідентифікації зацікавлених сторін, такий план визначає відповідні шляхи комунікації, рівні розповсюдження даних та загальні вказівки чи протоколи для проєктної команди. Це прекрасний приклад того, як різні елементи загального плану проєкту можуть доповнювати одне одного.
Типовими зацікавленими сторонами, яких необхідно зазначати в списку для поінформування чи розповсюдження інформації, є лідери проєкту, члени команди, функціональні менеджери, допоміжний персонал, обрані зовнішні постачальники та юридичні консультанти. У проєкті можуть бути залучені й інші зацікавлені сторони.
Джерела змін
Зміни трапляються. Відповідно до зростання й розвитку різноманітних речей з ними відбуваються зміни, які є цілком природними і вітаються. Так само і з проєктами. Однак, коли відбуваються зміни і не робиться відповідна оцінка їхнього позитивного чи негативного впливу на проєкт, виникають проблеми. Залежно від проєкту джерела змін можуть бути найрізноманітнішими. Подумайте про проєкти, над якими ви зараз працюєте. Що змусило вас змінити план або внести корективи? У деяких проєктах замовник або внутрішній відділ організації можуть внести зміни. А в інших зміни можуть відбуватися на всіх можливих напрямках.
Як бачимо, кожна сторона трикутника обмежень є ключовим обмеженням проєкту. Джерела змін зазвичай пов’язані з однією або кількома сторонами трикутника: змістом, терміном або вартістю. Якість проєкту є постійною змінною і завжди має розглядатися як потенційне джерело та фокус контролю змін. Зміни в змісті можна визначити як такі, що вливають на результати проєкту.
Коли зміни атакують, ваше завдання — зберігати баланс між сторонами трикутника, уносячи необхідні корективи у свій план. Якщо цього не робити, одна або кілька сторін трикутника змінять своє положення і він утратить свою рівновагу. Для успішного завершення такого проєкту потрібно буде докласти чимало додаткових зусиль. Наведу типові джерела загрози для рівноваги трикутника.
Зміст
- Унаслідок консолідації діяльності було додано інші проєкти.
- Клієнт змінив свої вимоги.
- Змінилася кон’юнктура ринку.
- Виникли технічні проблеми.
Термін
- Термін виконання проєкту скоротили.
- Зростає тиск конкуренції.
- Клієнт вимагає дострокового виконання проєкту.
Вартість
- Керівництво зменшило бюджет проєкту на 20%.
- Зросла вартість сировини.
- Робота над проєктом вимагає збільшення команди.
Джерела змін зазвичай пов’язані з однією або кількома сторонами трикутника: змістом, терміном або вартістю
Розуміння та визначення ймовірних джерел змін для ваших проєктів допоможе вам залишатися проактивними. Процес контролю змін вимагає розв’язання питання про те, чи потрібно обробляти запит на зміну, а потім визначити найбільш ефективний спосіб руху вперед. Деякі рішення прості: замовник згідно зі своїми правами вимагає вдосконалення дизайну або лідер проєкту зменшує пріоритетність проєкту та відкладає його виконання на три місяці.
Але часто стається так, що багато запитів на зміни потребують складних оцінок, аналізів та різних схвалень раніше, ніж зміни можна обробити. Не завжди очевидно, чи додасть певна зміна цінності проєкту, чи це просто «косметичні» корективи до його плану. Формальний процес контролю змін — це насправді ваш друг. Як ви побачите далі, він допомагає пройти через «сірі зони» змін, які часто виникають у процесі дозрівання проєкту.
Шість етапів у процесі контролю змін
Процес контролю змін може бути різним, однак зазвичай містить ряд важливих та обов’язкових етапів. У цьому параграфі я окреслю шість загальних етапів, які формують типовий процес контролю за змінами проєкту. Організаційна культура, процедура та тип проєкту безпосередньо впливають на те, як здійснюються ці етапи.
Зазвичай менеджер проєкту отримує запит на зміну від певної особи (фізичної особи/відділу/замовника). На цей момент важливо підтвердити поточну версію плану проєкту. Якщо прийнято рішення про обробку зміни, то буде виміряно її вплив на план та відповідно внесено корективи до плану. Потрібно зберігати актуальність базового плану.
- Етап 1. Унесіть початкову інформацію про контроль змін до свого журналу контролю змін. Унесення початкової інформації про контроль змін до свого журналу контролю змін є підсумком усіх ужитих дій щодо змін, які обробляються або обробка яких вимагається. Детальний журнал змін може зрештою слугувати біографією проєкту відповідно до його дозрівання.
- Етап 2. Визначте, чи слід обробляти зміну. Визначаючи, чи слід обробляти зміну, ви берете на себе роль охоронця проєкту. Я занадто часто бачив, як менеджери проєктів приймають зміни просто тому, що їх вимагають. Якщо зміна не має сенсу — якщо вона не додає цінності або її не варто обробити з інших причин,— відкиньте її. Попросіть пояснення чи обґрунтування, щоб мати змогу прийняти раціональне рішення. Якщо зміну відхилено, унесіть її до журналу та зупиніть процес. Якщо зміну підтверджено, розпочніть оцінку її впливу на план проєкту. Зазвичай це роблять за допомогою запитання «Як ця зміна впливає на сторони мого трикутника: зміст, термін і вартість?». Якість, ціль та інші елементи проєкту також слід ураховувати під час оцінки впливу. Підготуйте рекомендації щодо впровадження зміни та заповніть форму контролю змін.
- Етап 3. Надішліть рекомендації керівництву та/або замовнику для розгляду та затвердження. Оцінки впливу має бути представлено керівництву та/або вашому замовнику для розгляду та затвердження. За необхідності потрібно отримати й інші погодження (наприклад, від керівників функціональних відділів). Якщо отримуєте коментарі від зацікавлених сторін, унесіть і їх також.
- Етап 4. Оновіть план проєкту. Не забудьте оновити план проєкту! (Іноді про це забувають у шаленому темпі середовища проєкту.) Саме так ви забезпечуєте базовий план проєкту, який стане поточним.
- Етап 5. Надішліть оновлений план зацікавленим сторонам. Як уже було сказано раніше, під час розповсюдження оновленого плану важливим є зв’язок. Дотримання цього етапу гарантує, що всі зацікавлені сторони знатимуть про зміни та скорегований базовий план (наприклад, про його Версію 7). Якщо список розповсюдження буде неповним, між командою проєкту та однією або кількома зацікавленими сторонами простежуватиметься неузгодженість. Уявіть, що ваша проєктна група вже працює над Версією 3, а каліфорнійський офіс — над початковим планом (ох, повірте, це був украй неприємний момент).
- Етап 6. Відстежуйте зміни та прогрес щодо переглянутого плану. Вплив змін може бути незначним або серйозним, хорошим або поганим. Не забудьте перевірити трикутник проєкту, щоб забезпечити його збалансованість.
Організаційна культура впливає на те, як ви організовуєте процес контролю змін та управляєте змінами свого проєкту. Будьте гнучкими. Я часто запитую в учасників моїх семінарів, чи є в них чинний процес контролю змін, яким вони послуговуються; деякі кажуть «так», але більшість — «ні».
Це підтверджує і мій власний досвід. Коли я перейшов з оборонної промисловості (із жорсткими проєктними процесами) у середовище навчання дорослих (де менше таких процесів), мені потрібно було налаштуватися. Якщо ви стикаєтесь із середовищем, де немає процесу управління змін, то маєте сценарій «хороша/погана новина».
Складність полягає у встановленні контролю за змінами під час зіткнення зі стійкістю до змін, а також загальною апатією. Ніхто не хоче нічого підписувати, а підтримка в процесі прийняття рішень дуже мала. Але все одно це потрібно зробити! Тому важливо, щоб ви підтримували контроль над проєктом через ці зміни. Якщо не вдається отримати підпис зацікавленої сторони чи керівника відділу, то впишіть їхні імена чи назви підрозділів до форми контролю змін та вкажіть дату. Зрештою, це механізм управління, а не гра у квача.
Як менеджер проєкту ви відповідаєте за те, щоб боротися зі змінами змісту проєкту та тримати трикутник обмежень збалансованим і під контролем. Це ваш інструмент для вашого проєкту. Хороша новина за відсутності будь-якого процесу — це саме відсутність будь-якого процесу. Отже, ви можете налаштувати його в будь-який спосіб, оскільки не потрібно нічого змінювати. Так, це потребує більше часу та роботи, але отриманий результат буде вашим процесом, вашим стилем.
А тим, хто працює в середовищі зі встановленими процедурами контролю змін, скажу таке: «Використовуйте їх». Досить часто ці процедури розроблено для управління змінами продукту (наприклад, для відділу інформаційних технологій або відділу досліджень і розробок), а не самого проєкту. Переконайтеся, що ви застосовуєте цілісний підхід до змін та зосередьтеся на самому проєкті.
