Webinar presentation by Peter Gazaryan http://www.exigenservices.ru/webinars/risk-management

1. Управление проектными
рисками
Петр Газарян

2. Содержание тренинга
• Что такое риск
• Предмет управления рисками
• Идентификация и оценка рисков
• Стратегии управления рисками
• Процесс управления рисками

3. Что такое риск?
• Что такое риск?
• Почему и когда мы рискуем?
• Почему мы не рискуем?
• Почему мы пренебрегаем риском?

4. Практика
• Вы считаете ваш проект рискованным?
• Вы управляете рисками?

5. Что такое риск?
Риск – это событие, которое может произойти в ходе
проекта, и таким образом повлиять на исход проекта.
Риск связан с неопределенностью.
Риск имеет вероятность.

6. Предмет управления рисками

7. Управление рисками
Risk
Management
Risk
Assessment
Identification Analysis Prioritization
Risk Control
RM Planning Risk
Resolution
Risk
Monitoring

8. Идентификация рисков – примеры из Project Plans
• Wrong stored procedures, i.e. some procedure works incorrectly.
• Send bug report and wait for answer
• Requirements are defined vaguely and as clarified they become inconsistent (or contradictory)
• Provide to the customer our understanding of requirements wherever they seem to be unclear. Provide
interim versions of the application for customer evaluation
• Customer response to project related inquiries is too slow
• Ask customer beforehand to have enough time to get an answer
• The overall project estimates are wrong
• Review estimates on a regular basis and take corrective actions (find “shortcuts”, change priorities, add
resources, reduce functionality)
• Split the project in short iterations and update the estimates (as well as the requirements) before each
iteration
• The team will not be able to support the existing Oracle database due to the lack of knowledge.
• The team velocity can be low than expected.
• Increase the team size. Allocate 6 developers instead of 4 required and 3 testers instead of 2 required.
• The total effort required for open tasks is tool little to workload the entire team
• Probability - 5%, Impact - Immeasurable
• Let the team do some research for future projects. Or let them study new techs.

9. Идентификация рисков
• Как должен быть сформулирован риск:
o Понятная проблема
o Понятное влияние на проект
o Понятные способы решения проблемы
• В нашем случае практически всегда риски негативно влияют
на …
• Почему про некоторые риски забывают:
• Не хватает опыта или данных для идентификации
проблемы
• Невозможно или сложно измерить влияние риска на
проект
• Не ясны пути решения проблемы

10. Типичные источники рисков
• Требования
• Технологии и средства разработки
• Программный код и другие проектные артефакты
• Процесс разработки
• Окружение
• Человеческий фактор

11. Чеклист по управлению рисками I
• Регулярно пересматривайте матрицу рисков
• Привлекайте членов команды для анализа и оценки
рисков
• События происходят не так, как вы задумали. Надежда
на это – плохой план.
• Что если из проекта уйдет кто-то из членов команды?
• Что если ключевой дедлайн будет перемещен на более
раннее время?
• Анализируйте критический путь проекта.

12. Чеклист для поиска рисков II
• Какие аспекты проекта новы для вашей команды?
• Было ли у вас достаточно времени на
планирование?
• Есть ли риск что результаты проекта не будут
приняты клиентом?
• Есть ли зависимости от других команд, организаций,
сторонних продуктов?
• Возможно ли что цели проекта изменятся?
• У вас нет замены для ключевой фигуры/части
проекта.
• Интеграция подсистем, подпроектов – это источник
рисков.
• Вы четко понимаете цель проекта?

13. Оценка риска
• Выбрать метрику и пороговое значение
• Спрогнозировать ее значения в ходе проекта
• Определить размер потерь для пессимистичного варианта
(Risk Impact - RI)
• Рассчитать Risk Probability (RP) как вероятность перехода
через пороговое значение
• Расcчитать Risk Exposure как произведение Risk Impact и Risk
Probability

14. Метрики рисков
• Риск – трудности с использованием сторонней компоненты, что
приведет к высоким трудозатратам, соизмеримым на
самостоятельную разработку функциональности компоненты. (10
ч-дней)
• Метрика: средние трудозатраты на интеграцию компоненты
• Оптимистичный вариант: 1 ч.-день
• Реалистичный вариант: 4 ч.-дней
• Пессимистичный вариант: 14 ч.-дней (если через 4 дня поймем,
что надо писать самим)
• Transition Threshold: 4 ч.-дня
• Потери в пессимистичном случае: 10 ч.-дней
• Risk Probability: Средняя - 30%
• Risk Exposure: 3 ч-дня

15. Какие метрики можно подобрать?
• Риск – болезнь членов команды
• Риск – много ошибок

16. Метрики из упражнения 1
Текущий процент заболевших в компании
Отношение времени на bug-fixing ко времени
реализации функциональности

17. Как оценить вероятность?
Хороший подход – на основе вербальных оценок, связанных с
конкретными числами.
• Критическая 95% – 80%
• Максимальная 80% – 60%
• Высокая 60% – 40%
• Средняя 40% – 30%
• Малая 30% – 20%
• Минимальная 20% – 10%
Или
• Очень высокая (Very high) 80%
• Высокая (High) 60%
• Средняя (Medium) 40%
• Низкая (Low) 20%

18. Каким рискам нужно уделить больше внимания?
Приоритизация должда базироваться на common sense
Приоритизация по принципу Impact - Probability:
• High - High
• High – Low
• Low - High
• Low – Low
Приоритизация по Risk Exposure:
• Risk Exposure = Impact * Probability

19. Что дальше?
• Mitigate – смягчать
A.Совершать предварительные действия до материализации риска для снижения размера
возможных потерь
B.Планировать действия по борьбе с последствиями в случае материализации риска для
снижения размера фактических потерь
• Accept – принять
• Счесть допустимым и не закладывать резервов в бюджет
• Avoid – избегать
• тем или иным способом избавиться от источников риска
• Contain – включать в резерв
• Резервировать средства в бюджете в размере ожидаемых потерь в случае материализации
риска
• Transfer –
• Резервировать средства в бюджете в размере ожидаемых потерь в случае материализации
риска

20. Возможности
• Exploit
• Убрать неопределенность, так чтобы событие точно
произошло. Обратное к Avoid.
• Share
• Постараться выжать максимум из возможности для всех
вовлеченных сторон.
• Enhance
• Opposite to mitigate. Do all possible actions
• Accept
• Принять. Случится – хорошо. Не случиться – ничего
страшного.

21. Как выбрать стратегию?
Стоимость стратегии:
V = VA + RP * (VB + VC) = VA + RP * VB + RE
здесь:
VA – стоимость превентивных мер
VB – стоимость мер по борьбе с последствиями
VC – стоимость понесенных потерь
RP – вероятность риска (Risk Probability)
RE – средние ожидаемые потери (Risk Exposure)
Для стратегии Contain: V = Risk Exposure

22. Пример рассчета стратегии
• Риск – трудности с использованием сторонней компоненты, что
приведет к высоким трудозатратам, соизмеримым на
самостоятельную разработку функциональности компоненты. (10
ч-дней)
• Стратегия Mitigate – создание прототипа. 2 ч-дня. Тем самым
мы перейдем от пессимистичного варианта к оптимистичному и
сэкономим 3 дня.
• VA + RP * (VB + VC) = 2+0,3*(10+1) = 5,3 ч-дней.
• Стратегия Avoid – сразу начать писать самим. В этом случае
риск пропадает (VB и VC=0).
• VA + RP * (VB + VC) = 10 ч-дней.

23. Risk Assessment Form
• ID – уникальный идентификатор риска
• Date – дата выявления риска
• Description – описание риска
• Affected milestone
• Probability – вероятность наступления негативных последствий
• Impact – дополнительный effort, необходимый для преодоления негативных
последствий
• Exposure – среднеожидаемые потери
• Mitigation plan – стратегия смягчения риска и потерь
• Responsible – лицо, ответственное за выполнение Mitigation plan
• Close date – дата успешного завершения плана

24. Управление рисками по ходу проекта
• Регулярный сбор метрик
• Регулярный анализ ситуации и корректировка
параметров рисков
• Реализация задач Mitigation A согласно основному
плану проекта
• Включение задач Mitigation B в план, как только
«сработал» Transition Indicator
• Регулярная идентификация новых рисков

25. Вопросы