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

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

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

З’ясувати та оформити вимоги

Вимоги бувають двох типів:

1. Вимоги до проєкту – тобто. як ми маємо керувати проєктом.
2. Вимоги до продукту – тобто. що ми маємо отримати в результаті проєкту.

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

Усі вимоги потрібно дискретно висловити в Реєстрі вимог і в Документації щодо вимог. Що це за документи і чим вони відрізняються?

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

Потрібно розуміти, що зміни в проєкті неминучі. Про документування змін я докладно розповім у статті щодо документування проєкту в процесі контролю, а зараз просто зазначу, що основним джерелом змін у проєкті є мінливі забаганки і нові побажання основних стейкхолдерів проєкту (замовника, спонсора і ключових користувачів продукту). Звісно, зміни в проєкті неминучі, але вони і вкрай важливі для успіху проєкту. Річ у тім, що на початку проєкту побажання стейкхолдерів можуть бути не виразними, а в міру “дорослішання” самого проєкту і вимоги до проєкту та продукту стають дедалі зрілішими. Саме грамотне внесення змін у проєкт і забезпечує успішність проєкту. Як уже зазначалося в минулій статті, ми живемо у VUCA-світі, і те, що замовник хоче на початку проєкту, не дорівнює тому, що йому буде потрібно наприкінці.

Отже – вимоги змінюватимуться, а Реєстр вимог дає змогу відстежити ці вимоги, що змінюються, протягом усього проєкту. Ідеальним варіантом оформлення і ведення цього документа – використання спеціального ПЗ для відстеження вимог, типу Redmine або того ж MS Project Server, тільки трохи “доопрацьованого напилком”.

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

З малюнка видно, що опис вимог у Реєстрі досить стислий і часто потребує додаткової описової інформації. Для цього і використовується другий документ – Документація за вимогами, який описує кожну вимогу в усіх деталях, щоб вони стали однозначними (вимірюваними та перевіреними), відстежуваними та повними. Формат Документа за вимогами може варіюватися від простого документа, що перераховує всі вимоги, розділені на категорії за зацікавленими сторонами та пріоритетами, до певної папки-швидкозшивача або електронної папки на порталі проєкту, що містить у собі всі документи та файли, пов’язані з вимогами з Реєстру вимог. Наприклад, у Реєстрі зазначено, що документування якоїсь автоматизованої системи має бути здійснено відповідно до ГОСТ 34.201. Відповідно в Документації за вимогами сам цей ГОСТ має бути в паперовому або електронному вигляді, щоб будь-який розробник міг отримати до нього доступ і з’ясувати, чи все робили цього ГОСТу.

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

Описати обсяги робіт

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

Опис змісту містить у собі:

• Опис продукту, описаного в Статуті проєкту та в Документації за вимогами.
• Критерії приймання, тобто. умови, які мають бути виконані для того, щоб продукт і результати проєкту були прийняті замовником.
• Винятки з проєкту – явне формулювання того, що саме в проєкті точно не буде виконуватися, щоб не роздувати обсяги робіт проєкту.
• Обмеження, тобто межі або обмежувальні умови, які впливають на виконання проєкту, наприклад, зумовлений бюджет.
• Припущення – фактори, які вважаються правильними, реальними або визначеними без надання доказів і без демонстрації. Припущення можуть виявитися помилковими і зазвичай є джерелом ризиків у проєкті, але вони дають змогу запустити планування проєкту без довгих досліджень. Одним із найяскравіших прикладів допущення в історії управління проєктами є допущення, що місяць твердий. Чув про таке допущення? Ні? Я розповім:
  Середина 60-х років XX-го століття. Радянська місячна програма розробляється повним ходом. І тут виникає питання: яким робити шасі посадкової станції? Адже неможливо проектувати його, не знаючи, хоча б приблизно, куди станція сідатиме. А що являє собою ґрунт місячної поверхні, ніхто ще точно сказати не міг. Одна група астрономів стверджувала, що на Місяці ґрунт твердий, а друга так само переконливо доводила, що за багатовікову історію Місяця через постійне бомбардування метеоритами там утворився шар пилу, причому його товщина сягає 50-ти метрів у кратерах, а на рівних ділянках – десяти…
  Корольов зібрав нараду, запросивши всіх зацікавлених у місячній програмі фахівців. За дві години наради всі пересварилися один з одним, і тільки сам Корольов не вимовив жодного слова. Дивився і слухав. Немов чекав чогось. Нарешті, взяв слово.
  – Місяць – твердий! – сказав він різко і, як зазвичай, безапеляційно.
  Хтось із астрономів все-таки заперечив:
  – Це ще довести треба! Ніхто з учених не бере на себе сміливість написати – на Місяці, мовляв, такий-то ґрунт… і підписатися під цим!
  Корольов подивився втомленими очима на сидячих за столом:
  – Ах, ось чого вам не вистачає…
  Узяв блокнот, великим почерком написав на його аркуші: “Місяць – твердий“. Підписався: “С. КОРОЛЬОВ“. Поставив дату, вирвав аркуш із блокнота і передав співробітникові, який мав безпосередньо керувати проєктуванням станції.

Що стосується обмежень проєкту, то тут потрібно враховувати, що обмеження часто конкурентні та впливають одне на одного. Як правило, виділяють шість основних обмежень: бюджет, термін, ресурси, якість, ризики, ну, і самі обсяги робіт. І якщо, наприклад, зменшується термін проєкту, то, як правило, збільшується навантаження на ресурси, або збільшується бюджет, або погіршується якість, збільшуються ризики, ріжуться обсяги робіт. Усі подібні конкурентні взаємозалежності обмежень представлено на малюнку:

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

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

Розбити на складові

Розбиття обсягів робіт проєкту на більш дрібні і, отже, легше керовані частини дає змогу отримати WBS – структуроване бачення того, що необхідно досягти.
WBS, тобто work breakdown structure або ієрархічна структура робіт може бути організована по-різному, наприклад, за етапами проєкту, за основними конструктивами, за підпроєктами або мікс із цих елементів.

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

Візуалізація на схемі:

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

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

Для чого структуруємо?

1. Для розбивки проекту на керовані блоки
2. Для переходу від загальних описів до конкретних завдань
3. Для розподілу відповідальності та визначення комплексів робіт/підрядів
4. Для більш точної оцінки витрат

Найдетальніше методику розроблення WBS описано в Practice Standard for Work Breakdown Structures – Second Edition.

Разом

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

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

1. 
   Реєстр вимог
   і
   Документація за вимогами
   , що визначають, які саме вимоги до проєкту та продукту потрібно задовольнити для успішного досягнення цілей проєкту.
2. 
   Опис змісту проєкту
   – виклад змісту проєкту, зокрема основних результатів, обсягів робіт, припущень і обмежень.
3. 
   Базовий план з утримання
   і
   WBS
   узгоджені зі спонсором або замовником опис і розбивка обсягів робіт проєкту на дрібні керовані частини.

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

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