Практические инструменты управления рисками проекта

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

Халиль Джебран

Тема управления рисками всегда была и остается самой «вкусной» в проектном менеджменте. Это объяснимо: каждый руководитель проекта хотел бы безопасно провести корабль проекта между мелями и рифами проектных рисков. Однако реакция на публикации на тему управления проектными рисками бывает двоякой. Прочитав одни статьи, проект-менеджеры восклицают: «Ну, это банально! Мы и так занимаемся этим каждый день (а толку мало)!». Прочитав другие (более обстоятельные) материалы, те же руководители проектов жалуются на сложность методичного подхода к риск-менеджменту и неприменимость его в небольших проектах.

Итак, задача этой статьи — дать руководителям проектов не только теоретический базис, но и практический инструментарий, применимый (оправданный и эффективный) как в комплексных, так и в относительно небольших проектах.

Если попробовать определить управление рисками проекта просто, то на 70% это предусмотрительность, на 20% — различного рода резервирование, и лишь на оставшиеся 10% приходится непосредственное реагирование на рисковые события. Таким образом, как и в других процессах управления проектом, успех управления рисками закладывается в начале проекта. А предусмотрительность руководителя проекта — прямое следствие его опыта. В случае если проект вверен недостаточно опытному проект-менеджеру, его необходимо «усилить» коллегой или внешним консультантом, уже набившим шишки в предметной области проекта. Это что касается управления рисками в рамках одного проекта. Пока все просто.

С точки зрения управления портфелем проектов компании ее руководители (и собственники) хотели бы, чтобы риски проектов соотносились с ожидаемыми выгодами, и здесь уже не обойтись без аналитических инструментов. Находиться «внутри» и «снаружи» проекта — не одно и то же; необходим способ оценить проектные риски (изнутри) и донести обобщенные оценки до руководства компании (наружу). Кроме того, мечта любого директора — чтобы руководители проектов снова и снова не наступали на одни и те же грабли. На передний план выходит задача накопления, систематизации и использования опыта, полученного в проектах.

Так что, как ни крути, но компетентному руководителю корпоративного проекта нужно что-то большее, чем просто предусмотрительность.

Из истории вопроса

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

История дисциплины управления рисками уходит корнями в конец XVII — начало XIX веков, когда английский галантерейщик Джон Грант опубликовал результаты предпринятого им исследования продолжительности жизни, английский астроном и математик Эдмунд Галлей развил идеи Гранта, а швейцарский математик Даниил Бернулли дополнил сделанные «коллегами» выводы. Все это серьезно продвинуло риск-менеджмент в области страхования и инвестиций, в то время как в вопросе методологии управления проектными рисками долгое время не было единого подхода.

Большой вклад в дисциплину проектного риск-менеджмента сделала команда специалистов, работавших над первой редакцией PMBoK’а (PMBoK — Project Management Body of Knowledge (англ.) — Свод знаний по управлению проектами), вышедшей в 1996 году. Тогда были выделены четыре процесса управления рисками:

• идентификация риска;
• оценка риска;
• разработка методов реагирования на риск;
• контроль реагирования на рисковые события.

С тех пор PMBoK обновлялся каждые четыре года, и к 2004 году список процессов был дополнен стартовым процессом «планированием управления рисками». Оценка риска была разбита на два процесса: качественный и количественный анализ риска.

Редакция 2004 года существенно продвинула методологию управления проектными рисками. Соответствующий раздел PMBoK’а был дополнен доступными методическими примерами и диаграммами, а также хорошим «арсеналом». Проект-менеджерам стали доступны такие инструменты, как план управления рисками, иерархическая структура рисков (ИСРс), матрица вероятности и последствий, мозговой штурм, метод Делфи, идентификация основной причины, SWOT-анализ, анализ допущений, диаграммы влияния и причинно-следственных связей, реестр рисков и другие. То, что раньше скромно именовалось «мерами реагирования на риск», отныне стало «стратегиями реагирования на риски», классификацию которых полезно знать «назубок»: уклонение, передача, снижение (для реагирования на угрозы); использование, совместное использование, усиление (для реагирования на благоприятные возможности); принятие (общая для угроз и возможностей стратегия), а также механизм реагирования на непредвиденные обстоятельства (план «Б»).

Рассматриваемые далее инструменты управления проектными рисками не претендует на полноту охвата методологии, которую дает руководство PMBoK. Оно, в самом деле, описывает много полезных инструментов, и главу об управлении рисками руководителям проектов следует изучить. Можно ведь воспользоваться принципом японцев: попробуйте все, оставьте то, что работает.

Далее в статье — инструменты, проверенные практикой в белорусских компаниях и прижившиеся в них (а значит, оставленные как «работающие»).

А где возьмешь?! или Откуда берутся риски в проектах

Идентификация рисков (в этой статье за основу берется понятие риска, данное в PMBoK редакции 2004 года: риск проекта — это неопределенное событие или условие, которое в случае возникновения имеет позитивное или негативное воздействие по меньшей мере на одну из целее проекта, например, сроки, стоимость, содержание или качество.) — процесс, игнорировать который с точки зрения управления рисками просто преступление! Проводится идентификация на ранних стадиях проекта, когда руководитель и команда проекта работают над проектным заказом (техническим заданием) и планом проекта. Руководитель проекта может идентифицировать риски самостоятельно (обязательно проконсультировавшись у «старших товарищей» и изучив документы и переписку по схожим предшествующим проектам). Однако если есть такая возможность, к идентификации рисков рекомендуется привлечь ядро команды проекта (ее основных участников). Групповую работу можно провести в режиме мозгового штурма или по методу Делфи. В первом случае руководитель проекта организует совещание, на котором участники проекта «набрасывают в кучу» все возможные риски проекта. Как правило, участники мозгового штурма делают основной акцент на событиях, которые могут оказать на проект только негативное влияние (чистые риски). Для выявления чистых рисков применяется метод диверсионного анализа, хорошо зарекомендовавший себя при тестировании систем безопасности. При этом команда проекта ставит себя на место «злоумышленников» (например, конкурентов, ревизоров и так далее).

Нельзя сказать, что метод Делфи имеет очень широкое распространение, но я сталкивался с его применением для выявления технологических рисков в проектах НИОКР инжиниринговой компании, а также для идентификации рисков в крупной телекоммуникационной компании (обе из Беларуси). Метод предполагает анонимный опрос участников проекта (или экспертов), с последующим ознакомлением всех участников опроса с мнениями других. За несколько итераций специалисты достигают консенсуса. Метод особенно полезен при явной неравнозначности опыта участников, когда авторитет отдельных экспертов «давит» на других.

На этапе идентификации рисков полезно вернуться к понятию окружения проекта (статья Виктора Степанова «Проектный кастинг. Распределяем роли». Журнал «Финансовый директор» № 01/2009). Мы выделяли людей и факторы, способствующие или мешающие достижению целей проекта. Это и есть основные источники рисков. А значит, необходимо подумать, какие риски исходят от заказчика или спонсора проекта, от команды проекта, поставщиков, лицензоров, научно-технического прогресса, экологии и так далее (см. Рис. 1).

Рисунок 1. Пример иерархической структуры рисков по источникам возникновения

Искать и находить чистые риски — захватывающее занятие, однако не нужно забывать и о возможностях, поэтому в какой-то момент имеет смысл переключить внимание участников мозгового штурма на «позитив». Для этого можно предложить коллегам ответить на вопрос: о каких неожиданно открывшихся возможностях (позитивных событиях) в проекте стоит немедленно сообщить руководству? На схеме (Рис. 1) серым цветом выделены три возможности.

Мозговой штурм может проводиться и в формате SWOT-анализа, который, как раз, и ориентирован на выявление как угроз и слабых мест, так и возможностей и сильных сторон.

Минимальным «выходом» идентификации рисков может быть список рисков проекта. «Продвинутые» руководители проектов составляют ИСРс (как на Рис. 1) или реестр рисков, в которых риски классифицированы по источникам их возникновения.

Частая ошибка, свойственная недостаточно опытным руководителям проектов, — выделение в качестве рисков нарушение общего срока проекта, выход за рамки бюджета и несоответствие результата требованиям. Строго говоря, эти события негативного характера являются не рисками, а следствиями «срабатывания» других рисков проекта. Антирисковые мероприятия по отношению к «риску» выхода за рамки бюджета будут носить слишком общий характер. Необходимо работать с корневыми (первопричинными) рисками.

Навскидку

Еще Даниил Бернулли в далеком 1738 году заметил, что в процессе принятия решения людям свойственно уделять больше внимания размеру последствий разных исходов, нежели их вероятности. В действительности рационально ориентироваться не на величину последствий (влияние) риска, а на влияние риска с поправкой на вероятность его наступления (метрику риска):

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

И сразу при упоминании вероятности приходят на ум законы больших чисел и статистика, после чего руки опускаются: как можно говорить о точной количественной оценке вероятности таких событий, как, например, «повышение курса валюты контракта на Х%» или «несоответствие техническим требованиям», да и какой в этом смысл? Мотивация применять методологию резко снижается, поскольку сложность количественной оценки вероятности рисковых событий может быть непропорциональна сложности проекта.

Но ведь помимо количественной оценки рисков есть и качественный их анализ. Для этого используются вербальные (словесные) шкалы (см. Табл. 1).

Таблица 1. Таблица качественной оценки рисков проекта

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

Таблица 2. Таблица преобразования качественных оценок рисков в баллы

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

Полезным инструментом верхнеуровневого управления проектными рисками (с точки зрения руководства компании) является КБРП — комплексный балл рисков проекта. Его мы получаем, сложив численные значения метрик десяти (методология компании может устанавливать иное количество рисков, учитываемое при расчете КБРП, однако оно должно быть единым для всех проектов) максимальных рисков проекта. Если компания практикует технологичный подход к управлению проектами и регулярно составляет реестр проектов, то в нем будет полезно иметь колонку с КБРП. Тогда руководитель компании (либо директор проектов или другое ответственное за проектную деятельность лицо) всегда будет иметь информацию, какие из актуальных проектов на текущий момент содержат в себе больше рисков. Конечно, чтобы система работала, руководители проектов должны регулярно «переоценивать» риски и, соответственно, выводить актуальное значение КБРП (напомню, здесь идет речь об инструментах, реально работающих в белорусских компаниях. Руководители проектов инжиниринговой компании, уже упоминавшейся выше, пересчитывают КБРП ежемесячно. Проекты этой компании длятся в среднем полгода).

Запас карман не тянет

О том, что представляют собой основные стратегии реагирования на угрозы (уклонение, передача, снижение и принятие) и на возможности (использование, совместное использование, усиление), и как они могут реализовываться в проектах, лучше прочитать в руководстве PMBoK (PMBoK 2004, глава 11.5.2). Некоторые варианты перечисленных стратегий отображены ниже:

Рисунок 2. Стратегии реагирования на риски

Для иллюстрации выбора различных стратегий (или, проще говоря, антирисковых мероприятий) приведена врезка (см. Табл. 5, 6). Здесь же хотелось бы немного «развернуть» понятие стратегии принятия риска.

Пассивное принятие, когда принято решение не предпринимать никаких превентивных мер, очень смахивает на русское «авось». Команде проекта в случае наступления рискового события остается действовать на свое усмотрение, спасая цели проекта.

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

Отношение к финансовым резервам все еще неоднозначное. Многие руководители компаний и подразделений не воспринимают эту строку в бюджете проекта как инструмент управления рисками, исходя из того, что созданный резерв обязательно будет потрачен. Такая политика ведет к тому, что руководители проектов «прячут» резервы внутрь статей бюджета. Это «раздувает» смету и не решает главную проблему — когда возникают обстоятельства, неучтенные на старте проекта, команда проекта не имеет «запасного парашюта».

Опасность необоснованных расходов по смете с резервами действительно существует, но от этой напасти есть лекарство. Существует практика создания двух резервов с различными режимами использования (см. Табл. 3). Такая практика снижает риск того, что в компании не хватит ресурсов на завершение проектов, когда в них начнут один за другим срабатывать риски (что является нормальным для проектной деятельности).

Таблица 3. Виды и режимы использования финансовых резервов в проекте

В противовес компаниям, где планируют расходы «копейка в копейку», в технологически зрелой компании на руководителя проекта, который планирует без резервов, посмотрят косо. При этом опытные руководители проектов резервируют не только деньги, но и время. И снова: нельзя «зашивать» временные резервы внутрь сроков выполнения задач. Для этого следует создавать лаги (промежутки, так называемые «ефрейторские зазоры») между работами. Это не расхолаживает команду проекта, но позволяет сманеврировать в критических ситуациях (а они обязательно будут).

Небольшой комментарий к стратегии передачи риска. Наиболее распространенными формами реализации данной стратегии являются страхование риска и привлечение компетентного подрядчика на выполнение фрагмента работ, с которыми связан риск. Так вот: во втором случае риск можно считать переданным только тогда, когда подрядчику передана вся полнота ответственности. Реализовать это на практике очень сложно, поскольку заказчик проекта хотел бы иметь дело с организацией (командой), «подпоясавшейся» на весь проект, и проблемы с подрядчиком его мало волнуют. В случае наступления риска, переданного подрядчику, избежать удара по целям проекта и репутации компании (исполнителя проекта) вряд ли удастся.

Планирование антирисковых мероприятий целесообразно проводить в режиме совещания, например, сразу после мозгового штурма по идентификации рисков. Очень полезно на этом совещании выделить ответственных за несколько типов антирисковых мероприятий. Эти люди должны «вылавливать из эфира» общего обсуждения ценные мысли и формировать свой список мероприятий. Тогда по итогам совещания появятся несколько «черновых» списков:

• что застраховать;
• на какие работы привлечь подрядчиков;
• что оговорить в контрактах с поставщиками;
• чем дополнить контракт с заказчиком (устав проекта или ТЗ в случае внутреннего проекта);
• какие будут созданы резервы (на какие цели, с каким механизмом использования);
• какие необходимо запланировать мероприятия (инструктажи, обучение, консультации и так далее).

Такие списки существенно облегчают последующую работу руководителя проекта по планированию антирисковых мероприятий.

Страна невыученных уроков

«Видеть легко, трудно предвидеть», — говорил Бенджамин Франклин. И если вы не наделены даром провидца, то в помощь вам — опыт других.

Главной мечтой руководителей (и одновременно главной проблемой компаний, чья деятельность связана с проектами) остается накопление и распространение внутри компании опыта, приобретенного в проектах. Проблема не в том, что люди ошибаются (не ошибается тот, кто ничего не делает), а в том, что они повторяют ошибки. Лучше всего это видит руководитель, который знает о проблемах в разных проектах компании (в том числе об ошибках, допущенных в прошлых проектах), и видит, что его люди снова и снова наступают на одни и те же грабли.

Для накопления опыта пока не придумано ничего лучше, чем написание отчета по закрытию проекта. Отчет этот называется по-разному, но наиболее «говорящее» название — «посмертный отчет», или PMR (PMR – от Post Mortal Report — посмертный отчет (англ.)). Руководители проекта часто ленятся писать его или отделываются формальной отпиской. Здесь хотелось бы вернуться к афоризму, вынесенному в начало статьи. Тот, кто потрудится «наклониться и поднять камень», вносит весомый вклад в скорость продвижения компании, в ее эффективность и технологичность.

PMR обязательно должен содержать раздел, метко названный «lessons learned» (Lessons learned — усвоенные уроки (англ.)). Какие уроки извлекла команда проекта из сложных ситуаций, с которыми она столкнулась в ходе его реализации?

Написать раздел «lessons learned» легче, если ответить на вопросы:

· Что было сделано правильно, а что нет?

· Какие ошибки были допущены?

· Что можно было сделать лучше?

· Что бы вы сделали иначе?

· Какие сюрпризы вы не предвидели?

· Пришлось ли тратить резерв на ошибки?

· Пришлось ли отходить на запасные позиции?

· Какие уроки можно почерпнуть на будущее?

Помимо «усвоенных уроков» PMR может содержать разделы:

• Название проекта (код реестра)
• Руководитель и команда проекта
• Заказчик (спонсор) проекта
• Первоначальные и фактические рамки проекта (Рамки проекта – общая продолжительность, стоимость (трудоемкость) и обобщенные требования к результату (объем поставки))
• Отклонения от рамок и причины отклонений
• Открывшиеся возможности
• Упущенные возможности

Практика показывает, что руководители проектов охотнее делятся опытом (читай — пишут PMR'ы), когда сами набивают шишки. Для привития и закрепления полезной привычки можно применять материальные стимулы: не считать проект формально закрытым (а значит, и не производить «финальный расчет» по проектным премиям и бонусам), пока не будет написан и «выложен» в общедоступное место (в проектную папку на сервере) «посмертный отчет».

Итак, допустим, все руководители проектов старательно пишут и выкладывают отчеты по закрытию проектов. Следующий закономерный вопрос — как организовать использование накопленного опыта. Здесь все работает так же, как и в случае с подготовкой отчетов: тот, кто хотя бы раз почувствовал полезность от их использования, не поленится не только прочесть PMR’ы по закрытым проектам, но и пообщаться с их участниками. Ну а для «новичков», еще не осознавших полезности знакомства с «чужими ошибками», можно предложить такой механизм контроля: в «шапке» плана проекта предусмотреть поле «PMR-отчеты, изученные перед составлением плана проекта».

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

Существует также практика составления списка типичных рисков проекта. Рационально составлять такие списки по вышеописанному методу Делфи. Для разных типов проектов (коммерческий, инвестиционный, разработческий и так далее) имеет смысл составить и постоянно дополнять разные списки рисков. Для удобства использования списков риски должны быть структурированы по источникам.

Чтобы снизить влияние субъективизма (исключить его вряд ли удастся) при оценке вероятности и влияния риска, рекомендуется типичным рискам присвоить соответствующие шкалы, упрощающие процесс оценки:

Таблица 4. Пример шкалы оценки влияния и вероятности для риска задержки оплаты со стороны заказчика (во внешнем проекте)

Если руководство компании не стремится к тому, чтобы проекты с серьезными проблемами неуклонно шли к своей гибели, а руководители проектов до последнего скрывали негативную информацию (пытаясь «разрулить» проблемы самостоятельно либо оттягивая неприятный момент неизбежного «вскрытия»), в компании должно культивироваться особое отношение к ошибкам как к ценному приобретенному опыту, а не как к личному поражению менеджеров. Для этого, в частности, руководители проектов должны видеть, что споткнувшегося коллегу ждет не увольнение, а поддержка в и без того сложной ситуации и взвешенный анализ приобретенного (дорогостоящего) опыта.

Итак, для эффективного управления проектными рисками в компании необходимо:

• создать регулярный механизм накопления и использования опыта, полученного в проектах;
• подкреплять менее опытных руководителей проектов (привлекать в проект экспертов, кураторов);
• создать в компании регулярный механизм обмена опытом между руководителями проектов (совещания, мини-семинары);
• регулярно оценивать и «мониторить» проектные риски, в том числе на уровне руководства компании (с помощью реестра проектов и КБРП);
• создать в компании атмосферу «поощрения» ошибок;
• развивать корпоративную методологию управления проектными рисками.

Таблица 5. Пример выбора различных стратегий реагирования на риски в проекте поставки оборудования

Таблица 6. Пример выбора различных стратегий реагирования на риски в проекте проведения бизнес-конференции

Фото: photogenica.ru