Фінальне документування проєкту

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

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

Проєкт вважається повністю завершеним, якщо отримано три складові:

1. Створено результат (продукт) проєкту, формально передано замовнику і він працює (експлуатується) у нього.
2. Формально завершено всі контракти проєкту – тобто. проплачено й отримано всі гроші, а також усе закрито за бухгалтерією.
3. Фіналізовано ВСЯ документація проєкту, як технічна, так і управлінська, і підбито уроки досвіду.

За такого підходу, у команди не залишається “хвостів”. Тепер докладніше.

Фінальне документування результату

Є неформальне правило в управлінні проєктами – “Що більше паперу, то чистіша дупа”. Незважаючи на гротескну алегорію, правило працює.

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

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

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

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

Фінальне документування контрактів

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

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

Для цього використовується документ типу “папка”, званий “Завершені поставки”, який містить у собі:

1. Початкові запити
2. Пропозиції постачальників
3. Протоколи переговорів
4. Кореспонденцію за контрактом
5. Підписані контракти
6. Рахунки та платіжні доручення
7. Акти приймання

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

Попри те, що це мало хто робить у проєктах, підбиття фінальних підсумків проєкту – це найкорисніше, з погляду розвитку досвіду команди і зрілості системи управління проєктами (УП). Виражається все це у двох документах – у Звіті про завершення проєкту і в Уроках досвіду.

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

Але це ретроспектива, так би мовити, “патологоанатомія” завершеного проєкту. Взяли всі, випущені за час проєкту звіти, проаналізували їх, порівняли отримані результати, терміни і витрати з базовими планами і все внесли в підсумковий документ. Але найцікавіше криється в розвитку Системи УП.

Відволічуся від документування проєктів і зроблю маленький екскурс у зрілістьУП. Організаційна зрілість в управлінні проєктами поділяється на чотири основні рівні:

1. Рівень I: У професійній діяльності компанії встановлена і використовується професійна мова управління проєктами. Що означає однакове розуміння і використання понятійного апарату та глосарію управління проєктами всіма співробітниками, які беруть участь у проєктах.
2. Рівень II: Співробітники, які беруть участь у проєктах, вміють самостійно керувати нескладними проєктами та/або ефективно працювати в команді управління комплексними проєктами.
3. Рівень III: Створено пакет процедурно-регламентної документації, що формалізує методологію управління проєктами. Ця методологія вбудована в систему бізнес-процесів компанії.
4. Рівень IV: Встановлено та застосовуються інструменти сталого розвитку – бенчмаркінг, реінжиніринг бізнес-процесів, система управління якістю (з використанням базових процесів управління проєктами ISO10006 або ISO21500).

Умови, які має виконати компанія, щоб відповідати різним рівням зрілості:

Перший рівень зрілості

1. У компанії існує затверджений глосарій термінів з управління проєктами.
2. Цей глосарій легко доступний усім співробітникам компанії. Усі нові співробітники в обов’язковому порядку знайомі з цим глосарієм, тобто. HR-департаментом налагоджено процес термінологічної підготовки співробітників під час прийняття на роботу.
3. Усі співробітники компанії, які прямо або побічно беруть участь у проєктах, пройшли базове навчання з управління проєктами. При цьому базовий тренінг має бути змінений з урахуванням глосарію компанії. Інструктор повинен на тренінгу застосовувати термінологію управління проєктами, прийняту в компанії.

Другий рівень зрілості

1. Існує і доведено співробітникам короткий опис процесів управління проектами, що застосовуються в компанії.
2. Існують і надані співробітникам шаблони основних документів для управління проєктами, а також послідовність і правила їхнього заповнення та підтримання в актуальному стані.
3. У компанії існує елементарна інформаційна система управління проєктами (наприклад, єдине сховище проєктних документів та/або календар завдань проєктної команди).
4. Компанія пройшла аудит, у результаті якого продемонструвала, що учасники проєктів однаково розуміють і використовують процеси управління проєктами, документи управління проєктами та інформаційну систему управління проєктами.

Третій рівень зрілості

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

Четвертий рівень зрілості

1. Налагоджено процес внутрішнього навчання нових співробітників компанії та нових учасників проєктів.
2. Налагоджено процес регулярної перевірки знань співробітниками методології управління проектами та використовуваної інформаційної системи управління проектами.
3. Налагоджено процес підбиття уроків досвіду кожного завершеного (зокрема й закритих достроково) проєкту з виробленням рекомендацій і внесенням узгоджених змін у методологію та інформаційні інструменти управління проєктами.

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