21 ноября
«Создать успешное агентство — как выиграть в казино», сооснователь WakeApp Эдуард Лебедев
8 | 9 | 10 | 6 |
О том, как определить самые серьезные риски, которые возникают во время выполнения проектов, рассказывает наш эксперт Максим Якубович.
Риски проекта связаны с неопределенностью, имеющейся в проекте, а суть управления рисками сводится к снижению этой неопределенности. Первым шагом на этом пути является идентификация рисков, о чем я писал в предыдущей статье.
А теперь представьте, что команда проекта идентифицировала сотню рисков. Понятно, они имеют разные последствия и разную вероятность возникновения. Теперь нужно сопоставить риски между собой по важности и выбрать наиболее адекватную стратегию работы с каждым из них.
Например, риски с высоким рейтингом нужно постараться убрать из проекта, если, конечно, это экономически целесообразно (потому как стоимость уклонения от риска может оказаться дороже, чем последствия от его материализации). А для риска с низким рейтингом можно использовать стратегию принятия, т.к. уклоняться от него нецелесообразно.
Давайте сравним важность двух рисков для проекта «Внедрение CRM и автоматизация процессов управления отношениями с клиентами»:
1. Выбор программного продукта без понимания полного списка требований к нему приведет к большому количеству доработок продукта под процессы компании (а это означает «расползание» рамок проекта и рост объемов работ).
2. Изменение требований к программному продукту по ходу внедрения также приведет к «расползанию» рамок проекта и росту объемов работ.
Как видим, описанные риски имеют разные условия возникновения, но одинаковые последствия.
В теории управления проектами используется две характеристики рисков, с помощью которых можно оценить их важность: вероятность возникновения риска и его влияние на проект.
Зная эти параметры, можно высчитать важность риска по формуле:
Важность риска = Вероятность х Влияние.
На мой взгляд, есть два наиболее распространенных подхода – экспертный метод и использование статистики. Попробуем использовать для расчета вероятности обоих рисков статистический подход.
Чтобы определить вероятность возникновения риска, связанного с выбором программного продукта без понимания полных требований к нему, я использую результаты «Четвертого глобального исследования управления портфелями и программами проектов» от PricewaterhouseCoopers за 2014 год.
В исследовании говорится, что лишь 72% из респондентов были согласны, что в их проекте использовался структурированный подход для определения бизнес-требований. Для меня это означает, что есть как минимум 28%-ная вероятность, что в нашем проекте заказчик не согласится тратить деньги на использование структурированного подхода к сбору бизнес-требований.
Для оцифровки вероятности составим таблицу, в которой будем использовать числовую оценку от 1 до 3.
Итак, для описанного выше риска сбора неполных требований к программному продукту вероятность в 28% лежит на интервале от 1% до 33%. Ей присваивается числовая оценка 1.
Для риска, связанного с изменением требований к программному продукту по ходу проекта используем тот же опрос PricewaterhouseCoopers. В нем есть информация, что лишь в 43% проектов (или программ проектов) используются зрелые инструменты управления изменениями.
Я уверен, что в проектах, выполняемых на просторах СНГ, ситуация c управлением изменениями не лучше, чем получилась в результате исследования более чем 3 000 респондентов по всему миру. Поэтому считаю разумным ее принять. Она попадает в интервал от 34% до 67% с присвоением числовой оценки 2.
Теперь мы должны ответить на вопрос: если риск из потенциального станет реальным и превратится в проблему, насколько сильно эта проблема повлияет на ход проекта?
В литературе по управлению проектами часто предлагают рассмотреть степень влияния риска на 4 аспекта: цели, срок, бюджет и качество. Для их описания можно использовать вот такую матрицу влияния.
Для расчета общего влияния риска на проект будем использовать формулу:
Влияние = (Влияние на срок + Влияние на бюджет + Влияние на содержание + Влияние на качество) / 4
Используя описанную выше матрицу, рассчитаем по этой формуле влияние на проект такого риска, как сбор неполных требований к программному продукту. Его последствия нам известны, это увеличение объемов работ.
Определим, на какую величину они могут возрасти:
В итоге, получилась таблица.
Рассчитаем влияние риска на проект по формуле:
Влияние = (3+2+3+0) / 4 = 2.
Так как последствие для второго риска (изменение требований к программному продукту по ходу проекта внедрения) такое же, как и для первого, то его влияние на проект будет оцениваться, исходя из тех же размышлений. В итоге, мы также получим оценку в 2 балла.
После расчетов вероятности и влияния используем формулу расчета важности риска, приведенную вначале (Важность риска = Вероятность х Влияние).
Вносим полученные результаты в таблицу.
В нашем примере получилось, что риск, связанный с изменением требований по ходу проекта, является более важным по сравнению с риском того, что требования, собранные к началу проекта, будут неполными.
Если такой же алгоритм использовать для определения важности всех рисков проекта, мы получим рейтинг важности рисков.
Безусловно, вы будете правы, если скажете, что оценки очень субъективны и зависят от уровня экспертов. Если по вероятности материализации рисков мы еще можем найти статистику по некоторым событиям, то для определения влияния используется только экспертный метод. Но даже такая оценка, не лишенная субъективизма, представляется мне лучшей, чем ее отсутствие.
Итак, риски мы проранжировали. А что делать с ними дальше, я расскажу в следующей статье.
21 ноября
«Создать успешное агентство — как выиграть в казино», сооснователь WakeApp Эдуард Лебедев
19 ноября
Особое признание: Betera с двумя наградами престижной премии ADMA
19 ноября
Республиканский DemoDay – победители «Стартап-марафона» определятся в ближайшее время
19 ноября
3Х-кратный рост мясоперерабатывающего предприятия благодаря внедрению «1С:ERP Управление предприятием 2» компанией Академ и К
19 ноября
Бесплатные БелВЭБ-Кассы от Банка БелВЭБ!
18 ноября
Специальная партия SERES | AITO M5 уже в Минске: ваш рациональный выбор здесь и сейчас!
18 ноября
Международный форум ЭДО в Москве 2024: Взгляд на будущее электронного документооборота
18 ноября
Вторая жизнь рекламных баннеров: компания МТС презентовала уникальный мерч