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

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

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

3. Анализ отклонений и трендов - сравнение текущих показателей с первоначальным планом. Значительное отклонение в ту или иную сторону означает, что работа выполняется быстрее или медленне, чем планировалось, поэтому требуется введение дополнительных корректирующих мероприятий. идеально делать такой анализ по методу освоенного объема, но он достаточно редко встречается в программных проектах, поскольку они практически не используют классическую водопадную модель. Обычно сравнивают контрольные точки на начальном и текущем планах - и на этом анализ завершается.

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

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