Управление рисками - Инструменты управления рисками проекта

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

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

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

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

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

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

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

Для выявления чистых рисков применяется метод диверсионного анализа, хорошо зарекомендовавший себя при тестировании систем безопасности. При этом команда проекта ставит себя на место "злоумышленников" (например, конкурентов, ревизоров и так далее).

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

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

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

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

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

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

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

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

Управление риск финансовый

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

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

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

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

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

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

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

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

Режимы использования финансовых резервов в проекте

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

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

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

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

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

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

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

Для накопления опыта пока не придумано ничего лучше, чем написание отчета по закрытию проекта. Отчет этот называется по-разному, но наиболее "говорящее" название - "посмертный отчет", или PMR. Руководители проекта часто ленятся писать его, или отделываются формальной отпиской. Здесь хотелось бы вернуться к афоризму, вынесенному в начало статьи. Тот, кто потрудится "наклониться и поднять камень", вносит весомый вклад в скорость продвижения компании, в ее эффективность и технологичность.

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

- Что было сделано правильно, а что нет - Какие ошибки были допущены? - Что можно было сделать лучше? - Что бы вы сделали иначе? - Какие сюрпризы вы не предвидели? - Пришлось ли тратить резерв на ошибки? - Пришлось ли отходить на запасные позиции? - Какие уроки можно почерпнуть на будущее?

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

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

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

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

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

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

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

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

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

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

Управление рисками - Инструменты управления рисками проекта

Похожие статьи