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

На стадии планирования управления рисками проекта у нас имеется Реестр рисков проекта, календарно-ресурсный план проекта с перечнем задач по управлению рисками проекта.

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

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

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

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

Качественный анализ рисков проекта

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

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

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

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

Риски разработки ПО

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

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

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

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

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

Риск появления новых требований возникает в процессе разработки ПО, когда появляются всё новые и новые требования, которые отодвигают сроки и оценку конкретных задач.

Риск противоречивости в требованиях (декомпозиция спецификации) – это риски связанные с выявлением противоречивости в требованиях заказчика на этапе программирования или интеграции проекта.

Риски неправильно определённых системных требований – это риски, когда в самом начале проекта были некорректно сформулированы характеристики целевой системы, для которой разрабатывается программное обеспечение: программное окружение (операционная система, установленные компоненты, сервисы и т.п.) или требования к аппаратной части (частота процессора, объём жёсткого диска, объём оперативной памяти и т.п.).

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

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

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

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

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

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

Рассмотрим спекулятивные риски, присущие разработке ПО. Эти риски можно структурировать на риски финансовых ограничений, риски изменения конъюнктуры, риски изменения курсов валют.

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

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