Процесс управления рисками

Общее представление

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

Шесть этапов процесса управления рисками MSF – это

· Выявление

· Анализ и приоритезация

· Планирование

· Мониторинг

· Корректирование

· Извлечение уроков.

Выявление рисков (risk identification) – это фаза, позволяющая членам проектной группы вынести на обсуждение всей команды факты наличия рисков. Выявление рисков является начальной стадией процесса управления ими. Оно должно быть

осуществлено как можно раньше, и к нему необходимо постоянно возвращаться на протяжении всего жизненного цикла проекта.

Рисунок 1. Процесс управления рисками MSF

Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритезация рисков (risk prioritization) позволяет проектной группе производить управление наиболее важными из них, выделяя для этого необходимые ресурсы.

Планирование рисков (risk planning) производится исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом.

Мониторинг рисков (risk tracking) производится для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график. Мониторинг рисков обеспечивает прозрачность процесса управления рисками проекта на различных уровнях в дополнение к стандартному процессу управления проектом, отслеживающему степень завершенности проектных задач. Отчетность о рисках (risk reporting) обеспечивает информирование проектной группы, спонсоров и других заинтересованных сторон о состоянии рисков проекта и планов по управлению ими.

Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change

control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки.

Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия.

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

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

 

Выявление рисков

Введение

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

 

Цели

Целью фазы выявления рисков является создание проектной группой списка имеющихся рисков проекта. Этот список должен быть всеобъемлющим (comprehensive), охватывающим все факторы, влияющие на проект.

 

Исходные данные

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

проектом возможности. Также могут оказаться полезными отраслевые схемы классификации рисков, такие как таксономия рисков SEI9, проектные чеклисты (checklists)10, сводные отчеты о предшествующих проектах и другие опубликованные источники и отраслевые руководства.

Рисунок 2. Выявление рисков

Шаги по выявлению рисков

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

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

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

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

 

Структурированный подход

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

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

Такая систематизация может быть получена на основании опыта схожих проектов, осуществленных ранее, или же на основании опытных знаний индустрии в целом. Формулировка рисков (risk statement formulation) является основной методикой, применяемой в рамках MSF для оценки проектов, построения приоритезаций рисков и планирования связанной с рисками деятельности.

 

Классификация рисков

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

Следующая таблица показывает высокоуровневую классификацию источников рисков проектов.

Люди

Заказчики (customers)

Конечные потребители (конечные пользователи, end users)

Спонсоры

Заинтересованные стороны

Персонал

Организация

Профессиональная квалификация

Политика

Мораль

Процессы

Цели и задачи

Принятие решений

Характеристики проекта

Бюджет, затраты, сроки

Требования (requirements)

Проектирование (design)

Реализация (building)

Тестирование (testing)

Технологии

Безопасность

Среда разработки и тестирования

Инструментарий

Внедрение

Сопровождение

Операционная среда

Доступность

Внешние условия

Законодательство

Индустриальные стандарты

Конкуренция

Экономические условия

Технология

Бизнес-условия

Существует множество классификаций общих рисков проектов по разработке программного обеспечения. Хорошо известны и часто цитируются Barry Boehm11, Caper Jones12, и SEI Software Risk Taxonomy13, описывающие источники таких рисков.

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

Исчерпывающий обзор таких рисков, затрагивающих проекты в области разработки программного обеспечения, был составлен Steve McConnel.14

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

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

Прочие источники информации о рисках проектов включают в себя базы данных рисков индустриальных проектов, такие как Software Engineering Information Repository (SEIR)17, и внутренние корпоративные базы знаний о рисках.

Формулировки рисков

Формулировка риска – это выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта (текущим положением дел) и потенциально возможным, еще не случившимся событием или ситуацией. Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать. Первая и вторая части формулировки связываются такими словами, как “поэтому” и “в результате”, – они описывают не жесткую, но возможную (с вероятностью меньше 100%) причинно-следственную связь. Схематически это показано на рис. 3.

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

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

анализ причинно-следственных связей должен быть отложен до фазы планирования. На

раннем этапе работы над проектом можно встретить огромное количество таких формулировок рисков, которые указывают на недостаточную информированность проектной группы. Это могут быть такие выражения как: “Мы еще не знаем об X, поэтому...”

Рисунок 3. Формулировки рисков

При формулировании риска проектная группа должна рассматривать как причину потенциально возможного нежелательного исхода, так и непосредственно сам этот исход. Формулировка риска включает в себя видимое положение вещей в проекте (условие) совместно с гипотетической ситуацией, которая может наступить (последствие). В процессе работы по детальному анализу рисков проектная группа должна находить схожести и естественные объединения формулировок тех рисков проекта, которые имеют общую первопричину. Это может быть достигнуто отслеживанием вглубь цепочек причинно-следственных связей, отталкиваясь от каждого из сформулированных условий рисков18. Также полезно отслеживать причинно-следственную связь в противоположном направлении для выявления возможных масштабных эффектов на уровне организации и внешней среды за рамками одного проекта. Это позволяет более полно представить суммарный урон или упущенные возможности, имеющие одно общее условие19.

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

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

Результаты

Как минимум, в результате процесса выявления рисков должны быть получены их четкие, однозначные и согласованные формулировки, представленные в виде списка рисков. Если риски формулируются как связки условие-последствие в соответствии с рекомендациями SEI20, NASA21 или ранних версий MSF22, 23, то результатом будет набор таких условных формулировок для всех выявленных рисков. Этот список рисков (представленный в табличной форме) служит исходной информацией для следующей фазы процесса управления рисками – анализа. Выявление рисков обычно предоставляет значительный объем дополнительной полезной информации, включая обнаружение первопричин рисков, затрагиваемые стороны и др.

Дисциплина управления рисками MSF рекомендует вести запись формулировок выявленных рисков, их первопричин и приносимого ими ущерба в табличной форме. Также полезно классифицировать эти риски по какой-либо существующей таксономии, так как это может помочь пополнить базу знаний предприятия о рисках. В список рисков может также вноситься информация, определяющая контекст риска. Это должно позволить как другим сотрудникам, так и заинтересованным лицам со стороны понять суть произведенной работы по выявлению рисков24, 25, 26. Описание контекста рисков может включать в себя

· условия;

· ограничения;

· обстоятельства;

· допущения;

· влияющие факторы;

· взаимозависимости рисков;

· связанные с рисками вопросы;

· владельцы подвергающейся риску собственности;

· факторы, вызывающие у проектной группы беспокойство.

Полученный список рисков (с указанием или без указания условий и первопричин рисков, приносимого ущерба и контекстной информации) будет превращен в главную таблицу рисков на следующем этапе процесса управления рисками. Вот пример такого списка:

 

Первопричина	Условие	Последствие	Приносимый ущерб
Нехватка кадров	Могут быть объединены роли разработчиков и тестировщиков	В программном продукте будет содержаться больше ошибок	Заказчик будет менее доволен результатом
Изменения в технологии	Разработчикам придется использовать новый язык программирования	Увеличится затрачиваемое на разработку время	Наш продукт будет представлен на рынке в более поздние сроки, что приведет к захвату части рынка

			конкурентами
Организация	Часть группы	Обмен	Задержки в сроках
работы	разработчиков	информацией	сдачи готового
	находится в	внутри группы	продукта и
	Лондоне, а часть – в	затрудняется	дополнительные
	Лос-Анжелесе		трудозатраты

 

⇐ Предыдущая12345678910Следующая ⇒

Поделиться: