PRINCE2

PRINCE2-проєкт на одному екрані — готовий

Більшість тих, хто шукає PRINCE2, хоче побачити, як насправді виглядає проєкт, що ведеться за цим методом. Ось один — ритейлер замінює свій інтернет-магазин, як на сторінці про WBSWBSWork Breakdown Structure — обсяг проєкту у вигляді дереваДерево всього, що проєкт має створити, розкладене, доки кожен шматок не стане досить малим, щоб його оцінити й віддати одному власникові, — і, за визначенням, нічого, чого проєкт не створює. Діти мають складати рівно свого батька, і саме це робить його межею обсягу, а не списком задач.Докладніше в статті →Усі терміни: дев’ять місяців, фіксована ціна з агенцією, — у вигляді, в якому його затвердила рада проєкту в понеділок 3 лютого 2025 року. Це ключові рішення з документації ініціації проєкту — файлу, який PRINCE2 називає PID. Наступні розділи посилаються на рядки за номерами.

1. 1.Навіщо — бізнес-кейс

   1. 1.1Причина: контракт старої платформи завершується 31 жовтня 2025 року, а продовження коштує €380 000 ще на рік
   2. 1.2Вигоди: на €240 000 на рік дешевше утримувати магазин і конверсія з 2,1% до 2,4% протягом шести місяців після запуску — близько €550 000 валової маржі на рік
   3. 1.3Витрати: €1,2 млн на створення — €950 000 фіксованої ціни агенції та €250 000 власних витрат ритейлера — і €140 000 на рік на утримання
   4. 1.4Негативний ефект, названий уголос: служба підтримки обробляє замовлення приблизно на п’яту частину повільніше перші чотири тижні, поки вчиться працювати з новою адмінкою
   5. 1.5Що завершить проєкт: прогноз запуску пізніше 31 жовтня, коли настає продовження і зникає економія першого року; або тести зручності на стадії 2, що покажуть завершення оформлення не кращим, ніж зараз

2. 2.Хто вирішує

   1. 2.1Executive: комерційний директор ритейлера — володіє бізнес-кейсом і грошима; одна людина й ніколи не менеджер проєкту
   2. 2.2Senior Users: керівник електронної комерції — за конверсію — і керівник служби підтримки — за прийняття системи та негативний ефект із 1.4
   3. 2.3Senior Suppliers: директор із поставки агенції та керівник ІТ ритейлера — за хостинг і вивантаження з ERP
   4. 2.4Менеджер проєкту: у штаті ритейлера, а не агенції; веде проєкт щодня в межах допусків стадії
   5. 2.5Менеджери команд: двоє тимлідів агенції та тимлід платежів ритейлера, якому належить рядок WBS 4.3
   6. 2.6Незалежний нагляд, і жоден не підпорядкований менеджеру проєкту: фінанси — за бізнес, керівник якості служби підтримки — за користувачів, незалежний архітектор — за постачальника
   7. 2.7Орган затвердження змін: менеджер проєкту — до €5 000 за зміну, Executive разом із Senior Users — до €20 000, вище — рада; усе з бюджету змін у €40 000
   8. 2.8Підтримка проєкту: аналітик PMOPMOProject Management Office — офіс, що задає стандарти проєктівПідрозділ, що задає стандарти управління проєктами в організації, збирає звітність із проєктів і часом наймає проєктних менеджерів. Його цінність залежить від того, що саме з цього він робить: PMO, який лише збирає статус-звіти, додає рівень, не додаючи жодного рішення.Усі терміни веде реєстри й журнали — і ніколи не та сама людина, що здійснює нагляд

3. 3.Стадії — рада затверджує по одній

   1. 3.1Запуск, грудень 2024: мандат від керівництва 2 грудня, стислий опис проєкту й попередній бізнес-кейс, ініціацію затверджено 20 грудня
   2. 3.2Ініціація, 6–31 січня 2025: цей файл, повний бізнес-кейс і план проєкту; проєкт затверджено 3 лютого
   3. 3.3Стадія 2, «Фундамент», лютий–квітень: середовища, дизайн, акаунти й каталог; межа стадії питає, чи підтверджують тести зручності конверсію з 1.2
   4. 3.4Стадія 3, «Оформлення й міграція», травень–липень: оформлення замовлення, оплата карткою, перша повна репетиція міграції; межа стадії питає, чи тримається 15 вересня
   5. 3.5Стадія 4, «Реліз», серпень–жовтень: тести, приймання, перехід у понеділок 15 вересня, посилена підтримка до п’ятниці 10 жовтня, закриття в п’ятницю 24 жовтня
   6. 3.6На кожній межі рада ухвалює одне з трьох рішень: затвердити наступну стадію, попросити план для винятку або достроково закрити проєкт

4. 4.Допуски — сім цільових показників

   1. 4.1Час: запуск 15 вересня, не пізніше 29 вересня; кожна стадія може закінчитися на тиждень раніше чи пізніше
   2. 4.2Вартість: проєкт — до 5% понад €1,2 млн; кожна стадія — до 10% понад власний бюджет
   3. 4.3Обсяг: нічого з гілок WBS 4, 5, 6 і 8 не переноситься; до двох інших робочих пакетів можна завершити протягом чотирьох тижнів після запуску
   4. 4.4Якість: оформлення завантажується швидше ніж за 2 секунди для 95% запитів за потрійного піку минулої «чорної п’ятниці», і на момент запуску немає жодного відкритого дефекту першої категорії
   5. 4.5Вигоди: конверсія може бути 2,3% замість 2,4% без участі ради; нижче — рада переглядає 1.2
   6. 4.6Ризик: жодної загрози з експозицією понад €50 000 без власника й відповіді; усі відкриті загрози разом — у межах ризикового бюджету €80 000
   7. 4.7Сталість: стійки старого магазину в дата-центрі вимкнено протягом 30 днів після запуску; сторінки товарів — до 1,5 МБ замість теперішніх 4,2 МБ

5. 5.Як рада дізнається про стан справ

   1. 5.1Контрольні звіти (checkpoint): кожен менеджер команди — менеджеру проєкту, щоп’ятниці
   2. 5.2Звіт про стан (highlight): менеджер проєкту — раді щодругої п’ятниці; одна сторінка, прогноз щодо кожного рядка групи 4, три головні ризики, ухвалені рішення щодо проблем
   3. 5.3Звіт про виняток (exception): протягом двох робочих днів після того, як будь-який прогноз виходить за допуск стадії, — причина, варіанти, рекомендація
   4. 5.4Рада збирається на межах стадій і коли надходить виняток — не щотижня; прогноз за межами допуску проєкту йде повз неї до керівництва компанії

6. 6.Продукти — що поставляють, перш ніж скільки це триватиме

   1. 6.1Продукт проєкту: новий магазин, що приймає замовлення й оплату карткою для всього каталогу, з перенесеними акаунтами та історією замовлень, — Senior Users приймають його після користувацького приймання (WBS 7.4) і чотирьох тижнів посиленої підтримки (WBS 8.4)
   2. 6.2Розклад продуктів — це тридцять один робочий пакет із WBS; опис кожного продукту — його запис у словнику, як 4.3 на сторінці про WBS
   3. 6.3Робочі пакети затверджують по одному, кожен із власним допуском — оплата карткою, 4.3: 72 години плюс-мінус 10%
   4. 6.4Реєстр якості фіксує кожну перевірку: який продукт, хто перевіряв, щодо чого і з яким результатом

7. 7.Уроки, закриття і що після

   1. 7.1Уроки, прочитані до старту: переїзд 2018 року переносив замовлення один раз, у ніч запуску, і втратив два дні історії — тож цей план має дві повні репетиції
   2. 7.2Журнал уроків читають на кожній межі стадії; звіт про уроки після закриття йде в PMO
   3. 7.3Закриття: підтвердження приймання, передача в експлуатацію, рекомендовані подальші дії — серед них повернення коштів через оформлення, про яке попросили на третій місяць
   4. 7.4Огляди вигод через три й шість місяців після запуску, у грудні 2025 і березні 2026 року, — їх ведуть Senior Users і звітують Executive, коли проєкту вже не існує

8. 8.Налаштовано під цей проєкт

   1. 8.1Команди агенції працюють двотижневими спринтами всередині кожного робочого пакета; огляд спринту і є контрольним звітом із 5.1
   2. 8.2Окремих планів команд немає: беклоги спринтів і є планами команд
   3. 8.3Ризики, проблеми й уроки живуть в одному інструменті з трьома поданнями, а не в трьох документах

Що таке PRINCE2 — метод ухвалення рішень, а не будування

PRINCE2 часто порівнюють зі Scrum, і це порівняння спершу спантеличує майже кожного. Це не альтернативи. Scrum описує, як команда перетворює перелік роботи на робочий продукт. PRINCE2 описує, як організація вирішує розпочати проєкт, регулярно перевіряє, чи варто його продовжувати, і зупиняє, коли відповідь змінюється. Одне — про будування. Друге — про рішення й гроші.

Решту пояснює власне визначення методу. Проєкт, словами PRINCE2, — це «тимчасова організація, створена для поставки одного чи кількох бізнес-продуктів відповідно до узгодженого бізнес-кейсу». Кожна частина цього речення несе вагу. Тимчасова — означає, що є запланований кінець і процес закриття. Організація — означає ролі й права ухвалювати рішення, а не просто команду. А узгоджений бізнес-кейс — це записана причина витрачати гроші, та сама, яку рада знову й знову перечитує в рядку 1.5.

П’ять інтегрованих елементів

Видання 2023 року описує метод як п’ять елементів, що працюють лише разом. Чотири з них існували й раніше; люди як окремий елемент — новинка, і видання ставить їх у центр схеми.

Чотири рівні — і чому рада не є наглядовою комісією

PRINCE2 розділяє чотири рівні повноважень. Бізнес-рівень, що стоїть поза проєктом, замовляє його: видає мандат, призначає Executive і встановлює допуски проєкту. Рада проєкту спрямовує. Менеджер проєкту керує щодня. Команди поставляють. Кожен рівень працює в межах, заданих рівнем вище, і звітує йому в фіксованому форматі — саме це й записує група 5 хука.

Рада схожа на наглядову комісію, але це інша річ. Наглядова комісія — зазвичай форум: багато людей, порядок денний, оновлення статусу і жодного одноосібного власника рішення. Рада PRINCE2 має одну людину, що ухвалює рішення, — Executive, якого консультують ті, хто говорить від імені користувачів і постачальників. Вона збирається, коли є що вирішувати, і її рішення мають лише три можливі результати, перелічені в рядку 3.6.

Звідки він узявся і як називається тепер

Назва — абревіатура: PRojects IN Controlled Environments. 1989 року урядове агентство Великої Британії з комп’ютерних систем, CCTA, взяло версію старішого методу PROMPT II за стандарт для ІТ-проєктів і назвало її PRINCE. PRINCE2 з’явився 1996 року як метод для будь-яких проєктів, був оновлений 2009-го і 2017-го і переписаний як 7-ме видання 2023 року. 2013 року права перейшли від Кабінету міністрів до AXELOS — спільного підприємства з Capita, — а 2021-го AXELOS купила PeopleCert.

Два перейменування варто знати перед співбесідою чи тендером. 2023 року сім тем стали сімома практиками; більшість навчальних матеріалів в інтернеті досі каже «теми», і це ті самі сім речей. А PeopleCert відтоді перетворила PRINCE2 на назву цілої родини. Сам метод тепер продається як PRINCE2 Project Management, Version 7, з іспитом Foundation на 60 питань, з яких для складання треба 36. MSP тепер називається PRINCE2 Programme Management, MoP — PRINCE2 Portfolio Management, а M_o_R — PRINCE2 Risk Management.

Сім принципів — і як виглядає кожен, коли його немає

Принципи — це та частина, яку не обговорюють. Метод каже це одним реченням: якщо їх не застосовано, «це не PRINCE2-проєкт». Проєкт може відмовитися від документів, об’єднати процеси й суміщати ролі — і лишатися PRINCE2. Якщо він порушує принцип, то не лишається, хоч би що казали його папери. Корисна тут остання колонка: як кожен принцип виглядає ззовні, коли його не стало.

Третій принцип 2023 року отримав додаткове слово: ролі, відповідальність і стосунки. Це не прикраса. Проєкт позичає людей із кількох організацій на кілька місяців, і новий розділ видання про людей каже, що результат залежить від «міцності стосунків між ними». Схема ролей каже, хто вирішує. Вона не змусить керівника служби підтримки з рядка 2.2 довіряти агенції настільки, щоб повідомити про проблему на третьому тижні, а не на дванадцятому.

Сім практик — колишні теми

Якщо принципи — це те, що мусить триматися, то практики — те, чим треба керувати від першого дня до останнього. Жоден із цих аспектів не можна «зробити» один раз. І кожен приносить свої документи — звідси репутація методу як паперового, і саме тому існує група 8 хука.

PRINCE2 розрізняє шість видів проблем, і назва кожного підказує, хто нею займається. Проблема в прямому сенсі (problem) має негайний негативний вплив. Занепокоєння (concern) ще потребує оцінки строків і впливу. Зовнішня подія може вплинути на проєкт ззовні. Бізнес-можливість — несподіваний плюс. Запит на зміну пропонує змінити базовий план — затверджені версії планів і продуктів. Невідповідність специфікації (off-specification) — продукт, який не відповідатиме своїй специфікації якості.

Бюджет змін і орган затвердження змін із рядка 2.7 не дають запитам на зміну закупорити раду. Візьмімо запит, описаний на сторінці про WBS на третій місяць: повернення коштів через нове оформлення, «бо це ж очевидно частина платежів». Запис у словнику для 4.3 виключає повернення, тож це запит на зміну, а не уточнення. Агенція оцінила його в €18 000 і тиждень стадії 3. Це більше за €5 000 менеджера проєкту й менше за €20 000, які Executive і Senior Users можуть затвердити разом, — тож вони удвох вирішили це за одну розмову. Відклали на після запуску, і він повертається в рядку 7.3 як подальша дія. Раді не знадобилося збиратися.

Сім процесів — життя одного проєкту від початку до кінця

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

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

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

Допуски й винятки — як рада не заважає працювати

Допуск — це дозволене відхилення від плану, доки не треба питати рівень вище. PRINCE2 задає допуски для семи цільових показників, і видання 2023 року додало сьомий — сталість. Кожен рівень дає нижчому менший запас, ніж має сам. Бізнес-рівень дає раді допуски проєкту. Рада дає менеджеру проєкту допуски стадії. Менеджер проєкту дає кожному менеджеру команди допуски робочого пакета. Доки прогноз лишається в межах, рівню вище не треба чути нічого, крім регулярного звіту.

Виняток — це не те, що щось пішло не так. Це прогноз, що щось закінчиться поза допуском. Саме ця різниця робить основну роботу: менеджер проєкту піднімає виняток тієї миті, коли прогноз перетинає межу, а не тоді, коли дата вже минула, — і це дає раді час вибрати. Ось виняток, який трапився в проєкті магазину, крок за кроком, як іде процедура винятків PRINCE2.

• Проблема, 11 червня 2025 року: платіжний провайдер переносить слот сертифікації 3-D Secure для магазину на три тижні пізніше. Менеджер команди платежів того ж дня повідомляє менеджера проєкту.
• Прогноз: стадія 3 тепер завершується на три тижні пізніше, а допуск у рядку 4.1 — один тиждень. Запуск зсунувся б на 6 жовтня — поза допуском і самого проєкту.
• Звіт про виняток, 13 червня, — за два робочі дні, як вимагає рядок 5.3. Варіант A: чекати й просити керівництво компанії погодитися на запуск 6 жовтня. Варіант B: провести тести продуктивності й безпеки на тестовому двійнику провайдера, сертифікуватися паралельно й поглинути півтора тижня в стадії 3 за €22 000. Варіант C: запуститися на старішій платіжній сторінці провайдера без нового сценарію 3-D Secure і оновитися в листопаді. Рекомендація: B.
• Рада вирішує, 16 червня: варіант B і запит на план винятку. Варіант C відхилено з посиланням на 4.4: платіжний сценарій, який клієнт побачить зміненим двічі за три місяці, — проблема якості, а не економія.
• План винятку замінює решту стадії 3, з власними допусками, і рада затверджує його 20 червня. Запуск лишається на 15 вересня; €22 000 беруть із ризикового бюджету з 4.6, бо затримка провайдера вже була в реєстрі.

Два проєкти, які метод існує, щоб зупиняти

Обидва кейси — британські державні проєкти, перевірені Національним аудиторським офісом, у країні, уряд якої і написав PRINCE2. Жоден не провалився через брак методу на папері. Кожен прив’язано до рядка хука, який на нього відповідає.

FiReControl — сім років до зупинки

FiReControl мав замінити 46 місцевих диспетчерських пожежної служби Англії дев’ятьма регіональними центрами зі спільною національною комп’ютерною системою. Міністерство й Казначейство взяли зобов’язання 2004 року, як з’ясував Національний аудиторський офіс, «на основі дуже приблизних і нереалістичних оцінок витрат у £120 млн та очікуваної загальної чистої економії в £86 млн». Першу комплексну оцінку зробили через три роки, і вона показала £340 млн. Будівлі з’явилися першими: перші центри добудували в червні 2007 року, через три місяці після підписання ІТ-контракту з EADS.

Запобіжники методу існували на папері й були відсутні на практиці. 2008 року урядовий орган з перевірок з’ясував, що «рада проєкту не працювала як ефективний орган ухвалення рішень»; 2009-го — що «немає єдиного авторитетного власника вимог користувачів» і є «культурна вада — не ділитися поганими новинами рано». За час проєкту змінилося п’ять відповідальних власників і чотири директори проєкту. Міністерство розглядало припинення 2008 і 2009 року — і продовжувало. Коли в грудні 2010 року проєкт нарешті скасували, на нього вже витратили £245 млн, а завершення довело б загальну суму до £635 млн. Аудитори оцінили втрати щонайменше в £469 млн, а утримання дев’яти порожніх центрів уже коштувало £32 млн.

Рішення в грудні 2010 року, за словами аудиторів, було виправданим: продовження коштувало б ще £390 млн і рік затримки, а скасування з модернізацією місцевих диспетчерських — £310–400 млн. Саме таке порівняння вимагає рядок 1.5 на кожній межі: витрати, що ще попереду, проти альтернатив, без уже витрачених грошей. Безповоротні витрати (sunk cost) не повернеш завершенням проєкту, тож їм місце у звіті про уроки, а не в рішенні. FiReControl зробив таке порівняння один раз — із запізненням на шість років.

Digital Media Initiative у BBC — нікому сказати

Digital Media Initiative мала дати співробітникам BBC змогу створювати, поширювати й архівувати відео й аудіо зі своїх робочих місць. Siemens отримала контракт у лютому 2008 року; у липні 2009-го його розірвали — 18 місяців минуло, робочої системи не було, і BBC забрала роботу всередину. Меморандум Національного аудиторського офісу від 27 січня 2014 року з’ясував, що «BBC не призначила відповідального власника як єдину точку відповідальності». Розробка й бізнес-кейс були в одному підрозділі, вигоди — у підрозділах, що мали користуватися системою, і розрив між ними не належав нікому.

Звітність відмовила саме там, де стоїть рядок 5.3. Рейтинг ризику програми став червоним за жовтень–грудень 2011 року; правління дізналося про це в червні 2012-го, а BBC Trust — у липні 2012-го. До травня 2012 року робота відставала на 15 місяців від графіка в бізнес-кейсі, а бізнес-кейс, затверджений у квітні 2010 року, так і не переглянули. BBC скасувала програму в травні 2013 року, витративши £125,9 млн — £98,4 млн за вирахуванням того, що повернула від Siemens. Саме правління під час закриття назвало причиною «нездатність усвідомити серйозність проблем у звітах, які воно отримувало».

Де він вироджується — і чого PRINCE2 не може

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

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

Коли це застосовувати

Пов’язані сторінки

• МенеджментPMBOKPMBOK Guide — це довідник PMI з управління проєктами; його восьме видання (листопад 2025) задає шість принципів, сім доменів і сорок процесів. Це вже третій різний документ під цією назвою менш ніж за десять років: 6-те видання приписувало 49 процесів, 7-ме замінило їх дванадцятьма принципами, а 8-ме повернуло процеси. Сторінка починається з усіх елементів чинного видання на одному екрані; далі — яке видання хтось має на увазі, шість принципів, як поєднуються домени й процеси, налаштування на одному проєкті, PMBOK поруч із PRINCE2 і Scrum, система виплат Phoenix і де все це вироджується.
• МенеджментWork Breakdown StructureWork Breakdown Structure (WBS) — це ієрархічний розклад усього, що проєкт має створити, — і, за визначенням, нічого поза цим. Це межа обсягу, намальована як дерево: якщо якоїсь роботи в ньому немає, її немає і в проєкті, а додати її — це зміна, а не правка. Сторінка починається з готового WBS для ІТ-проєкту — вісім гілок, тридцять один робочий пакет, з кодами й рівно 100% разом; далі — правила, що роблять дерево WBS, словник, де насправді живе обсяг, коди й контрольні рахунки, глибина розкладу, WBS поруч з agile-беклогом, три задокументовані кейси і де все це вироджується.
• МенеджментWaterfallWaterfall — це спосіб вести проєкт у фіксованому порядку, коли кожну фазу завершують і затверджують до початку наступної. Його зазвичай викладають як застаріле, що його замінив Agile, і це водночас несправедливо й некорисно: це правильний вибір щоразу, коли змінити рішення пізно коштує дорожче, ніж ретельно все описати зараз. Сторінка починається з усіх фаз на одному екрані — що кожна створює, який гейт її закриває і скільки коштує зміна на ній; далі — що насправді написав Ройс 1970 року, кожна фаза по черзі, V-модель, шість питань, що вирішують між предиктивним та ітеративним планом, гібриди, якими живуть реальні проєкти, пʼять задокументованих випадків і де все це вироджується.