Сфера виконання "Невизначеність" (2.8 Uncertainty performance domain)

Сфера виконання "Невизначеність" (Uncertainty performance domain) стосується діяльності та функцій, пов'язаних з ризиком і невизначеністю.

Сфера виконання "Невизначеність" (2.8 Uncertainty performance domain) це одна зі сфер виконання в PMBOK 7

Ефективне виконання цієї області продуктивності призводить до наступних бажаних результатів:

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

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

В таблиці Застосування моделей в PMBOK® 7 (4.3) лише 2 методи відносяться до невизначеності, це Cynefin framework / Модель «Кеневін» (4.2.5.1) та Матриця Стейсі (Stacey Matrix) (4.2.5.2)

Наступні визначення мають відношення до області продуктивності невизначеності:

• Невизначеність (Uncertainty). Відсутність розуміння та усвідомлення проблем, подій, шляхів, якими слід йти, або рішень, які слід шукати.
• Невизначеність (Ambiguity). Стан неясності, труднощі у визначенні причини подій або наявність декількох варіантів, з яких можна вибрати.
• Складність (Complexity). Характеристика програми чи проекту або його оточення, якою важко керувати через людську поведінку, поведінку системи та невизначеність.
• Нестабільність (Volatility). Можливість швидких і непередбачуваних змін.
• Ризик (Risk). Невизначена подія або умова, яка, у разі настання, має позитивний або негативний вплив на одну або декілька цілей проекту.

Розділи (2.8.4), (2.8.1), (2.8.3), (2.8.2) відповідають абревіатурі VUCA (Volatility, uncertainty, complexity and ambiguity) і описані там.

Невизначеність у широкому розумінні - це стан незнання або непередбачуваності. Існує багато нюансів невизначеності, таких як

• Ризик, пов'язаний з незнанням майбутніх подій,
• Неоднозначність, пов'язана з незнанням поточних або майбутніх умов, і
• Складність, пов'язана з динамічними системами з непередбачуваними результатами.

Успішне подолання невизначеності починається з розуміння ширшого середовища, в якому працює проект. Аспекти середовища, які сприяють невизначеності проекту, включають, але не обмежуються ними:

• Економічні фактори, такі як волатильність цін, доступність ресурсів, можливість запозичення коштів та інфляція/дефляція;
• Технічні міркування, такі як нові або новітні технології, складність, пов'язана з системами та інтерфейсами;
• Правові або законодавчі обмеження чи вимоги;
• Фізичне середовище, що стосується безпеки, погоди та умов праці;
• Невизначеність, пов'язана з поточними або майбутніми умовами;
• Соціальні та ринкові впливи, що формуються громадською думкою та засобами масової інформації; та
• політичні впливи, як зовнішні, так і внутрішні по відношенню до організації.

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

Загальна невизначеність (2.8.1 General Uncertainty)

Невизначеність притаманна всім проектам. З цієї причини наслідки будь-якої діяльності неможливо точно передбачити, і може виникнути цілий ряд результатів.

Потенційні результати, які сприяють досягненню цілей проекту, називаються можливостями; потенційні результати, які мають негативний вплив на цілі, називаються загрозами. Разом можливості та загрози складають набір проектних ризиків. Існує кілька варіантів реагування на невизначеність:

• Збір інформації (Gather information). Іноді невизначеність можна зменшити, дізнавшись більше інформації, наприклад, провівши дослідження, залучивши експертів або виконавши аналіз ринку. Важливо також розпізнати, коли подальший збір та аналіз інформації перевищує користь від наявності додаткової інформації.
• Підготуйтеся до кількох результатів (Prepare for multiple outcomes). У ситуаціях, коли є лише кілька можливих результатів з області невизначеності, команда проекту може підготуватися до кожного з цих результатів. Це передбачає наявність основного рішення, а також резервного або запасного плану на випадок, якщо первинне рішення виявиться нежиттєздатним або неефективним. Якщо існує великий набір потенційних результатів, команда проекту може класифікувати та оцінити потенційні причини, щоб оцінити ймовірність їх виникнення. Це дозволяє проектній команді визначити найбільш ймовірні потенційні результати, на яких слід зосередитися.
• Проектування на основі наборів (Set-based design). Для зменшення невизначеності на ранній стадії проекту можна дослідити декілька варіантів або альтернатив. Це дозволяє проектній команді розглянути компроміси, такі як час проти вартості, якість проти вартості, ризик проти графіку або графік проти якості. Мета полягає в тому, щоб дослідити варіанти, щоб проектна команда могла вчитися на досвіді роботи з різними альтернативами. Неефективні або неоптимальні альтернативи відкидаються протягом усього процесу.
• Створюйте стійкість (Build in resilience). Стійкість - це здатність адаптуватися і швидко реагувати на неочікувані зміни. Стійкість стосується як членів проектної команди, так і організаційних процесів. Якщо початковий підхід до дизайну продукту або прототипу не є ефективним, проектна команда та організація повинні мати можливість швидко вчитися, адаптуватися та реагувати.

Неоднозначність (2.8.2 Ambiguity)

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

Наприклад, твердження "Минулого тижня повідомлялося, що графік виконується за графіком" є незрозумілим. Незрозуміло, чи було дотримано графік минулого тижня, чи було повідомлено про це минулого тижня.

Крім того, може виникнути питання щодо того, що означає "за графіком". Невизначеність такого типу можна зменшити, формально встановивши загальні правила і визначення термінів, наприклад, що означає "за графіком".

Ситуативна невизначеність з'являється тоді, коли можливий більш ніж один результат. Наявність декількох варіантів вирішення проблеми є формою ситуативної невизначеності. Рішення для дослідження невизначеності включають прогресивну розробку, експерименти та використання прототипів.

• Прогресивна розробка (Progressive elaboration). Це ітеративний процес підвищення рівня деталізації плану управління проектом у міру того, як стають доступними більші обсяги інформації та точніші оцінки.
• Експерименти (Experiments). Добре спланована серія експериментів може допомогти виявити причинно-наслідкові зв'язки або, принаймні, зменшити кількість невизначеностей.
• Прототипи (Prototypes). Прототипи можуть допомогти розрізнити взаємозв'язки між різними змінними.

Складність (2.8.3 Complexity)

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

У складних середовищах нерідко можна спостерігати, як сукупність окремих елементів призводить до непередбачуваних або ненавмисних результатів. Ефект складності полягає в тому, що неможливо зробити точний прогноз щодо ймовірності будь-якого потенційного результату або навіть знати, які результати можуть з'явитися.

Існує багато способів працювати зі складністю; деякі з них ґрунтуються на системному підході, деякі передбачають рефреймінг, а інші базуються на процесах.

Системний підхід (2.8.3.1 Systems-Based)

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

• Роз'єднання (Decoupling). Роз'єднання передбачає від'єднання частин системи з метою спрощення системи та зменшення кількості пов'язаних змінних. Визначення того, як частина системи працює самостійно, зменшує загальний розмір проблеми.
• Імітація (моделювання). Можуть існувати схожі, але не пов'язані між собою сценарії, які можна використовувати для моделювання компонентів системи. Проект будівництва нового аеропорту, який включає в себе зону з магазинами і ресторанами, може дізнатися про купівельні звички споживачів, шукаючи аналогічну інформацію про торгові центри та розважальні заклади.

Рефреймінг (2.8.3.2 Reframing)

Прикладами роботи зі складністю, яка передбачає рефреймінг, є

• Різноманітність (Diversity). Складні системи вимагають розгляду системи з різних точок зору. Це може включати мозковий штурм з командою проекту, щоб відкрити різні способи бачення системи. Це також може включати Дельфі-подібні процеси для переходу від дивергентного до конвергентного мислення.
• Баланс (Balance). Збалансування типу використовуваних даних замість того, щоб використовувати тільки прогнозні дані або дані, які звітують про минулі або відстаючі показники, забезпечує ширшу перспективу. Це може включати використання елементів, варіації яких можуть нівелювати потенційний негативний вплив один одного.

На основі процесів (2.8.3.3 Process-Based)

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

• Ітерація (Iterate). Побудова ітеративно або інкрементально. Додавайте функції по одній за раз. Після кожної ітерації визначайте, що спрацювало, що не спрацювало, реакцію клієнтів і те, чого навчилася команда проекту.
• Залучайте (Engage). Створюйте можливості для залучення зацікавлених сторін. Це зменшує кількість припущень і сприяє навчанню та залученню до процесу.
• Забезпечити відмовостійкість (Fail safe). Для елементів системи, які є критично важливими, створіть надмірність або елементи, які можуть забезпечити плавну деградацію функціональності в разі відмови критичного компонента.

Волатильність (2.8.4 Volatility)

Волатильність (Volatility) існує в середовищі, яке піддається швидким і непередбачуваним змінам. Нестабільність може виникати, коли відбуваються постійні коливання в наявних наборах навичок або матеріалах.

Волатильність (Volatility) зазвичай впливає на вартість і графік. Аналіз альтернатив і використання резервів вартості або графіку дозволяє впоратися з нестабільністю.

• Аналіз альтернатив (Alternatives analysis). Пошук і оцінка альтернатив, наприклад, розгляд різних способів досягнення мети, таких як використання іншого набору навичок, зміна послідовності робіт або передача робіт на аутсорсинг. Аналіз альтернатив може включати визначення змінних, які слід враховувати при оцінці варіантів, а також відносної важливості або ваги кожної змінної.
• Резерв (Reserve). Резерв витрат може бути використаний для покриття перевитрат бюджету через нестабільність цін. За певних обставин, резерв графіка може бути використаний для подолання затримок через нестабільність, пов'язану з доступністю ресурсів.

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

Ризик (2.8.5 Risk)

Ризики - це аспект невизначеності. Ризик - це невизначена подія або умова, яка в разі виникнення має позитивний або негативний вплив на одну або декілька цілей проекту.

Негативні ризики називаються загрозами, а позитивні - можливостями. Всі проекти мають ризики, оскільки вони є унікальними заходами з різним ступенем невизначеності.

Члени проектної команди повинні проактивно виявляти ризики протягом усього проекту, щоб уникнути або мінімізувати вплив загроз і запустити або максимізувати вплив можливостей. Як загрози, так і можливості мають набір можливих стратегій реагування, які можуть бути заплановані для реалізації в разі настання ризику.

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

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

Загальний ризик проекту (Overall Project Risk)

Загальний ризик проекту - це вплив невизначеності на проект в цілому, що виникає з усіх джерел невизначеності. Сюди входять індивідуальні ризики і схильність до наслідків варіації результатів проекту, як позитивних, так і негативних.

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

Загрози (2.8.5.1 Threats)

Загроза (Threat) - це подія або умова, яка, у разі її виникнення, має негативний вплив на одну або більше цілей. Можна розглянути п'ять альтернативних стратегій реагування на загрози, наведених нижче:

• Уникнення (Avoid). Уникнення загрози - це коли команда проекту діє, щоб усунути загрозу або захистити проект від її впливу.
• Ескалація (Escalate). Ескалація доречна, коли команда проекту або спонсор проекту погоджується з тим, що загроза виходить за рамки проекту або що запропонована відповідь перевищує повноваження менеджера проекту.
• Передача (трансфер). Передача передбачає передачу права власності на загрозу третій стороні для управління ризиком і прийняття на себе наслідків у разі виникнення загрози.
• Пом'якшення (Mitigate). При зменшенні загрози вживаються заходи, спрямовані на зниження ймовірності виникнення та/або впливу загрози. Дії з пом'якшення на ранніх стадіях часто є більш ефективними, ніж спроби виправити шкоду після того, як загроза вже виникла.
• Прийняття (Accept). Прийняття загрози означає, що загроза існує, але не планується жодних проактивних дій. Активне прийняття ризику може включати розробку плану дій на випадок надзвичайних ситуацій, який буде введено в дію, якщо подія відбудеться; або ж це може бути пасивне прийняття, що означає бездіяльність.

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

Метою реагування на загрози є зменшення кількості негативних ризиків. Ризики, які приймаються, іноді зменшуються просто з плином часу або через те, що ризикова подія не відбувається. На Рисунку 2-33 показано, як ризики відстежуються і зменшуються з плином часу.

Загрози (Threats) та Можливості (Opportunities) є одним з параметрів методики SWOT-аналізу. В статті є деякі додаткові стратегії щодо роботи з загрозами.

Можливості (2.8.5.2 Opportunities)

Можливості (Opportunities) - це подія або умова, яка, якщо вона виникає, має позитивний вплив на одну або декілька цілей проекту. Прикладом можливості може бути субпідрядник, який закінчує роботу раніше, що призводить до зниження витрат і скорочення термінів виконання робіт.

Можна розглянути п'ять альтернативних стратегій роботи з можливостями, які наведені нижче:

• Використовувати (експлуатувати). Стратегія реагування, за якої команда проекту діє так, щоб забезпечити реалізацію можливості.
• Ескалація (Escalate). Як і у випадку із загрозами, ця стратегія реагування на можливості використовується, коли проектна команда або спонсор проекту погоджується, що можливість виходить за рамки проекту або що запропонована реакція перевищує повноваження керівника проекту.
• Спільне використання (Share). Розподіл можливостей передбачає передачу права власності на можливість третій стороні, яка найкраще здатна отримати вигоду від цієї можливості.
• Посилювати (Enhance). Під час посилення можливостей проектна команда діє, щоб збільшити ймовірність появи або впливу можливостей. Дії з покращення на ранній стадії часто є більш ефективними, ніж спроби покращити можливість після того, як вона з'явилася.
• Прийняти (погодитися). Як і у випадку із загрозами, прийняття можливості означає визнання її існування, але не передбачає жодних проактивних дій.

Після того, як розроблено комплекс заходів реагування на ризики, його слід проаналізувати, щоб з'ясувати, чи не призвели заплановані заходи до появи вторинних ризиків.

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

Економічний підхід до визначення пріоритетності робіт дозволяє команді визначити пріоритети в діяльності з уникнення та зменшення загроз.

Порівняння очікуваної грошової вартості (EMV) ризику з очікуваною рентабельністю інвестицій (ROI) результату або функції дозволяє керівнику проекту обговорити зі спонсорами або власниками продукту, де і коли слід включити заходи реагування на ризики в заплановані роботи (див. Зображення 2-34).

Управлінський та резерв на випадок непередбачених обставин (2.8.5.3 Management and Contingency Reserve)

Резерв - це час або бюджет, виділений для управління ризиками. Резерв на випадок непередбачуваних обставин виділяється для подолання виявлених ризиків у разі їх виникнення.

Управлінський резерв - це бюджетна категорія, яка використовується для невідомих подій, таких як незаплановані роботи, що не входять до обсягу робіт.

Огляд ризиків (2.8.5.4 Risk Review)

Встановлення частого ритму або каденції сесій аналізу та зворотного зв'язку від широкого кола зацікавлених сторін допомагає орієнтуватися в проектних ризиках і проактивно реагувати на ризики.

Щоденні наради можуть використовуватися в будь-якому проекті і є джерелом для виявлення потенційних загроз і можливостей. Повідомлення про блокування або перешкоди можуть стати загрозою, якщо вони продовжуватимуть затримувати прогрес. Аналогічно, повідомлення про прогрес і прориви можуть вказувати на можливості, які слід використовувати і поширювати.

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

Обговорення ризиків на щотижневих нарадах гарантує, що управління ризиками залишається актуальним. Ці зустрічі можна використовувати для виявлення нових ризиків, а також для визначення змін до існуючих ризиків.

Ретроспективні наради та наради з вивчення уроків можна використовувати для виявлення загроз продуктивності, згуртованості проектної команди тощо, а також для пошуку шляхів покращення. Вони також можуть допомогти визначити практики, щоб спробувати різні способи використання та покращення можливостей.

Взаємодія з іншими областями результативності (2.8.6 Interactions With Other Performance Domains)

Область результативності "Невизначеність" взаємодіє з областями результативності "Планування", "Робота над проектом", "Виконання" та "Вимірювання" з точки зору продукту або результату.

Під час планування в плани можуть бути вбудовані заходи для зменшення невизначеності та ризиків. Ці заходи здійснюються в області результативності виконання. Вимірювання можуть показати, чи змінюється рівень ризику з часом.

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

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

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

Перевірка результатів (2.8.7 Checking Results)

У Таблиці 2-10 зліва наведено результати, а справа - способи їх перевірки.