Из статьи вы узнаете, как можно «увидеть» риски, и получите описание практически применимых инструментов идентификации рисков.

Но для начала давайте подумаем, насколько велика неопределенность в проектах или как сильно может отличаться дата завершения проекта от «нанопроцентной даты»?

Т. ДеМарко и Т. Листер в своей книге «Вальсируя с медведями» пишут о том, что руководителям проекта комфортно считать, что нормальный допуск – это плюс 10-15% от расчетного срока проекта без учета рисков: «То, что больше, кажется неправильным, каким-то недисциплинированным. Многие руководители даже считают это признаком слабости управления».

Так что же является допустимым отклонением от безрискового срока, рассчитанным на базе опыта? 

По мнению вышеупомянутых авторов, для отрасли разработки программного обеспечения диапазон допуска составляет порядка 150-200% от интервала с начала проекта до даты N (то есть к расчетному сроку можно смело прибавлять 150-200%). Этот диапазон получился на базе статистики большого количества ИТ-проектов и демонстрирует нам, насколько сильно может отличаться базовый план по срокам, не учитывавший риски, от фактического плана.

Для того чтобы повысить вероятность успеха проекта, при прогнозе сроков и бюджета проекта нужно обязательно учитывать влияние рисков на проект и пересчитывать сроки и бюджет. Ну а для того, чтобы учесть риски, их сначала нужно «увидеть». Как это можно сделать?

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

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

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

К примеру, на диаграмме есть запись о таком последствии как «Болезни членов команды». Как правильно сделать формулировку риска?

Можно сформулировать риск так:
1.    «Эпидемии инфекционных заболеваний в зимний период приведут к болезням членов команды проекта»

Или так:

2.    «Жаркое лето вызовет необходимость использования кондиционеров в офисе, что приведет к болезням участников проекта»

Как видим, последствие у рисков одно, а условия возникновения - разные.

Давайте сформулируем риски «Изменения требований» для источника «Заказчик проекта»:

1.     «Недостаточно глубокая проработка требований на старте проекта приведет к необходимости изменения требований по ходу проекта».

2.    «Сложность понимания заказчиком требований к продукту проекта приведет к частым изменениям требований по ходу получения первых результатов».

Последующая работа с рисками сводится к поиску возможности воздействовать на причину (условие) возникновения риска, поэтому, чем точнее описана причина, тем проще найти «противоядие».

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

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

Еще один простейший способ поиска рисков – изучение документов по проекту, таких как ИСР проекта, техническое задание на продукты проекта, поиск аналогичных проектов в архиве проектов компании и изучение Реестров рисков и Усвоенных уроков этих проектов. Если руководители похожих по содержанию проектов вели «Журнал проблем» в проекте или хотя бы написали «Усвоенные уроки» - это уже хороший источник для идентификации рисков.

Следующий способ – это поиск и изучение отраслевых классификаторов рисков. Это, по сути, отрефлексированный опыт отрасли. Такие классификаторы очень полезны – ничего выдумать не надо, риски из таксономии рассматриваем как риски нашего проекта.

Хорошим примером классификатора рисков я считаю документ, выпущенный SEI (Software Engineering Institute) под названием Taxonomy-Based Risk Identification. Документ описывает три класса рисков для софтверных проектов, каждый класс декомпозируется на элементы и атрибуты. В документе дается описание методики проведения исследований для создания классификатора и собственно, сам классификатор с пояснениями.

Скачать документ можно тут: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=11847

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

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

Обнаруженные на этапе идентификации риски заносятся в документ «Реестр рисков» (он может иметь и другое название), в котором важно прописать формулировку риска и примерное время его наступления.

Подведем итоги: в этой статье я описал простые инструменты, которые позволяют «увидеть» риски. Что с ними делать дальше – в следующих статьях. Удачи и до встречи в эфире!

Думайте о рисках!=)

Источник: Блог по управлению проектами