Планирование управления рисками
advertisement
Microsoft Solutions Framework Дисциплина управления рисками MSF вер. 1.1 Содержание АННОТАЦИЯ ...................................................................................................................................................... 2 ВВЕДЕНИЕ .......................................................................................................................................................... 3 ОСНОВНЫЕ СВЕДЕНИЯ О РИСКАХ .......................................................................................................... 4 БАЗОВЫЕ ПРИНЦИПЫ ................................................................................................................................... 4 КЛЮЧЕВЫЕ КОНЦЕПЦИИ ........................................................................................................................... 6 ПЛАНИРОВАНИЕ УПРАВЛЕНИЯ РИСКАМИ .......................................................................................... 9 ПРОЦЕСС УПРАВЛЕНИЯ РИСКАМИ ....................................................................................................... 10 ВЫЯВЛЕНИЕ РИСКОВ .................................................................................................................................. 12 АНАЛИЗ И ПРИОРИТЕЗАЦИЯ РИСКОВ .................................................................................................. 19 ПЛАНИРОВАНИЕ РИСКОВ ......................................................................................................................... 28 МОНИТОРИНГ РИСКОВ............................................................................................................................... 33 КОРРЕКТИРОВАНИЕ СИТУАЦИИ ............................................................................................................ 36 ИЗВЛЕЧЕНИЕ УРОКОВ ИЗ РИСКОВ ........................................................................................................ 37 УПРАВЛЕНИЕ РИСКАМИ КАК СОСТАВНАЯ ЧАСТЬ ЖИЗНЕННОГО ЦИКЛА ПРОЕКТА...... 42 УПРАВЛЕНИЕ РИСКАМИ НА ПРЕДПРИЯТИИ ..................................................................................... 43 УПРАВЛЕНИЕ ПОРТФЕЛЕМ ПРОЕКТОВ ............................................................................................... 44 ЗАКЛЮЧЕНИЕ ................................................................................................................................................. 45 Microsoft Solutions Framework ”Белая книга” (white paper) Опубликовано: июнь 2002г. Для получения дальнейшей информации по MSF, см. http://www.microsoft.com/msf Составители Allison Robin, директор, Microsoft Solutions Framework David Preedy, менеджер программы, Microsoft Solutions Framework Derick Campbell, менеджер продукта, Microsoft Solutions Framework Enzo Paschino, менеджер программы, Microsoft Solutions Framework Laura Hargrave, технический редактор, Microsoft Frameworks Marijke Born, выпускающий менеджер, Microsoft Frameworks Nancy Huber, технический редактор, Microsoft Frameworks Paul Haynes, менеджер программы, Microsoft Solutions Framework Pervez Kazmi, менеджер программы, Microsoft Solutions Framework ~1~ Rob Oikawa, менеджер программы, Microsoft Solutions Framework Scott Getchell, менеджер программы, Microsoft Solutions Framework Рецензенты Brian Carter, консультант, MCS National Practices Brian Willson, консультант по стратегиям в автомобильной промышленности, MCS Great Lakes David Millet, ведущий консультант, MCS NorCal Dolph Santello, ведущий консультант, MCS Northeast Francis Delgado Millan, менеджер-методист, Microsoft Enterprise Services Joseph Lopesilvero, главный менеджер проекта, Microsoft Project Management Office Paulo Henrique Leocadio, старший ведущий консультант, MCS Brazil Paulo Rocha, ведущий консультант, MCS New Zealand Rick Varvel, ведущий консультант, MCS PacWest Ron Stutz, управляющий консультант, MCS Rocky Mountain Paulo Rocha, Microsoft Consulting Services, New Zealand Anthony Saxby, Microsoft Consulting Services, UK Ralph Schimpl, Microsoft Consulting Services, Austria Ron Stutz, Microsoft Consulting Services, US Brian Willson, Microsoft Consulting Services, US Andres Vinet, Microsoft Consulting Services, Chile Перевод на русский язык Станислав Бусыгин, научный консультант, eLine Software, Inc., Украина/США Ольга Палий, консультант, eLine Software, Inc., Украина/США Редактор русского перевода Владимир Павлов, технический директор, eLine Software, Inc., Украина/США Рецензенты русского перевода Андрей А. Терехов, исполнительный директор ЗАО ЛАНИТ-ТЕРКОМ, Россия Иля Фортунов, старший архитектурный консультант, Microsoft Enterprise Services, UK Виталий Шорин, преподаватель, УЦ ИТ, Академия Народного Хозяйства при Правительстве РФ, Россия Аннотация Управление рисками (risk management) – это одна из ключевых дисциплин Microsoft Solutions Framework ® (MSF). MSF видит в изменениях и возникающей из-за них неопределенности неотъемлемые части жизненного цикла информационных технологий. Дисциплина управления рисками в MSF (MSF risk management discipline) ~2~ отстаивает превентивный подход к работе с рисками в условиях такой неопределенности, непрерывное оценивание рисков и использование информации о рисках в рамках процесса принятия решений на протяжении всего жизненного цикла проекта. Данная дисциплина предлагает принципы, идеи и рекомендации, подкрепленные описанием шестишагового процесса для успешного активного управления рисками. Этот процесс включает в себя выявление и анализ рисков; планирование и реализацию стратегий по их профилактике и смягчению возможных последствий; отслеживание состояния рисков и извлечение уроков из обретенного опыта. Введение MSF описывает процесс непрерывного выявления и оценки рисков, их приоритезации и реализации стратегий по превентивному управлению рисками на протяжении всех фаз жизненного цикла проекта, описываемого моделью процесса MSF (MSF process model).1 В данном документе представлены основные концепции дисциплины управления рисками MSF. Эта дисциплина предлагает принципы, идеи и методики успешного управления рисками IT-проектов, формализованные в виде шестишагового процесса. После прочтения данного документа проектная группа, имеющая опыт применения MSF, должна быть способна превентивно управлять рисками IT-проектов. Тем же, кто не знаком с процессом управления рисками в IT-проектах, этот документ дает базовое понимание концепций, терминологии и принципов, необходимое для внесения собственного вклада в управление рисками во всем жизненный цикле IT-проектов. Дисциплина управления рисками MSF заимствует хорошо известную модель процесса непрерывного управления рисками, разработанную Software Engineering Institute (SEI)2,3. При этом интерпретация этой модели дается в контексте обширного опыта Microsoft, Microsoft Consulting Services (MCS) и партнеров Microsoft в разработке программных продуктов и внедрению IT-проектов. Дисциплина управления рисками MSF возводит процесс управления рисками проектов в ранг стратегической задачи ITпредприятия, затрагивающей все фазы проектов. При этом уделяется особое внимание извлечению уроков из опыта предыдущих проектов. В рамках MSF управление рисками – это процесс выявления, анализа и превентивной работы над рисками в целях избежания их превращения в проблемы, приносящие ущерб или иной вред. Дисциплина управления рисками MSF имеет нижеследующие определяющие характеристики: Она всеобъемлюща и принимает во внимание все составляющие проектов: людей, бизнес-процессы и технологические элементы. Она включает в себя пошаговый, систематический и воспроизводимый процесс управления рисками проекта. Ее использование непрерывно на протяжении всего жизненного цикла проекта. Она превентивна и не исходит из идеологии действия по факту случившегося. Она вовлекает как отдельных работников, так и предприятие в целом, в непрерывное извлечение уроков из полученного опыта. ~3~ Она обладает достаточной гибкостью и способна интегрировать в себя множество различных методологий качественного и количественного анализа рисков. Основные сведения о рисках Управление рисками, присущими проектам, является существенной составляющей управления проектами в целом. Большинство людей увязывает понятие риска с потенциальным ущербом в ценности, управляемости, функциональности, качестве или же своевременности завершения проекта. Кроме того, итогом проекта может быть недополучение той прибыли, возможность получить которую имелась изначально. При этом неопределенности, повлиявшие на принятие решений, явившихся причиной таких результатов, также могут быть отнесены к элементам риска. В MSF риск проекта (project risk) понимается широко – как всякое событие или условие, которое может оказать позитивное либо негативное влияние на итоги проекта. Такое расширенное понимание спекулятивного риска (speculative risk) присутствует в финансовой индустрии, где решения в условиях неопределенности могут привести к получению прибыли точно так же, как и к убыткам. Это противоположно понятию чистого риска (pure risk) в индустрии страхования, где неопределенности связываются только лишь с потенциальными убытками в будущем.4 Риски отличаются от проблем и трудностей, так как они имеют отношение к будущим, потенциально возможным негативным результатам и убыткам. Проблемы же и трудности представляют собой нечто, имеющее место в настоящее время. Риски могут стать проблемами, если ими эффективно не управлять. В рамках MSF управление рисками рассматривается как процесс их выявления, анализа и эффективной превентивной работы над ними. Цель управления рисками – максимизировать положительное их влияние (открывающиеся возможности), но при этом минимизировать связанные с ними негативные факторы (убытки). Эффективный процесс выявления и управления рисками помогает достичь разумных компромиссов между упомянутыми опасностями и открывающимися возможностями. Проекты в области информационных технологий (IT) обладают специфическими характеристиками, в силу которых эффективное управление рисками становится жизненно важным для их успеха. Рыночная конкуренция, эволюция технических стандартов, равно как и другие факторы, могут заставить работающую над проектом группу модифицировать принятые планы и решения в середине проекта. Изменяющиеся требования пользователей, новый инструментарий и новые технологии, растущие угрозы для информационной безопасности, текучесть кадров – все это дополнительные факторы, способные повлечь за собой изменения в IT-проекте и заставить проектную группу принимать решения в условиях неопределенности (риска). Jim McCarthy писал: “Практически на каждой стадии даже самых успешных проектов по разработке программного обеспечения существует большое количество важнейших вещей, о которых ничего не известно” (из книги “Динамика разработки программного обеспечения”, 1995, стр. 99) 5. Базовые принципы Дисциплина управления рисками в MSF основана на убеждении, что такое управление должно производиться превентивно; это часть формального и систематического процесса, трактующего усилия, затрачиваемые на управление рисками, с позитивной ~4~ точки зрения. В основе этой дисциплины лежат все центральные для MSF принципы, идеи и методики, вносящие свой вклад в эффективное управление рисками проектов.6 Тем не менее нижеследующие принципы MSF особенно важны для дисциплины управления рисками. Проявляйте гибкость – будьте готовы к переменам Постоянная возможность изменений – это один из главных источников неопределенности, с которой приходится иметь дело проектной группе. Меры по управлению рисками не должны ограничиваться какой-либо одной фазой жизненного цикла проекта. Зачастую группа начинает работу с твердым намерением систематически осуществлять управление рисками от начала и до конца проекта, но под прессингом временных ограничений оказывается не в состоянии это сделать. “Гибкость” (agility) требует от проектной группы постоянной оценки и превентивного управления рисками на всех фазах жизненного цикла проекта, так как непрерывные изменения во всех аспектах проекта влекут за собой непрерывные изменения в его рисках. Превентивный подход позволяет команде воспользоваться изменениями и превратить их в новые возможности, не допуская негативных, разрушительных последствий, к которым эти изменения могли бы привести в противном случае. Поощряйте свободное общение MSF предполагает открытость в обсуждении рисков как внутри проектной группы, так и с ключевыми заинтересованными лицами (stakeholders), находящимися вне ее. Все члены проектной команды должны участвовать в обнаружении и анализе рисков. Для стимулирования такого всеобщего участия руководство всех уровней должно способствовать установлению позитивной и доброжелательной атмосферы. Открытое, честное обсуждение связанных с проектом рисков ведет к более точной оценке состояния проекта и более обоснованному принятию решений, как в рамках проектной группы, так и со стороны руководства и спонсоров. Извлекайте из всего уроки MSF исходит из того, что, концентрируя внимание на непрерывном самосовершенствовании и извлечении уроков из накопленного опыта, можно достичь большего успеха. Знания, полученные в рамках одного проекта, могут помочь при принятии решений в условиях недостатка информации в другом проекте, для чего эти знания должны быть доступны всем сотрудникам предприятия. MSF подчеркивает важность извлечения организацией уроков из каждого проекта путем интеграции соответствующих мероприятий в процесс управления рисками. Фокусирование внимания на опыте завершившихся проектов стимулирует взаимообучение путем открытого обмена накопленных знаний между проектными группами. Распределение ответственности при фиксации отчетности В рамках MSF никто не отвечает единолично за управление рисками. Обязанность каждого члена проектной группы – активное участие в этом процессе. В соответствии с утвержденными планами конкретные лица отвечают за определенные действия, связанные с управлением рисками проекта; каждый несет персональную ответственность за выполнение таких задач и отчитывается по ним точно так же, как и за другую свою деятельность в рамках проекта. Эта деятельность может затрагивать все аспекты проекта на протяжении всех его фаз и циклов процесса управления ~5~ рисками. Она начинается с выявления рисков в рамках области личной компетенции и ответственности и распространяется на анализ рисков, планирование рисков и исполнение задач по управлению ими на протяжении работы над проектом. В рамках модели проектной группы MSF те, в чью область компетенции входит “Управление проектом” (ролевой кластер “Управление программой”) несут окончательную ответственность за организацию в проектной группе деятельности, связанной с управлением рисками, и обеспечивают включение этой деятельности в повседневный процесс управления проектом7. Ключевые концепции В этом разделе мы рассмотрим понятия риска и управления риском, являющиеся ключевыми для понимания дисциплины управления рисками MSF. Риск - неотъемлемая часть всякого проекта или процесса Несмотря на то, что различные проекты могут быть связаны с большим или меньшим числом рисков, не существует ни одного проекта, полностью свободного от них. Проекты инициируются для того, чтобы организация могла получить некоторый результат, вносящий вклад в достижение цели ее существования. При этом всегда существуют неопределенности, связанные как с природой проекта, так и с внешними условиями, оказывающими влияние на успешное достижение искомого результата. Всегда помня о невозможности полностью избежать рисков, профессионалы MSF постоянно ищут пути разумных компромиссов между рисками и потенциальными возможностями и не становятся на путь абсолютной минимизации риска ценой исключения всего остального. Наиболее эффективно превентивное управление рисками MSF выбирает превентивный подход к выявлению, анализу и работе над рисками, фокусируясь на следующем: Предугадывайте проблемы вместо того, чтобы реагировать на них после их возникновения. Работайте над первопричиной, а не над проявляющимися симптомами. Готовьте планы решения проблем заранее, до того как проблемы возникнут. Используйте понятный, структурированный и воспроизводимый процесс разрешения проблем. Предпринимайте превентивные меры везде, где это возможно. Эффективное управление рисками не может быть сведено к простому реагированию на возникающие проблемы. Проектная группа должна работать над заблаговременным выявлением рисков и создавать стратегии и планы по управлению ими. Должны быть разработаны планы по решению проблем в случае их возникновения. Предвосхищение потенциальных проблем и заблаговременная подготовка четко составленных планов по борьбе с ними сокращает временные затраты в критических ситуациях. Такая деятельность способна ограничить негативный эффект, создаваемый этими проблемами, и даже помочь извлечь из них некоторую пользу. Определяющими характеристиками превентивного управления рисками являются профилактика рисков (risk mitigation) и сокращение их негативного воздействия. Профилактика может проводиться по отношению к одному специфическому риску и ~6~ иметь своей целью воздействие на его непосредственную причину. Но она может также относиться к исходной первопричине риска, равно как и к любому звену цепи причинно-следственных связей, порождающей риск. Лучшее время для профилактических мер – ранние этапы работы над проектом, когда проектная группа все еще может оказать своевременное влияние на его результат. Для предприятия особенно важны обнаружение и ликвидация первопричин рисков, так как соответствующие корректирующие шаги могут иметь далеко идущий позитивный эффект, выходящий за пределы одного отдельно взятого проекта. Например, отсутствие стандартов написания программного кода или же соглашений об именовании компьютеров в локальной сети явно может привести к плачевным последствиям в рамках разработки и внедрения отдельного проекта и, как следствие, будет в нем источником повышенного риска. Однако выработка таких стандартов и соглашений окажет позитивный эффект на все проекты, осуществляемые предприятием, – конечно, если эти стандарты и директивы начнут действовать в масштабе всей организации. Всячески одобряйте выявление рисков Эффективность управления зависит от правильного и полного понимания тех рисков, с которыми сталкивается проектная группа. Осознание многообразия возможных проблем и уровня потенциальных убытков может навести уныние на сотрудников. Как следствие, проектная группа будет смотреть на выявление рисков как на негативную деятельность. Некоторые члены проектной группы могут даже считать, что деятельность по выявлению рисков имеет своей реальной целью дискредитацию проекта. Точка зрения MSF диаметрально противоположна. Знание о существовании рисков - необходимое условие эффективной работы над ними. Следовательно, перспективы успеха проектной группы от проведения работы по выявлению рисков лишь увеличиваются. Открытое протоколируемое обсуждение рисков приводит к четкому разъяснению ролей и ответственности членов проектной группы как во время плановых мероприятий по профилактике рисков, так и при разрешении проблем, которые могут возникнуть. Это освобождает от дополнительных трудозатрат и позволяет проектной группе непосредственно сосредоточиться на своей работе. Члены проектной группы (и в особенности ее руководители) должны всегда трактовать выявление рисков как позитивный фактор. Это дает возможность получить максимально полную информацию о возникающих рисках. Негативное восприятие рисков мешает проектной группе обсуждать данную тему. Необходимо создание такой атмосферы, при которой все работники могут вносить свой вклад в выявление рисков без опаски быть подвергнутыми критике за искреннее выражение своих взглядов и небесспорных точек зрения. Примеры другой, негативной, атмосферы отношения к рискам найти легко. В частности, в некоторых организациях сообщение о новых рисках рассматривается как одна из форм жалоб на условия работы. При этом источником неприятностей начинает считаться персона, выражающая свое мнение относительно существования риска, и вся реакция сводится к реакции эту персону лично, а не на риск. В таком случае работники начинают проявлять осторожность при общении с коллегами на темы, связанные с рисками. Они избирательно сообщают только ту информацию, которая не вызывает негативной реакции у руководства и других членов проектной группы, что однозначно снижает эффективность управления рисками. Поэтому большего успеха достигнут те проектные группы, в которых существует доброжелательное отношение к выявлению рисков, и где работники, вносящие в эту деятельность существенный вклад, активно поощряются. ~7~ Чтобы получить максимальную выгоду от проекта, команда должна иметь желание пойти на риск. Для этого требуется отношение к рискам и неопределенностям как к средствам создания необходимых возможностей достижения успеха. Постоянная оценка Многие профессионалы в области IT воспринимают управление рисками в лучшем случае как необходимую, но тягостную задачу, которую нужно решать только на начальном этапе работы над проектом или при возникновении новых условий ведения бизнеса. Непрерывные изменения в проекте и окружающих обстоятельствах требуют от проектной группы регулярной переоценки известных рисков и модификации планов по профилактике и смягчению последствий возникновения проблем, связанных с этими рисками. Проектные группы также должны постоянно следить за появлением новых рисков. Управление рисками должно быть интегрировано в общий жизненный цикл проекта. При этом должна существовать возможность внесения необходимых изменений в планы и действия по управлению рисками без создания отдельной системы мониторинга и отчетности. Поддерживайте открытое общение Хотя отдельные члены проектной группы обычно знают о многих рисках, эта информация часто не доходит до группы в целом. Как правило, не представляет труда распространение такой информации вниз по организационной иерархии, но оказывается затруднительным передать такую информацию по ней вверх. На каждом уровне сотрудники хотят узнавать о рисках от своих подчиненных, но осторожничают с сообщением о них вышестоящим лицам. Такой ограниченный информационный поток сам по себе является потенциальным риском проекта, так как он приводит к принятию решений на основе еще более ограниченной и неполной информации. В силу этого менеджеры иерархических организаций должны поощрять и поддерживать открытое общение на темы рисков, а также обеспечивать всеобщее понимание рисков и планов по управлению ими. Вначале определяйтесь, затем действуйте Управление рисками связано с принятием решений в условиях неопределенности. Обобщенные формулировки рисков сохраняют значительную часть этой неопределенности и ведут к неоднозначному пониманию самого риска. Поэтому необходимы четкие описания существующих рисков, помогающие проектной группе обеспечить однозначное понимание риска всеми членами команды; понять причину (или причины) риска и их взаимоотношение с теми проблемами, которые могут возникнуть; иметь базу для количественного, формального анализа рисков и последующего планирования; дать уверенность заинтересованным в проекте сторонам и его спонсорам (sponsors) в том, что проектная группа в состоянии справиться с риском. MSF считает необходимым внимательное отношение к конкретной, специфической информации, позволяющей минимизировать ошибки управления рисками. Такие ошибки способны свести эффективность превентивного подхода на нет или же помешать процессу смягчения последствий возникших проблем. ~8~ Не судите о положении вещей исходя только из количества рисков Хотя члены проектной группы и ключевые заинтересованные лица часто воспринимают каждый риск как негативный фактор, важно не допускать суждения о проекте либо же бизнес-процессе исходя только из количества выявленных рисков. Риск в конце концов – это открывающаяся возможность, а не случившийся убыток или же недополученная прибыль. Дисциплина управления рисками в MSF предлагает использование структурированного процесса выявления рисков и их анализа с целью предоставления принимающим решения лицам информации не только о наличии рисков, но также и о значимости каждого из них. Планирование управления рисками Во время проектных фаз выработки концепции (envisioning) и планирования (planning) коллектив должен разработать формальный документ, описывающий управление рисками данного проекта. В нем необходимо дать ответы на следующие вопросы: В рамках каких допущений и ограничений производится управление рисками? Как будет реализовываться процесс управления рисками? Из каких шагов состоит этот процесс? Какие именно действия, роли участников и их обязанности, результаты характеризуют каждый шаг? Кто будет осуществлять действия по управлению рисками? Какие для этого требуются навыки/квалификация? Требуется ли дополнительное обучение? Как управление рисками данного конкретного проекта соотносится с действиями, производимыми на уровне всего предприятия? Какой инструментарий и какие методики будут применены? Какой терминологический аппарат будет использован для классификации и оценки рисков? Какова процедура приоритезации рисков? Как будут строиться планы управления рисками и планы мероприятий по смягчению возможных негативных последствий (contingency plans)? Как деятельность по управлению рисками будет интегрирована в общий план проекта? Какие действия будут предпринимать отдельные члены проектной группы для управления рисками? Как информация о положении дел будет распространяться внутри проектной группы? Среди заинтересованных в проекте сторон (stakeholders)? Каков механизм отчетности? Как будет производиться мониторинг прогресса? ~9~ Какая инфраструктура (базы данных, программные инструменты, хранилища информации) будет использована для обеспечения процесса управления рисками? Каковы риски процесса управления рисками? Какие ресурсы доступны для управления рисками? Каковы временные ограничения в мероприятиях, связанных с управлением рисками? Кто является спонсором, и какие присутствуют заинтересованные стороны? Планирование управления рисками не должно рассматриваться в отрыве от процесса планирования всего проекта, и деятельность по управлению рисками не должна восприниматься как “дополнительная” нагрузка к той “основной” работе, которую выполняют члены проектной группы. Поскольку риски являются неотъемлемой частью всех фаз всех проектов от начала и до конца, должны быть изначально выделены и должным образом распределены ресурсы, необходимые для эффективного управления рисками. Планирование управления рисками осуществляется проектной группой во время фаз выработки концепции и планирования (в рамках модели процесса MSF 8), и результирующий план управления рисками должен определять конкретные действия (задачи), ответственность за которые возложена на определенных членов проектной группы. Эти задачи должны быть интегрированы в сводный план проекта (master project plan) и в сводный календарный график проекта (master project schedule). Процесс управления рисками Общее представление Дисциплина управления рисками MSF отстаивает превентивное управление рисками, непрерывную оценку имеющихся рисков и интеграцию этих процессов в общую деятельность по принятию решений на протяжении всего жизненного цикла проекта или бизнес-процесса. Над риском ведется непрерывная и активная работа до тех пор, пока он либо исчезает, либо превращается в проблему, с которой необходимо справиться. Процесс управления рисками MSF, представленный на рис. 1, определяет шесть логических шагов, посредством которых проектная группа управляет текущими рисками, разрабатывает и исполняет стратегии управления рисками и извлекает уроки из своего опыта для использования на уровне всего предприятия. Шесть этапов процесса управления рисками MSF – это Выявление Анализ и приоритезация Планирование Мониторинг Корректирование Извлечение уроков. Выявление рисков (risk identification) – это фаза, позволяющая членам проектной группы вынести на обсуждение всей команды факты наличия рисков. Выявление рисков является начальной стадией процесса управления ими. Оно должно быть ~10~ осуществлено как можно раньше, и к нему необходимо постоянно возвращаться на протяжении всего жизненного цикла проекта. Рисунок 1. Процесс управления рисками MSF Анализ рисков (risk analysis) – это фаза преобразования накопленных во время предыдущего шага оценок и данных в форму, позволяющую осуществить приоритезацию рисков. Приоритезация рисков (risk prioritization) позволяет проектной группе производить управление наиболее важными из них, выделяя для этого необходимые ресурсы. Планирование рисков (risk planning) производится исходя из информации, полученной на этапе их анализа, и имеет своей целью выработку стратегий, планов и конкретных шагов. Календарное планирование рисков (risk scheduling) интегрирует эти планы в повседневный процесс управления проектом, обеспечивая непрерывность управления рисками. Эта стадия напрямую увязывает планирование рисков с планированием проекта в целом. Мониторинг рисков (risk tracking) производится для наблюдения за конкретными рисками и прогрессом в осуществлении составленных планов. Мониторингу должны быть подвергнуты сделанные оценки вероятности (probability) риска, его угрозы (impact), ожидаемая величина риска (exposure) и прочие факторы, способные повлиять на приоритет рисков. Наблюдению подвергаются также составленные планы, имеющиеся ресурсы и принятый календарный график. Мониторинг рисков обеспечивает прозрачность процесса управления рисками проекта на различных уровнях в дополнение к стандартному процессу управления проектом, отслеживающему степень завершенности проектных задач. Отчетность о рисках (risk reporting) обеспечивает информирование проектной группы, спонсоров и других заинтересованных сторон о состоянии рисков проекта и планов по управлению ими. Корректирование ситуации (risk control) представляет собой процесс исполнения принятых в отношении рисков планов и контроля за ходом их исполнения. Этот процесс также включает в себя инициирование изменений всего проекта (project change ~11~ control requests), если изменения в состоянии рисков либо в соответствующих планах влияют на прогнозируемый объем работы, требуемые ресурсы или сроки. Извлечение уроков (risk learning) формализует процесс усвоения накопленного за время работы над проектом опыта в форме, доступной для использования как внутри проектной группы, так и на уровне всего предприятия. Заметим, что описанные фазы являются логическими шагами и они не обязательно для каждого из рисков должны следовать друг за другом в строгом хронологическом порядке. Проектные группы могут циклически повторять шаги выявления-анализапланирования по мере обнаружения дополнительных факторов, влияющих на проект. При этом извлечение уроков может производиться лишь время от времени на уровне всего предприятия. Далеко не все риски проходят циклически через все приведенные выше шаги. Дисциплина управления рисками MSF полагает, что в каждом конкретном проекте на этапе планирования должно быть определено, когда и как процесс управления рисками инициируется, и при достижении каких условий происходит переход от одной фазы процесса управления рисками к другой как в отношении отдельных рисков, так и для различных их групп. Выявление рисков Введение Выявление рисков является начальным шагом процесса управления рисками MSF. Чтобы проектная группа могла приступить к их анализу и планированию, необходимо изначально выявить и четко и однозначно сформулировать имеющиеся риски. Выявляя риски, проектная группа должна уделить внимание максимально широкому кругу факторов. В частности, должно быть проведено исследование и выявление неучтенных особенностей проекта и той среды, в которой он будет разрабатываться, так как они могут существенно повлиять на проект или даже стать причиной его неуспеха. На рис. 2 показаны исходные данные, используемые на шаге выявления рисков, получаемый результат, а также предпринимаемые действия. Цели Целью фазы выявления рисков является создание проектной группой списка имеющихся рисков проекта. Этот список должен быть всеобъемлющим (comprehensive), охватывающим все факторы, влияющие на проект. Исходные данные Исходными данными фазы выявления рисков являются имеющиеся знания как об общих, так и о специфических для данного проекта рисках, связанных с бизнесом, технологиями, организациями и внешними условиями. Дополнительные факторы, которым должно быть уделено внимание: имеющийся у команды опыт, применяемые внутри организации подходы к рискам, выраженные в виде правил и инструкций, а также вся информация о проекте, известная на данный момент, включая его историю и текущее положение дел. Проектная группа может также использовать любые другие источники – должно быть задействовано все, что может помочь выявлению рисков. На начальном этапе проекта с целью выявления рисков полезно проводить мозговые штурмы, дискуссии или даже формальные семинары с участием различных заинтересованных лиц для ознакомления с их взглядами на риски и открываемые ~12~ проектом возможности. Также могут оказаться полезными отраслевые схемы классификации рисков, такие как таксономия рисков SEI9, проектные чеклисты (checklists)10, сводные отчеты о предшествующих проектах и другие опубликованные источники и отраслевые руководства. Рисунок 2. Выявление рисков Шаги по выявлению рисков В процессе выявления рисков проектная группа старается четко сформулировать и перечислить все имеющиеся в проекте риски. На начальной стадии проекта может быть организован семинар или мозговой штурм с целью выявления рисков, возникающих в новых условиях. К сожалению, многие организации смотрят на эту деятельность как на одноразовое мероприятие, которое производится в начале и не повторяется на протяжении жизненного цикла проекта. Дисциплина управления рисками MSF отстаивает иную точку зрения, в соответствии с которой выявление рисков должно производиться регулярно, на протяжении всего проекта. Мероприятия по выявлению рисков могут привязываться к временному графику (например, быть ежедневными, еженедельными или ежемесячными), вехам (milestones) проекта или даже ~13~ специфическим событиям (связанным с существенными изменениями в сфере бизнеса, технологий, менеджмента или внешней среды). Такие периодические мероприятия по выявлению рисков должны выполняться в соответствии с планами проектных групп. К примеру, выявление глобальных рисков проекта всей проектной группой может быть увязано с главными вехами проекта, но отдельные члены проектной группы в рамках областей своей компетенции могут производить выявление рисков повторно на промежуточных вехах (контрольных точках) проекта или даже в соответствии с некоторым еженедельным графиком. Во время первых шагов по выявлению рисков проекта особую важность представляет взаимодействие между членами проектной группы и другими заинтересованными сторонами, так как оно позволяет выявить различные взгляды на положение вещей и противоречия между ними. Для этого необходимо привлечь группы заинтересованных лиц и участников проекта с самыми различными интересами, опытом и профессиональными навыками. Процесс выявления рисков может также включать в себя исследовательскую работу, проводимую проектной группой, либо привлечение со стороны экспертов в предметной области проекта с целью получения больших знаний о специфически свойственных ей рисках. Структурированный подход Везде, где только это возможно, MSF рекомендует использовать в процессе управления рисками структурированный подход. В проектах по разработке и внедрению программного обеспечения использование классификаций рисков на этапе выявления предоставляет ясно определенный, воспроизводимый и поддающийся оценке подход. Классификация рисков дает основу для стандартизации терминологии, необходимой для мониторинга и отчетности, и является незаменимой для создания базы знаний о рисках на уровне предприятия или всей индустрии. Классификации рисков помогают проектной группе мыслить всесторонне, предоставляя готовую систематизацию всех составляющих проекта, требующих внимания при выявлении рисков. Такая систематизация может быть получена на основании опыта схожих проектов, осуществленных ранее, или же на основании опытных знаний индустрии в целом. Формулировка рисков (risk statement formulation) является основной методикой, применяемой в рамках MSF для оценки проектов, построения приоритезаций рисков и планирования связанной с рисками деятельности. Классификация рисков Классификации рисков (или категории рисков), иногда называемые таксономиями, предназначены для нескольких целей. Во время выявления рисков они стимулируют видение проектной группой всего многообразия рисков, возникающих из различных составляющих проекта. При проведении мозгового штурма классификации рисков облегчают одновременную работу с большим числом рисков, предоставляя подходящий способ группирования схожих рисков. Они также могут быть использованы в выработке общепринятой в проектной группе терминологии для мониторинга и отчетности о состоянии рисков. В конечном счете, классификации рисков совершенно необходимы для составления баз знаний о рисках на уровне предприятий и целых индустрий, так как они предоставляют инструментарий категоризации всей новой информации и удобного поиска существующих знаний. Следующая таблица показывает высокоуровневую классификацию источников рисков проектов. ~14~ Люди Заказчики (customers) Конечные потребители (конечные пользователи, end users) Спонсоры Заинтересованные стороны Персонал Организация Профессиональная квалификация Политика Мораль Процессы Цели и задачи Принятие решений Характеристики проекта Бюджет, затраты, сроки Требования (requirements) Проектирование (design) Реализация (building) Тестирование (testing) Технологии Безопасность Среда разработки и тестирования Инструментарий Внедрение Сопровождение Операционная среда Доступность Внешние условия Законодательство Индустриальные стандарты Конкуренция Экономические условия Технология Бизнес-условия ~15~ Существует множество классификаций общих рисков проектов по разработке программного обеспечения. Хорошо известны и часто цитируются Barry Boehm11, Caper Jones12, и SEI Software Risk Taxonomy13, описывающие источники таких рисков. Также имеются детализованные списки областей рисков, покрывающие определенное количество составляющих проекта. Риски календарного планирования – это одна из общих областей рисков, с которой сталкиваются все проектные группы. Исчерпывающий обзор таких рисков, затрагивающих проекты в области разработки программного обеспечения, был составлен Steve McConnel.14 Проекты в специфических предметных областях, проекты, осуществляемые с применением узкоспециальных технологий, проекты для вертикальных рынков, а также проекты со специфическим конечным продуктом могут содержать хорошо известные риски, уникальные для своей области. Например, в области информационной безопасности существуют риски связанные с кражей, потерей или искажением информации в результате злоумышленного действия или случайного события. Подобные риски обычно именуются опасностями (threats)15,16. При работе над проектами в таких областях полезно изучить классификации этих специальных рисков или же расширить имеющиеся классификации рисков общего назначения. Это должно обеспечить надлежащую широту мышления проектной группы при выявлении рисков проекта. Прочие источники информации о рисках проектов включают в себя базы данных рисков индустриальных проектов, такие как Software Engineering Information Repository (SEIR)17, и внутренние корпоративные базы знаний о рисках. Формулировки рисков Формулировка риска – это выражение на естественном языке причинно-следственной связи между реально существующим фактором проекта (текущим положением дел) и потенциально возможным, еще не случившимся событием или ситуацией. Первая часть формулировки риска называется условием (condition) и содержит описание существующего фактора или особенности проекта, которые, по мнению проектной группы, могут сделать результат проекта убыточным либо же сократить получаемую от проекта прибыль. Вторая часть формулировки риска называется (по)следствием (consequence). Она описывает ту нежелательную ситуацию, которой следует избежать. Первая и вторая части формулировки связываются такими словами, как “поэтому” и “в результате”, – они описывают не жесткую, но возможную (с вероятностью меньше 100%) причинно-следственную связь. Схематически это показано на рис. 3. Такая форма описания риска удобна тем, что на ранних этапах процесса управления рисками она увязывает последствие риска с видимым (и потенциально контролируемым) его условием. Использование альтернативного подхода, при котором проектная группа не концентрируется на описании условий на фазе выявления рисков, ведет к тому, что на более позднем этапе (при разработке стратегий управления) приходится восстанавливать условия и причины рисков. Заметим, что формулировки рисков не являются предложениями в форме “если-то”. В действительности они представляют собой факты наличия возможных, но еще не случившихся зависимостей. Рассмотрение гипотетических причинно-следственных связей “если-то” может оказать помощь при выработке планов с использованием деревьев альтернатив на этапе анализа и планирования. Однако на этапе выявления рисков задача состоит в обнаружении максимально возможного их числа. Поэтому анализ причинно-следственных связей должен быть отложен до фазы планирования. На ~16~ раннем этапе работы над проектом можно встретить огромное количество таких формулировок рисков, которые указывают на недостаточную информированность проектной группы. Это могут быть такие выражения как: “Мы еще не знаем об X, поэтому...” Рисунок 3. Формулировки рисков При формулировании риска проектная группа должна рассматривать как причину потенциально возможного нежелательного исхода, так и непосредственно сам этот исход. Формулировка риска включает в себя видимое положение вещей в проекте (условие) совместно с гипотетической ситуацией, которая может наступить (последствие). В процессе работы по детальному анализу рисков проектная группа должна находить схожести и естественные объединения формулировок тех рисков проекта, которые имеют общую первопричину. Это может быть достигнуто отслеживанием вглубь цепочек причинно-следственных связей, отталкиваясь от каждого из сформулированных условий рисков18. Также полезно отслеживать причинно-следственную связь в противоположном направлении для выявления возможных масштабных эффектов на уровне организации и внешней среды за рамками одного проекта. Это позволяет более полно представить суммарный урон или упущенные возможности, имеющие одно общее условие19. Зачастую оказывается, что одно условие риска влечет за собой множество последствий. Также возможно, что последствие, выявленное в одной составляющей проекта, может оказаться в роли причины/условия в другой составляющей. Подобные ситуации должны регистрироваться проектной группой в форме, позволяющей учесть на этапе анализа существующие между рисками взаимозависимости и взаимодействия. Такие взаимоотношения могут означать, что исчезновение одного риска может привести к ликвидации целой группы зависимых рисков и соответствующим изменениям в состоянии рисков всего проекта. Документирование этих взаимозависимостей на ранней стадии обнаружения рисков способно обеспечить гибкое детальное планирование рисков, эффективно использующее ресурсы проекта для работы над первопричинами и начальными звеньями цепочек причинно-следственных связей. Выявление причинно-следственных связей рисков должно дополняться фазами анализа и приоритезации с дальнейшей перепроверкой взаимозависимостей и первопричин наиболее важных рисков. ~17~ Результаты Как минимум, в результате процесса выявления рисков должны быть получены их четкие, однозначные и согласованные формулировки, представленные в виде списка рисков. Если риски формулируются как связки условие-последствие в соответствии с рекомендациями SEI20, NASA21 или ранних версий MSF22,23, то результатом будет набор таких условных формулировок для всех выявленных рисков. Этот список рисков (представленный в табличной форме) служит исходной информацией для следующей фазы процесса управления рисками – анализа. Выявление рисков обычно предоставляет значительный объем дополнительной полезной информации, включая обнаружение первопричин рисков, затрагиваемые стороны и др. Дисциплина управления рисками MSF рекомендует вести запись формулировок выявленных рисков, их первопричин и приносимого ими ущерба в табличной форме. Также полезно классифицировать эти риски по какой-либо существующей таксономии, так как это может помочь пополнить базу знаний предприятия о рисках. В список рисков может также вноситься информация, определяющая контекст риска. Это должно позволить как другим сотрудникам, так и заинтересованным лицам со стороны понять суть произведенной работы по выявлению рисков24,25,26. Описание контекста рисков может включать в себя условия; ограничения; обстоятельства; допущения; влияющие факторы; взаимозависимости рисков; связанные с рисками вопросы; владельцы подвергающейся риску собственности; факторы, вызывающие у проектной группы беспокойство. Полученный список рисков (с указанием или без указания условий и первопричин рисков, приносимого ущерба и контекстной информации) будет превращен в главную таблицу рисков на следующем этапе процесса управления рисками. Вот пример такого списка: Первопричина Условие Последствие Приносимый ущерб Нехватка кадров Могут быть объединены роли разработчиков и тестировщиков В программном продукте будет содержаться больше ошибок Заказчик будет менее доволен результатом Изменения в технологии Разработчикам придется использовать новый язык программирования Увеличится затрачиваемое на разработку время Наш продукт будет представлен на рынке в более поздние сроки, что приведет к захвату части рынка ~18~ конкурентами Организация работы Часть группы разработчиков находится в Лондоне, а часть – в Лос-Анжелесе Обмен информацией внутри группы затрудняется Задержки в сроках сдачи готового продукта и дополнительные трудозатраты Анализ и приоритезация рисков Введение Анализ и приоритезация рисков – это второй шаг процесса управления рисками MSF. Анализ рисков трансформирует имеющиеся данные о рисках в форму, облегчающую принятие решений. Приоритезация рисков указывает, какие из них являются наиболее важными и, как следствие, работа над ними должна быть проведена прежде всего. Во время этого этапа проектная группа рассматривает риски из списка, составленного при их выявлении, задает приоритеты и формирует главную таблицу рисков. Рисунок 4. Анализ и приоритезация рисков ~19~ Используя эту таблицу, проектная группа может определить самые существенные из рисков - для управления ими надлежит выделить необходимые ресурсы для планирования и реализации соответствующих стратегий. Проектная группа может также выявить столь несущественные риски, что их влиянием можно пренебречь и вычеркнуть их из списка. По ходу работы над проектом и при изменении внешних обстоятельств шаги выявления и анализа рисков должны повторяться, и главная таблица рисков должна обновляться. В ней могут появляться новые риски и исчезать старые, не оказывающие более на проект существенного влияния. Исходные данные и результаты фазы анализа и приоритезации изображены на рис. 4. Цель Основной целью шага анализа рисков является их приоритезация и определение тех рисков, на которые стоит выделить ресурсы для дальнейшей работы с ними. Исходные данные Анализ рисков – это трансформация “сырого” списка, составленного на шаге выявления, в главную таблицу рисков. При его проведении проектная группа может использовать как собственный опыт, так и “внешние” источники информации. В качестве таковых могут выступать правила и рекомендации, действующие в организации, базы данных рисков индустрии, имитационные и аналитические модели, а также управленческое звено организации, эксперты предметной области проекта и др. Процесс анализа рисков Существует много количественных и качественных методик проведения приоритезации рисков. Одна из них, простая и удобная в использовании, заключается в выработке проектной группой коллективных оценок двух общепризнанных параметров каждого из рисков – вероятности (probability) и угрозы (impact). Произведение этих двух величин дает единую метрику риска, называемую ожидаемой величиной (exposure). Вероятность риска Вероятность риска – это мера возможности того, что последствие риска, описанное в его формулировке, действительно наступит. Вероятность риска должна быть больше нуля, так как иначе он из себя ничего не представляет. Также вероятность риска должна быть меньше 100%, иначе он не содержит неопределенности и представляет собой уже известную проблему. Оценка вероятности и ее применение – достаточно сложная задача. Однако имеющиеся на уровне предприятия или индустрии базы данных о рисках способны помочь получить такие оценки исходя из опыта значительного количества схожих проектов. В большинстве ситуаций проектные группы могут представить собственный опыт и/или имеющиеся в индустрии опытные данные в виде простых и понятных формулировок, которые затем могут быть превращены в числовые значения. Это может быть простейшая градация “низко-средне-высоко”, отображаемая в отдельно взятые численные значения (17%, 50%, 84%), либо же сложные оценки таких выражений как “почти невозможно”, “маловероятно”, “возможно”, “почти наверняка” и т.д. Следующая таблица демонстрирует трехуровневое разделение вероятности ~20~ Интервал вероятностей Значение вероятности, используемое для вычислений Словесная формулировка Числовая оценка От 1% до 33% 17% низкая 1 От 34% до 67% 50% средняя 2 От 68% до 99% 84% высокая 3 Следующая таблица представляет семиуровневое разделение вероятности Интервал вероятностей Значение вероятности, используемое для вычислений Словесная формулировка Числовая оценка От 1% до 14% 7% крайне маловероятно 1 От 15% до 28% 21% низкая вероятность 2 От 29% до 42% 35% скорее нет 3 От 43% до 57% 50% 50-50 4 От 58% до 72% 65% возможно 5 От 73% до 86% 79% весьма правдоподобно 6 От 87% до 99% 93% почти наверняка 7 Заметим, что используемое вероятностное значение представляет собой среднее значение из интервала. При помощи таких таблиц можно оценить вероятность на основе имеющейся словесной формулировки или числового интервала. При проведении численного оценивания рисков необходимо использовать для каждого из них один и тот же диапазон, чтобы полученная приоритезация была единообразна. Независимо от используемой методики количественного оценивания неопределенности, проектная группа должна выработать механизм получения единой итоговой оценки вероятности каждого риска, выражающей консенсуальное решение группы. Угроза риска Угроза риска (risk impact) представляет собой меру серьезности негативных последствий, уровень убытков или оценку потенциальных возможностей, связанных с риском. Угроза должна быть непосредственным числовым выражением последствия риска, описанного в его формулировке. Она может оцениваться в денежных единицах или же по некоторой субъективной шкале. Выражение угроз всех рисков в деньгах имеет то преимущество, что оно будет более понятно инвесторам бизнеса. Финансовые угрозы рисков могут представлять собой долговременные расходы на функционирование и сопровождение продукта, уменьшение доли компании на рынке, кратковременные затраты на дополнительную работу или же цену возможностей. ~21~ В иных ситуациях предпочтительна субъективная пятибалльная или десятибалльная шкала для оценки угрозы рисков. Для применения простых методик приоритезации рисков в главной таблице рисков необходимо указать величины угрозы всех рисков в одинаковых единицах. Поэтому полезно иметь таблицы преобразования специфических единиц измерения, таких как время и деньги, в значения, которые могут быть сопоставлены с субъективными единицами оценок, используемыми другими методиками анализа рисков. Пример показан в следующей таблице. Оценка Денежное выражение 1 до $100 2 $100-$1000 3 $1000-$10,000 4 $10,000-$100,000 5 $100,000-$1,000,000 6 $1,000,000-$10 миллионов 7 $10 миллионов-$100 миллионов 8 $100 миллионов-$1 миллиард 9 $1 миллиард-$10 миллиардов 10 свыше $10 миллиардов Такой подход позволяет сравнивать угрозы рисков различных проектов предприятия. Данная конкретная шкала представляет собой логарифмическую величину, при которой оценка угрозы берется примерно равной log10(сумма)-1. Большие значения соответствуют большим денежным суммам. Когда фискальные единицы не могут быть применены, проектная группа может использовать другие шкалы оценки угрозы, охватывающие необходимые составляющие. К примеру, Hall (1998) предлагает следующий подход27: Оценка Перерасход средств Календарный график Технические условия 1 (низкая) до 1% сдвиг на 1 неделю небольшая потеря производительности 2 (средняя) до 5% сдвиг на 2 недели умеренное снижение производительности 3 (высокая) до 10% сдвиг на 1 месяц серьезный ущерб для производительности 4 (критическая) от 10% сдвиг более 1 мес. задача не может быть выполнена Система оценки воздействий должна отражать политику и ценности организации и проектной группы. ~22~ Убыток размером $10,000 может быть терпимым для одной проектной группы или организации, но совершенно недопустимым для другой. Для учета рисков с очень малой вероятностью (но большой угрозой) необходимо, чтобы шкала угроз была достаточно широкой, включающей катастрофические исходы. Ожидаемая величина риска Ожидаемая величина риска (risk exposure) показывает общий уровень опасности риска, вбирая в одну числовую величину информацию о возможности реализации риска и уровне его угрозы. Проектная группа может затем использовать эту величину для приоритезации рисков. В простейшем случае количественного анализа рисков ожидаемая величина вычисляется как произведение вероятности риска и его угрозы. Когда для оценки вероятности и угрозы используются шкалы, может быть полезным создать матрицу возможных сочетаний значений этих шкал и разделить риски по категориям – на малые, средние и большие. К примеру при использовании трехзначной шкалы для вероятности и угрозы, возможные значения ожидаемой величины могут быть представлены такой таблицей: Вероятность / Угроза Низкая=1 Средняя=2 Высокая=3 Высокая=3 3 6 9 Средняя=2 2 4 6 Низкая=1 1 2 3 Преимущество табличной формы представления уровней рисков заключается в том, что в отчетах для спонсоров и других заинтересованных лиц различные группы рисков могут быть выделены различными цветами. Например, красным – большие риски (в правом верхнем углу), желтым – средние риски вдоль диагонали, и зеленым – малые риски в нижнем левом углу. Такое разделение очень четко и легко понимаемо (“большой риск” воспринимается легче, чем “большая ожидаемая величина”). Дополнительные количественные методики Поскольку конечной целью анализа рисков является помощь в принятии необходимых проектных решений, должен быть выбран метод приоритезации рисков, подходящий для данного проекта и удобный для проектной группы, заинтересованных лиц, совместимый с существующей корпоративной инфраструктурой управления рисками (средствами и процессами). В некоторых проектах может быть уместным использование взвешенных многопараметрических методов в целях учета таких дополнительных факторов, как временные ограничения, величина потенциально возможной выгоды, надежность вероятностных оценок, величина материальных или информационных активов и т.д. Ниже в таблице представлен пример такой взвешенной матрицы приоритезации, вычисляемой по формуле: Ожидаемая величина риска = 0.5(вероятность X угроза) – 0.2(срок)+0.3(затраты на реализацию X вероятность успешного управления), учитывающей не только вероятность и угрозу риска, но также временные границы и затраты на эффективное управление. Этот метод позволяет учесть в ожидаемой величине риска критичность временного ограничения (необходимого срока осуществления плана по управлению и смягчению) и стоимость и эффективность плана. Таким образом, эти факторы окажутся принятыми во внимание в процессе принятия решения. Такой обобщенный подход позволяет ~23~ проектной группе приоритезировать риски с учетом любой поставленной в проекте цели. Ожидаемая Вероятность величина риска Угроза (в тыс. дол.) Срок (when needed) (недели) Затраты на Вероятность реализацию успешного (в тыс. управления дол.) 125.025 0.5 500 1 2 0.5 83.596 0.84 200 4 4 0.33 37.64 0.33 200 2 20 0.84 4.9816 0.33 30 4 3 0.84 Выбор “правильного” метода либо сочетания методов зависит от разумности той или иной формы компромисса между затратой усилий на анализ рисков и опасностью ошибочной или нечеткой приоритезации. Всегда следует помнить, что анализ не самоценен – он нужен для принятия правильных решений. Поэтому на количественные подходы к приоритезации рисков следует смотреть в контексте имеющихся бизнесцелей, возможностей и проверенных управленческих методик. Принимаемые решения не должны автоматически диктоваться полученными количественными оценками приоритетов. Результаты Анализ рисков предоставляет проектной группе приоритезированный список рисков, который необходим на этапе планирования. Дисциплина управления рисками MSF называет его главной таблицей рисков (master risk list). Детальная информация о рисках, включающая в себя условия проекта, контекст, первопричину риска, использованные в процессе анализа значения оценочных величин и др., может быть вынесена для каждого риска в отдельный документ. Главная таблица рисков Главная таблица рисков содержит условие возникновения риска, потенциальный эффект риска (последствие) и информацию, используемую для приоритезации (такую как вероятность, угроза и ожидаемая величина). Будучи отсортированной по убыванию ожидаемой величины рисков (или по иному критерию, используемому для ранжирования), эта таблица служит базисом для приоритезации рисков на этапе планирования. Пример главной таблицы рисков при использовании двухпараметрической оценки (вероятность и угроза) приведен ниже. Приоритет Причина Последствие Вероятность Угроза Ожидаемая величина 1 Затянутый временной график проекта Потеря финансирова ния в конце года 80% 3 2.4 2 Отсутствие стандартов кодирования для нового Выпуск продукта, содержащего ошибки 45% 2 0.9 ~24~ языка программирования Отсутствие спецификации требований в письменном виде 3 Некоторые требования не будут реализованы 30% 2 0.6 Малая угроза = 1, средняя угроза = 2, сильная угроза = 3 Ожидаемая величина = Вероятность Х Угроза Уровень детализации главной таблицы рисков соответствует уровню детализации изначального списка рисков. Эта таблица является ”живым” документом, лежащим в основе непрерывного процесса управления рисками. Она должна постоянно корректироваться и дополняться на протяжении этапов анализа, планирования и мониторинга. Главная таблица рисков – это фундаментальный документ, обеспечивающий активный и превентивный процесс управления рисками. Она помогает проектной группе в принятии решений, предоставляя основу для: процесса приоритезации; выявления критических мер, которые необходимо предпринять; выявления взаимозависимостей. Ниже приведен список элементов, включаемых в главную таблицу рисков. Метод, использованный для определения ожидаемой величины риска, должен быть четко описан в плане управления рисками. Производимые в нем вычисления должны отражать точку зрения проектной группы на оценку важности различных факторов. Элемент Назначение Обязательность Формулировка риска Четкое описание риска Обязателен Вероятность Количественная мера возможности Обязателен Угроза Количественная мера серьезности убытка или стоимости потенциальной возможности Обязателен Критерий приоритезации Единая мера значимости Обязателен Приоритет Приоритезация управления Обязателен Ответственное лицо Обеспечение проведения плановых мероприятий касательно риска Обязателен План предотвращения Описание превентивных мер Обязателен ~25~ План реагирования (смягчения последствий) и его триггеры Описание исправительных мероприятий Обязателен Первопричина Исходная посылка появления риска Желателен Приносимый ущерб Обеспечение корректности оценки угрозы Желателен Контекст Исходные соображения проектной группы при выявлении риска Желателен Время для реализации Принципиальные временные ограничения на реализацию плановых мероприятий Желателен Прочие методы проведения анализа Некоторые проектные группы могут включить в свою деятельность дополнительные уровни анализа для обеспечения лучшего понимания рисков проекта. Необходимые дополнительные методики описываются в учебниках по менеджменту и управлению рисками28,29. Такие приемы как анализ деревьев решений, причинный анализ, анализ по Парето, имитация и анализ чувствительности практически доказали свою эффективность для количественного оценивания рисков. Решение о применении этого дополнительного инструментария должно быть основано на уверенности проектной группы в том, что его вклад в процесс приоритезации или планирования окупит дополнительные расходы. Документ описания риска Во время анализа риска (как и во время последующего планирования относящихся к риску мероприятий) удобно свести всю информацию, имеющую отношение к данному риску, в один документ, называемый документом описания риска (risk statement form). Этот документ обычно содержит данные из главной таблицы рисков, которые дополняются информацией, необходимой для проведения процесса управления риском. Документы описания рисков уместно рассматривать отдельно от главной таблицы рисков в случае, если плановые мероприятия по управлению рисками поручены не входящим в проектную группу лицам или коллективам. В следующей таблице представлена информация, которую проектная группа должна учесть при составлении документа описания риска. Элемент Назначение Идентификатор риска Уникальное имя риска (используется для мониторинга и отчетности) Источник риска Общее указание на исходный фактор риска (используется для поиска первопричин) Условие возникновения риска Описание существующего условия/причины потенциального убытка (первая часть формулировки ~26~ риска) Последствие риска Описание негативного эффекта, возникающего при реализации риска (вторая часть формулировки риска) Вероятность риска Вероятностная величина больше 0, но меньше 100%, указывающая на “шансы” реализации риска Классификация угрозы риска Общая характеристика типа воздействия, которое может оказать риск Угроза риска Количественная мера угрозы риска. Может представлять собой как денежную величину, так и просто значение из некоторой принятой шкалы оценки угрозы Ожидаемая величина риска Общая мера важности риска, принимающая во внимание как вероятность риска, так и его угрозу Контекст риска Дополнительная информация, проясняющая природу риска и связанные с ним обстоятельства Связанные риски Перечень идентификаторов других рисков, находящихся с данным риском в какой-либо зависимости Список главных рисков Анализ рисков дает оценку значимости каждого из них, что помогает решить, какие именно риски заслуживают внимания. Управление рисками требует временных и иных затрат и “отвлекает” сотрудников от другой деятельности, поэтому проектной группе важно выделить именно те из рисков, управление которыми абсолютно необходимо. Выделение списка главных рисков - простой способ проведения эффективного мониторинга. Список главных рисков должен быть доступен для всех заинтересованных сторон и может включаться в документы отчетности, такие как описание и рамки проекта (vision/scope document), план проекта (project plan) и отчеты о текущем состоянии проекта (project status reports). Обычно проектная группа выявляет ограниченное число главных рисков, над которыми следует вести работу (для большинства проектов не более 10) и выделяет ресурсы именно на них. Даже если у проектной группы возникает намерение управлять более чем 10-ю главными рисками, имеет смысл сконцентрироваться только на самых главных рисках, и лишь после того, как они взяты под контроль, переходить к менее критичным. По окончании приоритезации рисков проектная группа должна сконцентрироваться на выработке стратегии управления и включении соответствующих планов в общий план проекта. Деактивация рисков Риски могут быть деактивированы – признаны несущественными на данный момент. Это позволяет проектной группе сосредоточиться на других рисках, действительно требующих активного управления. Классификация риска как несущественного означает, что проектная группа сочла неоправданными какие-либо затраты усилий на его мониторинг. Решения по деактивации принимаются на этапе анализа рисков. ~27~ Некоторые риски деактивируются в силу их неправдоподобности, т.е. практически стабильной нулевой вероятности. Другие могут быть деактивированы, так как имеют очень малую угрозу, т.е. более выгодным оказывается принятие возможного ущерба, нежели затраты усилий на управление. Заметим, что не рекомендуется деактивировать риски, угроза которых выше определенного порога, если только проектная группа не является абсолютно уверенной в том, что их вероятность (а, следовательно, и ожидаемая величина) останется низкой при любых непредвиденных обстоятельствах. Также заметим, что деактивация рисков не тождественна их разрешению. При определенных обстоятельствах деактивированный риск может появиться вновь, и проектная группа решит опять принять его во внимание и осуществлять управление им. Планирование рисков Введение Рисунок 5. Планирование рисков На этапе планирования рисков (третьем этапе процесса управления рисками), основываясь на имеющейся таблице главных рисков, происходит построение планов конкретных действий. Планирование (planning) включает в себя разработку детальных стратегий и мероприятий в отношении каждого из главных рисков, приоритезацию этих мероприятий и создание сводного плана управления рисками. Последующее календарное планирование (scheduling) включает в себя интеграцию задач управления рисками в общий календарный график проекта. Задачи из плана управления рисками ~28~ поручаются определенным членам проектной группы, и их выполнение подвергается активному мониторингу. Этот этап схематически изображен на рис. 5. На этом шаге в главной таблице рисков фиксируется дополнительная информация о наиболее приоритетных и значимых рисках. Иногда удобнее вынести эту информацию в отдельные документы, используемые членами проектной группы, ответственными за соответствующие риски. Цели Основная цель шага планирования рисков – разработка детальных планов управления главными рисками, выявленными во время анализа, и обеспечение исполнения этих планов посредством их интеграции в общие процессы управления проектом. Исходные данные Дисциплина управления рисками MSF предполагает тесную интеграцию процесса планирования рисков с другими стандартными проектными процессами планирования и обеспечивающими их средствами. Исходные данные процесса планирования рисков включают в себя не только главную таблицу рисков, список главных рисков и базу знаний о рисках, но также общие проектные планы вместе с календарными графиками проекта. Мероприятия При разработке планов по сокращению ожидаемой величины риска: концентрируйте внимание на рисках с большой ожидаемой величиной; для понижения вероятности направляйте свою деятельность на причину риска; ищите первопричины, а не боритесь с симптомами; для сокращения угрозы направляйте свою деятельность на последствие; после определения первопричины, ищите схожие риски, которые могут следовать из анализируемой первопричины; помните о взаимозависимостях и взаимодействиях рисков. Некоторые подходы, применимые к сокращению рисков: используйте доступные ресурсы для сокращения тех рисков, с которыми проектная группа в состоянии справиться сама; для рисков, находящихся вне контроля проектной группы, найдите возможные обходные пути для их сокращения или передайте управление этими рисками лицам, имеющим необходимые полномочия (эскалация). Планируя конкретные действия, проектная группа должна рассмотреть шесть следующих возможных подходов: Исследование (research). Достаточно ли мы знаем о данном конкретном риске? Должны ли мы лучше изучить его, чтобы получить о нем больше информации и определить его характеристики до того, как мы предпримем какие-либо действия? ~29~ Принятие (accept). Можем ли мы пережить последствия риска, если они всетаки наступят? Можем ли мы принять риск и не предпринимать по этому поводу никаких дальнейших действий? Избежание (avoid). Можем ли мы избежать риска, изменив способ действия? Перенос (transfer). Можем ли мы перенести риск на другой проект, проектную группу, организацию или частных лиц? Предотвращение (mitigation). Можно ли сделать что-то заранее для уменьшения вероятности риска или его угрозы? Смягчение последствий (реагирование, contingency). Может ли угроза риска быть уменьшена путем планирования некоторой реакции на него? Исследование Многие из рисков связаны с неопределенностями, порожденными неполной информированностью. Они могут быть эффективно разрешены после дополнительного изучения связанной с ними предметной области. Например, до окончания составления плана проектная группа может принять решение о проведении маркетингового исследования, чтобы больше узнать об имеющихся у пользователях базовых навыках и об их желании использовать новые технологии. В случае решения о проведении исследований план управления риском должен включать в себя описание этих исследований, включая формулировки проверяемых гипотез и изучаемых вопросов, необходимое кадровое обеспечение и лабораторное оборудование. Принятие Природа некоторых рисков такова, что лучшим решением является их принятие для реализации открываемых ими возможностей, так как просто не существует эффективных превентивных или коррективных мер. Принятие не есть бездействие. План управления рисками должен включать в себя обоснование того, почему проектная группа избрала принятие риска, а не выработку мер по его предотвращению и смягчению последствий. Имеет смысл продолжить мониторинг таких рисков на случай изменения их вероятности, угрозы или появления новой возможности управления. Для обеспечения мониторинга должны быть выделены необходимые ресурсы, и он должен основываться на метриках, установленных в рамках процесса по управлению рисками проекта. Избежание Возможно, выявленный риск может быть разрешен наилучшим образом некоторыми изменениями в самом проекте (его рамках, scope), исключающими существование риска. В таком случае план управления рисками должен включать в себя обоснование изменения, и оно должно быть также отражено в плане самого проекта. Кроме того, должны быть инициированы мероприятия, необходимые для претворения принятого изменения в жизнь. Перенос Иногда возможно передать управление риском третьей стороне, непосредственно не участвующей в проекте. Примерами таких случаев являются: страхование; ~30~ найм сторонних консультантов с большим опытом работы; покупка готовой компоненты вместо ее создания собственными силами; привлечение внешних субподрядчиков. Перенос риска не обязательно означает его исчезновение. В общем случае перенос риска породит другие риски, требующие превентивного управления, но имеющие приемлемый уровень. Например, привлечение внешнего консультанта может перенести технологические риски за пределы проектной группы, но породит риски в областях управления и бюджетирования. Предотвращение План предотвращения риска описывает меры и мероприятия, осуществляемые заблаговременно для предотвращения риска или сокращения его угрозы или последствий до приемлемого уровня. Предотвращение риска, в отличие от избежания, концентрируется на его снижении до приемлемого уровня (избежание означает изменение проекта с целью этот риск обойти). Главная цель предотвращения риска – снижение его вероятности. Например, некоторое дополнительное количество подключений к Internet сокращает риск полной потери доступа в глобальную сеть. Не для каждого риска есть эффективная стратегия предотвращения. В таких случаях целесообразно спланировать меры по смягчению последствий риска. Смягчение последствий (реагирование) Планирование мер по смягчению последствий риска заключается в создании запасных планов на случай, если превентивные меры по предотвращению негативных последствий не достигнут цели. Такие планы необходимы для всех рисков, включая те, для которых разработаны планы по предотвращению. Они предусматривают действия на случай реализации риска и должны минимизировать влияние последствий. Чтобы быть эффективными, эти планы должны быть разработаны заблаговременно. Проектная группа может установить триггер (trigger) (условие применения плана реагирования) на основании типа самого риска и того влияния, которое он оказывает. Существует два типа триггеров: Триггеры момента времени устанавливаются в привязке к датам (обычно, наипозднейшим), вплоть до которых нечто существенное должно произойти. Триггеры уровня опираются на какие-либо измеряемые или наблюдаемые параметры. Проектная группа должна как можно раньше согласовать триггеры планов реагирования с руководством, чтобы не возникли задержки с выделением бюджетных и других ресурсов для реализации этих планов. Календарное планирование Календарное планирование (scheduling) относящейся к рискам деятельности должно следовать стандартным методикам, рекомендованным MSF30 для календарного планирования проекта. Важно, чтобы проектная группа понимала, что мероприятия по управлению рисками – это неотъемлемая часть всякого проекта, а не дополнительная работа, осуществляемая на добровольных началах. Вся деятельность, связанная с ~31~ рисками, должна быть включена в календарный план проекта и подчиняться стандартным процедурам отчетности. Результаты Результатом этапа планирования риска должен быть четко построенный план действий, использующий один из шести детально рассмотренных выше подходов. Шаги, реализующие эти планы, должны быть интегрированы в общий план проекта и его календарный график. Это включает в себя специфицирование количества выделяемых ресурсов, расписания и задач, определяющих действия членов проектной группы. Главная таблица рисков должна быть дополнена описаниями планов по предотвращению и реагированию и иной необходимой информацией. Деятельность по управлению рисками Относящаяся к рискам деятельность должна регистрироваться и контролироваться подобно любой другой деятельности в проекте, поскольку ее важность не уступает важности какой-либо иной работы. Как и все остальные мероприятия, относящиеся к рискам задачи должны иметь дату обязательного завершения и быть разбиты на персональные задания. Таким образом, не должно возникать разногласий о том, кто за что ответственен. Документирование планов Проектная группа должна разработать уточненные планы для каждого из главных рисков, включающие действия по предотвращению и смягчению последствий, триггеры и детальное описание всех необходимых шагов. Информация, которую проектная группа может принять во внимание, документируя планируемые действия, включает в себя следующее: Идентификатор риска. Уникальное имя риска (для мониторинга и отчетности). Формулировка риска. Описание риска на естественном языке, включая ведущее к потерям условие и сами эти потери (последствия), которые возникнут, если риск превратится в проблему. Стратегия предотвращения риска. Один или два абзаца текста, описывающих стратегию проектной группы по предотвращению этого риска, включая все сделанные допущения. Метрика предотвращения риска. Метрика, которая будет использоваться проектной группой для определения успеха мероприятий по предотвращению риска. Планируемые действия. Список мероприятий, которые проектная группа должна осуществить для реализации стратегии управления риском, включая даты обязательного завершения этих мероприятий и информацию о персональной ответственности за них. Стратегия смягчения последствий. Один или два абзаца, описывающих стратегию команды в случае, если меры по предотвращению риска не оказали должного эффекта. Эта стратегия будет реализовываться после срабатывания триггера плана смягчения последствий. ~32~ Триггеры планов реагирования (смягчения последствий). Критерии, используемые проектной группой для определения условий начала осуществления плана смягчения последствий. Метрика реагирования. Метрика, используемая проектной группой для определения эффективности стратегии реагирования. Ответственность. Ролевой кластер и отдельные лица, ответственные за осуществление запланированных действий. Обновление плана и календарного графика проекта Документы планирования рисков должны быть интегрированы с общим планом проекта, и запланированные действия должны быть включены в его календарный график. Мониторинг рисков Рисунок 6. Мониторинг рисков Мониторинг рисков (risk tracking) – это четвертый шаг процесса управления рисками MSF. Он важен для эффективной реализации запланированных действий. Мониторинг обеспечивает своевременное исполнение превентивных мер и планов по смягчению последствий. Первоочередная деятельность проектной группы на этом этапе – ~33~ наблюдение за количественными параметрами рисков и условиями их триггеров с целью отслеживания моментов “включения” запланированных по отношению к риску действий. Мониторинг – это наблюдательная деятельность, предусмотренная составленным ранее планом управления рисками. Процесс мониторинга схематически показан на рис. 6. Цели Цели фазы мониторинга рисков: наблюдение за прогрессом в выполнении принятых планов (предотвращения рисков и смягчения их последствий) и количественными параметрами (метриками), приводящими в действие триггеры планов смягчения последствий, а также информирование проектной группы о необходимости осуществления планов реагирования в случае активации соответствующих им триггеров. Исходные данные Основными исходными данными для мониторинга являются: Подготовленные ранее планы действий в отношении рисков, содержащие описание шагов по предотвращению и смягчению последствий, а также специфицирующие характеристики и количественные триггеры, подлежащие мониторингу. Любые необходимые отчеты о ходе проекта (из числа используемых для оценки прогресса проекта в рамках стандартной схемы управления проектом). В зависимости от того, к каким количественным параметрам проектная группа применяет мониторинг, могут быть использованы различные дополнительные источники информации. В их число входят базы данных мониторинга проектов, хранилища исходного кода программ и системы регистрации рабочего времени. Даже такие источники, как базы данных отделов кадров, могут быть полезны в получении необходимой для мониторинга информации. Мероприятия по мониторингу Во время фазы мониторинга проектная группа в процессе своей повседневной работы воплощает в жизнь планы по предотвращению рисков. За прогрессом этой деятельности ведется наблюдение. Также производится наблюдение за изменениями значений триггеров рисков. Все это отражается в отчетах, составляемых для каждого из рисков. Примеры параметров, к которым могут быть привязаны триггеры, и за которыми может проводиться постоянное наблюдение: Количество “открытых” (найденных и неисправленных) ошибок на один модуль или компонент. Среднее за неделю количество сверхурочных часов работы на одного сотрудника. Еженедельное количество изменений в требованиях к разрабатываемой системе. ~34~ Отчетность о состоянии рисков Отчетность о рисках должна осуществляться на двух уровнях. Внутри проектной команды регулярные отчеты о состоянии рисков должны рассматривать четыре возможные ситуации для каждого риска: Риск разрешен, т.е. план действий в отношении этого риска выполнен. Предпринимаемые действия идут в соответствии с разработанным планом. В этом случае они должны быть в соответствии с ним продолжены. Некоторые действия отклоняются от намеченного плана. В этом случае должны быть приняты корректирующие меры. В отношении одного или нескольких рисков ситуация существенно изменилась. Как правило, это должно означать повторное проведение шагов анализа и планирования. В отчетах, представляемых “внешним” заинтересованным сторонам, проектная группа должна докладывать о главных рисках и затем резюмировать состояние дел по управлению ими. Также полезно бывает показать, какими были приоритеты рисков в предшествующих отчетных периодах, как они изменялись, и сколько раз каждый из рисков находился в списке главных рисков. По мере осуществления управления рисками общий уровень ожидаемой величины рисков проекта должен приближаться к приемлемому значению. Результаты Цель отчета о состоянии риска – информирование о происходящих изменениях в статусе риска и о прогрессе в осуществлении планов по его предотвращению. Сведения, которые полезно указать в отчете: Наименование риска. Классификация риска (к какой области проекта относится). Исходные оценки вероятности, угрозы и ожидаемой величины. Текущие оценки вероятности, угрозы и ожидаемой величины. Уровень риска (низкий, средний, высокий). Краткое изложение планов предотвращения и смягчения последствий. Состояние плана предотвращения (завершенные мероприятия). Готовность плана по смягчению последствий. Состояния триггеров. Планируемые действия. Лицо, ответственное за риск. Цель сводного отчета о рисках, направляемого руководству или внешним заинтересованным сторонам, – доклад об общем состоянии рисков проекта. Полезно включить в такой отчет следующую информацию: Наименование проекта. Уровень риска в различных составляющих проекта. ~35~ Тенденции изменений в рисках. Сводка планов по предотвращению и смягчению последствий. Такой отчет обычно включается в общий отчет о состоянии проекта. Корректирование ситуации Пятый шаг процесса управления рисками MSF – корректирование ситуации (risk control) - предполагает осуществление мероприятий, предусмотренных планами смягчения последствий тех рисков, для которых сработали соответствующие триггеры. Процесс корректирования ситуации изображен на рис. 7. Рисунок 7. Корректирование ситуации Инициирование корректирующих действий основывается на информации, полученной во время процесса мониторинга. MSF рекомендует использование существующих стандартных механизмов управления проектом для планирования контроля рисков; корректировки отклонений от планов; реакции на достижение триггерных условий. ~36~ Результаты и уроки, извлеченные из плановых мероприятий по смягчению последствий, включаются затем в отчет о ходе выполнения планов и их результатах. Таким образом соответствующая информация становится частью проектной/корпоративной базы знаний о рисках. При этом необходимо охватить как можно больше информации о возникших проблемах и о деталях осуществления плана, что важно для определения эффективности примененного подхода. Цель Цель этапа корректирования ситуации – успешное выполнение выработанных ранее проектной группой планов по смягчению последствий главных рисков. Исходные данные Исходными данными для шага корректирования ситуации являются документы, детально описывающие действия проектной группы, запланированные в отношении рисков, а также отчеты о состоянии рисков, указывающие на активацию триггеров. Действия по корректированию ситуации Действия по корректированию ситуации должны использовать стандартные механизмы и средства управления проектом для инициации, мониторинга и оценки прогресса выполнения соответствующих планов. Специфика деталей планов может варьироваться от проекта к проекту, но отчетность о ходе выполнения планов должна следовать общим процедурам. Необходимо постоянно повторять шаг выявления новых рисков, чтобы вовремя обнаружить возникающие вторичные риски и риски, возрастающие в силу исполнения планов по смягчению последствий других рисков. Результаты Результатом шага корректирования ситуации является стандартный отчет о состоянии проекта, документирующий прогресс выполнения планов по смягчению последствий рисков. Полезно также кратко изложить извлеченные уроки (например, что возымело действие, а что показало свою неэффективность). Если изменения в текущей картине рисков могут потребовать привлечения дополнительных ресурсов или повлечь изменения в объеме работ и длительности проекта, то должен быть инициирован запрос соответствующего изменения (change control request) (это относится к проектам, использующим формальные процедуры управления изменениями). Извлечение уроков из рисков Введение Извлечение уроков (learning from risk) – это шестой, заключительный, шаг процесса управления рисками MSF. Он позволяет стратегически оценить мероприятия по управлению рисками с точки зрения предприятия (организации). Этот шаг иногда называют “отдачей от рисков”, подчеркивая все то ценное, что организация приобретает – новые навыки, зрелость проектной группы и организации в целом, совершенствование процесса управления и др. Извлечение уроков может быть начато в любой момент и должно идти непрерывно на протяжении всего процесса управления рисками MSF. На этом шаге важно сконцентрироваться на трех ключевых целях: ~37~ Контроль текущего процесса управления рисками, позволяющий проектной группе регулярно получать обратную связь. Обмен накопленным опытом с другими проектными группами, особенно в отношении выявления рисков и успешных стратегий их предотвращения. Это позволит пополнять существующую базу знаний о рисках. Усовершенствование процесса управления рисками на основе отзывов и пожеланий проектной группы. ~38~ Рисунок 8. Извлечение уроков Для обмена опытом организовывают совещания, посвященные рассмотрению рисков. Они должны проводиться регулярно и, как и все другие совещания в рамках MSF, планироваться заблаговременно, с выработкой ясной и общеизвестной повестки дня. В них должны принимать участие все заинтересованные лица; атмосфера, в которой они ~39~ проходят, должна быть максимально доброжелательной и демократичной. Шаг извлечения уроков схематически представлен на рис. 8. Типы извлекаемых уроков Классификация рисков – мощное средство обеспечения доступности извлеченных из предыдущего опыта уроков для тех проектных групп, которые будут осуществлять оценку рисков в будущем. Двумя аспектами извлечения уроков, затрагивающими классификацию рисков, являются: Новые риски. Если проектная группа столкнулась с проблемой, риск возникновения которой не был выявлен изначально, необходимо проанализировать, существовали ли какие-либо предпосылки ее предсказания, т.е. обнаружения риска. Возможно, существующие списки рисков нуждаются в обновлении, чтобы эффективнее выявлять признаки такого риска в будущем. Если был найден новый риск, его необходимо внести в корпоративную базу знаний. Успешные стратегии предотвращения рисков. Другой принципиальный момент, который необходимо усвоить в качестве урока – это опыт успешных (или даже неуспешных) стратегий предотвращения рисков. Использование устоявшихся классификаций рисков предоставляет разумный метод группирования схожих рисков. В силу этого проектным группам не составляет труда детально изучить стратегии управления рисками, ранее приводившие к успеху. Управление извлечением уроков Организации, использующие методики управления рисками, зачастую находят необходимым применение классификационного подхода к управлению рисками проекта. При его использовании полезно следовать следующим правилам: Должен быть назначен человек, лично ответственный за определенные разделы классификации рисков и одобрение изменений в них. Классификации рисков должны учитывать необходимость полного охвата всех имеющихся рисков и при этом не быть чересчур усложненными и неудобными в использовании. Иногда создание нескольких альтернативных классификаций для различных типов проектов помогает существенно упростить их применение. Должна поддерживаться база знаний о рисках, содержащая классификации рисков, их определения, критерии диагностики и системы оценок, а также отзывы использовавших эти знания проектных групп. Процесс анализа опыта должен быть хорошо организован и обеспечивать извлечение всех возможных уроков. Мероприятия по анализу связанного с рисками опыта могут быть проведены совместно с анализом завершившегося проекта, когда результаты управления рисками станут уже для всех очевидными. Контекстная классификация рисков Выявление рисков может быть усовершенствовано выработкой классификаций рисков, учитывающих контекст проекта. К примеру, организация, разрабатывающая проекты, может создать различные классификации для различных типов проектов. По мере ~40~ накопления значительного опыта проектов определенного типа их риски могут быть определены с большей точностью и ассоциированы с успешными стратегиями их предотвращения. База знаний о рисках База знаний о рисках – это формализованный или неформализованный механизм накопления опыта, полезного для осуществления управления рисками в будущем. Не имея такой базы, организация может столкнуться с трудностями при внедрении превентивного управления рисками. База знаний о рисках отличается от базы данных процесса управления рисками, используемой для хранения и мониторинга информации о конкретных рисках, планов по ним и их состоянии в ходе реализации проекта. Достижение зрелости в управлении знаниями о рисках База знаний о рисках – это ключевой фактор постоянного совершенствования управления рисками. На нижнем уровне зрелости рабочие группы не имеют никакой базы знаний. Любая проектная группа начинает каждый раз процесс управления рисками с нуля. В таких условиях управление рисками, как правило, не превентивно – оно производится по факту случившегося – хотя и может достигнуть более высокого уровня активности. На этом уровне проектная группа обычно не осуществляет профилактических мер при управлении рисками. Следующий уровень зрелости включает использование неформализованной базы знаний, представленной, главным образом, знаниями наиболее опытных членов организации. Зачастую это достигается созданием рабочего органа, ответственного за риски, в котором такие лица наблюдают за работой каждой из проектных групп. Подобный подход поощряет активное управление рисками и может обеспечить некоторую степень его превентивности посредством использования определенных инструкций и требований. Вот пример такой инструкции: “Все проекты, длящиеся дольше 20 дней, должны пройти проверку их рискованности до того, как они будут начаты”. Начальный уровень формализации базы знаний о рисках достигается применением более структурированного подхода к выявлению рисков. Дисциплина управления рисками MSF предлагает применять в этих целях классификации рисков. Вводя формализованные процедуры накопления опыта и его систематизации, организация способна достичь значительно более высокого уровня превентивного управления, так как начинают становиться видимыми исходные причины рисков. Зрелые организации накапливают не только опыт обнаружения признаков, указывающих на вероятный риск, но также и стратегии, применявшиеся для управления рисками вместе с данными об их успешности. При таком уровне развития базы знаний шаги по выявлению и планированию рисков могут основываться на опыте большого числа проектных групп. Это позволяет всей организации оптимизировать расходы на управление рисками и увеличить отдачу от инвестирования в проекты. Опыт показывает, что при создании базы знаний о рисках: Ее ценность увеличивается с появлением большего числа схожих процессов (к примеру, организация концентрируется на схожих проектах или повторяющихся бизнес-процессах). ~41~ Когда организация всегда концентрируется только на одном из проектов, становиться возможным поддержание меньшими усилиями более простой базы знаний о рисках. Управление рисками не должно превращаться в механический процесс, устраняющий для проектной группы необходимость размышлений. Даже в повторяющихся ситуациях условия ведения бизнеса, ожидания заказчиков, профессиональные навыки проектной группы и технологии подвержены непрерывным изменениям. Как следствие, проектная группа всегда должна производить оценку стратегий управления рисками с учетом конкретной специфики проекта. Управление рисками как составная часть жизненного цикла проекта Процесс управления рисками в MSF тесно интегрирован с общим жизненным циклом проекта. Оценка рисков может быть начата на этапе выработки концепций, поскольку в этот момент проектная группа и заинтересованные стороны начинают формировать видение проекта, его границ и рамок. С появлением каждого нового ограничения или допущения, связанного с проектом, начинает появляться все больше и больше рисков. Проектная группа должна инициировать мероприятия по обнаружению рисков как можно раньше. По результатам шагов анализа и планирования рисков необходимые планы по предотвращению и смягчению последствий должны быть сразу включены в календарный график проекта и его сводный план. Ход выполнения этих планов должен подвергаться мониторингу в рамках стандартного процесса управления проектом. Хотя процесс управления рисками обычно начинается с календарного планирования этапов изначального выявления и анализа рисков, вслед за этим шаги по планированию, мониторингу и контролю должны выполняться отдельно для каждого из главных рисков. Дисциплина управления рисками MSF подразумевает, что проектная группа постоянно проводит выявление и мониторинг рисков. Группа осуществляет необходимые корректирующие действия в соответствии с расписанием и планом проекта, и при наступлении связанных с триггерами рисков событий. Следует помнить, что на протяжении всего жизненного цикла проекта возникают новые риски, и это требует проведения дополнительных шагов анализа и планирования. Нет никакой необходимости привязывать шаги управления рисками к контрольным точкам (вехам, milestones) проекта. Однако некоторые проектные группы могут начинать выявление и анализ рисков во время таких контрольных точек, так как это удобный повод для оценки состояния проекта. Также в этот момент можно резюмировать извлеченные уроки. В целом, выявление и мониторинг рисков – непрерывная деятельность. Члены проектных групп должны постоянно искать возникающие в проекте риски и предоставлять их на рассмотрение всей командой. Также члены проектных групп постоянно должны следить за ходом выполнения принятых в отношении рисков планов. Шаги анализа (и повторного анализа) рисков, также как и внесение изменений в планы по управлению рисками, чаще всего будут периодическими мероприятиями, проводимыми проектной группой. Иногда они заблаговременно планируются (возможно, с привязкой к контрольным точкам проекта), а иногда являются результатом неожиданного события (например, обнаружения новых рисков во время шагов мониторинга или корректировки). Мероприятия по извлечению уроков из ~42~ полученного опыта чаще всего планируются и проводятся вскоре после главных контрольных точек (вех) проекта и, обязательно, по его окончании. По ходу проекта тип рисков, которым уделяется внимание, также должен изменяться. На ранних этапах доминируют риски связанные с бизнесом, рамками проекта, требованиями к конечному продукту и проектированием этого продукта. С течением времени начинают играть важную роль технологические риски, связанные с реализацией проекта. Затем внимание переходит к рискам поддержки и сопровождения. Для организации деятельности по выявлению рисков в моменты основных фазовых переходов полезно использовать контрольные перечни (checklists) и классификации рисков. Управление рисками на предприятии Для получения максимальной отдачи от затрат на управление рисками важно иметь единое видение процесса управления рисками в масштабе всего предприятия. Создание культуры управления рисками Хотя лишь очень немногие организации отрицают необходимость управления рисками в своих проектах, большинство из них испытывают затруднения при попытках полноценного внедрения превентивного подхода к управлению рисками. Зачастую они могут произвести оценку рисков на начальном этапе каждого проекта, но оказываются не в состоянии продолжить этот процесс на последующих этапах. Двумя основными причинами этого являются: Напряженный временной график работы проектной группы. Опасение, что повышенное внимание к рискам снизит энтузиазм заказчика или даже создаст у него негативное впечатление. Первопричина этих воззрений проста: нередко менеджеры сами не понимают того вклада, который управление рисками вносит в проект. В результате они не выделяют достаточно времени для управления рисками (впрочем, такие менеджеры часто не выделяют достаточно времени и для другой управленческой деятельности). Затем, при возникновении дополнительных временных, бюджетных или иных ограничений, они приносят в жертву прежде всего упомянутые мероприятия по управлению рисками. Поэтому особенно важно удостовериться в том, что все заинтересованные стороны хорошо понимают важность управления рисками. Это дает возможность сформировать культуру, в которой управление рисками занимает достойное место. Практикой многих коллективов подтверждена значимость следующих шагов, направленных на институциализацию управления рисками на предприятии: Обеспечьте поддержку управления рисками со стороны спонсоров. Ищите совета менеджеров, обладающих значительным опытом и глубокими знаниями в области управления рисками. Объясните всем заинтересованным сторонам важность управления рисками и возможные потери в случае его отсутствия. Обучите ядро менеджерского состава управлению рисками. Эти люди смогут предложить ролевые модели и рекомендации для остальных работников. Эффективным подходом к обучению управлению рисками является сочетание теоретических семинаров с практикой, предоставляемой реальными проектами. ~43~ Приглашайте все заинтересованные стороны на мероприятия по анализу опыта, связанного с рисками, и обеспечьте их доступ ко всей отчетности. Введите схему поощрения членов проектной группы, эффективно выявляющих риски и/или работающих над ними. Убедитесь, что проектные группы учитывают риски в календарном планировании и при принятии ключевых решений. Собирайте отзывы заинтересованных сторон проекта об эффективности процесса управления рисками. Регулярно анализируйте и при необходимости пересматривайте этот процесс с целью обеспечения существенности и ощутимости его вклада в проект. Вознаграждайте выявляющих риски членов проектных групп. Управление портфелем проектов Организации, осуществляющие много проектов, могут значительно выиграть от процесса управления рисками, охватывающего весь портфель проектов. Выгода обычно состоит в следующем: Ресурсы и усилия могут быть распределены между проектами в соответствии с возникающими в них рисками. Каждый, кто осуществляет управление рисками на уровне проекта, имеет возможность эскалации своих вопросов и получения “внешнего” для проекта мнения о его рисках. Используя опыт коллег, проектные группы могут быстрее самосовершенствоваться. Для каждого проекта осуществляется контроль процесса управления рисками. Заметим, что анализ рисков в рамках всего портфеля дополняет оценку рисков, производимую каждой из проектных групп. Проводящая анализ рисков портфеля группа не имеет должных знаний о конкретном проекте, чтобы определить его риски. Также она не обладает временем, необходимым для проведения мер по предотвращению рисков. Однако эта группа может внести свой вклад в анализ и планирование рисков. Поскольку упомянутая аналитическая группа обычно состоит из более опытных менеджеров, ее члены могут использовать свои знания для помощи проектным группам в определении значимости тех или иных рисков в процессе приоритезации. Эти менеджеры могут также рекомендовать эффективные и проверенные опытом стратегии предотвращения рисков и смягчения их последствий. Ниже приводятся рекомендации по управлению рисками портфеля проектов: Заручитесь поддержкой исполнительного руководства компании. Регулярно предоставляйте “наверх” отчеты о новых данных и извлеченных уроках, полученных в процессе анализа рисков портфеля проектов. Планируйте собрания заблаговременно. В идеале, планируйте их регулярно в такие дни, когда смогут присутствовать большинство руководителей проектов. Заблаговременно приглашайте аналитическую группу – хорошие аналитики имеют много других обязанностей. ~44~ Тщательно выбирайте проекты, представляемые на анализ. Вы можете исходить из ежемесячного графика анализа больших проектов, но нужно также обеспечить регулярный анализ широкого спектра проектов средней величины. Устанавливайте фиксированный круг вопросов, рассматриваемый по каждому из проектов. Таким образом руководители проектов будут знать, что ожидать от проводимых собраний. Например, 20 минут выделяется на доклад о текущих оценках рисков, затем 20 минут идет обсуждение стратегий по предотвращению и смягчению последствий, а затем делается 5-ти минутный обзор извлеченных уроков для обмена опытом с другими проектными группами. Используйте стандартизированную документацию отчетности. Убедитесь, что все документы розданы всем участникам собрания заблаговременно. Это позволит сократить трату времени. Стимулируйте посещение аналитических совещаний руководителями внутрипроектных групп – либо лично, либо по телефону (т.н. “селекторное” совещание). Убедитесь, что проводимые встречи приносят проектным группам пользу. Часто это может быть достигнуто анализом прогресса в тех вопросах, которые, в узком понимании, не являются рисками, но где опыт аналитической группы способен помочь проектной группе. Избегайте персональных порицаний за сложившуюся в проекте ситуацию. Позволяйте каждому члену проектной команды сделать заявку о рассмотрении их проекта. Заключение Дисциплина управления рисками MSF отстаивает превентивный структурированный подход к управлению рисками разработки и внедрения программного обеспечения. Процесс управления рисками MSF состоит из шести логических шагов (выявление, анализ, планирование, мониторинг, корректирование и извлечение уроков), которые должны постоянно выполняться проектной группой в течение жизненного цикла проекта. Фаза извлечения уроков служит для обмена опытом, связанным с рисками проекта, и для повышения эффективности управления рисками предприятия путем пополнения общей базы знаний о рисках. Информация, содержащаяся в настоящем документе, представляет текущую точку зрения корпорации Майкрософт по обсуждаемым вопросам на момент публикации. В условиях меняющейся рыночной конъюнктуры, требующей соответствующей корректировки ведущихся разработок, данную информацию не следует рассматривать в качестве какого бы то ни было обязательства со стороны Майкрософт; корпорация не может гарантировать точность информации, представленной после даты публикации. Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ. На пользователе лежит ответственность за соблюдение всех применимых в данном случае законов об авторском праве. В целях обеспечения авторских прав никакая часть настоящего руководства ни в каких целях не может быть воспроизведена или передана в какой бы то ни было форме и какими бы то ни было средствами (электронными или ~45~ механическими, включая фотокопирование и запись на магнитный носитель), если на то нет письменного разрешения корпорации Майкрософт. Предмет данного руководства может быть защищен патентами, патентными заявками, товарными знаками, авторским правом или иным образом в пользу корпорации Майкрософт. Данный документ не дает разрешения на использование этих патентов, товарных знаков или авторского права, если таковое не оговорено явным образом в каком-либо лицензионном соглашении корпорации Майкрософт. © Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены. Microsoft является охраняемым товарным знаком корпорации Майкрософт в США и других странах. Названия компаний или продуктов, указанные здесь, могут быть товарными знаками соответствующих владельцев. Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf . MSF Process Model v. 3.0, 2002 (доступно на http://www.microsoft.com/msf/) Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Carnegie-Mellon University, 1996). 3 Ronald P. Higuera, “Team Risk Management: A New Model for Customer-Supplier Relationships”, SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University), 1994. 4 Encarta 2002, Статья “Insurance. II. Reasons for Insurance”. 5 Jim McCarthy, Dynamics of Software Development (Redmond, Washington: Microsoft Press, 1995), page 99. 6 Восемь принципов – это: 1. ожидайте изменений – проявляйте гибкость (expect things to change – stay agile); 2. вырабатывайте общее видение (work toward a shared vision); 3. концентрируйтесь на бизнес-ценностях (focus on delivering business value throughout the life cycle); 4. инвестируйте в качество (invest in quality); 5. извлекайте уроки из любого опыта – и положительного, и отрицательного (learn from all experiences – good and bad); 6. поощряйте открытое общение (foster open communication); 7. распределенная ответственность, фиксированная отчетность (clear accountability, shared responsibility); 8. команда, наделенная полномочиями (empowered team). 7 MSF Team Model 3.0 Whitepaper (http://www.microsoft.com/msf/). 8 См. более детальное рассмотрение в MSF 3.0 Process Model Whitepaper, доступно на http://www.microsoft.com/msf/ 9 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report CMU/SEI-96TR-012 ESC-96-012 (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University, 1996). 10 К примеру, Steve McConnell, Software Project Survival Guide, (Redmond, WA: Microsoft Press), 1998. 11 Barry W. Boehm, Software Risk Management, (New York, NY: IEEE Press), 1989. 12 Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13741406-4 13 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report, 1996. 14 Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91. 15 Thomas R. Peltier, Information Security Risk Analysis, (Boca Raton: Auerbach Publications, 2001). 16 Donald L Pipkin, Information Security: Protecting the Global Enterprise, (Newark, NJ: Prentice Hall, 2000). 17 http://seir.sei.cmu.edu/ 18 Одна из эффективных методик мозгового штурма для обнаружения первопричины называется “Пять почему”. Согласно этому подходу, команда должна поставить вопрос “Почему это так?” по отношению к условию риска, дать ответ и циклически повторить “Почему это так? - Потому что ...” до пяти раз. 1 2 ~46~ Это может быть достигнуто вариацией методики “5 почему”, при которой команда циклически повторяет вопрос-ответ “Что тогда?..Тогда будет...” до пяти раз. 20 Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Carnegie Mellon University, 1996). 21 Linda H Rosenberg , Theodore Hammer , Albert Gallo, Continuous Risk Management at NASA, 1999 (http://satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html) 22 MSF Risk Management Process Whitepaper, 2001. 23 Principles of Application Development- Course 593 and Course 1517. 24 Rosenberg LH, et al., 1999. 25 Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Ch. 4, “Identify Risk”. 26 Dorfee AJ, et al, 1996. 27 Elaine Hall, Managing Risk, p. 101. 28 Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Chapter 11. 29 Elaine Hall, Managing Risk. 30 См. MSF 3.0 Project Management Discipline, доступно на: http://www.microsoft.com/msf/ 19 ~47~