3.8. Управление рисками проекта
Управление риском проекта включает в себя процессы, связанные с определением, анализом и реагированием на риск проекта. Оно включает максимизацию результатов положительных событий и минимизацию последствий неудач. Рис. 3.18 дает обзор следующих основных процессов:
-
идентификация риска – определение того, какие рисковые события могут повлиять на проект и документирование характеристик каждого из них;
-
определение количества риска – вычисление количества риска и рисковых взаимодействий для оценки диапазона возможных результатов проекта;
-
разработка методов реагирования на риск – определение шагов по увеличению вероятности наступления благоприятных событий и ускорение реагирования на угрозы;
-
контроль реагирования на риск – реагирование на изменения в риске на протяжении всего хода проекта.
Эти процессы пересекаются друг с другом, а также с процессами из других сфер знания. Каждый процесс может включать в себя усилия одного или более индивидуумов или групп в зависимости от нужд проекта. Каждый процесс обычно встречается, по крайней мере, один раз в каждой фазе проекта.
Хотя процессы представлены здесь как дискретные элементы с четко определенными границами, на практике они могут перехлестываться и пересекаться не описанными здесь способами.
Различные прикладные сферы часто используют различные названия для процессов, описанных здесь. Например:
-
идентификацию риска и определение количества риска иногда именуются как один общий процесс, и этот комбинированный процесс может быть назван анализом риска или оценкой риска;
-
разработку методов реагирования на риск иногда называется планированием реагирования или смягчением (уменьшением) риска;
-
разработку методов реагирования на риск и контроль реагирования на риск иногда объединяют в один процесс, и этот комбинированный процесс может быть назван управлением риском.
Идентификация риска
Идентификация риска состоит в определении того, какие риски наиболее вероятно повлияют на проект, и в документировании характеристик каждого из них. Идентификация риска – не одноразовое мероприятие; оно должно проводиться регулярно во время выполнения проекта.
Идентификация риска должна адресоваться как ко внутренним, так и внешним рискам. Внутренние риски – процессы, события, которые команда проекта может контролировать или влиять на них, такие как распределение персонала и сметы. Внешние риски – те процессы, события, которые выходят за пределы контроля или влияния команды проекта, такие как сдвиги рынка или действия правительства.
Рис. 3.18. Обзор процессов управления риском проекта
3.9.Управление обеспечением проекта
Управление обеспечением проекта включает процессы, необходимые для приобретения товаров и услуг за пределами исполняющей организации. Для простоты товары и услуги независимо от их количества будем называть "продуктами". Рис. 3.19 дает обзор следующих главных процессов:
-
планирование поставок – определение того, что и когда поставлять;
-
планирование обращений – документирование товарных требований и выявление потенциальных источников;
-
обращение – получение подходящих заявок, ходатайств, предложений;
-
выбор источника – выбор из потенциальных продавцов;
-
управление контрактом – управление отношениями с продавцом;
-
закрытие контракта – исполнение и завершение контракта, включая разрешение всех спорных вопросов.
Эти процессы пересекаются друг с другом, а также с процессами из других сфер знания. Каждый процесс может включать в себя усилия одного или более индивидуумов или групп в зависимости от нужд проекта. Хотя процессы представлены здесь как дискретные элементы с четко определенными границами, на практике они могут перехлестываться и пересекаться не описанными здесь способами.
Управление обеспечением проекта обсуждается с точки зрения Покупателя в отношениях Покупатель-Продавец. Отношения Покупатель-Продавец может существовать на многих уровнях проекта. В зависимости от прикладной области продавец может называться контрагентом, продавцом или поставщиком.
Продавец обычно управляет своей работой как проектом. В таких случаях:
1. Покупатель становится заказчиком и, таким образом, ключевым стэйкхолдером для продавца.
-
Команда управления проектом Продавца должна быть связана со всеми процессами управления проектами, а не только с процессами, принадлежащими этой области знания.
-
Условия контракта становятся ключевыми входными данными для многих процессов продавца. Контракт может реально содержать входные данные (например, основные предметы, цели, ключевые вехи, стоимостные цели), или он может ограничивать свободу выбора команды проекта (например, мнение покупателя часто является определяющим в проектах какого-либо дизайна).
В этом разделе предполагается, что продавец является внешним элементом по отношению к исполняющей организации. Однако основная часть дискуссии равномерно применима к формальным соглашениям между другими подразделениями исполняющей организации. Когда включены неформальные соглашения, тогда более применимы процессы, описанные в разделе 9 - Управление человеческими ресурсами проекта и разделе 7 - Управление коммуникациями проекта.
Рис. 3.19. Обзор процессов управления обеспечением проекта