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

Чтобы добиться обратного, успешного и точного понимания рисков, будем использовать PMBOK и используем определение риска.

Проектный Риск - это неопределенное событие или условие , если оно произойдет то может иметь позитивное или негативное воздействие на цели проекта. У риска есть причина и если риск произойдет , то и воздействие.

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

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

Итак

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

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

Продолжение напишите сами… (пять минут на размышление).

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

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

Пожалуйста , подумайте пять минут и напишите свои примеры.

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

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

Пожалуйста впишите свои примеры из практики…

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

Причины риска это неопределенные особенности проекта,следовательно они не неопределены .

Следовательно это не риски(смотри определение риска).Если мы решили что причины - это риски и внесли их как таковые в нашу документацию то это приведет к неправильному определению рисков проекта, так как их вероятное возникновление определено, они факты. Это означает что в матрице они получат высший ранг, а подлинные риски, вероятность меньше 100%, могут быть вообще незамеченными.

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

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

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

Всегда нужно учитывать в оценке риска что КАЖДЫЙ риск имеет два измерения это неопределенность ,вероятность возникновения, и воздействие на цели , если риск возникает.

Будьте внимательны только подлинные риски имеют эти два измерения. Причины определенны и не имеют вероятности.

Последстввия же - это просто отображение на измерение воздействия на цели.

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

В результате (по причине)< определенное событие> <неопределенное событие> может случиться

что может вести к < воздействию на цели проекта>.

Примеры:

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

Использование нового ПО это определенный факт, является причиной неопределенности и вызывает риск.

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

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

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

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

Фактическая причина - это отсутствие опыта данных проектов.

Неопределенное событие - возможность неправильного сбора требований.

Непредвиденное будущее воздействие - невыполнение задач по исполнению.

• В плане у нас 10 человек в команде , но мы имеем только 6 на данный момент, возможно мы не выполним операцию в установленное время и мы можем запаздывать по расписанию.

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

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

Причина

Риск

Последствия

Отклик

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

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

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

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

Риск

Отклик

Тогда в риск мы включаем только подлинный риск , без причины и последствий.