Спойлер: Ця стаття описує як читати PMBOK #7, якщо ви:

1. хочете використовувати його на практиці,
2. хочете підготуватись до сертифікації PMP.

Час від часу чую, що новий PMBOK «не зрозумілий», «поганий», «не системний», тощо… додайте своє. Особливо в порівнянні з PMBOK#6. Всі вимагають повернути все взад: вареники розліпити, дим в трубу, дрова попиляти назад у колоди…

Це зрозуміло, тому що 6-й PMBOK був побудований на базі процесів, які PMI описала ще в 1996 році в першої версії PMBOK. Всі вивчили, зрозуміли, запам’ятали такі зручні для нас процеси управлінського життєвого циклу проєкту:

1. Ініціація
2. Планування
3. Виконання
4. Моніторинг та контроль
5. Завершення

Як написано в самому PMBOK#7, цитую: «Ці бізнес-процеси забезпечили послідовні та передбачувані практики:

• Які можна задокументувати;
• За допомогою яких можна було б оцінити ефективність процесів;
• За допомогою яких можна було б удосконалити процес для досягнення максимальної ефективності та мінімізації загроз.»

Але минулі PMBOKи від #1 до #6 були корисними на тих етапах зрілості проєктного менеджменту в світі (1996-2017 р). Але зрілість зростала, з’являлись нові ідеї, підходи, фреймворки, методики, інструменти, тощо. РМВОК ставав все більш неповороткий, все важче було його оновлювати задля відповідальності сучасним умовам УП:

• #1-#4 версії давали нам всім методичку – робіть ТАК, як прописано в наших процесах і збільшите ймовірність успіху проєкту.
• #5-#6 вже скрізь нагадували про tailoring, adaptation та agility (а #6 взагалі був спарований з Agile PG). Тобто підказував – спочатку подумай, а потім роби ось наприклад ТАК (знову процеси).
• #7 версія могла стати останньою, якщо б продовжила цю практику, але ж в РМІ пішли на важкий та ризикований крок, і випустили книгу, в якої пропонують спочатку подумати, а потім робити як вам заманеться. Зрілість УП в світі зросла настільки, що просто процеси з входами, виходами та інструментами вже не працюють. Сучасне УП мусить базуватись на принципах, а інструменти, процеси та артефакті – це “підніжний корм”, бери що тобі подобається.

Більш того, PMBOK#7 не варто використовувати без PMIstandards+, де можна знайти всю необхідну додаткову інформацію і по процесах, і по інструментах, і по всій решті артефактів та документів.

Як читати PMBOK #7 для використання на практиці?

PMBOK#7 пише: «Незважаючи на те, що стандарти на основі процесів ефективні в підтримці передових практик, вони є директивними за своєю природою. Оскільки управління проєктами розвивається швидше, ніж будь-коли раніше, орієнтацію минулих видань на процеси неможливо підтримувати так, щоб сприяти відображенню повноти постачання цінності.»

А ще й надає ось такий рисунок:

З цього можна зробити висновок, що все пропало. Надалі будуть існувати тільки ефемерні «принципи», та якісь нові «сфери виконання» (домени)…

Але ще раз подивіться на Сфери виконання. А я для зручності пронумерую їх та намалюю стрілочки послідовності:

Вам це не нагадує вже зрозумілий та звичний управлінський життєвий цикл проєкта від ініціації до завершення?

Давайте розглянемо рисунок з PMBOK#6:

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

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

Тепер ще раз дивимося на коло сфер виконання PMBOK#7:

1. Стейкхолдери: Згадайте два процеси ініціації проєкту з PMBOK#6 – призначення керівника проєкту спонсором або ініціатором (тобто підписання статуту проєкту) та ідентифікація стейкхолдерів. Так і тут, ця сфера виконання стоїть на першому місці, тому що визначення та розуміння стейкхолдерів має вирішальне значення на етапі ініціювання. Потреби, очікування та вплив стейкхолдерів значною мірою формують цілі та підхід проєкту. Все починається з розуміння, хто наші стейкхолдери, які їх вимоги до проєкту, як будемо їх залучати. Ця сфера виконання не закінчується майже до кінця проєкту, але основні зусилля будуть на початку.
2. Команда: Після визначення стейкхолдерів і початку проєкту важливо зібрати правильну команду. Цей домен мусить починатися з середини ініціації та тривати аж до виконання, де навички та динаміка команди відіграють життєво важливу роль у досягненні цілей проєкту. До речі, мені тут якраз не подобається підхід всіх попередніх PMBOKів. Вони пропонували збирати команду після планування… А тоді хто мав займатися плануванням? Сам проєктний менеджер на одинці? Чи зі спонсором?
3. Підхід до розробки та життєвий цикл: Ця сфера виконання зосереджена на визначенні підходу до розробки проєкту (гнучкий, водоспадний, гібридний тощо) і фаз життєвого циклу. Зазвичай це узгоджується з самим початком фази планування, де встановлюються методи та процеси для проєктної роботи.
4. Планування: Центральна для фази планування, ця сфера виконання передбачає розробку детальних планів щодо виконання, моніторингу та контролю проєкту. Для аджайл проєктів ця сфера не закінчується майже до кінця проєкту.
5. Проєктна робота: Відповідно до класичної фази виконання, ця сфера передбачає виконання проєктної роботи згідно з планами, управління ресурсами та сприяння навчальному середовищу для постійного вдосконалення.
6. Постачання: Цей домен також узгоджений із фазою виконання та зосереджується на створенні доробків проєкту, гарантуючи, що вони відповідають узгодженому обсягу та якості.
7. Вимірювання: Ця сфера тісно пов’язана з класичним етапом моніторингу та контролю, де результативність проєкту вимірюється відповідно до плану управління проєктом і вносяться необхідні коригування.
8. Невизначеність: Розгляд ризиків і невизначеностей є безперервним процесом, але особливо важливим на етапі моніторингу та контролю. Ця сфера включає виявлення, аналіз і реагування на ризики та невизначеності, які можуть вплинути на цілі проєкту. Хоча, чесно кажучи, це єдина сфера виконання яку мені хочеться переставити вище – десь після команди, або перед плануванням. Тому що невизначеність найвища на початку проєкту, та вона мусить поступово зникнути завдяки плануванню та виконанню проєкту.

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

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

Відійшовши від процесів, та переключившися на принципи, PMI забезпечів собі можливості розвивати PMBOK ще на декілька редакцій вперед.

Як читати PMBOK #7, щоб підготуватись до сертифікації PMP?

В цьому випадку все набагато складніше. Хто намагався якось зв’язати PMBOK#7 з PMP Exam Content Outline (ECO) 2021, той пам’ятає як швидко нічого не вийшло. Тому що вони дійсно ніяк не пов’язані. PMI рекомендує PMBOK#7 як одну з книг для підготовки, але тільки одну з багатьох.

Але вся потрібна для підготовки до PMP інформація в PMBOK#7 є. Звісно не по всіх тасках ECO повна, а по деяких надлишкова. Наприклад, для таска 1.14 «Promote team performance through the application of emotional intelligence» є тільки частина глави 2.2.4.4 «Навички взаємодії» з назвою «Емоційний інтелект». А для таска 2.4 «Engage stakeholders» є інформація в 99 главах, та ще й цієї темі призначені окремий принцип 3.3 «Ефективно залучати стейкхолдерів» та окрема сфера виконання 2.1 “Стейкхолдери”.

Я зробив таку табличку взаємозв’язку PMBOK#7 та PMP ECO 2021:

Можете скачати її в форматі MS Excel за посиланням – PMDoc.ua/wp-content/uploads/PMBOK7-PMPECO2021-Matching.xlsx

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

1. Читаєте від обкладинки до розділу 2.1.1.4 «Engage» включно, після цього складаєте мікроіспит 1.9 «Collaborate with stakeholders». Більше на цю тему в PMBOK#7 майже нічого не буде.
2. Далі читаєте до розділу 2.2.4.4 «Interpersonal Skills – Emotional intelligence» та складаєте мікроіспит 1.14 «Promote team performance through the application of emotional intelligence». Надалі на тему емоційного інтелекту в PMBOK #7 взагалі нічого немає.
3. Длалі в такої послідовності:

2.4.3 Project Team Composition and Structure	Task 1.11 Engage and support virtual teams
2.5.1 Project Processes	Task 1.7 Address and remove impediments, obstacles, and blockers for the team
2.5.10 Checking Results	Task 1.10 Build shared understanding
2.7.6 Growing and Improving	Task 1.5 Ensure team members/stakeholders are adequately trained
3.5.6 Delivery	Task 3.1 Plan and manage project compliance
4.2.1.1 Situational Leadership® II	Task 1.2 Lead a team
4.2.1.2 OSCAR Model	Task 1.13 Mentor relevant stakeholders
4.2.5.1 Cynefin Framework	Task 1.4 Empower team members and stakeholders
4.2.6 Project Team Development Models	Task 1.6 Build a team
4.2.6.2 Drexler/Sibbet Team Performance Model	Task 1.3 Support team performance
4.2.7.1 Conflict Model	Task 1.1 Manage conflict
4.2.7.2 Negotiation	Task 1.8 Negotiate project agreements
4.6.1 Strategy Artifacts	Task 2.13 Determine appropriate project methodology/methods and practices
4.6.3 Plans	Task 2.2 Manage communications
4.6.7 Reports – Quality report	Task 2.7 Plan and manage quality of products/deliverables
4.6.7 Reports – Risk report	Task 2.3 Assess and manage risks
4.6.8 Agreements and Contracts	Task 2.11 Plan and manage procurement
4.6.9 Other Artifacts – Project calendar	Task 2.6 Plan and manage schedule
4.6.9 Other Artifacts – Project team charter	Task 1.12 Define team ground rules
4.7 Artifacts Applied Across Performance Domains	Task 2.12 Manage project artifacts
X2.2 The Sponsor Role	Task 2.17 Plan and manage project/phase closure or transitions
X2.3 Lack of Engagement	Task 2.8 Plan and manage scope
X2.4 Sponsor Behaviors	Task 2.15 Manage project issues
X3.2 The PMO Value Proposition—Why Have One?	Task 2.9 Integrate project planning activities
X3.3 Key PMO Capabilities	Task 2.16 Ensure knowledge transfer for project continuity
X3.4 Evolving for Stronger Benefits Realization	Task 2.4 Engage stakeholders
X3.5 Learn More about PMOs	Task 2.14 Establish project governance structure
X4.1 Introduction	Task 2.1 Execute project with the urgency required to deliver business value
X4.2 Global Market Shifts	Task 2.10 Manage project changes
X4.3 Impact on Project Delivery Practices	Task 3.3 Evaluate and address external business environment changes for impact on scope
X4.4 Organizational Considerations for Product Management	Task 3.2 Evaluate and deliver project benefits and value
X4.5 Summary	Task 2.5 Plan and manage budget and resources

4. Потім читаєте до самого кінця та складаєте останній мікроіспит 3.4 «Support organizational change».

Для зручності, я додав цю послідовність в файл Excel, який ви завантажили вище (вкладинка PMBOK Reading Flow).

Висновок

Отже, це як в тому анекдоті, коли на безлюдний острів викинуло українця, німця та росіянина. Німець бігає в паніці, намагається зв’язатися з рятівниками, та висловлює стурбованість. Росіянин кудись одразу зник (можливо поперся кудись завойовувати чужі землі). А українець розорав городик, знайшов дику цибульку, здобув десь м’яса, розвів багаття та готує вже вечерю. Підходить німець і бачить, що їжі не багато і на трьох може на довго не вистачити. І намагаючись налаштувати українця проти росіянина, починає з далека: «Не люблю я цих росіян!». А українець йому: «Це тому що ти їх готувати не вмієш!»

От і тут – PMBOK багатьом не подобається, тому що вони його поки що читати не вміють.

І на останок ще одна цитата з того ж PMBOK #7, розділ X5.6 «Підсумок»: «Постійні зміни у професії управління проєктами та способах управління проєктами підтримують менш директивний стандарт. Галузеві дослідження, глобальна участь із широким представництвом галузей та ітеративний процес розгляду сформували та підтвердили перехід від стандарту, заснованого на процесах, до стандарту, заснованого на принципах. Майбутні команди можуть оцінити вплив переходу у Стандарті з управління проєктами та використати цю інформацію для покращення або перегляду майбутніх видань.»