В Deadline, Том Демарко пишет о том, что для управления проектом, достаточно управлять его рисками. Действительно, всю работу ПМа можно свести к одному — борьба с рисками, которые могут помешать проекту завершиться в срок, в бюджет и с необходимым уровнем качества. Если, по какой-то причине, рисков в проекте нет, то нет и предмета работы ПМа.
Но проектов без рисков, наверное, не существует в природе и с ними так или иначе приходится работать. О том, как это делать, можно прочесть в PMBOK, на википедии и на тематических ресурсах. В этой статье больше практики, чем теории. Ее цель — показать на примерах недорогой и эффективный подход к управлению рисками проекта.
PMBOK рекомендует управлять рисками в 4 этапа:
Спланируем их:
Будем повторять весь цикл с периодичностью в две недели, этого должно быть достаточно. План готов, осталось подробно описать шаги.
Цель этого этапа — выявить некоторое количество неизвестных рисков проекта. Полагаем, что потенциальных проблем вокруг нас бесконечно много, поэтому задачу будем ставить количественно. В начале проекта, неплохо идентифицировать 50–100 рисков, в дальнейшем — по 20–30 штук.
На входе: план проекта, текущий список рисков (если есть);
Процесс:
На выходе: обновленный список рисков в формате «причина-риск-эффект».
Пример:
Очевидно, что бороться со всеми рисками сразу дорого и малоэффективно. Цель этого этапа — выявить наиболее важные из них. Для каждого риска оценим его Вероятность и Последствия по десятибалльной шкале. Перемножив их, получим Важность. Обозначим также некоторую границу Важности (например 50), чтобы понять какие риски критичны и далее работать только с ними.
На входе: список рисков;
Процесс:
На выходе: список критичных рисков;
Пример:
Фактически, на этом этапе и происходит управление проектом. Для каждого риска, из списка критичных, необходимо придумать стратегию, которая наш проект от него обезопасит. Всего стратегий используется три:
Transfer. Переносим ответственность за последствия риска на третью сторону (заказчика, компанию партнера, страховую компанию и так далее). Применять эту стратегию есть смысл, если сами мы не можем повлиять на риск и есть на кого эту ответственность переложить.
Accept. Принимаем ответственность за последствия риска на себя, но ничего не делаем, оставляем все как есть. Применять этот подход есть смысл только когда с риском мы поделать ничего не можем, а делать трансфер на третью сторону неоправданно дорого.
Mitigate. Боремся с риском, принимая ответственность на него на себя. Для борьбы с риском хорошо иметь несколько планов. Основной, для того, чтобы риск подавить, и отходной, на случай если риск все-таки случился и влияет на проект:
На входе: список критичных рисков;
Процесс:
На выходе: список критичных рисков со стратегией и планом на каждый риск, обновленный план проекта;
Пример:
Это скорее процесс, чем этап. Его цель — поддерживать список рисков и план проекта в актуальном состоянии.
На входе: спланированный список рисков, план проекта, ежедневные отчеты команды;
Процесс:
На выходе: обновленный список рисков, обновленный план проекта;
Пример:
Для проекта с командой в 15 человек, расходы на управление рисками составят 50–60 человеко-часов в месяц. При этом будет идентифицироваться около 50 новых рисков, из них в среднем 10 самых важных будет планироваться и подавляться. Положив, что критичный риск отбирает у проекта минимум 40 человеко-часов, получаем от 400 человеко-часов экономии ежемесячно.
Процесс, описанный в этой статье, можно и нужно улучшать. Можно усложнять его для сложных больших проектов, можно упростить и тратить на работу с рисками 2 часа в месяц. Так или иначе, гораздо дешевле работать с рисками как-то, чем не работать с ними вообще.
Но проектов без рисков, наверное, не существует в природе и с ними так или иначе приходится работать. О том, как это делать, можно прочесть в PMBOK, на википедии и на тематических ресурсах. В этой статье больше практики, чем теории. Ее цель — показать на примерах недорогой и эффективный подход к управлению рисками проекта.
Риск менеджмент план
PMBOK рекомендует управлять рисками в 4 этапа:
- Идентификация. Выявить риски, которые могут помешать целям проекта.
- Анализ. Определить, какие из выявленных рисков наиболее опасны.
- Планирование. Спланировать наиболее опасные риски.
- Мониторинг и контроль. Поддерживать план проекта и список рисков в актуальном состоянии.
Спланируем их:
| Что |
Кто |
Когда |
Как |
|---|---|---|---|
| Идентификация рисков |
ПМ + команда проекта |
Вторник 14–00 |
Митинг. 1 час |
| Оценка рисков |
ПМ + лиды |
Вторник 15–00 |
Митинг. 1 час |
| Планирование рисков |
ПМ + ПМы других проектов |
Вторник 16–00 |
Митинг. 2 часа |
| Мониторинг и контроль |
ПМ |
Ежедневно 13–00 |
Активность. 30 мин |
Будем повторять весь цикл с периодичностью в две недели, этого должно быть достаточно. План готов, осталось подробно описать шаги.
Идентификация рисков
Цель этого этапа — выявить некоторое количество неизвестных рисков проекта. Полагаем, что потенциальных проблем вокруг нас бесконечно много, поэтому задачу будем ставить количественно. В начале проекта, неплохо идентифицировать 50–100 рисков, в дальнейшем — по 20–30 штук.
На входе: план проекта, текущий список рисков (если есть);
Процесс:
- ПМ собирает митинг со всей командой, сообщает о его цель, длительность и agenda;
- ПМ сообщает о статусе проекта, об основных текущих рисках и проблемах, отвечает на вопросы;
- Участники митинга озвучивают потенциальные риски. Принимаются все идеи без исключения, без обсуждений и комментариев;
- ПМ записывает результаты в формате «причина-риск-эффект». Как только цель достигнута, либо время истекло, митинг завершается;
На выходе: обновленный список рисков в формате «причина-риск-эффект».
Пример:
Анализ рисков
Очевидно, что бороться со всеми рисками сразу дорого и малоэффективно. Цель этого этапа — выявить наиболее важные из них. Для каждого риска оценим его Вероятность и Последствия по десятибалльной шкале. Перемножив их, получим Важность. Обозначим также некоторую границу Важности (например 50), чтобы понять какие риски критичны и далее работать только с ними.
На входе: список рисков;
Процесс:
- ПМ собирает митинг с тим лидами, сообщает о его цель, длительность и agenda;
- ПМ оглашает риск, участники митинга оценивают его вероятность и последствия;
- ПМ записывает оценки, как только цель митинга достигнута, либо время истекло, митинг завершается;
- ПМ считает важность рисков как Вероятность*Последствия, сортирует список по убыванию Важности;
- ПМ обозначает риски, превысившие границу Важности в списке;
На выходе: список критичных рисков;
Пример:
Планирование рисков
Фактически, на этом этапе и происходит управление проектом. Для каждого риска, из списка критичных, необходимо придумать стратегию, которая наш проект от него обезопасит. Всего стратегий используется три:
Transfer. Переносим ответственность за последствия риска на третью сторону (заказчика, компанию партнера, страховую компанию и так далее). Применять эту стратегию есть смысл, если сами мы не можем повлиять на риск и есть на кого эту ответственность переложить.
Accept. Принимаем ответственность за последствия риска на себя, но ничего не делаем, оставляем все как есть. Применять этот подход есть смысл только когда с риском мы поделать ничего не можем, а делать трансфер на третью сторону неоправданно дорого.
Mitigate. Боремся с риском, принимая ответственность на него на себя. Для борьбы с риском хорошо иметь несколько планов. Основной, для того, чтобы риск подавить, и отходной, на случай если риск все-таки случился и влияет на проект:
- Основной план необходимо внедрять сразу, до того как риск случился. Он должен понижать либо Вероятность, либо Последствия риска. Тут нам поможет запись рисков в формате «причина-риск-эффект». Чтобы понизить Вероятность риска, нужно бороться с его причиной. Чтобы побороть Последствия, нужно защищать предмет его воздействия.
- Отходной  план внедряется в случае, если меры по борье с риском не принесли результатов, риск случился и стал проблемой.
На входе: список критичных рисков;
Процесс:
- ПМ собирает митинг с руководителями других проектов, сообщает о его цель, длительность и agenda;
- ПМ оглашает риск, участники митинга определяют стратегию работы с ним, основной план и запасной план (для Mitigate);
- ПМ записывает планы в риск лист, как только цель митинга достигнута, либо время истекло, митинг завершается;
- ПМ обновляет план проекта, добавляя основные планы по рискам;
На выходе: список критичных рисков со стратегией и планом на каждый риск, обновленный план проекта;
Пример:
Мониторинг и контроль
Это скорее процесс, чем этап. Его цель — поддерживать список рисков и план проекта в актуальном состоянии.
На входе: спланированный список рисков, план проекта, ежедневные отчеты команды;
Процесс:
- ПМ выполняет ревизию списка рисков, обновляет оценки, обновляет устаревшие планы;
- ПМ выявляет случившиеся риски, принимает решение о внедрении отходных планов, обновляет план проекта;
На выходе: обновленный список рисков, обновленный план проекта;
Пример:
Итог
Для проекта с командой в 15 человек, расходы на управление рисками составят 50–60 человеко-часов в месяц. При этом будет идентифицироваться около 50 новых рисков, из них в среднем 10 самых важных будет планироваться и подавляться. Положив, что критичный риск отбирает у проекта минимум 40 человеко-часов, получаем от 400 человеко-часов экономии ежемесячно.
Процесс, описанный в этой статье, можно и нужно улучшать. Можно усложнять его для сложных больших проектов, можно упростить и тратить на работу с рисками 2 часа в месяц. Так или иначе, гораздо дешевле работать с рисками как-то, чем не работать с ними вообще.