Делегирование рисков – проект реорганизуется таким образом,
чтобы переложить риски на третью сторону (заказчика, банки, вендора и т.п.);
Принятие рисков – риски признаются в качестве неизбежной
составляющей проекта, проводится постоянный мониторинг симптомов их
наступления, постоянно корректируется план действий в случае наступления
рисков [9].
Различают две основные категории рисков – прямые и опосредованные. На
прямые риски проектная команда может каким-то образом повлиять, а
опосредованные риски команда контролировать не может в принципе.
Риски делятся на следующие основные виды:
Ресурсные риски:
o Организация (выполняла ли организация прежде проекты такого
масштаба, существует ли формальный процесс разработки программного
обеспечения и т.п.);
o Финансирование (полностью ли обеспечено финансирование
проекта, фиксирована ли стоимость проекта или она является предметом для
обсуждения, точно ли выполнена оценка затрат и т.п.);
o Люди (достаточно ли людей для выполнения проекта, обладают ли
они необходимыми навыками и опытом, работали ли они вместе раньше и т.п.);
o Время (реалистичен ли план проекта, насколько критичной является
дата окончания проекта и т.п.);
o Бизнес (что произойдет, если конкурент выйдет на рынок первым,
выгода, полученная от реализации проекта больше, чем затраты на него, что
произойдет, если ключевые поставщики не смогут выполнить свои обязательства
и т.п.);
Технические риски:
o Область действия (scope) проекта (могут ли быть измерены критерии
успешного завершения проекта, требования стабильны и хорошо поняты, область
действия жестко фиксирована или может расширяться в будущем и т.п.);
o Технологии (отлажена ли применяемая технология или она только
была разработана, и т.п.) [11];