Проектні менеджери іноді планують тривалість проекту, ґрунтуючись лише на власному досвіді. Однак розрахунки на прикладі найбільш успішних та найбільш невдалих задач, які вони виконували, швидше за все виявляться некоректними.
Частина менеджерів може несвідомо міркувати за принципом «Я бачу те, що хочу бачити». Поширений випадок, коли управлінець більше довіряється тим відомостям, які відповідають його світогляду. А інформація, що не зустрічає мисленого схвалення, ігнорується.
Ще один виклик при складанні розкладу проекту – комплексність відносин між різними ризиками. Події можуть відбутися в будь-який час під час виконання процесу, мати кореляцію між собою, або стати причиною для появи інших невизначеностей. Одна і та ж подія може мати різний вплив залежно від обставин, і менеджер може «гасити пожежу» теж різними способами.
Методологія моделювання подій (ECM) передбачає, що як би добре не було підготовлено розклад проекту, стануться події, які змінять планований час. Визначити їх заздалегідь, щоб управляти ними – ось головне завдання. ECM не зосереджена на постійних проблемах, тому що виявити і виправити їх можна і без спеціального аналізу.
Візуалізація ризиків, щоб легше їх вивчати – ще одна важлива задача для методології.
Походження
Методологія подійного моделювання сформувалася приблизно до кінця 2000‑х рр. на основі інших інструментів аналізу ризиків. Звід знань по управлінню проектами (PMBOK Guide) рекомендував 2008 року такі техніки для ризикового аналізу: дерево прийняття рішень, метод Монте-Карло та аналіз чутливості. Два останніх підходу і стали базою для Event Chain Methodology.
Метод Монте-Карло допомагає розрахувати статистичний розподіл результатів, відштовхуючись від даних із певною вірогідністю. Аналіз чутливості виявляє ризики з найбільшим впливом на процеси.
Ще одна частина методології – мова графічного опису для моделювання бізнес-процесів, UML. Візуалізація зв’язків між невизначеностями активно застосовувалася в сфері розробки програмного забезпечення і передбачала складання діаграм Ганта й інших графіків для мережі подій.
Також використовуються техніки прогнозу, які аналізують історичні дані. Виявляються схожості між процесами, що відбувалися раніше, і поточними.
Перелічені техніки увійшли у метод моделювання подій. Під їх впливом, розклад проекту складається таким чином:
- Підготуйте розклад проекту для оптимального сценарію. Порахуйте тривалість, вартість та інші ключові параметри. Оптимістичні показники варто відразу прибрати з розрахунків, тому що в більшості випадків проектні менеджери внаслідок самовпевненості, помилкових розрахунків і заради мотивації команди і так закладають самі сміливі цифри.
- Складіть список подій і ланцюжків подій. Спрогнозуйте ймовірність їх настання та вплив на ресурси і діяльність компанії.
- Проведіть кількісний аналіз методом Монте-Карло (як це зробити, ми розповімо далі в статті). Тоді ви зможете визначити, наскільки реально завершити проект в зазначену дату і без непередбачених витрат.
- Проведіть аналіз чутливості. З його допомогою ви виявите ті події і ланцюжки подій, які матимуть найбільший вплив на проект. Потім можете зробити перевірку на реальність даних, щоб оцінити, чи вірно визначили ймовірність настання подій.
- Повторюйте аналіз під час виконання проекту, ґрунтуючись вже на реальних даних і на те, чи відбулися прогнозовані події. Також ви можете провести переоцінку показників ймовірності і впливу ризиків, відштовхуючись від поточних показників.
Принципи ЕСМ
Виявляйте момент настання події і збуджений стан
У більшості випадків, процеси не є постійними і одноманітними. На них впливають зовнішні події, які змінюють їх стан. Коли змінилися умови процесу – для його виконання потрібні інші ресурси або більше часу – він перейшов у збуджений стан. До настання змін він перебував у вихідному стані.
Стан процесу може бути прив’язаним до події. Наприклад, проведення зібрання під відкритим дахом залежить від зовнішньої події «Погана погода». У випадку дощу процес перейде в збуджений стан – зустріч пройде в закритому приміщенні. Тепер процес не залежить від події «Погана погода».
Подія має вплив і ймовірність. Припустимо, процес прив’язаний до події «Зміна вимог». Він може відбутися з імовірністю 50% і викликати затримку на 50% у порівнянні з вихідним станом. Однак при повторенні такого сценарію затримка може скласти вже 25%, так як менеджмент прийняв у минулий раз певні заходи для стримування.
Вплив події може призвести до того, що процес буде відкладений, розпочатий заново, зупинений зовсім, або вимагатиме нових ресурсів і заходів.
Кожна подія має момент настання. Він може бути абсолютним, прив’язаним до певної дати, або відносним – відбутися на початку, середині або кінці процесу. Від моменту настання події залежить його вплив.
Нижче приклад аналізу методом Монте-Карло, як перезапуск проекту, що має ймовірність 50%, вплине на тривалість процесу, який триває 5 днів у вихідному стані:
Найбільша ймовірність до кінця процесу | Однакова ймовірність протягом усього процесу | Тільки до кінця процесу | |
Середня тривалість процесу при виникненні події | 5,9 днів | 6,3 днів | 7,5 днів |
ЕСМ також виділяє пом’якшувальну подія – реакцію менеджера на збуджений стан процесу з метою повернути його у вихідний стан.
Визначте ланцюжки подій
Деякі події можуть спричинити за собою виникнення інших, утворюючи ланцюжки подій. Наприклад, зміна вимог призвела до затримки процесу, і для його прискорення менеджер залучив ресурси, виділені для іншого процесу. У результаті кінцеві терміни не дотримуються, і проект в цілому провалюється.
Подія, яка викликає ланцюжок, називається відправником. Подія, «яка приймає естафету» – одержувачем. Одержуваний ефект від ланцюжка подій називають мультикастингом.
Ланцюжок подій
Ланцюжок подій призводить до більших затримок, ніж вплив на процеси незалежних подій. Нижче показаний такий приклад впливу на три процесу в проекті, для кожного з яких ймовірність перезапуску становить 50%. При цьому процеси тривають по 5 днів. Аналіз проводився методом Монте-Карло.
Вплив незв’язаних подій | Вплив ланцюжка подій | |
Середня тривалість процесу | 18,9 днів | 19 днів |
У 2004 році Інститут проектного менеджменту (PMI) виділив 4 стратегії для управління ризиками:
- Прийняття ризиків: збуджений стан процесу вважається допустимим
- Перерозподіл ризиків: згаданий вище приклад з ланцюжком подій, коли оригінальна подія спричиняє зміни для іншого процесу
- Пом’якшення ризиків: спроба повернути процес у вихідний або менш збуджений стан
- Уникнення ризиків: план проекту відразу побудований так, щоб стани процесів не були прив’язані до зовнішніх подій.
Складіть діаграми для ланцюжків подій і таблиці для станів процесів
Візуалізувати відносини між подіями можна за допомогою діаграм Ганта. Ось правила їх створення:
- події зображуйте стрілками з підписаними поруч назвами
- події з негативним впливом показуйте стрілками вниз, позитивні події – стрілками вгору
- події в ланцюжку з’єднайте лініями
- подія-відправник з численними лініями до подій-одержувачів вважається мультикастингом
- глобальні події, які впливають на всі процеси, зображайте поза діаграмою Ганта. Загрози вказуйте зверху від діаграми, можливості – знизу.
Ось деякі поради, щоб ваша діаграма Ганта не перетворилася в заплутану схему з безліччю відгалужень:
- горизонтальні стрілки подій відповідають середньому моменту настання ризику
- ймовірність події вказуйте поруч з його стрілкою
- розмір стрілок може відповідати ймовірності події. Маленька стрілка сигналізує про невелику ймовірність
- процес у збудженому стані відображати більш високим прямокутником, ніж для вихідного стану
- статистичний розподіл на момент ризику вказуйте поряд з діаграмою
- різні події та лінія, пов’язані з різними ланцюжками подій, виділяйте неоднаковими кольорами.
Також в ЕСМ використовуються таблиці станів процесів. У рядках вказуйте стани процесів, у стовпцях – інформацію про події. Відображаються 4 параметри: ймовірність, момент настання, вплив, та до якого збудженого стану призведе ризик. Якщо клітинка таблиці порожня, значить, стан не прив’язаний до вказаної події.
Ось таблиця станів процесів для IT-компанії, на яку можуть чекати значні або незначні правки коду:
Подія 1: Зміни в архітектурі | Подія 2: Проблеми з інструментами для розробки | Подія 3: Вимоги несуттєво змінились |
Исходное состояние | Вірогідність: 20% Наступає в будь-який час Збуджений стан: переписування коду Вплив: затримка на 2 тижні | Вірогідність: 10% Наступає в будь-який час Збуджений стан: переписування коду Вплив: затримка на 1 тиждень |
Збуджений стан: переписування коду | Вірогідність: 10% Наступає на початку даного стану процесу Збуджений стан: невеликі правки в коді Вплив: затримка на 2 дні | |
Збуджений стан: незначні правки |
Проведіть ризиковий аналіз методом Монте-Карло
Як тільки ви визначили ризики, ланцюжок подій і до яких станів процесів вони прив’язані, можна використовувати метод Монте-Карло для визначення загального впливу подій.
Навіть коли всі ризики позначені, завжди існують невизначеності – коливання – які пов’язані з вартістю і тривалістю проекту. Щоб їх врахувати, необхідно обчислити статистичні розподілу часу для запуску, тривалості і вартості проекту. Тільки базою для розрахунків не повинні бути ті ж приводи, які ви відносили до подій – інакше відбудеться накладка ризиків.
Щоб правильно виконати аналіз методом Монте-Карло, дотримуйтесь цих кроків:
- Вирахуйте моменти настання ризику на основі статистичного розподілу для моменту настання при кожному стані.
- Перевірте, чи відбудуться події-відправники при заданій імовірності.
- Визначте, чи потрібно оновлювати з урахуванням цього експерименту ймовірності подій-одержувачів.
- Перевірте, чи відбулися події-одержувачі при заданій імовірності.
- Проводьте аналіз для кожного процесу у вихідному і збудженому стані.
- Якщо сталася подія, із-за якої процес доведеться скасувати, відразу позначте цей процес як той, який слід скасувати, і врахуйте нові витрати і витрати часу при плануванні проекту.
- Якщо сталася подія, яка викликає виникнення іншої – втручання менеджера як пом’якшувальна дія – то уточніть розклад проекту. Запишіть кількість експериментів, при яких відбулася пом’якшувальна дія.
- Враховуйте разом сукупний вплив подій на вартість і тривалість проекту і коливання тривалості і вартості.
В результаті ви отримаєте ймовірність успішного виконання як проекту, так і окремих процесів.
Знайдіть критичні ланцюжки подій і вартість події
Події або ланцюжки подій, що мають найбільшу ймовірність вплинути на процеси, називаються критичними. Визначити їх можна в ході аналізу чутливості, вивчивши кореляції між головними параметрами проекту, як вартість і тривалість, і ланцюжками подій.
Відстежити критичні події або критичні ланцюжки подій можна за допомогою таблиці чутливості.
Задача_1 | Задача_2 | Задача_3 | Коефіцієнт кореляції | Вартість події |
Подія_1 | 47% | 41% | 0,77 | $5300 |
Подія_2 | 50% | 0,5 | $3440 | |
Подія_3 | 10% | 0,2 | $1380 |
На ній ми бачимо ймовірність настання подій для кожної з трьох задач. Вплив кожної події призведе до того, що задачу доведеться виконати заново. Кожна із задач має змінні витрати в $6667, тобто в цілому проект буде коштувати $20 000. З урахуванням ризиків його вартість вже складе більше $30 000.
Не полінуйтеся проводити вимірювання і в ході проекту
Під час виконання проекту важливо продовжувати проводити аналіз ризиків, відштовхуючись від поточних показників. Однак, як проводити розрахунки, якщо подія, прив’язана до процесу, не сталася? Або навпаки, подія настала, але чи відбудеться вона ще раз?
Для цього придумані 3 підходи:
- Імовірність настання події для частково завершеної події залишається такою ж, незважаючи на те, як часто вона вже відбувалась. Наприклад, погана погода, згідно з планом, може вплинути на проект 10 разів за рік. Якщо через півроку після запуску негода спостерігалася 8 разів, то вона може статися ще 5 разів.
- Ймовірність ризику для частково завершеного процесу залежить від передбачуваного моменту настання. Наприклад, якщо зміна вимог зазвичай відбувається між початком і серединою задачі, а виконана вже половина, то ймовірність події буде знижуватися до кінця процесу.
- Ймовірність ризику повинна визначатися менеджментом на будь-якій стадії процесу. Якщо після зміни вимог «відв’язати» подію від процесу, тобто підготуватися до нього, то наступного разу вона вже не вплине.
Графік нижче показує, як стежити за ймовірністю того, що проект буде виконаний в заданий термін. Ймовірність постійно змінюється під тиском різних подій і ланцюжків подій. У більшості випадків, ймовірність знижується на деякий час. Однак завдяки пом’якшувальній дії від менеджерів, які не забувають проводити кількісний аналіз в ході проекту, шанс на дотримання дедлайну регулярно оновлюється.
Алгоритми ЕСМ
При аналізі ризиків з допомогою методології можуть виникнути проблеми, які в англомовній літературі називають феноменами (Event Chain Methodology Phenomenon). Алгоритми для рішення базуються на перерахованих вище принципах ЕСМ.
Повторювані процеси
Іноді подія може викликати повторний запуск задачі, яка раніше вже була завершена – процес треба повторити через результати наступного за ним. Щоб змоделювати такий сценарій, не потрібно правити розклад проекту. Визначте таку подію і прив’яжіть її до процесу, який вказує на попередній процес. Також встановіть ліміт подій, що викликають повторення процесу.
Пом’якшуючі дії
Дії менеджменту у відповідь в разі настання подій часто вносять у розклад проекту. Через це ускладнюється наочність схеми і подальший аналіз ризиків. У таких випадках передбачте пом’якшуючі дії в діаграмах з подіями або ланцюжками подій.
Затримки в ланцюжку подій
Події можуть викликати інші події як одразу, так і через час. У більшості випадків розраховується ймовірність затримки, а не її тривалість.
Вирівнювання ресурсів
Уявімо, що у нас 3 процеси, які пересікаються, і для яких потрібно 1 ресурс. І в один момент нам доведеться їх перерозподілити. Варіанти рішення – розділити сили або відкласти проект – вносьте в розклад проекту, прив’язавши їх до події. Такий сценарій повинен вивчатися при аналізі методом Монте-Карло.
Кореляція подій і ефект залучення
Деякі події можуть мати кореляцію, при цьому не входити в ланцюжок. Наприклад, якщо компанія використовує два пристрої чи програми від одного виробника/розробника, то погана якість одного з компонентів може свідчити про те, що і інший компонент буде працювати неприйнятно. Такі кореляції враховуються в аналізі методом Монте-Карло.
Ефект залучення виникає, коли стану зовсім незалежних процесів змінюються в один і той же час без впливу однакової події. Це може бути пов’язано з низкою звільнень співробітників – настрої в колективі здатні погіршитися, що негативно відобразиться на продуктивності. З часом такий ефект зникає, так як персонал звикає до змін.
Компанії та організації, які застосовують ЕСМ
Event Chain Methodology застосовується всесвітньо відомими компаніями та структурами: агентством NASA та Міністерством енергетики США, авіавиробниками Boeing і Lockheed Martin, виробниками комп’ютерної техніки HP і IBM, представниками сфери нафтовидобутку Syncrude і Schlumberger, і багатьма іншими.
Існують красномовні приклади того, в які втрати виливалися ілюзії та помилки при плануванні проектів. У 2003 році збій в програмному забезпеченні став головною причиною найбільшого блекауту в історії Північної Америки. Без електрики залишилися близько 50 млн споживачів у США і Канаді. Економічні втрати склали $6 млрд.
В 1996 році провідні компанії у сфері апаратного та програмного забезпечення Oracle, Sun Microsystems і IBM брали участь у суперамбіційному проекті під назвою Network Computers (NC). Метою було завоювати ринок мережевими комп’ютерами, яким не потрібні дисководи – вони завантажували необхідне програмне забезпечення з Інтернету. Таке обладнання також працювало без потужного процесора і жорсткого диска, тому на відміну від стандартних персональних комп’ютерів коштувало менше $1000. Здавалося, що успіх забезпечений.
Проте проектні менеджери компаній зі світовим ім’ям не врахували відразу 4 ризики:
- стандартні ПК будуть коштувати менше 1000 доларів
- програмне забезпечення для мережевих комп’ютерів вийде поганим
- Інтернет-інфраструктури на той момент не вистачить для глобальної роботи NC
- користувачам не сподобається ідея зовнішнього контролю, коли дані з їх системи слідували б на сервер.
Ймовірність для кожного ризику, що він не відбудеться, становила приблизно 70%. Однак загальна ймовірність, що незалежні ризики не трапляться, була набагато нижчою: 0,7х0,7х0,7х0,7 = 0,24.
Так і вийшло: мільйони доларів були інвестовані в провалений проект, що завершився у 2000 році. Комп’ютери-конкуренти різко подешевшали, ціна стала нижче $1000, софт для NC виходив «сирим», а сама ідея випередила свій час – Інтернет почав ставати по-справжньому масовим тільки з 1998 року.
Дослідники, які вивчали провальні проекти, виявили, що головною причиною невдач ставали не природні чинники, а помилки в управлінському судженні. Національний інститут стандартів і технологій США підрахував в 2002 році, що помилки у програмному забезпеченні призводять до втрат на $59,5 млрд для американської економіки, що складав на той момент 0,6% від ВВП країни. Також дослідження показало, що третини втрат можна було уникнути, якби було проведено покращене тестування.
Програми для моделювання подій для проектного менеджменту
- Risk Assesor: Додаток для Android дозволяє оцінити ризики, складати і відсилати звіт для запобігання невизначеностей, і підготувати план проекту.
- Business Risk Assesment (BRISK): Телепрограма для оцінки, управління та пом’якшення ризиків. Фактори впливу можна відобразити у вигляді карти.
- Sensitivity Analysis: Додаток для проведення аналізу чутливості для двох альтернатив. Складає графік з результатами аналізу.
Вердикт
Мотиваційні фактори впливають на ключові параметри процесів більше, ніж ризики. Методологія моделювання подій допомагає подолати вибіркове сприйняття, схильність менеджера до затвердження тієї інформації, яка відповідає його принципам, а також зверхвпевненість і помилковість планування.
ЕСМ враховує ті чинники, які не зачіпають інші техніки для аналізу ризиків: момент настання ризику, ланцюжки подій, затримки у виникненні подій, що пом’якшують дії. Щоб спростити виявлення подій і їх ланцюжків, складаються діаграми і таблиці для стану процесів.