Версия для печатиОтправить другу

 Автор: Алексей Ким, akim@lessonslearned.ru, www.lessonslearned.ru
 
В предыдущей заметке по рабочим документам проекта я описал реестр открытых вопросов. Реестр открытых вопросов - инструмент, помогающий формализовать коммуникации на проекте, способствующий полному выяснению неясных моментов, прояснению размытых ситуаций и помогающий охватить картину проекта в целом. В настоящей заметке я бы хотел рассмотреть следующий инструмент управления проектом: реестр рисков. Реестр рисков содержит описание всех идентифицированных рисков проекта, а также информацию по работе с ними и помогает избежать либо минимизировать получаемый ущерб от множества угроз, подстерегающих на проекте. Управление рисками проекта – область знаний, игнорировать которую на проекте невозможно. Риски и работы по управлению ими оказывают влияние буквально на все на проекте.
 

Реестр рисков
На проектах я веду реестр рисков в файле Excel. Вообще, насколько я знаю, в Microsoft Project Server есть возможность привязки рисков и вопросов проекта к работам проекта и к проекту в целом используя представления Sharepoint Portal и Sharepoint Services. Однако, я ими не пользуюсь, привычка, наверное. Впрочем, большинство полей в моем Excel файле совпадают с полями рисков в Project Server. Реестр рисков на проекте используется не так часто, как реестр открытых вопросов, однако данный реестр важен для успеха проекта. У меня реестр рисков содержит следующие поля:
 
Номер или код – уникальный идентификатор вопроса. Служит для идентификации рисков.
 
Риск – поле содержащее наименование риска. Я именую риски их содержимым, тем самым избегаю необходимости введения дополнительного поля.
 
Категория – для себя мы выделили четыре категории рисков (внешние, организационные, управленческие и технологические риски). Категоризация помогает сгруппировать риски для более подробного рассмотрения.
 
Вес – вес риска помогает отделить те риски, которые признаются весомыми для проекта и требуют плана реагирования от прочих рисков проекта. Вес риска является произведением вероятности риска на возможный ущерб от реализации этого риска.
 
Дата открытия риска – дата регистрации риска, т.е. занесения его в реестр.
 
Дата реализации риска – дата когда риск реализовался.
 
Срок – если риск актуален до какой-то даты, то у него заполняется поле срок.
 
Триггер – если реализация срока привязана к какому-то событию, то в данное поле заносится это событие.
 
Последствия – в это поле заносится информация о последствиях реализации риска.
 
Владелец – в данное поле заносится владелец риска, т.е. сотрудник, отвечающий за реализацию/нереализацию данного риска. По умолчанию – менеджер проекта, но может меняться.
 
Статус – статус риска. У меня в реестре, данное поле может принимать только три значения (Открыт, Активен, Закрыт).
 
Дата закрытия – дата закрытия риска. Теоретически, один раз закрытый риск может быть повторно открыт, но на практике я с этим не сталкивался.
 
Стратегия – в данное поле заносится стратегия работы с риском, описание в общих словах, что именно планируется сделать по данному риску.
 
Комментарии – поле, куда заносятся комментарии.
 
Реестр рисков на наших проектах ведется с самого начала проекта (как и прочие реестры). Изначально его формирует менеджер проекта. В этом очень помогают усвоенные уроки с других проектов. После формирования команды проекта мы работаем с реестром рисков следующим образом. Для начала мы заполняем его всеми мало-мальски реалистичными рисками проекта, определяемыми коллективно на первой сессии по управлению рисками проекта. Цель первой сессии – идентификация как можно большего количества рисков, существующих на проекте. На данном этапе мы не смотрим на их важность или вероятность, т.к. исходим из предпосылки, что и важность и вероятность риска в ходе проекта могут меняться и риски невероятные сегодня могут вполне стать реальной угрозой через квартал или полугодие. После идентификации рисков команда присваивает каждому риску категорию. Затем, выбирается порог для отслеживания рисков (обычно, среднее значение между максимальным весом риска и минимальным). Независимо друг от друга каждый член команды проекта присваивает оценки для вероятности и ущерба каждого риска, после чего вычисляется значение веса риска (произведение вероятности на возможный ущерб), по мнению каждого сотрудника. Вес риска в реестре берется как среднеарифметическое значение из весов, проставленных членами проектной команды. В случае, если вес риска выше порогового значения, для него разрабатывается стратегия реагирования на риск. PMI рекомендует, помимо указанного плана, разрабатывать план на случай, если план реагирования не сработает. Честно признаюсь, такой план мы не разрабатываем.
 
Риски пересматриваются раз в неделю, либо раз в две недели. Наиболее важные на момент отчета риски включаются в отчет о статусе проекта, предоставляемый руководству вместе с информацией о ходе работы с риском. Все работы на проекте ведутся с учетом всех идентифицированных рисков. Очень важно начать работу с рисками на наиболее ранней стадии проекта, т.к. учет рисков и их последствий для проекта может значительно повлиять на решения и работы, принимаемые и выполняемые на проекте.
 
Не забывайте про риски и успешных вам проектов!