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

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

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

Від загального…

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

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

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

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

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

До складу Плану ресурсів входять такі розділи:

1. Ієрархічна структура ресурсів, ідентифікованих і оформлених спеціально для цього проєкту.
2. Матриця відповідальності – структура, що приводить організаційну структуру проєкту у відповідність з ієрархічною структурою робіт і допомагає призначити кожному пакету робіт відповідальну особу або команду.
3. Кадрове забезпечення проєкту, що дає змогу відповісти на низку запитань, які виникають під час планування команди проєкту, такі як:
   • Чи будуть люди виділятися з-поміж співробітників компанії або залучатися зі сторони?
   • Чи повинні члени команди працювати в офісі або вони можуть працювати віддалено?
   • У скільки обійдеться залучення людей з необхідною кваліфікацією?
   • Яку допомогу керівнику проєкту можуть надати відділ персоналу та функціональні підрозділи компанії?
   • тощо.
4. Календарі ресурсів, що описують необхідні терміни для членів команди проєкту, індивідуально або колективно, а також визначають, коли мають розпочатися заходи з набору команди і які ресурси потенційно доступні в той час, коли заплановано операції.
5. План вивільнення ресурсів, який визначає спосіб і час звільнення членів команди та інші ресурси, що корисно як проєкту, так і членам команди. Коли ресурси вивільняються з проєкту, витрати, пов’язані з цими ресурсами, не впливають на проєкт, що дає змогу знизити вартість проєкту. Моральний стан членів команди кращий, коли не відбувається пересмикування ресурсів з одного проєкту в інший, а всі переходи заздалегідь сплановані.
6. План навчання персоналу, що включає шляхи допомоги членам команди в отриманні необхідних компетенцій і сертифікатів, які приноситимуть користь проєкту.
7. Визнання та заохочення, які містять критерії для заохочень та опис планованої системи їх використання, що сприяє розвитку та зміцненню бажаної поведінки. Встановлення чітких періодів розподілу заохочень гарантує, що визнання і заохочення не буде забуто. Заохочуватися має тільки бажана поведінка. Люди мотивовані, якщо вони відчувають, що їх цінують у компанії, і це підтверджується нагородами, отриманими ними.
8. Відповідність, що містить опис стратегій виконання нормативних актів, державних законів, а також інших встановлених правил відбору та найму персоналу.
9. Безпека, що містить опис політик і процедур, які захищають членів команди від загроз безпеки.

Таким чином, ми загалом описали всі ресурси, необхідні для проєкту, і процес їх отримання в проєкт, але проєкти виконують люди! Ні комп’ютери, ні документи, ні процеси, ні машини і механізми, а саме ЛЮДИ! А злагоджена робота команди проєкту та участь у проєкті ключових зацікавлених сторін – запорука успішного виконання проєкту, досягнення очікуваних результатів і прийняття цих результатів замовниками.

Тож давайте задокументуємо команду нашого проєкту!

… до приватного

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

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

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

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

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

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

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

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

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

Разом

З точки зору документування, підсумок планування ресурсів і команди проєкту має такий вигляд:

1. 
   Вимоги до ресурсів
   і
   План ресурсів
   що дають повний опис того, які ресурси знадобляться для проєкту, і яким чином їх буде отримано в проєкт.
2. 
   Організаційна діаграма проєкту
   і
   Опис ролей
   документи, що документують команду проєкту та визначають повноваження й обов’язки членів команди.
3. 
   Накази про призначення персоналу
   і
   Трудові контракти
   які легалізують роботу співробітників у компанії загалом і над проєктом зокрема.

• Шаблони всіх цих документів можна отримати/ погортати тут:
  • 
    ЗСУП.ЧР.Комплект
    за PMBOK (5th edition).
  • 
    ІСО21500:Ресурси
    за ISO 21500:2012.
• Повний пакет шаблонів, створених на основі PMBOK (5-ї редакції) можна отримати тут:
  ЗСУП.Комплект.v5
  
• Повний пакет шаблонів, створених на основі ISO 21500:2012 можна отримати тут:
  ІСО21500:Комплект
  
• Усі приклади та шаблони документів порталу PMDoc, пов’язані з управлінням людськими ресурсами різних проєктів, можна отримати тут:
  Людські ресурси
  .

У наступній статті я розповім, як документувати терміни проєкту.