Как управлять рисками в проектах. Часть 3. Ранжирование рисков
Все посты на эту тему:
Как управлять рисками в проектах. Часть 1. Начало
Как управлять рисками в проектах. Часть 2. Поиск рисков
Как управлять рисками в проектах. Часть 3. Ранжирование рисков
Как управлять рисками в проектах. Часть 4. Стратегия реагирования на риск
Как управлять рисками в проектах. Часть 5. Все происходит из-за денег, сынок
Продолжаем наш сериал про управление рисками в проектах (я предупреждал – это оооочень долгая история).
Мы уже знаем, что такое риск в управлении проектами. Мы помним, что все проектные риски влияют на основные параметры – качество, стоимость и сроки проекта. И мы не забыли, что искать риски нужно в реестре источников, а также – в плане проекта. Теперь разберемся, как это делать.
Предположим, вы управляете нашим любимым проектом по подготовке к автомобильному путешествию всей семьей из Москвы в Красноярск. Вы – менеджер, управлять рисками – часть вашей работы. Вы составили план-график проекта, выписали из него все задачи и понимаете, как они влияют на сроки, стоимость и качество. Отлично. Затем вы прошерстили все потенциальные источники...
Лирическое отступление. Может показаться, что для определенной категории проектов какие-то риски нехарактерны в принципе. Например, для проектов разработки софта, природные явления, вроде бы, малоинтересны. Я тоже так думал, пока в 2005 году наша команда, ключевые разработчики которой жили в Штатах, не столкнулась с последствиями урагана Катрина. Догадайтесь, в каком городе жили эти разработчики. Правильно, в Новом Орлеане. Поэтому в этом году наша команда последствия урагана Сэнди даже не заметила, не считая пары дней простоя. Люди хорошо учатся на своих ошибках.
Ну так вот, проверили вы источники, обратились к своему опыту, вспомнили о чужом, и больше идей у вас нет. Но внутреннее чутье не велит останавливаться – вы явно что-то забыли. И тут вас осеняет: «Женааааа!», – кричите вы, откидываясь на диванную подушку. «Иди сюда, разговор есть!»
И правильно – когда все личные резервы поиска рисков исчерпаны, пора привлекать вашу проектную команду. Собираетесь вы с проектной командой и устраиваете мозговой штурм – просите ваших коллег по проекту назвать риски, которые они видят. И это работает. Потому что у каждого есть свои тревоги по поводу успешности проекта. Гарантированно назовут такие, о которых вы забыли!
Проектная команда опрошена. Жена подсказала пару интересных рисков, связанных с особенностью пищеварения кошки (и вы уже купили специальный наполнитель для дорожного лотка), напомнила о непоседливости ребенка (и вы уже скачали на свой айпад десяток мультиков). Вдруг еще что-то забыли? Пора позвонить тестю и лучшему другу, один из них бывший дальнобойщик, а второй каждый год на машине возит семью в Анапу. Оба – эксперты в вопросе организации дальних поездок, хотя в вашу проектную команду и не входят. Эксперты беспристрастны, это люди со стороны, они не так, как команда, вовлечены в проект и не сильно заинтересованы в его провале или успехе. В реальном проектном мире экспертами могут выступать люди, которым вы доверяете или, реже, специально приглашенные специалисты.
Мозговой штурм провели, экспертов опросили. Что еще? Да хватит, уверяю вас. Тут не так важно вспомнить все сразу, сколько начать анализ рисков и делать это регулярно. Оптимальная частота – раз в неделю. Это означает, что каждую неделю надо проводить мозговой штурм с командой, общаться с экспертами (для этого они должны быть в курсе хода проекта), просматривать план и другие документальные источники.
На самом деле наука управления рисками предложит вам еще с десяток методов поиска. Но, поверьте, если вы хорошо с ними знакомы и используете, вы вряд ли дочитали до этого места. ))
Итак, еще раз. Чтобы найти риски, нужно регулярно, не реже раза в неделю, проводить (в порядке значимости процедуры):
Поиск рисков командой проекта.Поиск новых рисков в плане проекта.Поиск в реестре источников рисков.Опрос экспертов.
Лирическое отступление. Мозговой штурм – самый эффективный способ не только потому, что помогает выявить риски в проекте. Он хорош, прежде всего тем, что дает возможность команде встретиться по умному поводу и свободно общаться. Как ни странно, это сплачивает гораздо лучше, чем пиво в пятницу (даже если все спорят и кричат). Мне вспоминается, как я работал в крупной компании, и один из менеджеров собирал нас всех на кухне, чтобы рассказать про то, как он в молодости покупал творог на базаре, но не купил его, а зато напился. Всегда была одна и та же дурацкая история, но обраставшая все новыми и новыми деталями. Два десятка человек мучались, слушая этот бред. Дело было давно, но чувство раздражения по поводу бездарно потраченного времени у меня осталось до сих пор.
Кстати, а как поступать с рисками, которые мы так и не выявили? И жену спросили, и всех родственников помучали, и знакомым позвонили, и план проверили, и все-все, вроде, учли, но осталось же что-то, о чем забыли?
Как бы вы поступили с рисками, которые есть, но вы их не знаете? (пишите в комментах)
Давайте теперь вспомним, что еще в первой части моего рассказа мы хотели оценить степень воздействия риска на проект. Для каждого найденного риска необходимо ответить на два вопроса:
«Насколько возможно возникновение этого риска?»
и
«Сильно ли риск повлияет на проект?»
Ну вот что значит «насколько возможно»? Внутренняя шкала для ранжирования вида неопределенности у каждого человека своя. Но зависит она, в основном, от его видения проекта. Предположим, мы идентифицировали два риска: «Автомобиль сломается по дороге» и «Мы заплатим штраф гаишнику за превышение скорости». Как рассматривал бы возможность материализации этих рисков молодой водитель на новом джипе? Про первый риск он сказал бы: «Вряд ли это произойдет! У меня новая отличная машина, только что прошла полное обслуживание, я в ней уверен». Про второй он сказал бы: «Да, это очень возможно! Дорога незнакомая, я люблю быструю езду. Наверняка попадусь!» А как оценил бы эти риски человек предпенсионного возраста на стареньком автомобиле отечественного производства? На первый вопрос он ответил бы: «Очень возможно, машина старая, бывает, подводит. А уж на таком расстоянии...» А про второй сказал бы: «Вряд ли, я езжу медленно, супругу укачивает от быстрой езды».
Так и в реальных проектах – возможность проявления риска сильно зависит от внутренней организации проекта. Именно поэтому сложно придумать универсальный (и понятный) алгоритм для качественного оценивания возможности возникновения риска. Но существует простой способ: а давайте разделим все риски по возможности возникновения на 4 группы:
A. Незначительная возможность возникновения.B. Низкая возможность возникновения.C. Средняя возможность возникновения.D. Высокая возможность возникновения.
(Я специально избегаю терминов из теории вероятностей, ну ее, не в ней дело... пока, по крайней мере.)
Ну а дальше вы просто смотрите внимательно на каждый риск и приписываете ему возможность возникновения по этой шкале. Почему градаций четыре, а не сто четыре? Да пожалуйста, если ваш инструментарий позволяет ранжировать возможность возникновения риска с такой точностью, вы молодец. Почему градаций четыре, а не три? Тоже понятно – с тремя ранжирование превратится в фарс, вы будете всем рискам приписывать среднюю возможность возникновения, и управлять таким набором в дальнейшем не получится. Так что больше четырех можно, меньше – нет.
Разбираемся со вторым вопросом: «Сильно ли риск повлияет на проект?» Логика абсолютно такая же: что русскому хорошо, то немцу – смерть. На один проект риск повлияет очень сильно, на другой – очень слабо. В нашем модельном примере про автопутешествие, риск поломки какого-то узла на джипе может оказаться фатальным для машины, а владелец отечественного автомобиля прикрутит эту хреновину проволокой и еще пятьсот километров проедет.
По аналогии, воздействие риска на проект (точнее последствия этого воздействия) будем тоже описывать четырьмя состояниями, например, так:
A. Незначительные последствия.B. Средние последствия.C. Значимые последствия.D. Критические последствия.
С этими параметрами поступаем так же, как с предыдущими: приписываем каждому риску одно из четырех значений.
Там четыре параметра, тут четыре параметра – пора их связать и построить таблицу, в которой по вертикали будет один параметр, а по горизонтали – другой:
Эта таблица называется матрицей рисков, любой менеджер проектов ее может представить с закрытыми глазами.
Она помогает нам ранжировать риски в проекте. Вот смотрите, каждой возможности возникновения соответствует своя степень воздействия на проект. Например, пара «Незначительная возможность возникновения» – «Незначительные последствия». Нужно ли нам беспокоиться о риске с такими параметрами? Нет, пока не стоит. Это какое-то почти невозможное событие, да еще и почти на нас не влияющее. Назовем это «низким риском». А если риск описывается парой «Средняя возможность возникновения» – «Средние последствия»? Тут уже надо беспокоиться и думать, что делать с этим риском. Такие риски назовем «средними». И так далее – выделим еще, например, «высокие риски» и «критические риски».
А можно ли было нарисовать ее иначе? Например, поставить ячейке «Средняя возможность возникновения» –«Средние последствия» значение "низкий риск"? Конечно. Все зависит от проекта, только вы определяете, как вам ранжировать риски.
Интуитивно понятно, что в красную зону этой матрицы попали риски, с которыми надо что-то делать. А в зеленую – пока можно подождать. Вообще же, ранжирование рисков в проекте нужно для того, чтобы мы могли определить для каждого ранга свою стратегию управления.
Но об этом в следующий раз.
(продолжение следует)