11.4 Контроль за реакцією на ризик

Контроль за реакцією на ризик включає виконання плану управління ризиками, для того щоб реагувати на ризиковані події в ході виконання проекту. Коли відбуваються зміни, то повторюється основний цикл з ідентифікації, кількісної оцінки та реакції на ризик. Важливо розуміти, що навіть ретельний і всебічний аналіз не зможе правильно визначити всі ризики та ймовірності; тому необхідні контроль і покрокові дії.

11.4.1 Вхідні дані для контролю за реакцією на ризик

. 1 План управління ризиком. Див. пункт 11.3.3.1.

.2 Фактичні ризиковані ПОДІЇ. Деякі з ідентифікованих ризикованих подій відбуваються, деякі - ні. Ризиковані події, що відбуваються, називають фактичними ризикованими подіями, або джерелами ризику, і команда управління проектом повинна усвідомити, що ризикована подія сталася і має бути реалізованою розроблена на ризик реакція.

.З Ідентифікація додаткового ризику. По мірі здійснення контролю і складання звітів з виконання проекту (описаних в підрозділі 10.3) можуть бути визначені потенціальні ризиковані події, або джерела ризику, які заздалегідь не були визначені.

11.4.2 Методи та засоби для контролю за реакцією на ризик

.1 Понаднормові роботи. Понаднормові роботи - це позапланова реакція на негативні ризиковані впливи. Понаднормові роботи не плануються тільки тоді, коли у разі виникнення конкретної ризикованої події реакція не визначена.

.2 Додаткові реакції на ризик. Якщо ризикована подія не передбачається або ефект від неї більший, ніж очікувався, то планова реакція може бути не адекватною, і тоді необхідно повторити процес розвинення реакції на ризик, а може і процес кількісної оцінки ризику.

11.4.3 Результати контролю за реакцією на ризик

.1 Коригуючі ДІЇ. Коригуючі дії насамперед містять планову реакцію на ризик (наприклад, реалізацію планів з невизначеностей або понаднормові роботи).

2. Коригування плану управління ризиком. Очікувані ризиковані події виникають або не виникають, і оскільки вплив фактичних ризикованих подій можна оцінити, то оцінки ймовірностей і значень ризиків, а також інших аспектів плану управління ризиками мають бути скориговані.

12.Управління закупівлями в проекті

Управління закупівлями в проекті включає процеси, необхідні для

придбання товарів і послуг за межами виконавчої організації. Далі для

простоти товари та послуги, незалежно від кількості, називатимуться «продукт». Малюнок 12—1 містить огляд таких основних процесів:

1. Планування закупівель - визначення того, що і коли необхідно придбати.

2. Планування клопотань - документальне оформлення вимог до продукту та визначення потенціальних джерел його отримання.

3. Клопотання - отримання тендерної документації, тендерних пропозицій або інших слушних пропозицій.

4. Вибір джерела - вибір серед потенціальних продавців.

5. Адміністрування контракту — управління зв'язком з продавцем.

6. Закриття контракту - завершення і врегулювання виконання

завдань контракту, включаючи вирішення відкритих питань.

Зазначені процеси взаємодіють як між собою, так і з процесами

інших галузей застосування знань з проектного менеджменту

Кожний процес може включати зусилля одного чи кількох індивідуумів або

груп індивідуумів, спрямовані на задоволення потреб проекту, і

виконується, як правило, по одному разу на кожній фазі проекту.

Хоч тут процеси представлені як дискретні елементи з чітко визначеними зв'язками, на практиці вони можуть перекриватися і взаємодіяти між собою в різний спосіб, що докладно тут не описується. Детально обговорені взаємодії між процесами в розділі 3.

Управління закупівлями в проекті обговорюється з позиції покупця у відношенні «покупець-продавець». Відношення «покупець-прода-вець» може існувати на багатьох рівнях одного проекту. Залежно від прикладної сфери продавець може бути названий підрядчиком або постачальником.

Продавець звичайно управляє своєю роботою у проекті. В таких випадках:

• Покупець стає споживачем або основною зацікавленою особою по відношенню до продавця.

• Команда менеджерів проекту продавця повинна зосередитися на всіх процесах управління проектом, а не тільки на тому, який належить до їх галузі знання.

• Строки та умови контракту стають основними вхідними даними для багатьох процесів продавця. Контракт може фактично містити вхідні дані (наприклад, основний результат, ключові віхи, вартісні задачі) або він може бути обмежений рішеннями команди проекту (наприклад, під час проектування часто буває необхідним затвердження рішень з питань персоналу з боку покупця).

У даному розділі передбачається, що продавець є особою із зовні відносно організації, що виконує проект. Проте, більшість міркувань також застосовна і тоді, коли формальна угода укладається з якимось підрозділом організації, що виконує проект. У випадку неформальних угод краще застосовувати процеси, описані в розділах 9, 10.