PMBOK

PMBOK на одному екрані — восьме видання, усі елементи

Більшість тих, хто шукає PMBOK, хоче побачити його структуру, а структура за чотири роки змінилася двічі. Ось чинна, повністю: спершу шість принципів, потім сім доменів результативності з кожним із їхніх сорока процесів. Якщо процес перейменували порівняно з 6-м виданням, стара назва стоїть поруч, бо саме її більшість досі вимовляє вголос. Назви процесів подано англійською, як у книжці. Наступні розділи посилаються на рядки за номерами.

1. 1.Governance (врядування) — 9 процесів; єдиний домен у всіх п’яти фокус-областях

   1. 1.1Initiate Project or Phase — раніше Develop Project Charter
   2. 1.2Integrate and Align Project Plans
   3. 1.3Plan Sourcing Strategy — раніше Plan Procurement Management
   4. 1.4Manage Project Execution — раніше Direct and Manage Project Work
   5. 1.5Manage Quality Assurance — раніше Manage Quality
   6. 1.6Manage Project Knowledge
   7. 1.7Monitor and Control Project Performance
   8. 1.8Assess and Implement Changes — раніше Perform Integrated Change Control
   9. 1.9Close Project or Phase

2. 2.Scope (обсяг) — 6 процесів

   1. 2.1Plan Scope Management — серед його результатів тепер і план управління якістю
   2. 2.2Elicit and Analyze Requirements — раніше Collect Requirements
   3. 2.3Define Scope
   4. 2.4Develop Scope Structure — раніше Create WBSWBSWork Breakdown Structure — обсяг проєкту у вигляді дереваДерево всього, що проєкт має створити, розкладене, доки кожен шматок не стане досить малим, щоб його оцінити й віддати одному власникові, — і, за визначенням, нічого, чого проєкт не створює. Діти мають складати рівно свого батька, і саме це робить його межею обсягу, а не списком задач.Докладніше в статті →Усі терміни
   5. 2.5Monitor and Control Scope — раніше Control Scope; тепер охоплює й вимірювання якості результатів
   6. 2.6Validate Scope

3. 3.Schedule (розклад) — 3 процеси; у 6-му виданні було шість

   1. 3.1Plan Schedule Management
   2. 3.2Develop Schedule
   3. 3.3Monitor and Control Schedule — раніше Control Schedule

4. 4.Finance (фінанси) — 4 процеси; раніше Cost

   1. 4.1Plan Financial Management — раніше Plan Cost Management
   2. 4.2Estimate Costs
   3. 4.3Develop Budget — раніше Determine Budget
   4. 4.4Monitor and Control Finances — раніше Control Costs

5. 5.Stakeholders (стейкхолдери) — 7 процесів; комунікації тепер тут

   1. 5.1Identify StakeholdersStakeholderтой, кого зачіпає результатБудь-хто, чию роботу або результати зачіпає те, що будують, — незалежно від того, чи може він щось вирішувати. На практиці важлива різниця між тими, з ким радяться, і тими, хто може сказати «ні».Усі терміни
   2. 5.2Plan Stakeholder Engagement
   3. 5.3Plan Communications Management
   4. 5.4Manage Stakeholder Engagement
   5. 5.5Manage Communications
   6. 5.6Monitor Stakeholder Engagement
   7. 5.7Monitor Communications

6. 6.Resources (ресурси) — 5 процесів

   1. 6.1Plan Resource Management
   2. 6.2Estimate Resources — раніше Estimate Activity Resources
   3. 6.3Acquire Resources
   4. 6.4Lead the Team — раніше два процеси, Develop Team і Manage Team
   5. 6.5Monitor and Control Resourcing — раніше Control Resources

7. 7.Risk (ризик) — 6 процесів

   1. 7.1Plan Risk Management
   2. 7.2Identify Risks
   3. 7.3Perform Risk Analysis — раніше два процеси, якісний і кількісний аналіз
   4. 7.4Plan Risk Responses
   5. 7.5Implement Risk Responses
   6. 7.6Monitor Risks

8. 8.П’ять фокус-областей — колишні групи процесів під новою назвою

   1. 8.1Initiating (ініціація) — дозвіл на проєкт або на його наступну фазу
   2. 8.2Planning (планування) — як поводитимуться з обсягом, часом, грошима, людьми й ризиками; близько половини з сорока процесів
   3. 8.3Executing (виконання) — робота і керівництво людьми, які її виконують
   4. 8.4Monitoring and Controlling (моніторинг і контроль) — порівняння того, що відбувається, із планом і рішення про зміни; триває весь час поруч з іншими чотирма
   5. 8.5Closing (завершення) — приймання, передача й уроки — для проєкту або для фази

Яке PMBOK хтось має на увазі — три видання, три різні документи

PMI видає довідник із 1996 року. Двадцять років видання мали одну форму — групи процесів на перетині з областями знань, — а кількість процесів дрейфувала від 37 до 49. Потім форма змінилася двічі, тож нині в ужитку одразу три видання: організації, контракти й посадові інструкції досі працюють за 6-м, ціле покоління сертифікованих фахівців вивчало 7-ме, а 8-ме — те, що PMI видає зараз.

Один том — два документи. Від 7-го видання книжка містить The Standard for Project Management — нормативну частину — разом із Guide, яке пояснює. PMI називає 8-ме видання «найбільш заснованим на даних і сформованим спільнотою оновленням в історії довідника», побудованим на «понад 48 000 точок даних» від практиків. Коли хтось каже «PMBOK каже», варто спитати, яке видання і який із двох документів, бо стандартом є лише один із них.

Іспит — це не книжка

Багато читачів приходять сюди на шляху до PMP — сертифікації PMI Project Management Professional. Із липня 2026 року іспит іде за новою програмою: People — 33%, Process — 41%, Business Environment — 26%. Близько 40% питань стосуються предиктивних підходів, а решта ділиться між agile та гібридними. Програма PMI прямо каже, що «між цією оновленою програмою іспиту PMP і A Guide to the Project Management Body of Knowledge є помітні відмінності». Готуйтеся спершу за програмою; довідник — джерело для неї, а не її навчальний план.

Шість принципів — чого кожен вимагає звичайного понеділка

Принцип корисний лише тоді, коли змінює рішення. Ось кожен із шести на одному проєкті — ритейлер замінює інтернет-магазин, як на сторінках про WBS і PRINCE2, дев’ять місяців за фіксованою ціною, — і рішення, яке він змінив.

• 1. Дивитися цілісно

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

• 2. Фокусуватися на цінності

  Цінність — дешевший в утриманні магазин і конверсія з 2,1% до 2,4%, а не тридцять один робочий пакет. Огляди вигод через три й шість місяців після запуску — місце, де принцип справді перевіряють.

• 3. Вбудовувати якість

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

• 4. Бути підзвітним лідером

  Бізнес-кейсом володіє одна названа людина — комерційний директор. Менеджер проєкту звітує про прогноз щодва тижні, включно з поганими, — принципи дбайливого врядування й лідерства 7-го видання, об’єднані в один.

• 5. Інтегрувати сталість

  Сторінки товарів зменшуються з 4,2 МБ до менш ніж 1,5 МБ, а стійки старого магазину вимикають протягом 30 днів після запуску — це записано й вимірюється, як час і вартість. Як принцип — нове у 2025 році.

• 6. Будувати культуру повноважень

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

Три принципи 7-го видання не мають тезок серед шести, і кожен живе рівнем нижче. Налаштування — окремий розділ, про нього розділ нижче. Оптимізація відповідей на ризики живе в домені Risk, групі 7 хука. Залучення стейкхолдерів — у домені Stakeholders, групі 5.

Сім доменів і сорок процесів — як поєднується структура

Домен результативності — це сфера практики, яку проєкт має тримати здоровою. Сорок процесів живуть усередині доменів, і кожен процес також належить до однієї з п’яти фокус-областей — груп процесів 6-го видання під новою назвою. Вони перетинаються: домен каже, про що дбають, а фокус-область — на якому етапі життя проєкту чи фази зосереджена робота.

Фокус-області — не фази, і читати їх як фази — найстаріша хибна інтерпретація PMBOK, перенесена без змін від груп процесів. Моніторинг і контроль триває весь час поруч з іншими. Проєкт із трьома фазами проходить усі п’ять фокус-областей у кожній із них — тому перший і останній процеси називаються Initiate Project or Phase і Close Project or Phase.

Арифметику варто зробити один раз, бо вона показує, звідки взялися сорок. У 6-му виданні їх було 49. Schedule втратив три процеси, якість і закупівлі — по два, а дві пари злилися в один процес кожна: два аналізи ризиків у рядку 7.3 і розвиток та управління командою в рядку 6.4. Це дев’ять, а 49 мінус дев’ять — сорок. Якість не зникла разом зі своєю областю. Власний список виправлень PMI показує, що Plan Scope Management видає план управління якістю, а Monitor and Control Scope визначено як такий, що охоплює «вимірювання якості результатів».

Кожен домен закінчується перевіркою

Найпрактичніше доповнення у 8-му виданні легко пропустити: кожен домен закінчується таблицею цільових результатів і перевіркою, яка показує, чи досягнуто кожен. Таблиця домену Scope, 2-6, вимірює розповзання обсягу (scope creep) як незаплановані результати, поділені на всі результати, а стабільність вимог — як незмінені вимоги, поділені на всі вимоги, обидва у відсотках. На проєкті магазину після затвердження базового плану додали три результати — ціни другої служби доставки, сторінку замовлення для друку й вивантаження для фінансів, — тож розповзання обсягу становило 3 із 34, або 8,8%. Із 124 вимог базового плану 109 жодного разу не змінилися: стабільність 87,9%.

Перейменовані процеси несуть із собою й agile-прочитання. Визначення Develop Scope Structure, рядок 2.4, у списку виправлень каже, що «в agile-проєктах ця робота відповідає декомпозиції беклогу продукту», де робочі елементи можна розбити на епіки, фічі й user storiesuser storyпотреба з погляду користувачаКороткий опис того, що потрібно користувачеві й навіщо, зазвичай у формі «Як …, я хочу …, щоб …», — обіцянка розмови, а не специфікація. Слабкість тут та сама, що й сила: без критеріїв приймання, узгоджених у цій розмові, двоє людей збудують з однієї картки дві різні речі.Докладніше в статті →Усі терміни, — ту саму ієрархію, яку розбирає сторінка про епіки, фічі й задачі. WBS і беклог тепер — один процес двома діалектами.

Налаштування — сорок процесів, один проєкт

У 7-му виданні налаштування було принципом. У 8-му це розділ, і опис PMI вміщається в один рядок: «Навчіться адаптувати практики, інструменти й техніки до вашої команди, організації та середовища». На практиці це рішення щодо кожного процесу: виконувати формально, виконувати полегшено, вбудувати в інший документ чи залишити комусь іншому. Ось запис проєкту магазину — усі сорок рішень.

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

PMBOK поруч із PRINCE2 і Scrum

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

Проєкт магазину використав усі три без суперечностей. Рада PRINCE2 затверджувала стадії й тримала допуски. Процеси PMBOK дали техніки, які рада вважала відомими комусь, — оцінку за фіксованою ціною в рядку 4.2, карту стейкхолдерів у 5.1, відповіді на ризики в 7.4. А команди агенції працювали за Scrum усередині кожного робочого пакета. Суперечка про те, хто з трьох «кращий», зазвичай означає, що у двох людей різні проблеми.

Phoenix — проєктна структура, яку сприйняли за врядування

Система виплат зарплати Phoenix уряду Канади — найяскравіший недавній випадок, коли бракувало всіх принципів одразу, і її аудит надзвичайно точний. Міністерство громадських послуг і закупівель Канади мало централізувати виплати для 46 відомств у новому центрі в Мірамічі й перевести весь уряд на нову програму розрахунку зарплати. Бюджет — $310 млн, із них $155 млн — на створення програми. Очікувана економія — близько $70 млн на рік із 2016–17 фінансового року, переважно тому, що кожен фахівець із виплат мав вести 400 справ працівників замість 184.

Попередження були. Огляд Gartner на замовлення Секретаріату Казначейської ради, переданий 11 лютого 2016 року, назвав один критичний ризик: Phoenix може не виплачувати зарплату точно й вчасно, бо систему не протестовано повністю. Він рекомендував поступове розгортання й паралельну роботу старої системи. Phoenix запустили для 34 відомств 24 лютого 2016 року і для решти 67 — 21 квітня. До 30 червня 2017 року через помилки не було виплачено понад $520 млн, а в черзі чекали 494 500 запитів щодо зарплати.

Висновок Генерального аудитора був прямим: «Створення і впровадження Phoenix стало незбагненним провалом управління проєктом і нагляду». Для цієї сторінки найважливіше речення звучить далі. Міністерство мало комітети, голів і лінії звітності й вважало, що цього досить: «Міністерство громадських послуг і закупівель Канади вважало комітети й структуру управління проєктом Phoenix, які воно створило, врядуванням і наглядом. На нашу думку, це насправді була лише структура управління проєктом». Врядування — це та частина, що може сказати проєкту «ні», і вона мусить доходити до того, хто ухвалює рішення, шляхом, який проєкт не контролює.

Чому середні значення ховають такі проєкти, як Phoenix

Phoenix — не виняток. Бент Фліпб’єрг і Александер Будзіер 2011 року дослідили для Harvard Business Review 1 471 ІТ-проєкт. Середнє перевищення витрат становило 27% — звучить так, ніби з цим можна жити. Але «кожен шостий проєкт у вибірці був чорним лебедем із перевищенням витрат у середньому на 200% і перевищенням строків майже на 70%». Дослідження 2022 року, у якому Фліпб’єрг із колегами проаналізували 5 392 ІТ-проєкти, показало, що перевищення підкоряються степеневому розподілу: багато малих і «товстий хвіст» екстремальних, який план, побудований на середніх, грубо недооцінить.

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

На практиці PMBOK з’являється у двох місцях: як словник PMOPMOProject Management Office — офіс, що задає стандарти проєктівПідрозділ, що задає стандарти управління проєктами в організації, збирає звітність із проєктів і часом наймає проєктних менеджерів. Його цінність залежить від того, що саме з цього він робить: PMO, який лише збирає статус-звіти, додає рівень, не додаючи жодного рішення.Усі терміни і як джерело для PMP. Знати його найважливіше саме на цій межі: інженерній команді, що працює за Scrum усередині програми під управлінням PMO, потрібен хтось, хто перекладе «ціль спринту» мовою PMO так, щоб жодна сторона не відчула, що її перекладають. Вироджується він передбачувано.

• Цитувати одне видання так, ніби воно чинне, — п’ять груп процесів у 2021 році, дванадцять принципів у 2026-му.
• Читати фокус-області, як колись групи процесів, як фази проєкту.
• Виконувати всі сорок процесів формально на тримісячному проєкті — це театр управління.
• Сприймати принципи як чекліст для галочок, а не як основу для міркувань.
• «Ми це налаштували» як відповідь на питання, чому пропустили щось потрібне, — без жодного запису рішення.
• Панель показників, побудована на переставлених формулах першого накладу.
• Комітети й лінії звітності, видані за врядування, без шляху до того, хто ухвалює рішення, який проєкт не контролює.
• Словник PMBOK, яким перейменовують agile-процес, не змінюючи способу ухвалення рішень.

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

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

• МенеджментPRINCE2PRINCE2 — це метод управління проєктами, збудований навколо одного питання, на яке проєкт відповідає знову й знову: чи варто його й далі фінансувати? Він майже нічого не каже про те, як виконується робота, і дуже багато — про те, хто має право вирішити, що вона триває. Сторінка починається з одного проєкту, налаштованого за PRINCE2, у готовому вигляді; далі — що таке цей метод, сім принципів, сім практик і сім процесів, допуски й винятки, два проєкти, які метод існує, щоб зупиняти, і де він вироджується.
• МенеджментРизик-менеджментРизик-менеджмент — це рішення наперед про те, що може піти не так, на що з цього варто витратити гроші вже зараз і хто помітить, якщо воно почнеться. Ризик — це ще не проблема, і саме тому з ним дешево мати справу. Сторінка починається з повної карти — сім груп і двадцять вісім рядків, які можна звірити з власним проєктом, — а далі: як оцінити ризик без вдаваної точності, чотири відповіді, практики, які справді зрушують число, і шість публічних провалів із контролем, якого в кожному бракувало.
• МенеджментМетодики оцінюванняМетодики оцінювання в IT — це одиниці, якими команда прогнозує, скільки роботи займе завдання: story points, людино-дні, години або розміри футболок (T-shirt). Вони не взаємозамінні. Кожна переносить крок, що перетворює зусилля на дату, в інше місце й до іншої людини, і кожна ламається по-своєму, впізнавано. Сторінка починається з усіх чотирьох поруч і таблиці, яка з них пасує до якого рішення, а далі — чому чесна оцінка є діапазоном, а не числом, кожна одиниця детально, шість задокументованих оцінок, що пішли не так, і де оцінювання перетворюється на театр.