Документування контрольних функцій проєкту

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

Документування контрольних функцій проєкту – це підпроцес моніторингу та контролю проєкту. Нагадаю, що загальне управління проєктами я намагаюся виносити за рамки цього циклу статей, і описую тільки склад і правила заповнення документів для управління проєктами.

Документування проєкту під час моніторингу та контролю розкладається на “перевірку результатів”, “облік змін” і “регулярну звітність за проєктом”.

Якість результатів

Як я вже говорив у статті з документування якості проєкту, якість підрозділяють на “якість виконання проєкту” і на “якість продукту проєкту”. Там же говорив, що “забезпечення якості” це довгостроковий повторюваний процес. Отже, ми не можемо досягти ідеальної якості в проєкті, оскільки проєкт виконуємо лише один раз. Доведеться чимось жертвувати. Тому давай залишимо якість системи управління проєктами на совісті менеджерів з якості всієї компанії і співробітників Офісу Управління Проєктами, а самі зосередимося на якості продукту проєкту.

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

1. Вимірювання контролю якості, за допомогою якого ми фіксуємо відповідність продукту і виконаної роботи нашим метрикам якості, і, за необхідності, запускаємо процес профілактичних і коригувальних дій.
2. Акт приймання результатів, за допомогою якого формально приймаються результати, що відповідають початковим вимогам, або запускається процес виправлення дефектів.
3. Звіт про контроль якості. А це той самий документ, який дає змогу поліпшити систему управління якістю проєктів загалом у компанії. За допомогою нього ми виявляємо, з одного боку, хороші та найкращі практики, з іншого – вузькі місця і недоліки, і на підставі цього виробляємо рекомендації щодо поліпшення якості проєктів.

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

Зміни

O! Це найцікавіше в проєкті. Світ змінюється. Змінюється з величезною швидкістю. Відповідно, зовнішнє оточення проєкту часто змінюється швидше, ніж відбуваються зміни в самому проєкті.

Саме в процесі управління змінами ховається успішність проєктів. Але це лірика, що стосуються управління проєктом, а що стосується документування проєкту, то впродовж усього проєкту необхідно реєструвати Запити на зміни в Реєстрі змін, оцінювати їх із погляду змісту, ресурсів, термінів, вартості, якості та ризиків, оцінювати їхній вплив і користь, а також отримувати схвалення на їхню реалізацію.

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

Запит на зміну може оформити будь-який учасник проєкту. У первісному заповненому варіанті він включає:

• Опис запиту
• Рекомендований пріоритет
• Передбачуваний вплив на проєкт

Далі, після аналізу запиту, виноситься резолюція: схвалити, повернути на доопрацювання або відхилити.

Кожен запит на зміни паралельно вноситься в таблицю Реєстру змін:

Де:

• Зміна – формально задокументований Запит на зміну, тобто. запит на збільшення або зменшення змісту проєкту, зміну стратегій, процесів, планів або процедур, зміну цін або бюджетів чи перегляд розкладів.
• Ініціатор – П.І.Б. та контактні дані особи, яка ініціювала Запит на зміну. Такі запити може подати будь-яка стейкхолдер, залучена до проєкту. Хоча зміни можуть бути ініційовані усно, вони обов’язково мають бути зареєстровані в письмовій формі та передані в систему управління змінами та/або управління конфігурацією.
• Тип – запити можуть бути прямими або непрямими, ініційованими ззовні або зсередини, необов’язковими або обов’язковими згідно із законом або контактом, а також можуть охоплювати коригувальну дію, попереджувальну дію, виправлення дефекту або оновлення.
• Пріоритет – визначає, на скільки важлива реалізація цієї зміни щодо інших змін.
• Вплив – потенційний вплив на проєкт у показниках термінів, вартості та ризиків, а також зміна правил або процедур проєкту, його змісту або якості.
• Дата – дата видання Запиту на зміну вказується з метою забезпечення своєчасного опрацювання всіх запитів, що є винятково важливим, оскільки повільні рішення можуть негативно вплинути на терміни, вартість або здійсненність зміни.
• Відповідальний – П.І.Б. особи, відповідальної за заходи щодо змін.
  Як правило, Запити на зміни обробляються менеджером проєкту або призначеним членом команди відповідно до системи управління змінами.
• Статус – поточний стан Запиту на зміну. Оновлення статусу показують, що зміни схвалено, відхилено, відправлено на доопрацювання або реалізовано.

Якщо в компанії існує інформаційна система управління проєктами, то цей процес можна легко автоматизувати, щоб Запити одразу потрапляли до Реєстру. Якщо ні, то Запити оформляються у Word, а Реєстр ведеться в Excel.

Звіти забезпечують зацікавлених учасників проєкту, зокрема спонсора проєкту, менеджера проєкту і команду проєкту, точним і актуальним описом ходу виконання проєкту.

У проєктному управлінні застосовується модель DIKW (data, information, knowledge, wisdom) – інформаційна ієрархія, де кожен рівень додає певні властивості та цінності до попереднього рівня:

• У підставі містяться дані.
• Інформація додає контекст.
• Знання додає відповідь на запитання “як?” (механізм використання).
• Мудрість додає відповідь на запитання “коли?” (умови використання).

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

• Дані про виконання робіт – “сирі” спостереження і вимірювання, виявлені під час виконання робіт проєкту. Наприклад: відсоток фізично завершених робіт; вимірювання технічного виконання; дати початку і закінчення планових операцій; кількість запитів на зміни; кількість дефектів; фактичні витрати; фактичні тривалості. Про Дані я розповідав у статті “Документування проєкту під час виконання”.
• Інформація про виконання робіт. Дані про виконання робіт аналізуються та інтегруються на підставі взаємозв’язків між різними областями/етапами проєкту. Наприклад: статус результатів; статус реалізації запитів на зміни; прогнози до завершення.
• Звіти про виконання робіт – фізичне або електронне представлення Інформації про виконання робіт, призначене для ухвалення рішень, висвітлення питань і проблем, вироблення дій або усвідомлення ситуації. Наприклад: звіти про статус; обґрунтування; інформаційні записки; “приладові панелі” проєкту; рекомендації та оновлення.