Запустити проєкт на одному ентузіазмі легко, але без чітких домовленостей він швидко починає буксувати. Якщо команда не знає точних меж своєї роботи, дедлайни зсуваються, бюджет витрачається неефективно, а менеджер втрачає контроль над процесом.
Саме для цього потрібен план управління проєктом. Він зазвичай складається з кількох ключових блоків: дій і цілей проєкту, задач, ресурсів, відповідальних, строків, бюджету, ризиків і критеріїв успіху.
Що таке план управління проєктом?
План управління проєктом — це документ, у якому описані всі важливі елементи проєкту: від активностей і ресурсів до критеріїв успіху, ризиків і способів контролю. Під час підготовки такого плану project manager намагається охопити весь проєкт аж від старту і до завершення.
План управління проєктом є одним із найважливіших документів під час створення проєкту. Так само як проєкт не може бути реалізований без участі зацікавлених сторін, він не може бути ефективно виконаний без зрозумілого плану управління.
До великого плану управління проєктом можуть входити окремі документи:
- план управління вартістю;
- план управління строками;
- план управління якістю;
- план управління ризиками;
- план управління ресурсами;
- план комунікації;
- інші супровідні документи.
У традиційному project management план охоплює всі основні етапи: старт, планування, виконання, моніторинг і завершення. В Agile-проєктах усе складніше, адже через гнучкий формат роботи проєкт не завжди можна спланувати до самого кінця на старті.
Тому плани можуть розроблятися, оновлюватися й погоджуватися протягом усього життєвого циклу проєкту.
Зазвичай у проєкту є два плани управління:
- Базовий план — погоджується керівництвом або замовником. Саме за ним оцінюють успішність виконання задач, строки та якість результату.
- Робочий план — версія, у яку project manager вносить зміни відповідно до нової інформації, задач або обставин.
Для чого потрібен план управління проєктом?
Основні питання, на які відповідає план:
- Чому? Яку проблему розв’язує проєкт? У чому його цінність? Чому він отримав підтримку або фінансування?
- Що? Які основні результати має дати проєкт? Що потрібно зробити для успішного завершення?
- Хто? Кого потрібно залучити до роботи над проєктом? За що відповідатиме кожен учасник? Як буде організована команда?
- Коли? Які строки проєкту? Коли мають бути виконані ключові етапи?
Milestone — це контрольна точка в межах проєкту. Наприклад, перехід до нового циклу або завершення важливого етапу.
Основні цілі плану управління проєктом:
- Координація дій учасників. До проєкту залучена не тільки команда, а й зацікавлені особи. Чим більший проєкт, тим складніше підтримувати узгоджений робочий процес.
- Відстеження статусу виконання проєкту. У традиційному управлінні процес часто має жорстку послідовність кроків. У сучасному project management дедалі частіше використовують Agile-підходи, де проєкт ділиться на менші робочі частини.
- Чітке розуміння ролі кожного учасника. Команда має розуміти, хто за що відповідає, які очікування є до кожної ролі та як окрема задача впливає на загальний результат.
- Пошук проблемних зон до активної фази розробки. Довгострокові проєкти особливо страждають від прихованих проблем. У гнучких підходах це частково вирішується через постійне тестування, перевірку гіпотез і пошук слабких місць для подальших коригувань.
Ключові компоненти плану управління проєктом
Скласти універсальний шаблон плану для всіх проєктів неможливо. Але є базові елементи, на основі яких можна побудувати структуру майбутнього плану.
Основні компоненти плану:
- Короткий опис плану. Кілька абзаців про ключові елементи проєкту, які розкриваються в документі.
- Стратегічна та організаційна відповідність. Тут описують результати аналізу стейкхолдерів і організаційних цілей, які підтримує проєкт.
- Визначення обсягу проєкту. Цей блок включає мету, задачі, очікувані результати, а також інструменти PBS і WBS. Також важливо прописати критерії якості, тобто те, як замовник оцінюватиме ефективність продукту або послуги.
- PBS. Product breakdown structure — інструмент для аналізу, документування та передачі результатів проєкту. PBS є частиною продуктового підходу до планування, який використовується, зокрема, у PRINCE2.
- WBS. Work breakdown structure — ієрархічне розбиття робіт проєкту на менші задачі до рівня, де вже зрозуміло, як саме виконувати роботу, оцінювати її та планувати.
- Оцінка доцільності та резервні плани. У цьому блоці оцінюють економічну, технічну й організаційну доцільність виконання проєкту, а також визначають і аналізують ризики. Також варто прописати план дій для критичних ситуацій.
- Обмеження. Список відомих обмежень, такі як: фіксований бюджет, нестача ресурсів, технічні умови, рішення керівництва або інші фактори.
- Вимоги до команди проєкту. Тут описують організацію команди, ролі й відповідальність учасників. Також можна додати вимоги до навчання.
- Матеріальні вимоги. У цьому розділі зазначають простір, обладнання, програмне забезпечення та інші ресурси, потрібні для виконання проєкту.
- Графік і контрольні точки. Розділ описує milestones і графік активностей проєкту. Зазвичай він включає три ключові елементи: результат роботи, дату або тривалість і критичні залежності.
- Бюджет або оцінка вартості. Очікувані витрати зазвичай ділять на кілька типів: капітальні витрати, операційні витрати й оплату праці учасників команди.
- Управління ризиками. Детальний опис процесу роботи з ризиками: від виявлення через брейншторминг, інтерв’ю або SWOT-аналіз до вибору системи моніторингу.
- Управління змінами. Цей блок схожий на управління ризиками, але стосується саме змін. Тут варто прописати алгоритм внесення змін, методологію управління змінами та спосіб оцінки їхньої успішності.
- Управління комунікацією. У цьому розділі project manager описує систему комунікації для команди й стейкхолдерів, а також канали передачі документації та оновлень щодо проєкту.
- Додатки. Це можуть бути будь-які документи: нотатки, презентації, сертифікати, схеми, дослідження або додаткові матеріали.
До слова, список розділів плану можна доповнювати залежно від особливостей конкретного проєкту.
Базовий і робочий плани проєкту
Під час роботи над проєктом project manager, команда й зацікавлені в цьому проєкті особи, зазвичай працюють із двома типами планів:
- Базовий план — первинний, стабільний, погоджений замовником або іншими відповідальними людьми, а також узгоджений зі стейкхолдерами.
- Робочий план — версія базового плану, яка відображає зміни в термінах, вартості або інших параметрах проєкту.
У процесі розробки проєкту можна порівнювати базовий і робочий плани та бачити, де робота просідає, а де, навпаки, виконання йде швидше або економніше, ніж очікували.
У рідкісних випадках зміни під час проєкту вносять безпосередньо в базовий план управління.
У Worksection діаграма Ганта дозволяє побачити різницю між базовим і робочим планом: синій колір показує загальний час, червоний — протерміновані задачі, зелений — задачі, завершені вчасно.
Як розробити план управління проєктом?
Універсальної інструкції, яка підійде абсолютно кожному бізнесу, немає — все залежить від масштабу компанії, сфери та команди. Проте, щоб не пропустити нічого важливого, найкраще рухатися за перевіреною логікою.
Ми зібрали базовий покроковий алгоритм, який допоможе вам структурувати думки й покроково створити надійний план для будь-якого проєкту.
Простий покроковий алгоритм написання плану з 16 пунктів:
- Визначити стартові умови для розробки плану. Важливо зрозуміти, з ким ви будете його створювати: самостійно, з керівництвом, причетними сторонами або з командою. Також потрібно визначити, де й коли відбуватиметься робота, які методи та інструменти будуть використовуватися.
- Визначити початкові умови проєкту. У цьому блоці описують зміст проєкту, вимоги до результатів і підхід до управління. Наприклад, проєкт може бути створений для продажу певного продукту протягом 12 місяців із конкретною кількісною ціллю.
- Розділити роботи на ті, що виконуватиме команда, і ті, що передаються на аутсорсинг.
- Створити WBS проєкту. Тобто розбити проєкт на менші керовані частини. Це схоже на Agile-підхід, де велика робота ділиться на багато невеликих задач.
- Поставити задачі для кожної частини WBS і побудувати зв’язки між ними.
- Визначити необхідні компетенції для виконання кожної задачі.
- Оцінити час і гроші, потрібні для виконання задач.
- Побудувати критичний шлях проєкту. Його зручно відображати через схему або діаграму Ганта.
- Створити календарний план проєкту. Потрібно визначити стартові, проміжні та фінальні дати.
- Розрахувати вартість проєкту.
- Прописати вимоги до якості.
- Призначити відповідальних за конкретні задачі.
- Спланувати формат роботи із зацікавленими особами.
- Розрахувати ризики.
- Зафіксувати обмеження проєкту.
- Ще раз пройтися по всіх пунктах плану. Після цього залишиться доопрацювати список закупівель, вимоги й погодити план з іншими в проєкті.
Кумулятивний метод розрахунку ризиків — це спосіб оцінки факторів ризику, які можуть завадити отримати запланований дохід. Під час побудови ставки дисконтування за основу береться безризикова ставка доходності, до якої додається премія за інвестиційний ризик проєкту або компанії.
Погодження плану управління проєктом
За нашими спостереженнями, можна виокремити такі пункти в погодженні самого плану:
- Керівники команд надсилають спільно розроблений план project manager.
- Керівник проєкту погоджує план або, якщо є помилки, повертає його на доопрацювання.
- Project manager надсилає погоджений план керівникам проєктних команд для подальшого виконання.
Але така схема більше підходить для команд із налагодженими процесами, які виконують кілька проєктів один за одним або працюють у вже звичному форматі.
Якщо план управління проєктом створюється з нуля, цей метод може не підійти. У таких випадках базовий план погоджує директор компанії або власник проєкту за участі project manager.
Поради, як створити план управління проєктом
- Зафіксуйте план у матеріальній формі. Неважливо, буде це документ на папері чи спеціальне програмне забезпечення. Навіть дрібні нюанси потрібно прописати, інакше можуть виникнути проблеми в комунікації між учасниками та зацікавленими сторонами.
- Залучайте зацікавлені сторони до створення плану. Так ви зменшите ризик різного бачення проєкту, очікуваних результатів і пріоритетів.
- Організуйте систему документообігу. Проєкти створюють багато документів: концепції, ідеї, дизайни, презентації, плани управління ризиками, діаграми критичного шляху тощо. Для швидкого доступу до них має бути зрозуміла система.
- Дослідіть деталі перед розробкою плану. Спочатку варто зрозуміти очікування замовників, учасників проєкту, цілі й методи, які потрібно застосувати під час підготовки плану. Така попередня робота зменшує витрати часу й кількість помилок.
- Поговоріть із командою перед стартом. Це допоможе отримати актуальне розуміння компетенцій співробітників і побачити, чи є зацікавленість у майбутньому проєкті. Один із принципів Agile Manifesto вказує на те, що проєкти мають виконувати мотивовані професіонали, яким довіряють.
План — це лише старт. Як перетворити його на результат?
План управління проєктом — це не чарівна паличка. Сам по собі документ залишається просто декларацією намірів, якщо у вас немає інструментів для його втілення.
Проте такою опорною точкою може стати Worksection. Він переносить плани в реальне життя за допомогою зручних проєктів, задач, підзадач, а також інтегрованого обліку бюджетів, часу та відповідальних прямо всередині робочого простору. Це найпростіший спосіб побудувати прозорі процеси, де кожен учасник команди чітко бачить різницю між базовим планом та поточним робочим процесом.
Пам’ятайте, що грамотний план — це фундамент, який визначає більшу частину успіху вашого проєкту.