Управление риском проекта

Управление рисками проекта

Великие дела всегда вершатся с большим риском

Геродот, греческий историк

Исследование «Хаос»

Исследование «Хаос»

• среднее превышение времени разработки — 222%;
• среднее превышение затрат на разработку — 189%;
• отставание в удовлетворении требований пользователя на 27 месяцев.

Понятие риска

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

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

Например, «болезнь или увольнение менеджера проекта» – это

риск, а «отсутствие опыта разработки у персонала» – это фактор.

Примеры:

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

Характеристики риска

1. Вероятность того, что рисковое событие произойдет. Вероятности принято задавать числом от 0 до 1 или в процентах.

2. У щерб в случае реализации риска. Эта величина определяет, насколько сильно пострадает проект, если рисковое событие произойдет.

Классификация рисков

• устранимые, т.е. такие, которых с помощью специальных мер можно избежать или которые можно предотвратить;
• неустранимые, т.е. такие, повлиять на которые менеджер проекта не может.

Примеры

Риск «потеря всех данных проекта».

Риск «прекращение финансирования проекта в результате банкротства инвестора».

Категории рисков

« Известные неизвестные». Это те риски, которые можно идентифицировать и подвергнуть анализу. В отношении таких рисков можно спланировать ответные действия.

«Неизвестные неизвестные». Риски, которые невозможно идентифицировать и, следовательно, спланировать ответные действия.

Устранение рисков

Преодоление риска – это проведение мероприятий, в

результате которых вероятность рискового события

сводится к нулю.

Предотвращение риска – это проведение мероприятий, в

результате которых ущерб риска сводится к нулю.

Примеры

Риск «потеря всех данных проекта».

Риск «болезнь или увольнение менеджера проекта».

Причины возникновения рисковых ситуаций

?

Порядок управления рисками программных проектов по PMBOK

PMBOK – американский национальный стандарт по управлению проектами

Порядок управления рисками

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

Стандарты управления рисками программных проектов

ГОСТ Р 51901 — "Управление надежностью. Анализ риска технологических систем".

ISO 12207 «Процессы жизненного цикла программных средств»

ISO 15504 «Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем»

Главные риски программных проектов

• Требования заказчика отсутствуют / не полны / подвержены частым изменениям.
• Отсутствие необходимых ресурсов и опыта.
• Отсутствие рабочего взаимодействия с заказчиком.
• Неполнота планирования. «Забытые работы».
• Ошибки в оценках трудоемкостей и сроков работ.

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

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

Источники исходных данных для выявления и описания характеристик рисков:

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

Подходы для сбора информации о рисках

Опрос экспертов — цель-идентифицировать и оценить риски путем интервью подходящих квалифицированных специалистов. Специалисты высказывают своё мнение о рисках и дают им оценку, исходя из своих знаний, опыта и имеющейся информации.

Мозговой штурм - привлекаются квалифицированные специалисты, которым дают «домашнее задание» — подготовить свои суждения по определенной категории рисков. Затем проводится общее собрание, на котором специалисты по очереди высказывают свои мнения о рисках. Важно: споры и замечания не допускаются. Все риски записываются, группируются по типам и характеристикам, каждому риску дается определение. Цель — составить первичный перечень возможных рисков для последующего отбора и анализа.

Подходы для сбора информации о рисках

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

" Карточки Кроуфорда " . Суть этой методики в следующем. Собирается группа экспертов 7-10 человек. Каждому участнику мини-исследования раздается по десять карточек (для этого вполне подойдет обычная бумага для записок). Ведущий задает вопрос: "Какой риск является наиболее важным в этом проекте?" Все респонденты должны записать наиболее, по их мнению, важный риск в данном проекте. При этом никакого обмена мнениями не должно быть. Ведущий делает небольшую паузу, после чего вопрос повторяется. Участник не может повторять в ответе один и тот же риск. После того как вопрос прозвучит десять раз, в распоряжении ведущего появятся от 70 до 100 карточек с ответами. Если группа подобрана хорошо (в том смысле, что в нее входят люди с различными точками зрения), вероятность того, что участники эксперимента укажут большинство значимых для проекта рисков, весьма высока. Остается составить список названных рисков и раздать его участникам для внесения изменений и дополнений.

Результат идентификации рисков

Список рисков с описанием их основных характеристик: причины, условия, последствий и ущерба.

Список рисков проекта создания «Автоматизированной системы продажи документации»

Причина

Условия

Требования не ясны.

Последствия

Отсутствие описания сценариев использования системы.

Недостаток квалифицированных кадров.

Текучесть кадров.

Ущерб

Задержка начала разработки прикладного ПО. Большой объем переработок.

Архитектура и код низкого качества.

Частая смена участников команды.

Задержки в сроках сдачи готового продукта и дополнительные трудозатраты.

Большое число ошибок. Большие затраты на их исправление.

Задержки в сроках сдачи готового продукта и дополнительные трудозатраты.

Низкая производительность при вводе новых участников в проект.

Задержки в сроках сдачи готового продукта и дополнительные трудозатраты.

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