Документування тривалості проєкту
Команда проєкту була оформлена минулою статтею, а поки вона формується, ми розберемося, як документувати терміни проєкту, тобто. його тривалість. Для цього нам знадобляться результати документування обсягів робіт, кілька експертів із технології виконання задуманого і додаток типу Microsoft Project.
Підписуйтесь на групу PMDoc у Facebook, і обговорюйте з колегами питання документування проєктів |
| Мене звуть Анатолій Савін . Я експерт із документування та автор тренінгу “Документування проєктів”. Я продовжую цикл статей і відео-уроків з управлінського документування проєктів. Перед тобою четверта стаття з цього циклу – “Документування тривалості проєкту”. |
Документування тривалості проєкту – це окремий випадок планування термінів проєкту і розроблення графіка. Нагадаю, що загальне управління проєктами я намагаюся виносити за рамки цього циклу статей, і описую тільки склад і правила заповнення документів для управління проєктами. Загалом процеси розроблення розкладу описані в Practice Standard for Scheduling, а ми задокументуємо це!
Творення графіка
Є 4 основні способи наповнення графіка проєкту:
- Розробка “зверху-вниз” або від загального до часткового. Тобто ми спочатку розбиваємо проєкт на великі блоки, потім деталізуємо ці блоки, поки не дійдемо до окремих робіт.
- Розробка “знизу-вгору” або від приватного до загального. Тобто спочатку генерується велика кількість завдань, які потрібно зробити, а потім вони збираються в групи, підпроєкти та кластери.
- Використання готового графіка подібного проєкту й адаптація його під потреби та умови нашого проєкту.
- Використання шаблонів графіків і галузевих нормативів.
Усі ці способи легко комбінуються один з одним. Ось ми і скомбінуємо.
Наразі в нас уже є WBS (після документування обсягів робіт проєкту), тому переносимо її в MS Project (або подібний інструмент) і отримуємо чудову структуровану основу графіка верхнього рівня (тобто починаємо з першого способу). Далі, потрібно кожен елемент WBS декомпозувати на дрібні елементи. І для нас немає жодної різниці, у який спосіб ми будемо це робити. Можемо для підпроєктів використовувати графіки з минулих проєктів (спосіб 3), для конструктивів – шаблони і нормативи (спосіб 4), а кожну фазу деталізувати знизу-вгору (спосіб 2). Головне – у результаті своєї деталізації дійти до окремих робіт і отримати попередній Список операцій проєкту.
Але як зрозуміти нормально ми деталізували чи продовжувати далі дробити завдання? Давай розберемо, що таке “робота”.
Як квант у фізиці – неподільна порція будь-якої величини, так і робота – це неподільна частина проєкту. Для неї зберігається чітке правило – вона виконується одним виконавцем в один період управління.
Своєю чергою, розмір “бригади-виконавця” і тривалість управлінського періоду залежать від масштабу проєкту. Якщо проєкт на роки і в нього залучено сотні людей, то виконавцем може бути цілий департамент компанії в особі його керівника, а управлінський період довжиною в квартал. Якщо проєкт маленький, то і виконавцем є 1 людина, а період – 1 тиждень.
Робота, звісно, може початися в одному періоді, а закінчиться в наступному. Але вона не може тривати два і більше періодів. Так само дотримуємося правила одного виконавця, щоб уникнути колективної безвідповідальності. Дивимося на роботи довші за наш управлінський період і з кількістю виконавців більше одного і продовжуємо декомпозицію.
Зрозуміло, що для занадто віддалених у часі робіт ми не зможемо це зробити тут і зараз. А це й не потрібно. Декомпонуйте методом хвилі, що набігає. Можете спланувати роботи на місяць-два? Плануйте! Решту сплануєте протягом цього місяця.
Крім того, підтримання рівномірного періоду управління – це свого роду тактовий генератор проєкту. До нього, наприклад, прив’язуються віхи проєкту, і я не рекомендую закладати більше ніж дві віхи в один період або виконувати проєкт без віх довше ніж два періоди. До нього ж прив’язується фінансування проєкту, регулярність поставок, виділення ресурсів тощо. І в цьому немає нічого дивного і складного, оскільки весь наш робочий час складається з таких періодів – тиждень, декада, місяць, квартал… Вибирайте будь-який період, залежно від масштабу нашого проєкту.
Отже, у нас є перелік робіт і є ресурси(докладніше у статті “Документування команди проєкту”). Тепер потрібно визначити тривалості робіт, розставити ці роботи в логічній послідовності та задокументувати зв’язки між ними. Усі роботи в рамках проєкту мають бути взаємопов’язані та подані у вигляді мережевої діаграми. Тоді легко визначається критичний шлях проєкту і його загальна тривалість.
| Шаблони документів для розробки розкладу: |
Звісно ж, графік, підготовлений у такій послідовності(WBS – Список операцій – Ресурси – Тривалість – Зв’язки), далеко не завжди відповідає нашим обмеженням за термінами і завантаженням ресурсів. Тому потрібно “підчистити” свою роботу.
Прибрати за собою
Я не буду тут розповідати про всі способи стиснення й оптимізації розкладу. Ці способи добре описані в тому ж Practice Standard for Scheduling, у PMBOK або в будь-якій іншій літературі з управління проєктами. Я тут розповім про одну хитрість, як перевірити якість розробки графіка самим оформлювачем цього документа. Особливо це актуально, коли цей оформлювач добре знає інструмент документування (MS Project), але нічого не тямить у технології виконання робот проєкту.
Така ситуація зустрічається часто-густо. Експерти зібралися, “нагенерували” завдань, надали якісь шматки графіка, вказали основні взаємозв’язки, прикинули ресурси і розійшлися. Планувальник оформив усе це в одному графіку, незрозумілості уточнив у експертів і домігся прийнятних термінів, застосувавши методи стиснення розкладу.
І начебто, і діаграма Гантта є, і експерти кивають головою (принаймні кожен підтверджує свою частину графіка), але як перевірити, все це в зборі злетить чи не злетить?
Отже, хитрість. Потрібно просто побудувати S-криву за створеним графіком. Як будувати криву, дивіться в мікро-відео-уроці.
Дивимося на отриману S-криву. На що вона більше схожа?
- Якщо на похилу букву S (варіант I), то розклад складено правильно. У нас є:
- не дуже активний початок (коли всі учасники ще збираються думками і дуже висока ймовірність змін, але змін ще поки що на папері, а не на об’єкті);
- швидка реалізація основної частини робіт;
- і знову не дуже активне плановане завершення, яким ми зможемо скористатися, якщо щось піде не так в основній частині.
- Якщо варіант II, то ми спланували аврал. Тобто на початку є час на розкачку, але наприкінці немає часу на непередбачувані ситуації.
- Якщо варіант III, то ми спланували провал. У проєкті не передбачено часу на спокійну підготовку. Усі засоби і ресурси з ходу кидаються “в бій”. А ми пам’ятаємо закон Мерфі “Якщо щось може піти не так, воно обов’язково піде не так. Якщо все ідеально сплановано і нічого не може піти не так, то з’явиться щось, що обов’язково піде не так”. Але на переробку цього “не так” уже ресурсів може не вистачити.
- Ну, і варіант IV, гарний своєю рівномірністю, але не позбавлений проблем варіантів II і III, хоча, звісно, не так яскраво як у цих варіантах.
Перевіривши таким чином свій графік, оформлювач аргументовано може поспілкуватися з керівником проєкту і з експертами для приведення графіка в потрібний формат.
Шаблони документів розкладу проєкту:
|
Разом
З точки зору документування, підсумок планування тривалості проєкту має такий вигляд:
WBS
,
Список операцій
і
Вимоги до ресурсів
отримані на етапах документування обсягів робіт і документування команди, які дають нам можливість розпочати розробку розкладу проєкту.- Оцінка тривалості операцій і Послідовність операцій у вигляді подань “PA_PERT Entry Sheet” і “Мережева діаграма” у файлі MS Project “ISO21500-5TIM1-Розклад”.
Розклад проєкту
, який об’єднує операції проєкту, тривалості, залежності та іншу інформацію про планування.
- Шаблони всіх цих та інших документів з управління термінами проєкту можна отримати/ погортати тут:
ЗСУП.Терміни.Комплект
за PMBOK (5th edition).
ІСО21500:Строки
за ISO 21500:2012.
- Повний пакет шаблонів, створених на основі PMBOK (5-ї редакції) можна отримати тут:
ЗСУП.Комплект.v5
- Повний пакет шаблонів, створених на основі ISO 21500:2012 можна отримати тут:
ІСО21500:Комплект
- Усі приклади та шаблони документів порталу PMDoc, пов’язані з управлінням термінами різних проєктів, можна отримати тут:
Терміни проєкту
.
У наступній статті я розповім, як документувати бюджет проєкту.
Залишити відповідь
Бажаєте приєднатись до дискусії?Не соромтеся робити внески!