2 формулы для определения самых опасных рисков проекта – от Максима Якубовича

О том, как определить самые серьезные риски, которые возникают во время выполнения проектов, рассказывает наш эксперт Максим Якубович.

Риски проекта связаны с неопределенностью, имеющейся в проекте, а суть управления рисками сводится к снижению этой неопределенности. Первым шагом на этом пути является идентификация рисков, о чем я писал в предыдущей статье.

А теперь представьте, что команда проекта идентифицировала сотню рисков. Понятно, они имеют разные последствия и разную вероятность возникновения. Теперь нужно сопоставить риски между собой по важности и выбрать наиболее адекватную стратегию работы с каждым из них.

Например, риски с высоким рейтингом нужно постараться убрать из проекта, если, конечно, это экономически целесообразно (потому как стоимость уклонения от риска может оказаться дороже, чем последствия от его материализации). А для риска с низким рейтингом можно использовать стратегию принятия, т.к. уклоняться от него нецелесообразно.

Формула важности риска

Давайте сравним важность двух рисков для проекта «Внедрение CRM и автоматизация процессов управления отношениями с клиентами»:

1. Выбор программного продукта без понимания полного списка требований к нему приведет к большому количеству доработок продукта под процессы компании (а это означает «расползание» рамок проекта и рост объемов работ).

2. Изменение требований к программному продукту по ходу внедрения также приведет к «расползанию» рамок проекта и росту объемов работ.

Как видим, описанные риски имеют разные условия возникновения, но одинаковые последствия.

В теории управления проектами используется две характеристики рисков, с помощью которых можно оценить их важность: вероятность возникновения риска и его влияние на проект.

Зная эти параметры, можно высчитать важность риска по формуле:

Важность риска = Вероятность х Влияние.

Как просчитать вероятность возникновения риска

На мой взгляд, есть два наиболее распространенных подхода – экспертный метод и использование статистики. Попробуем использовать для расчета вероятности обоих рисков статистический подход.

Чтобы определить вероятность возникновения риска, связанного с выбором программного продукта без понимания полных требований к нему, я использую результаты «Четвертого глобального исследования управления портфелями и программами проектов» от PricewaterhouseCoopers за 2014 год.

В исследовании говорится, что лишь 72% из респондентов были согласны, что в их проекте использовался структурированный подход для определения бизнес-требований. Для меня это означает, что есть как минимум 28%-ная вероятность, что в нашем проекте заказчик не согласится тратить деньги на использование структурированного подхода к сбору бизнес-требований.

Для оцифровки вероятности составим таблицу, в которой будем использовать числовую оценку от 1 до 3.

Итак, для описанного выше риска сбора неполных требований к программному продукту вероятность в 28% лежит на интервале от 1% до 33%. Ей присваивается числовая оценка 1.

Для риска, связанного с  изменением требований к программному продукту по ходу проекта используем тот же опрос PricewaterhouseCoopers. В нем есть информация, что лишь в 43% проектов (или программ проектов) используются зрелые инструменты управления изменениями.

Я уверен, что в проектах, выполняемых на просторах СНГ, ситуация c управлением изменениями не лучше, чем получилась в результате исследования более чем 3 000 респондентов по всему миру. Поэтому считаю разумным ее принять. Она попадает в интервал от 34% до 67% с присвоением числовой оценки  2.

Формула влияния рисков на проект

Теперь мы должны ответить на вопрос: если риск из потенциального станет реальным и превратится в проблему, насколько сильно эта проблема повлияет на ход проекта?

В литературе по управлению проектами часто предлагают рассмотреть степень влияния риска на 4 аспекта: цели, срок, бюджет и качество. Для их описания можно использовать вот такую матрицу влияния.

Для расчета общего влияния риска на проект будем использовать формулу:

Влияние = (Влияние на срок + Влияние на бюджет + Влияние на содержание + Влияние на качество) / 4

Используя описанную выше матрицу, рассчитаем по этой формуле влияние на проект такого риска, как сбор неполных требований к программному продукту. Его последствия нам известны, это увеличение объемов работ.

Определим, на какую величину они могут возрасти:

• Мой личный опыт показывает, что в аналогичных проектах неполные требования привели к увеличению объемов работ более чем на 10% от запланированного.  Это означает, что оценка влияния на содержание проекта будет 3 балла.
• Если проект продолжается около 1 года, а содержание изменится более чем на 10%, то (если не увеличится объем ресурсов) можно спрогнозировать увеличение сроков примерно на тот же процент, что и содержание проекта. Поэтому для календарного графика поставим оценку в  2 балла (сроки для проекта длительностью в 1 год при увеличении содержания на 10% вырастут примерно на 1 месяц, а при большем объеме изменений – свыше 1 месяца).
• В связи с ростом объемов работ более чем на 10% бюджет проекта, очень вероятно, также изменится более чем на 10%. Присваиваем такому  аспекту, как перерасход  средств оценку в 3 балла
• На качество продуктов проекта рост объемов работ не должен повлиять. Аспекту качество проекта присваивается оценка в 0 баллов

В итоге, получилась таблица.

Рассчитаем влияние риска на проект по формуле:

Влияние = (3+2+3+0) / 4 = 2.

Так как последствие для второго риска (изменение требований к программному продукту по ходу проекта внедрения) такое же, как и для первого, то его влияние на проект будет оцениваться, исходя из тех же размышлений. В итоге, мы также получим оценку в 2 балла.

Сопоставление рисков

После расчетов вероятности и влияния используем формулу расчета важности риска, приведенную вначале (Важность риска = Вероятность х Влияние).

Вносим полученные результаты в таблицу.

В нашем примере получилось, что риск, связанный с изменением требований по ходу проекта, является более важным по сравнению с риском того, что требования, собранные к началу проекта, будут неполными.

Если такой же  алгоритм использовать для определения важности всех рисков проекта, мы получим рейтинг важности рисков.

Безусловно, вы будете правы, если скажете, что оценки очень субъективны и зависят от уровня экспертов. Если по вероятности материализации рисков мы еще можем найти статистику по некоторым событиям, то для определения влияния используется только экспертный метод. Но даже такая оценка, не лишенная субъективизма, представляется мне лучшей, чем ее отсутствие.

Итак, риски мы проранжировали. А что делать с ними дальше, я расскажу в следующей статье.