Проектные менеджеры иногда планируют продолжительность проекта, основываясь только на личном опыте. Однако расчеты на примере самых успешных или неудачных заданий, которые они выполняли, скорее всего окажутся некорректными.
Часть менеджеров может неосознанно рассуждать по принципу «Я вижу то, что хочу видеть». Распространенный случай, когда управленец больше доверяется тем сведениям, которые соответствуют его мировоззрению. А информация, не встречающая мысленного одобрения, игнорируется.
Еще один вызов при составлении расписания проекта — комплексность отношений между разными рисками. События могут произойти в любое время во время выполнения процесса, иметь корреляцию между собой или стать причиной для появления других неопределенностей. Одно и то же событие способно иметь разное влияние в зависимости от обстоятельств, и менеджер может «тушить пожар» тоже разными способами.
Методология моделирования событий (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 ресурс. И в один момент нам придется их перераспределить. Варианты решения — разбить силы или отложить проект — вносите в расписание проекта, привязав их к событию. Такой сценарий должен изучаться при анализе методом Монте-Карло.
Вот пример схемы, когда 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
Приложение для проведения анализа чувствительности для двух альтернатив. Составляет график с результатами анализа.
Вердикт
Мотивационные факторы влияют на ключевые параметры процессов больше, чем риски. Методология моделирования событий помогает преодолеть избирательное восприятие, склонность менеджера к утверждению той информации, которая соответствует его принципам, а также сверхуверенность и ошибочность планирования.
ЕСМ учитывает те факторы, которые не затрагивают другие техники для анализа рисков: момент наступления риска, цепочки событий, задержки в возникновении событий, смягчающие действия. Чтобы упростить выявление событий и их цепочек, составляются диаграммы и таблицы для состояния процессов.