Рекомендации стандартов на тему как управлять рисками проектов не следует принимать как догму. Каждый конкретный проект уникален и требует адаптации теоретических положений к его условиям. В значительной мере это касается и управления рисками проекта.
Как следует из PMI PMBoК, риск — это неопределенное событие или условие, которое может повлиять на цели проекта. У рисков имеются свои источники и последствия. Риски отличаются от проблем и трудностей, так как имеют отношение к будущим, потенциально возможным негативным результатам. Проблемы же и трудности представляют собой нечто, имеющее место в настоящее время. Риски могут стать проблемами, если ими эффективно не управлять. При реализации любого ИТ-проекта особое внимание требуется уделять разработке и применению методов управления рисками.
Для управления рисками в проектах используются процедуры идентификации рисков, их качественная и количественная оценка. Еще на этапе формирования плана проекта осуществляется прогнозирование ситуаций, чтобы предупредить риски и разработать план реагирования на них.
Как управлять рисками? Управление рисками подразумевает действия для достижения целей управления рисками. Для компаний целями управления рисками могут быть повышение рентабельности бизнеса, повышение конкурентоспособности и т. п. В нашем случае — это выполнение ИТ-проекта качественно, в установленные сроки, в рамках бюджета с сохранением логических рамок работ. При этом надо понимать, что процесс этот далеко не линейный. Практически все его этапы связаны между собой, и по завершении почти любого из них может выявиться необходимость возврата к предыдущему.
По достижении целей управления рисками выполнение мероприятий может быть продолжено в интересах поддержания заданного уровня управления существующими рисками или для обнаружения новых рисков. Повторение этапов образует жизненный цикл управления рисками и не заканчивается при завершении ИТ-проекта (сдача системы в промышленную эксплуатацию, создание ИТ-инфраструктуры компании и пр.), а выходит на новый виток развития.
Рассмотрим пример подхода к управлению проектными рисками.
Идентификация рисков
В первую очередь необходимо определить риски, которые способны повлиять на проект, то есть их идентифицировать. Для этого полезно не только использовать прежний опыт, но и привлечь участников проекта, экспертов, пользователей, менеджеров других проектов и т. д. Идентификация рисков — итеративный процесс. Первую итерацию может сделать команда управления проектом, вторую — другие участники проекта, окончательную — внешние по отношению к проекту специалисты. В процессе идентификации рисков важно наметить планы потенциального реагирования. При идентификации проектных рисков можно выделить группы управленческих рисков, организационных рисков, технических и технологических рисков, а также рисков внешних.
В результате идентификации определяются: риски и условия рисков — действия или окружение проекта, которые могут сделать риски более вероятными, а также триггеры или признаки рисков, указывающие на то, что риск произошел или может произойти.
На практике, как правило, технические риски в ИТ-проекте хотя и случаются, но с ними почти всегда можно сладить. Сложнее дело обстоит с такими рисками, как «политические игры», «отсутствие поддержки руководства», «нежелание, сопротивление пользователей, подрядчиков», «недостаточное финансирование».
Качественный и количественный анализ
После того как риски определили, описали условия, признаки их возникновения, следует провести их качественный и количественный анализ.
Качественная оценка нужна для расстановки приоритетов рисков по степени их влияния на результаты проекта в разрезе его стадий. При этом качественно оценивается вероятность риска и важность его последствий. Такая оценка должна проводиться регулярно на протяжении всего ИТ-проекта. Качественная оценка рисков базируется на плане управления рисками, перечне идентифицированных рисков, текущем состоянии проекта, точности и надежности исходной информации, опросных списках для оценки вероятности и последствий рисков. К методам качественной оценки рисков относится, например, идентификация рисков по шкале: очень высокие, высокие, умеренные, низкие, очень низкие, а также заполнение матрицы «Вероятность/последствие риска».
По результатам качественной оценки рисков производится их ранжирование, составляется перечень приоритетных рисков, определяется перечень рисков, которые требуют дополнительного анализа, оценки и управления.
Результатами количественного анализа рисков будут перечень и оценка приоритетных рисков, вероятностный анализ (моделирование) проекта, вероятности нарушения сроков и стоимости проекта, необходимые страховые резервы.
К методам количественного анализа рисков относятся, например, статистические методы, математические методы моделирования, анализ сценариев развития ситуации при возникновении того или иного рискового события и ряд других методов.
Использование методов математического моделирования и прогнозирования в области управления рисками позволяет улучшить принятие решений на основе прогнозирования рисков, рассчитать различные варианты развития событий и разработать сообразно с вариантами планы реагирования на них.
Рассмотрим пример качественного и количественного анализа рисков. Пусть в ИТ-компанию поступил запрос на внедрение информационной системы. При этом требования заказчика соответствуют одному из имеющихся у компании типовых вариантов внедрения со сроком внедрения 180 дней и стоимостью внедрения 4 млн. руб. Известно, что при внедрении могут иметь место риски, способные повлиять на параметры проекта (объем работ, сроки, качество, стоимость внедрения) и сделать реализацию данного проекта для исполнителя невыгодной. Необходимо так скорректировать параметры проекта внедрения, чтобы минимизировать возможные риски.
В качестве примера представлен ограниченный набор рисков: отсутствие согласованных требований заказчика к системе, сложность (либо невозможность) интеграции с существующими информационными системами заказчика, недостаточный уровень знаний пользователей.
По результатам предварительного обследования предприятия группой экспертов принимается решение о составе рисков для данного проекта, составляется реестр рисков с оценкой степени влияния каждого риска на проект каждым экспертом отдельно. Для однозначности оценок количество экспертов должно быть нечетным. Если мнение эксперта соответствует положительному решению о наличии того или иного риска, то ему ставится в соответствие число 1, иначе — 0. После сбора мнений экспертов определяется среднее арифметическое значение по каждому риску, после чего полученное число округляется до ближайшего целого, значение которого формализует наличие или отсутствие соответствующего риска.
Таблица 1. Оценка наличия (отсутствия) рисков
| Риски | Мнения экспертов | Итог | ||
|---|---|---|---|---|
| Эксперт 1 | Эксперт 2 | Эксперт 3 | ||
| Отсутствие согласованных требования Заказчика к системе | Да (1) | Нет (0) | Нет (0) | Нет (˜0) |
| Интеграция с существующими информационными системами Заказчика | Да (1) | Да (1) | Нет (0) | Да (˜1) |
| Недостаточный уровень знаний пользователей | Да (1) | Да (1) | Да (1) | Да (=1) |
В данном примере делается допущение, что мнения экспертов равнозначны, их следует принимать в расчет в равной мере (в противном случае при расчете среднего арифметического необходимо было бы учитывать весовые коэффициенты для каждого из экспертов).
Теперь необходимо определить величину потерь, связанных с рисками в стоимостном и временном выражениях. Например, так, как показано в таблице:
Таблица 2. Оценка величины потерь
| Отсутствие согласованных требования Заказчика к системе | Интеграция с существующими информационными системами Заказчика | Недостаточный уровень знаний пользователей | |
|---|---|---|---|
| Возможные потери дохода, руб. | 0 | 1,000,000 | 100,000 |
| Возможные потери времени, дней | 30 | 60 | 0 |
Далее строки таблицы 2 поочередно перемножаются с последним столбцом таблицы 1 и суммируются с соответствующими характеристиками типового варианта внедрения:
- срок внедрения = 180 + (30 x 0) + (60 x 1) + (0 х 1) = 240 дней;
- стоимость внедрения = 4,000,000 + (0 х 0) + (1,000,000 x 1) + (100,000 x 1) = 5,1 млн. руб.
В результате получаются скорректированные сроки и стоимость проекта с учетом возможных рисков.
Мониторинг, отчетность, контроль
Следующим аспектом системы управления рисками является формирование мониторинга и отчетности. Из общераспространенных на практике можно назвать следующие формы документирования процесса управления рисками ИТ-проекта: отчет менеджера проекта, журнал рисков проекта, журнал проблем, журнал требований на изменение проекта.
Отчет менеджера проекта — это, по сути, еженедельный отчет о состоянии дел по проекту, содержащий сведения о результатах проекта, угрозах, проблемах, требованиях на изменение проекта, перечень планируемых работ в следующем отчетном периоде.
В журнале рисков проекта, как правило, фиксируются риски проекта, отмечается статус риска и решение по реагированию на него (открыт, анализируется, рекомендована резолюция, резолюция утверждена, резолюция исполнена, не будет действий).
В журнале проблем фиксируются уже возникшие проблемы, формализуются планы устранения проблем, их исполнения, системы контроля возможных рецидивов и профилактики предупреждений. Он обязательно должен включать план мероприятий по устранению проблем, сроки и ответственных. В нем также осуществляется строгое ведение статуса проблемы (открыта, отправлена на анализ, анализируется, решена, закрыта, не будет никаких действий).
Журнал требований на изменение проекта заполняется в том случае, когда назрела необходимость корректировки проекта, будь то сроки, логические рамки, финансирование или смена проектной команды. Доводить дело до этого, конечно, крайне нежелательно, но если все-таки такая потребность возникла (а она определяется руководителем проекта по согласованию с заказчиком), то в журнале фиксируются необходимые действия для выполнения изменений, а также дается оценка влияния этих действий на план и стоимость работ.
Для контроля за рисками целесообразно разработать контрольные процедуры, распределить ответственность и отслеживать эффективность механизма контроля.
Процедуры контроля за рисками находят свое отражение в отчетности по проекту: в еженедельном отчете менеджера, о котором уже упоминалось, и в протоколах совещаний по проекту. Рекомендуется все процедуры и формы отчетности закреплять в уставе проекта — документе, на основании которого ведется управление конкретным проектом.
Планы реагирования на риски
В случаях когда рисковое событие все-таки произошло, существует несколько способов реагирования на риски:
- избегание риска,
- передача части или всего риска третьим лицам,
- снижение риска.
Избегание риска предполагает изменение плана проекта таким образом, чтобы исключить угрозу, вызванную негативным риском, — например, увеличить сроки или уменьшить состав работ по проекту. Примером избегания рисков может быть также отказ от проекта, если его реализация не приведет к ожидаемым результатам. Некоторых рисков, возникающих на ранних стадиях проекта, можно избежать после уточнения требований заказчика, детализации плана проекта, тщательной проработки договорной документации.
Методы передачи риска третьим лицам применяются, если риски весьма вероятны и размер ущерба невелик, либо если вероятность наступления ущерба низка, однако его размер значителен. В этом случае производится сравнение затрат на передачу риска с ожидаемым результатом. Наиболее часто используемым методом этой группы является страхование рисков. В мировой практике страхование рисков активно используется. Российские страховщики тоже предлагают программы страхования технических рисков (сбой сервера, обрыв линий связи и т. п.).
Сутью методов снижения риска является уменьшение вероятности наступления риска и уменьшение объемов возможных потерь. Менеджер на основании данных, полученных на стадии качественного и количественного анализа риска, разрабатывает планы реагирования, позволяющие понизить воздействие риска. В качестве примеров мероприятий по снижению рисков можно привести: внедрение более простых процессов управления проектом, выбор надежного поставщика программного обеспечения, разработку прототипов внедряемых систем, проведение большего количества тестовых испытаний.
Для снижения рисков также может применяться метод распределения рисков между участниками проекта. Этот вопрос должен решаться еще на этапе организации проекта в ходе заключения договоров. Необходимо максимально предусмотреть соблюдение интересов сторон в случае возникновения как внутренних, так и внешних рисков.
Очень хорошо зарекомендовал себя метод планирования резервов. Базовые параметры проекта лучше планировать «с запасом». Величина запаса экспертно оценивается в 20% от первоначальной величины. Для эффективного выполнения проекта необходимо создавать резервные фонды управления рисками, которые могут составлять до 10% от общего бюджета управления проектом.
Елена Нижникова,
старший менеджер департамента управленческих и информационных технологий компании «АКГ “РБС”»; NijnikovaES@rbsys.spb.ru
Игорь Белов,
старший консультант департамента управленческих и информационных технологий компании «АКГ “РБС”»; BelovIA@rbsys.ru
Опубликовано в журнале «Директор информационной службы», №7 за 2010 год