Стратегия по минимизации рисков бизнес план

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

Фото с сайта valuendo.com

В предыдущей статье мы рассмотрели два риска для проекта «Внедрения CRM и автоматизации процессов управления отношениями с клиентами».

Риск 1. Выбор программного продукта без понимания полного списка требований к нему. Приведет к необходимости делать большое количество доработок продукта под процессы компании (а это означает «расползание» рамок проекта и рост объемов работ).

Риск 2. Изменение требований к программному продукту по ходу проекта внедрения. Приведет к «расползанию» рамок проекта и росту объемов работ по нему.

Управление рисками сводится к тому, чтобы нивелировать их влияние на проект, а в идеале – полностью убрать потенциальную проблему из проекта.

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

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

Рассмотрим их на примере нашего кейса.

Стратегия уклонения предполагает полное исключение риска из проекта. Мы должны придумать реагирование, которое позволит быть уверенными, что риск не материализуется. Это самая «дорогая» стратегия, т.к. для некоторых рисков она вынуждает отказываться от определенных работ, менять цели проекта или, в самом радикальном случае, отказываться от проекта.

Попробуем уклониться от риска неполного списка требований (риск 1).

Можно ли быть уверенным на 100%, что мы собрали все требования? Я считаю, это невозможно. Даже если мы будем считать, что собрали все, по ходу реализации проекта может возникнуть новое требование.

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

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

Можем ли мы передать кому-то риск, связанный с неполными требованиями? Как вариант, мы можем передать работу, связанную со сбором требований, консультантам «под ключ», прописав в контракте штрафные санкции за ошибки (это будет непросто, но вполне возможно).

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

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

Применим эту стратегию для наших рисков. Сначала проработаем риск с неполными требованиями.

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

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

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

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

Ну и четвертая стратегия – это принятие риска.

Как кажется из названия стратегии, до наступления риска предполагается «ничего не делать». С нашей ментальностью это часто любимая стратегия работы с рисками. Однако совсем ничего не делать – это не управление рисками. Есть два варианта для четвертой стратегии – активное и пассивное принятие.

Активное – формируется резерв времени и денег на устранение последствий материализации риска.

Пассивное – предполагает наличие плана Б (устранения последствий проблемы) на случай, если риск материализуется.

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

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

Для риска изменения требований стратегия активного принятия та же. И размер резерва времени и денег так же становится предметом переговоров.

Пассивным принятием для обоих рисков станет использование резерва времени и денег, который был заложен в проект.

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

Обобщим стратегии в таблице.

Проанализируем, какие из описанных стратегий наиболее уместны для риска, связанного с пропуском требований:

1. Стратегия уклонения от риска невозможна.

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

3. Сбор требований выделить в отдельный проект или этап проекта – это возможный вариант и в случае выбора «водопадной» модели жизненного цикла проекта так оно и будет.

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

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

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

4. Заложить запас времени в расписание проекта и резерв в бюджет проекта – я бы постарался это сделать.

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

Для второго риска подход абсолютно аналогичен.

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

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

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

Удачи вам в управлении рисками и успешных проектов!