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

Запускаючи нові проєкти, ми часто ставимо собі питання – З чого почати? Насправді все просто. Існує чудове правило: “Хочеш розібратися зі своїми думками – впиши їх у папір”. Так і з проєктами, хочеш запустити новий проєкт – почни висловлювати свої ідеї про проєкт у буквено-цифровий і графічний спосіб, на папері, на комп’ютері – не важливо!

Щоб зрозуміти послідовність запису своїх думок “на папері”, потрібно розуміти технологію зародження проєкту. Усе починається із задуму. Задум може бути виражений на папері або не виражений, але його головна відмінність від ідеї в тому, що ним можна ділитися. Задум – це ідея, яку однаково розуміють усі учасники проєкту. У задумі ми повинні чітко сформулювати проблематику, що викликала проєкт, і завдання, яке належить вирішити. Перевірити грамотність формулювання задуму можна запитанням “Що і для чого ми робимо?”, і якщо учасники проєкту однозначно на нього відповідають, то перший етап пройдено – у нас є ЗАМИСЛ.

На основі задуму формуються цілі проєкту. Головна характеристика цілей – вони мають бути вимірними. Неможливо досягти того, що не можна виміряти! Тому формулюючи кожну мету, потрібно запитувати себе “Чим міряти буду?” і якщо формулювання мети дає відповідь на це запитання, то в тебе є ЦІЛІ. Хоча, звісно, вимірність мети – це не єдина її характеристика. В ідеалі потрібно мати SMART-цілі. “SMART” (від англійського “тлумачний; розумний”) – це абревіатура слів Специфічні (конкретний; пояснюється, що саме необхідно досягти), Вимірюване (вимірюваний; пояснюється, чим буде вимірюватися результат), Досяжний (досяжний; пояснюється, за рахунок чого планується досягти мети), Relevant(значущий; визначення, чи справді виконання цього завдання дасть змогу досягти бажаної мети?) та Time-bound(обмежений у часі; визначення часового проміжку, після настання якого має бути досягнута мета). Якщо попрацювати й описати цілі в такому контексті, то всім учасникам буде однозначно зрозуміло, що, коли і навіщо з’являтиметься в результаті проєкту.

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

Статут проекту

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

Для створення чинних Статутів потрібно розуміти суть цього документа і сенс його використання в проєктах. Що говорить нам PMBOK про Статут проєкту? Це “документ, випущений ініціатором або спонсором проєкту, який формально авторизує існування проєкту і надає керівнику проєкту повноваження використовувати ресурси організації в операціях проєкту”. Вчитайся і вдумайся в кожне слово! “Документ, випущений ініціатором або спонсором проєкту” – це якийсь папір, виданий людьми, які мають владу для запуску проєкту і мають ресурси для забезпечення проєкту, тобто ТОПами, першими особами компанії. “Формально авторизує існування проєкту” – тобто. як мінімум підписом, а може ще й печаткою, узаконює існування самого проєкту, та ще й визначає джерело цього узаконення. “Надає керівнику проєкту повноваження використовувати ресурси” – тобто передає керівнику проєкту “шматочок” влади над ресурсами компанії. Так, так! Саме частина влади перших осіб організації має бути передана керівнику проєкту, щоб від міг нормально виконувати проєкт.

Отже, якщо процеси управління проєктами в компанії тільки зароджуються, достатньо буде якогось письмового Наказу про початок проєкту, виданого першою особою організації. У цьому Наказі вказати, яких цілей потрібно досягти, і хто має повноваження та відповідальність щодо їх досягнення. Якщо система досить зріла, то, не мудруючи лукаво, беремо Статут, описаний у PMBOK або в ISO21500, і заповнюємо такі розділи:

1. Призначення або обґрунтування проєкту, тобто. для чого і навіщо ініціюється цей проєкт. Проєкт запускається, якщо є: потреба ринку; виробнича потреба; потреба замовника; технічний прогрес; юридичні обмеження або норми; суспільна потреба; або подібне. Ці пункти можна назвати проблемами, сприятливими можливостями або вимогами бізнесу. Головна ідея полягає в тому, що керівництво повинне вирішувати, якою має бути відповідна реакція компанії і які проєкти слід авторизувати, зафіксувавши їх у Статутах.
2. Вимірювані цілі проєкту та відповідні критерії успіху. Як уже згадувалося вище, це якраз той розділ, у якому описується, як і чим будемо вимірювати результати проєкту. Критеріями оцінки можуть бути стандарти, правила або тести, на яких може ґрунтуватися рішення або судження, або за допомогою яких можна оцінити продукт, послугу, результат або процес. Також у цьому розділі вказується, що становить успіх проєкту, хто вирішує, що проєкт виявився успішним, і його критерії приймання результатів проєкту.
3. Високорівневі вимоги, що задовольняють потреби, побажання та очікування Замовника, Спонсора та інших учасників проєкту. На що мають бути спрямовані роботи; яку стратегічну позицію слід посісти; яке завдання слід розв’язати; якого результату потрібно досягти; який потрібно виробити продукт; або яку послугу необхідно надати. Тут потрібно звернути увагу, що в Статуті проєкту вказуються тільки високорівневі вимоги. Повний перелік вимог має бути відображений у спеціальному документі щодо вимог, наприклад, у Матриці відстеження вимог.
4. Припущення, обмеження та винятки проєкту, здатні вплинути на реалізацію проєкту. Припущення – це фактори, які для цілей планування вважаються правильними, реальними або визначеними без надання доказів або демонстрації. Обмеження – це стримувальні фактори, що впливають на хід виконання проєкту, програми, портфеля або процесу. Винятки – це пакети робіт, які в цьому проєкті виконуватися точно не будуть, щоб не роздувати обсяги робіт проєкту. Слід звернути увагу, що в Статуті проєкту вказуються тільки високорівневі допущення, обмеження та винятки. Повний перелік має бути представлений в Описі змісту проєкту під час планування змісту.
5. Високорівневі ризики, де вказується, наскільки компанія готова ризикувати (тобто рівні толерантності Спонсора і Замовника проєкту до ризиків); що або хто може завадити реалізації проєкту; як це вплине на строки, бюджет, якість та обсяги робіт проєкту; а також дається короткий опис, яким чином здійснюватиметься управління ризиками проєкту. Також як і з минулими двома пунктами, повний перелік ризиків має бути відображений у спеціальному документі Реєстрі ризиків (на етапі планування ризиків).
6. Зведений розклад контрольних подій (віх), який зазвичай задають контрактом або іншими вимогами, що вказують, у які саме строки мають відбутися ті чи інші віхи проєкту, і хто відповідальний за їхнє походження. Тут теж вказуються тільки високорівневі віхи. Повний перелік віх має бути відображений у Графіку проєкту. Для самоперевірки, чи відповідають віхи, описані в цьому розділі, вимогам високорівневості розділів Статуту, можна поставити собі три простих запитання, на які має бути отримано позитивну відповідь:
   • Це справді важливі моменти чи події проєкту?
   • Є необхідна і достатня кількість віх, щоб контролювати послідовний (тобто без авралів і тривалих простоїв) перебіг проєкту?
   • Відомо хто і коли має досягти віхи?
7. Зведений бюджет, що вказує, скільки коштуватиме проєкт і скільки грошей спонсор проєкту готовий надавати щомісяця (або щокварталу, щотижня, …). Детальний бюджет, на основі цих даних, буде потім відображений у Базовому плані за вартістю.
8. Керівник проєкту. Як ішлося вище, це найважливіший розділ Статуту, який містить інформацію про призначеного Керівника проєкту, його рівень відповідальності та повноважень, тобто хто відповідає за успішну реалізацію проєкту і що йому для цього необхідно. Звісно ж, рекомендується, щоб Керівник проєкту брав участь у розробленні Статуту проєкту, оскільки цей документ наділяє його повноваженнями використовувати ресурси організації для виконання проєкту і відповідальністю за досягнення цілей проєкту.

Вихідна інформація

Вихідною інформацією для запуску проєкту може бути:

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

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

Призначення команди

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

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

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

Коли в команду буде призначено відповідних осіб, можна переходити до планування проєкту. Документ за даними призначеннями, назвемо його
“Наказ про призначення персоналу проєкту”
може містити довідник команди проєкту, пам’ятки для членів команди та імена членів команди.

Команда проєкту, звісно ж, має величезний вплив на проєкт, а управління проєктами було б приємним і захопливим заняттям, якби не спонсори та замовники…

Реєстр зацікавлених сторін

Уже не для кого не секрет, що ми живемо у VUCA-світі. Якщо для когось це ще секрет, то якраз по секрету розповідаю: VUCA – це абревіатура слів volatility, uncertainty, complexity і ambiguity(нестабільність, невизначеність, складність і неоднозначність), які використовуються для опису якихось умов і ситуацій. Термін VUCA почали застосовувати в 1990-ті роки серед англомовних військових, у яких зник один єдиних ворог і “світ” навколо них змінився до критичної невпізнаваності. Трохи пізніше, процеси, технології та події на планеті Земля стали теж підходити під VUCA-опис, а багато військових повиходили на свою ранню пенсію і продовжили свої кар’єри в бізнесі. Ось тоді-то цей термін і перекочував у корпоративний і консалтинговий сектор.

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

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

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

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

Таблична частина Реєстру зацікавлених сторін виглядає приблизно так:

Послідовність заповнення таблиці та аналізу ЗС:

1. Визначити всі потенційні зацікавлені сторони проєкту та суттєву інформацію про них, таку як ролі, відділи, інтереси, знання, очікування та рівні впливу. Таким чином заповнюються перші 5 колонок зазначеної вище таблиці. Ключові ЗС, такі як спонсор або замовник, виявляються легко. Решту зазвичай визначають під час спілкування з виявленими стейкхолдерами. Бажано в Реєстрі ЗС вказати всіх потенційних зацікавлених сторін.
2. Заповнюємо колонку “Влада”. Негативної влади не буває, тому обираємо ЗС із максимальною владою і ставимо йому 100% (зазвичай це спонсор проєкту). Переглядаємо список ЗС, знаходимо людину з мінімальними можливостями впливу на наш проєкт і ставимо їй 0% влади. Градуювавши таким чином шкалу влади, розставляємо решті стейкхолдерів відсотки за владою, просто попарно порівнюючи їх один з одним.
3. Заповнюємо колонку “Інтерес”. Мається на увазі інтерес до успіху проєкту, який може бути як позитивним, так і негативним. Зазвичай максимальна зацікавленість в успіху проєкту у керівника, йому і ставимо 100%. Максимальна зацікавленість у провалі проєкту може бути у конкурента, або у якогось ворога нашого ПМа, все залежить від приватної ситуації. Знаходимо цю людину і ставимо їй -100%. Градуювали шкалу інтересу, розставляємо відсотки іншим ЗС.
4. Потім у MS Excel (або в чому ти там складав Реєстр ЗС?) за колонками “П.І.Б.”, “Влада” і “Інтерес” будуємо матрицю. І отримуємо приблизно такий вигляд:
   
5. Візуально об’єднуємо ЗС у кластери і формуємо для них стратегії управління:
   • У кого інтерес від -50% до +50%, і влада від 0% до 50% – на того витрачаємо мінімум зусиль. Наша стратегія – “Спостерігати”.
   • У кого інтерес від -50% до +50%, і влада від 50% до 100% – як правило, це якісь наглядові або регламентні органи, яким все одно що буде з результатом нашого проєкту, але їм важливо, щоб у проєкті були виконані визначені законами і нормативами процеси. Наша стратегія – “Задовольняти”, тобто. виконати те, що вони вимагають, або переконати, що в нашому проєкті цього виконувати не потрібно.
   • У кого інтерес від +50% до +100%, але влада від 0% до 50% – це клас людей, які постійно відволікають команду нешкідливими, на перший погляд, запитаннями на кшталт “Як там у вас справи в проєкті?”, але які настирливо віджирають величезну кількість дорогоцінного часу команди. Наша стратегія – “Інформувати”. Причому бажано інформувати пасивно. Створіть якусь розсилку, або щось на кшталт соцмережі для цих людей, або повісьте великий монітор над входом у кімнату команди проєкту, і закидайте інформацію туди.
   • Навпаки, у кого інтерес від -100% до -50%, але влада від 0% до 50% – це клас людей, які намагаються зробити дрібну капость проєкту або просто “наврочити” наш проєкт. Стратегія – “Приховувати інформацію” або “Дезінформувати”.
   • У кого інтерес від +50% до +100%, і влада від 50% до 100% – це ті самі ключові зацікавлені сторони проєкту, про які пишуть усі книжки і стандарти з УП, і з якими керівнику проєкту потрібно працювати щільно і завжди. Це саме ті люди, які в підсумку вирішать, був проєкт успішним чи ні. Наша стратегія – “Активно залучати”. І не потрібно боятися зайвої участі цих стейкхолдерів у справах проєкту. Є чудове правило в УП – “Що більший контроль процесу, то легше здавати результат”.
   • Ну, і остання (у прямому і переносному сенсі) група – це ті, у кого інтерес від -100% до -50%, а влада теж велика – від 50% до 100%, – це клас людей, з якими керівнику проєкту теж доведеться дуже тісно працювати. Ба більше, активно залучаючи людей з минулого пункту, як ресурс для “боротьби” з цими. Стратегія – “Активно оборонятися” або навіть “Нападати”.

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

Разом

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

1. 
   Статут проєкту
   який визначає цілі проєкту та надає керівнику проєкту владу над ресурсами.
2. 
   Наказ про призначення персоналу
   і, за необхідності,
   Трудові контракти
   з людьми – документи, які визначають початковий склад команди для планування проєкту і наділяють команду повноваженнями і відповідальністю.
3. 
   Реєстр зацікавлених сторін
   що визначає перелік людей, на інтереси яких вплине проєкт або його результат; а також визначає стратегію поведінки команди щодо кожного класу ЗС.

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

Відео-урок із документування проєкту на старті:

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