Marina Lou: Об идентификации рисков

Оригинальная статья!

Идентификация рисков – зачастую последнее, чем занимается менеджер на стадии начала проекта, и чаще всего это происходит, когда Клиент поджимает и требует спецификации с подробными сроками и стоимостью, а Команда уже провела не один митинг для оценки и обсуждения объема планируемых работ и ждет отмашки для старта. И прекрасно понятно, что после идентификации и анализа рисков может измениться все – и стоимость, и сроки, и список задач. Но… на полноценные исследования нет времени… накинем 20% к времени… 15% к стоимости… Наверное, достаточно.

Идентификация рисков

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

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

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

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

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

Матрица влияния/вероятности

Анализ рисков

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

В список рисков, вероятность возникновения которых очень мала, а влияние незначительно, могут попасть вымышленные ситуации. Оригинальные предложения по избежанию таких рисков можно распечатать и повесить на Scrum board или другое видное место. В случае, если на собрании были выявлены риски с крайне малой вероятностью возникновения, но серьезными последствиями, имеет смысл упомянуть о них в разделе ‘Форс-мажоры’ плана проекта.

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

Область С
Область С заполняют риски со средней вероятностью возникновения и возможным сильным влиянием, либо наоборот – средним влиянием и высокой вероятностью возникновения. Кроме создания плана минимизации последствий данных рисков, необходимо обсудить, как избежать возникновения этих рисков?

Область D
В области D находятся риски, вероятность возникновения которых более 50%, а степень влияния на проект может достигать критической. Риски в данной области требуют самого тщательного анализа. Кроме плана минимизации последствий и предотвращения возникновения, необходимо разработать список критериев, изменение значений которых будет означать, что вероятность возникновения риска увеличивается. В плане управления проектом необходимо предусмотреть действия по отслеживанию значений показателей, и указать промежутки времени между точками контроля.

Область E
Наличие рисков в области E ставит под сомнение адекватность плана проекта. В этой области расположены риски с вероятностью возникновения более 80%, критически влияющие на проект. Другими словами, скорее всего произойдет ситуация, за которой последует провал проекта. Стартовать работу над проектом при наличии таких рисков крайне нецелесообразно. Это серьезный повод пересмотреть план проекта (который включает сроки, стоимость, использование ресурсов, коммуникации, взаимосвязи с внешними организациями), и изменить его таким образом, чтобы снизить вероятность или влияние таких рисков, и переместить их в область D.

Итого

Результатом анализа рисков является внесение изменений в план проекта и создание отдельного документа (Плана управления рисками). Наличие подобного документа позволит также серьезно сэкономить время при идентификации рисков на похожем или однотипном проекте.

Вот теперь, после утверждения обновленного плана проекта/сроков/стоимости, можно стартовать работу.