11.5 Планирование реагирования на риски.

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

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

11.6 Мониторинг и управление рисками.

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

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

Целью мониторинга рисков является определение того, что:

• реагирование на риски производится в соответствии с планом;

• эффективность реагирования соответствует ожиданиям, или есть необходимость в разработке нового реагирования;

• допущения проекта по-прежнему справедливы;

• подверженность рискам изменилась, с анализом трендов;

• наступило событие, являющееся признаком риска (триггер);

• применяются правильные методики и процедуры;

• возникли или наступили риски, которые ранее не были идентифицированы.

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

12. Управление контрактами проекта.

Управление контрактами проекта включает процессы, необходимые для получения продуктов и услуг, обеспечивающих исполнение содержания проекта, вне исполняющей организации. Для упрощения изложения далее и продукты и услуги (как единичные, так и множественные) будем в общем случае называть продуктом. Выделяют следующие основные процессы:

• планирование контрактов – определение предмета и сроков поставок;

• планирование заявок – документирование требований к продукту и определение потенциальных поставщиков;

• получение предложений – получение расценок, заявок, оферт или предложений от потенциальных поставщиков;

• выбор поставщиков – выбор среди потенциальных поставщиков;

• администрирование контрактов – управление взаимоотношениями с поставщиками;

• закрытие контрактов – завершение и проведение взаиморасчетов по контрактам, включая разрешение спорных вопросов.

Эти процессы взаимодействуют между собой с процессами из других областей знаний. В зависимости от потребностей проекта в каждый процесс могут быть вовлечены как один человек, так и группа лиц. Несмотря на то, что данные процессы представлены как обособленные элементы с четко очерченными границами, на практике они могут пересекаться и взаимодействовать различными способами, детально здесь не описанными. Взаимодействие процессов подробно обсуждается в Гл.3.

Управление контрактами проекта рассматривается с точки зрения покупателя во взаимоотношениях покупатель-поставщик. Эти взаимоотношения могут присутствовать в проекте на различных уровнях. В различных областях приложений поставщик может называться субконтрактор, вендор или продавец.

Обычно поставщик рассматривает свою деятельность как проект. В этом случае:

• покупатель становится клиентом и, соответственно, является ключевым участником проекта для поставщика;

• команда поставщика по управлению проектом должна владеть всеми процессами по управлению проектами, а не только в своей области приложения;

• положения и условия контракта становятся ключевыми входами для многих процессов в проекте поставщика. Контракты в свою очередь могут содержать входы (например, основные результаты, ключевые контрольные события, целевые затраты) или ограничивать возможности команды проекта (например, согласование с покупателем вопросов назначения персонала часто присущи для конструкторских проектов).

В данной главе предполагается, что поставщик является внешним по отношению к исполняющей организации. Большая часть обсуждения, однако, в равной степени относится к формальным соглашениям между подразделениями исполняющей организации. Для неформальных соглашений более применимы процессы, описанные в гл. 9 (Управление человеческими ресурсами проекта) и гл. 10 (Управление взаимодействием).