Проєктний менеджмент критичного ланцюга
Проєктний менеджмент критичного ланцюга (CCPM) є способом планування і управління проєктами, що акцентується на необхідних ресурсах (люди, обладнання, фізичний простір) для виконання задач проєкту, розроблений Еліяху Моше Голдратом. Він відрізняється від більш традиційних методів, похідних від методу критичного шляху та алгоритмів PERT, що акцентуються на порядку виконання задач та жорсткому плануванні. Метод критичного шляху тяжіє до балансування використання ресурсів, та потребує їх гнучкості на початкових етапах проєкту.
Проєктний менеджмент критичного ланцюга базується на методах та алгоритмах, похідних від Теорії обмежень. Ідея CCPM була представлена у 1997 в книзі Еліяху Моше Голдрата, Критичний Ланцюг. Застосування CCPM дозволило підвищити з 10% до 50% швидкість виконання проєктів та/або їх вартість у порівнянні з традиційними способами (наприклад, CPM, PERT, Gantt, і т.д.), що розроблялися з 1910-х до 1950-х років.
Відповідно до досліджень, що проводилися починаючи з 1998го року, традиційних методів проєктного менеджменту компанією Standish Group та іншими, лише 44% проєктів зазвичай закінчуються вчасно. Більшість проєктів закінчуються у термін 222% від запланованого, 189% від початкового бюджету, 70% проєктів не реалізовано у запланованому обсягу та 30% відміняються до завершення. Завданням CCPM є покращення продуктивності відповідно до цієї традиційної статистики.
При використанні традиційних методів проєктного менеджменту, 30% втраченого часу і ресурсів типово споживається марнотратними процесами, зумовленими такими причинами як погане розподілення по мультизадачності (зокрема перемикання між задачами), синдромом студента, Законом Паркінсона, внутрішніми затримками та браком пріоритезації.[1]
В розрізі проєкту, критичний ланцюг є послідовністю як пріоритетно-, так і ресурсозалежних задач, що запобігають завершенню проєкту у коротший термін за умови обмежених ресурсів. Якщо ж ресурси завжди доступні в безмежних кількостях, тоді метод критичного ланцюга проєкту ідентичний Методу критичного шляху.
Критичний ланцюг є альтернативою аналізу критичного шляху. Головні риси, що відрізняють критичний ланцюг від критичного шляху є наступні:
- Використання (часто неявно) залежності ресурсів. Неявність в даному випадку означає, що вони не включені у мережу проєкту, але мусять бути визначені у вимогах до ресурсів.
- Брак пошуку оптимального рішення— "достатньо доброго" рішення вистачить через те, що:
- Загальновідомо, наразі немає аналітичного методу для пошуку абсолютного оптимуму (тобто для отримання в загалом найкоротшого критичного ланцюга).
- Властива невизначеність у оцінках набагато більша за різницю між оптимумом та наближено-до-оптимуму ("достатньо добрі" рішення).
- Визначення та установка буферів:
- Проєктний буфер
- Живильні буфери
- Ресурсні буфери (компанії зазвичай неохоче йдуть на виділення більшої кількості ресурсів)
- Моніторинг прогресу виконання проєкту та його здоров’я за допомогою моніторингу витрати буферів, а не моніторингу продуктивності індивідуальних задач відповідно графіку.
Планування CCPM збирає докупи великі об’єми резервного часу, що були додані до задач проєкту як буфери — для захисту продуктивності "до певної дати" та уникнення витрат цього резервного часу через погане розподілення по мультизадачності, Синдрому студента, Закону Паркінсона та слабко синхронізованої інтеграції.
Проєктний менеджмент критичного ланцюга використовує управління буферами замість методу засвоєного об’єму для оцінки продуктивності проєкту. Частина проєктних менеджерів вважає, що технології методу засвоєного об'єму є оманливими через те, що вони не вирізняють прогрес по обмеженнях проєкту (наприклад, по критичному ланцюгу) від прогресу по не-граничних умовах (наприклад, по інших шляхах). Методологія ланцюга подій може визначити розмір проєкту, живлення та буфери ресурсів.
План проєкту чи структура декомпозиції робіт (WBS) створюється у дуже схожий спосіб до критичного шляху. План будується у зворотньому напрямі від дати завершення з кожним завданням, що має починатися якомога пізніше.
У кожної задачі визначається і встановлюється тривалість. Деякі програмні рішення додають ще інші тривалості: перша "найкраща здогадка," або 50%-ва імовірність тривалості, та додаткова "безпечна" тривалість, яка має вищу імовірність для настання (десь 90% чи 95%, в залежності від об'єму ризику, прийнятною для даної організації). Інші програмні рішення проходять через всі оцінки тривалості кожної задачі та видаляють фіксований відсоток, що буде включений у буфери.
Ресурси виділяються кожній задачі, план рівномірно розподіляється за ресурсами за допомогою використання "агресивних тривалостей". Найдовша послідовність ресурсно-збалансованих задач, що визначені у проєкті з самого початку і до самого кінця визначається як критичний ланцюг. Розподілення задля використання 50%-ї оцінки визначає, що половина задач рано почнеться та половина закінчиться пізно, таким чином сумарна девіація по тривалостям у проєкті буде нульовою.
Зважаючи на те, що виконання задач частіше вимагає більшого часу згідно Закону Паркінсона, Синдрому Студента та інших причин, CCPM використовує "буфери" для моніторингу графіку виконання проєкту і фінансової продуктивності. "Додаткова" тривалість кожної задачі у критичному ланцюгу— різниця між "безпечними" тривалостями та 50% тривалостями—збирається у буфер наприкінці проєкту. Таким же чином, буфери збираються у кінці кожної послідовності задач, що складають критичний ланцюг. Дата у кінці проєктного буферу надається зовнішньому стейкхолдеру як дата випуску. Після цього точка відліку вважається установленою, що дозволяє почати фінансовий моніторинг проєкту.
Альтернативна методологія оцінки тривалості використовує імовірнісну оцінку за методом Оцінки Монте-Карло. У 1999 році дослідники застосували симуляцію для оцінки впливу ризиків, пов'язаних з кожним компонентом структури декомпозиції робіт проєкту на тривалість проєкту, ціну та продуктивність. Використовуючи симуляцію Монте-Карло, проєктний менеджер може застосувати різноманітні імовірності різних факторів ризику, що впливають на певний компонент проєкту. Імовірність настання випадку може варіюватися від 0% до 100%. Вплив ризику вноситься в симуляційну модель разом з імовірністю настання. Кількість ітерацій симуляції Монте-Карло залежить від рівня толерантності до помилок та надають графік щільності, що відображає сумарну імовірність впливу ризику на випуск проєкту.
Коли план завершено та проєкт готовий для старту, вносяться всі необхідні зміни в мережу проєкту та блокуються розміри буферів проєкту (мається на увазі, що їх запланована тривалість не може бути зміненою протягом виконання проєкту), тому що вони використовуються для моніторингу графіку виконання проєкту та фінансових показників.
За відсутності слабких місць в тривалостях окремих завдань ресурси фокусують на певному завданні для його завершення і передачі наступному члену групи. Кінцева мета на даному етапі - уникнути поганого розподілення мультизадачності. Вона досягається за рахунок надання інформації по пріоретизації усім ресурсам. У літературі проводять аналогію з естафетою. Кожен елемент проєкту має рухатися якомога швидше: протягом виконання частки елементу у проєкті, виконавці мають сфокусуватися на завершенні призначеного завдання якомога швидше, з мінімізацією відволікання та мультизадачності. У деяких варіантах навчання, фактичні завдання вивішуються на спеціальних дошках, де вказується, коли виконавці працюють над задачами критичного ланцюга, щоб інші не могли їх переривати. Метою цього етапу є подолання тенденції відкладання роботи або виконання додаткової роботи, коли здається, що на це є достатньо часу. Література по CCPM робить контраст "традиційного" проєктного менеджменту,що моніторить дати початку та завершення. CCPM змушує людей рухатися якомога швидше у незалежності від дат.
Через те, що тривалості задач плануються з 50% імовірністю, є тиск на ресурси, щоб вони виконували задачі критичного ланцюга якомога швидше, долаючи синдром студента та Закон Паркінсона.
Відповідно до авторів методології, моніторинг є, деякою мірою, найбільшою перевагою методу Критичного Ланцюга. Через варіацію індивідуальних задач з 50% імовірності, немає сенсу у спробах змусити закінчити кожне завдання "вчасно" - оцінки ніколи не можуть бути досконалими. Замість цього ми моніторимо буфери, що були створені протягом етапу планування. Графік лихоманки чи подібний графік можуть бути створені та опубліковані задля споживання буферу як функції завершення проєкту. Якщо рівень використання буферу низький, проєкт буде виконано вчасно. Якщо рівень використання буферу такий, що лишається мало буферного часу, або буфер наприкінці проєкту порожній, мають бути виконані дії по корекції планів або мають бути розроблені плани по поверненню втрат. За умов, коли рівень споживання буферу перевищує деяку критичну позначку (грубо кажучи: рівень, коли схоже, що всі буфери будуть спожиті перед закінченням проєкту, що призведе до пізнього завершення), тоді ці альтернативні плани мають бути введені в дію.
Історія та обговорення принципів, що лежать в основі CCPM.
Критична послідовність була початково ідентифікована у 1960-х роках.
- Теорія обмежень
- Методологія ланцюга подій
- Метод критичного шляху
- Управління проєктами
- Менеджер проєкту
- ↑ Harvey Maylor, Project Management
- Project Management In the Fast Lane, ISBN 1-57444-195-7
- Critical Chain Project Management, ISBN 1-58053-074-5
- Projects in Less Time: A Synopsis of Critical Chain, by Mark Woeppel
- A critical look at critical chain project management [Архівовано 4 березня 2016 у Wayback Machine.], Tzvi Raz, Robert Barnes and Dov Dvir, Project Management Journal, December 2003.
- a critical review of "A Critical Look at Critical Chain" [Архівовано 5 березня 2016 у Wayback Machine.], Scott Button, EM 540 Research Paper, March 2011
- "Lean, Agile and Six Sigma IT Management", by Peter Ghavami (2008)
- Critical Chain Project Management Theory and Practice [Архівовано 17 серпня 2018 у Wayback Machine.], Roy Stratton, POMS 20th Annual Conference, May 2009
- An Online Guide To Theory Of Constraints [Архівовано 24 січня 2016 у Wayback Machine.] - Опис буферизації проєктів та Менеджмент Буферів Критичного Ланцюга
- Critical Chain Project Management News [Архівовано 17 січня 2016 у Wayback Machine.] - Останні новини та джерела інформації