Документування проєкту під час виконання

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

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

Тут варто, напевно, зазначити, що левову частку документів під час виконання команда повинна складати для продукту проєкту. На те воно і “виконання”. Саме на цьому етапі з’являється результат роботи команди. Але я не знаю, який у тебе проєкт, і, отже, навіть припустити не можу, як документувати продукт, який ти створюєш у своєму проєкті. Тому просто прошу поставитися до документування продукту так само відповідально, як ми в цьому циклі статей ставимося до документування проєкту, оскільки документи проєкту дадуть тобі змогу розвивати систему управління проєктами, а документи продукту – грамотно і всебічно використовувати продукт проєкту.

Отже, документування виконання… Усе розкладається на “хто виконує проєкт” і “що виконується в проєкті”. При цьому “хто” розкладається на “своїх” і “залучених”.

Сколоти команду “своїх”

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

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

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

• підвищення навичок, необхідних для проєкту;
• поліпшення командної взаємодії;
• і обмін знаннями в команді.

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

1. Відомості про члена команди (ПІБ, дату народження, освіту, стаж).
2. Детально заповнену матрицю оцінювання.
3. Сумарну оцінку за напрямами: результативність, професіоналізм, творчість, комунікативні та управлінські навички.
4. Загальну сумарну оцінку.
5. Коментарі та зауваження керівника проєкту до оцінки.
6. Рекомендації щодо професійного зростання та розвитку.

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

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

Доповни команду “залученими”

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

1. Наші запити
2. Їхні пропозиції

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

Почну із запитів. Як правило, команда проєкту надсилає потенційним підрядникам такі типи запитів:

1. Запит початкової відповіді продавця (щоб познайомитися і зрозуміти, що “на іншому кінці дроту” є ще хтось живий; як правило, це просто електронний лист вільної форми).
2. Запит інформації (це вже може бути документ, у якому команда просить потенційного підрядника надати їй ту чи іншу інформацію про продукт, послугу або можливості підрядника).
3. Запит пропозиції (документ, за допомогою якого команда офіційно запитує пропозиції продуктів або послуг у передбачуваного учасника тендера).
4. Запит розцінок (документ, за допомогою якого команда офіційно запитує у передбачуваних продавців ціни на стандартні продукти і послуги).
5. Оголошення тендера (офіційне оголошення тендера).
6. Запрошення до переговорів (документ або електронний лист, за допомогою якого команда запрошує потенційних продавців і постачальників до переговорів).

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

Після оцінок усіх пропозицій (нагадую, що саме управління проєктом я виношу за рамки цього циклу статей, а описую тільки як документувати все це; як проводити тендери дивись у PMBOK або ISO21500), потрібно підписати контракти з обраними підрядниками і постачальниками, і тим самим офіційно включити їх до складу своєї команди.

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

1. Предмет контракту
2. Реквізити та підписи сторін
3. Стандартні умови та загальні положення
4. Визначення та інтерпретація
5. Відповідальність Виконавця
6. Відповідальність Замовника
7. Угоди щодо ризиків
8. Період дії, зміна та припинення контракту
9. Ціна контракту, порядок оплати та відшкодування витрат
10. Конфіденційність
11. Врегулювання спорів
12. Зміст робіт проекту та обсяг послуг
13. Ієрархічна структура робіт
14. Звітність Виконавця
15. Гарантійні зобов’язання та технічна підтримка
16. Графік виконання робіт проекту
17. Персонал, обладнання, допоміжні засоби та послуги третіх сторін, що надаються Замовником
18. Шаблон Запиту на зміни
19. Шаблони Щотижневого та Щомісячного звітів

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

Збір факту – це “сирі” звітності за проєктом. Про саму звітність я розповім у наступній статті про документування проєкту на етапі контролю. А під час виконання проєкту потрібно просто фіксувати факт.

Цим фактом є спостереження і вимірювання, виявлені під час виконання робіт проєкту, тобто. голі, неприкриті зведення з полів, такі як:

• відсоток фізично завершених робіт;
• вимірювання технічного виконання (скільки^м3 викопано, скільки тонн доставлено, скільки рядків написано тощо);
• дати початку і закінчення планових операцій;
• кількість запитів на зміни;
• кількість дефектів;
• фактичні витрати;
• фактичні тривалості робіт;
• ступінь досягнення метрик якості;
• інформація про використання ресурсів.

Усе це в повному обсязі або окремо фіксується кожним виконавцем у документі, який так і називається
“Дані про хід виконання”
. Документ простий і може бути оформлений у вигляді електронного листа. Хоча в ідеалі ці дані краще вносити одразу в графік проєкту в системі управління проєктами, типу MS Project Server.

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

Склад його такий:

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

Зрозуміло, що це не зовсім документ у класичному його розумінні. Він може ніколи не з’явитися в паперовому вигляді, хіба що як роздруківка на якій-небудь нараді. Це постійно змінювана таблиця, в якій, крім самих проблем, вказуються конкретні люди, в обов’язки яких входить вирішення конкретних проблем до певного терміну.

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