Как управлять рисками в проектах. Часть 4. Стратегия реагирования на риск
Все посты на эту тему:
Как управлять рисками в проектах. Часть 1. Начало
Как управлять рисками в проектах. Часть 2. Поиск рисков
Как управлять рисками в проектах. Часть 3. Ранжирование рисков
Как управлять рисками в проектах. Часть 4. Стратегия реагирования на риск
Как управлять рисками в проектах. Часть 5. Все происходит из-за денег, сынок
Одна купчиха зевнула, а к ней в рот залетела кукушка. Купец прибежал на зов своей супруги и,
моментально сообразив, в чем дело, поступил самым остроумным способом.
С тех пор он стал известен всему населению города, и его выбрали в сенат.
Даниил Хармс
Продолжаем наше захватывающее путешествие в увлекательный мир проектных рисков.
Мы уже знаем, что такое риск в управлении проектами, как и где его искать и как ранжировать проектные риски. Сегодня мы узнаем, что можно сделать с риском, который мы нашли.
Напомню еще раз, что риск - это негативное событие, которое может произойти и повлиять на наш проект.
Оказывается, существует всего четыре варианта реакции на такое событие:
Мы можем его принять.
Мы можем от него уклониться.
Мы можем его передать другому.
Мы можем снизить его влияние.
Давайте разберемся с каждым из этих вариантов.
Принятие риска означает, что мы как проектная команда осведомлены о негативном событии, и ясно понимаем его последствия. Но либо просто не знаем, что с ним делать, либо не хотим ничего с ним делать. Другими словами, принимая риск, мы никак не меняем ни план проекта, ни команду, ни любой другой важный «проектообразующий» параметр.
Давайте вспомним про наш любимый проект - подготовку к автомобильной поездке из Москвы в Красноярск. Предположим, мы собираемся ехать туда дождливой осенью. Мы ищем риски и находим такой: «Дорожные условия ухудшатся из-за дождя». Ну, что ж, ухудшатся - так ухудшатся. Мы никак не можем влиять на погоду, нам остается только принять этот риск, в нашем случае это разумная стратегия реагирования.
Какие же риски стоит принимать? Во-первых, те, которые вызваны действиями непреодолимой силы - мы ничего не можем с ними сделать. Во-вторых, те, у которых низкий ранг - мы ничего не хотим с ними делать. Вспомните матрицу рисков - низкий ранг означает, что это либо эти риски не сильно влияют на наш проект, либо возможность их возникновения мала:
В-третьих, мы должны принять все риски, о которых ничего не знаем. Помните, я спрашивал, что же делать с неизвестными рисками, которые мы не нашли даже после всех мозговых штурмов и прочими способами (конечно, не помните, я и не надеюсь)? Вот так и надо с ними поступать - принять.
Нужно понимать, что, принимая риск, мы сохраняем его в проекте. Все гадости, которые этому риску сопутствуют, по-прежнему висят над нами и готовы нас порадовать.
На самом деле, когда говорят о стратегии принятия риска, не имеют в виду стратегию «махнуть рукой на проблему» и «сложить лапки». Это не фатализм, это, скорее, такое осознанное решение ничего не делать. Принимая риск, необходимо увеличивать бюджет проекта на какую-то определенную величину, прикрывая таким образом если и не все риски, то хотя бы неизвестные. Иным словами, принимая риск, мы резервируем в бюджете проекта определенный запас средств для возможного покрытия последствий действия риска.
Не обязательно принимать риск, можно от него уклониться.
Уклонение от риска предполагает, что мы вообще перестроим работу так, чтобы исключить риск из нашего проекта. Как мы можем уклониться от риска «Дорожные условия ухудшатся из-за дождя»? Да очень просто, мы никуда не поедем. Или поедем, но не в Красноярск, а в Ташкент, там осенью с погодой получше. Можно ли считать это уклонением? Нет, это жульничество! Ведь мы изменили цели проекта! Теперь у нас уже совсем другой проект, с новыми целями, и новым планом. В жизни, конечно, бывает и такое - кардинально меняются цели проекта, меняется мнение клиентов, меняется запланированный результат.
Но если не менять цели, как уклоняться от риска? Один из способов - прояснить требования и, не затрагивая целей проекта, постараться сократить список задач, которые нужно сделать.
Пример. Мы внедряем в банке проект - создаем сеть платежных терминалов. Первоначальные планы - полноценный платежный терминал, в котором можно и счет мобильного телефона пополнить, и за квартиру заплатить, и взнос по кредиту сделать. Налицо серьезный риск для (как минимум) сроков проекта - надо подружить терминал, процессинговую систему и внутренние финансовые системы банка. Однако в ходе анализа выясняется, что основная цель - это разгрузка касс в офисах банка, и терминалы будут устанавливаться только в них. А значит на фиг телефоны и квартплату, оставляем только функцию погашения, и связываем терминал с банковскими системами без участия процессинга.
Еще пример из жизни. Был у меня проект родом из Латинской Америки - по разработке системы управления для игорного бизнеса. В процессе анализа стало понятно, что необходимо использовать некую систему, разработанную маленькой чешской компанией. Компания была такая мутная, что риск использования ее продукции был виден невооруженным взглядом. А вдруг мы на них понадеемся, а они растворятся в красивой дымке, окутывающей по утрам Карлов мост? Переговоры с компанией ситуацию не прояснили. Аналогов ее продукции мы не нашли. И было принято решение уклониться от риска работы с этой компанией и написать довольно большой кусок кода самим. Уклонение оказалось правильной стратегией - чешская компания действительно прожила недолго.
Итак, уклоняясь от риска, мы полностью исключаем его из нашего проекта, желательно - не затрагивая цели.
Что делать, если уклониться от риска нельзя? Можно попробовать передать его другому.
В отличие от стратегии принятия риска, в которой мы резервируем собственные средства для работы с его последствиями, в случае передачи риска мы используем не свои, а заемные средства. С передачей риска знакомы все, кто хоть раз оформлял страховку на автомобиль. Вообще, любой страховой продукт - это передача риска.
Как передается риск в проектной области? Скажем, риск изменения сроков проекта? Например, привлечением вендора по модели fixed price. Как только мы заключили с вендором контракт, все риски за проект должен нести он (ха-ха-ха). На самом деле, это красивый модельный пример. Вендором можно прикрыться, если дойдет до разборок на высшем уровне (генеральный директор РусГидро с этим утверждением не согласится), но с точки зрения рисков сдвига сроков и ухудшения качества, привлечение вендора, скорее, несет в себе дополнительные риски (генеральный директор РусГидро может это легко подтвердить).
В действительности же, передача риска отлично работает в сфере финансовых рисков, но плохо - в управлении проектами.
Что делать, если ни одна из трех описанных выше стратегий к риску не применима? Остается последний вариант - снизить влияние риска.
По большому счету, снижение влияния риска - это понижение его ранга. Посмотрите еще раз на матрицу рисков - ранг риска зависит от возможности его возникновения и от последствий его воздействия на проект. Уменьшая один из этих параметров, мы понижаем ранг риска.
Забавно, но статистика показывает, что, в первую очередь, управленцы набрасываются на последствия и начинают придумывать, как их уменьшить. Это и понятно - последствия можно потрогать, выразить в деньгах, товарах, синяках и шишках. С возможностью возникновения хуже, потому что за пределами моего рассказа ее называют вероятностью, а с вероятностью обращаться умеют только выпускники мехмата, и то не все.
Вернемся к нашему проекту про автомобильную поездку и рассмотрим риск «Можно проколоть колесо по дороге в Красноярск». Как нам снизить влияние этого риска? Во-первых, можно уменьшить возможные последствия - взять еще одно колесо, запасное. Тогда на трассе мы его поменяем, и, хотя риск воздействует на проект (мы же потратили 15 минут и испачкали руки), но влияние это незначительно. Во-вторых, можно снизить возможность возникновения - выбирать дорогу с лучшим покрытием (при наличии альтернативы).
Пример из жизни. В одной компании решили внедрить программу для составления планов проектов. Жадное руководство слышало, что у популярных платных программ есть бесплатные аналоги. Возник риск, что проектные менеджеры получат инструмент, которым пользоваться не смогут. Тогда было проведено публичное тестирование возможных альтернативных вариантов и результаты показаны руководству. Руководство осознало, что бесплатные аналоги не выполняют ряд функций, необходимых для работы, и закупило платный вариант.
Итак, для каждого найденного в проекте риска нужно выбрать одну из стратегий реагирования - принятие, уклонение, передачу (перенос) или снижение влияния.
Вы-то, наверное, думаете, что скоро конец? А до конца еще далеко. Как сказал один великий поэт,
The woods are lovely, dark, and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.
(продолжение следует)