PMBOK
PMBOK — це звід знань PMI з управління проєктами і, починаючи з 7-го видання, принципово інший документ, ніж той, якого більшість вчили. Він перестав приписувати 49 процесів і тепер описує 12 принципів та 8 доменів результативності, що робить його способом мислення, а не процедурою для виконання. На цій сторінці — усі дванадцять принципів, усі вісім доменів, стара структура, яку ви, найімовірніше, носите в голові, і чим це відрізняється від PRINCE2.
- Чинне видання
- 7-ме
- Структура
- 12 принципів · 8 доменів
- Видає
- PMI
Зміна, яку більшість пропустила
Два десятиліття PMBOK був процесним стандартом: п’ять груп процесів, десять областей знань, 49 процесів, кожен із визначеними входами, інструментами й виходами. Якщо вас вчили PMBOK до 7-го видання, ви носите саме цю модель — і саме її досі припускає більшість співбесідних питань.
7-ме видання повністю замінило цю структуру. Замість процесів для виконання воно подає 12 принципів для міркування і 8 доменів результативності, за якими треба стежити, і трактує предиктивний, agile та гібридний підходи як однаково легітимні, а не agile як додаток. Заявлена причина: фіксований набір процесів не міг лишатися актуальним для того діапазону робіт, які тепер називають проєктами.
Одна структурна деталь пояснює значну частину плутанини навколо чинного видання. Те, що видано одним томом, насправді є двома документами. Перший, The Standard for Project Management, є нормативною частиною й містить 12 принципів та систему постачання цінності. Другий, власне Guide, є пояснювальним і містить 8 доменів результативності, налаштування та каталог моделей, методів і артефактів. Коли хтось каже «PMBOK каже», варто розуміти, яку половину він має на увазі, бо стандартом є лише одна з них.
Дванадцять принципів
Принципи є нормативним ядром чинного видання, і їх варто читати поодинці, а не як перелік чеснот. Кожен — це позиція щодо рішення, з яким проєктні менеджери справді стикаються, і кілька з них суперечать тому, як проєкти зазвичай ведуть, — і саме це в них корисне.
| Принцип | До чого він зобов’язує |
|---|---|
| Дбайливе врядування | Діяти чесно й дбати про довірене — включно із зобов’язаннями поза проєктом: перед організацією і перед тими, кого він зачіпає. |
| Команда | Свідомо будувати середовище співпраці: спільна власність, ясні зони відповідальності й повноваження ухвалювати рішення там, де є знання. |
| Стейкхолдери | Залучати їх активно й постійно, а не розсиланням звіту. Їхнє сприйняття цінності є частиною того, чи проєкт вдався. |
| Цінність | Суть у цінності, а не в результатах. Проєкт, що видав усе зі списку й не дав вигоди, не вдався, — і цей принцип існує, щоб це можна було сказати вголос. |
| Системне мислення | Помічати взаємодії між частинами й реагувати на них. Проєкт живе всередині системи, що на нього реагує, і оптимізація вашої частини може погіршити ціле. |
| Лідерство | Лідерську поведінку очікують від будь-кого в проєкті, а не лише від власника посади, — і це набір поведінок, тож їх можна навчитися. |
| Налаштування | Проєктувати підхід під контекст. Важчий процес, ніж потребує ситуація, — це дефект, а не обережність; попереднє видання ніколи не казало цього так прямо. |
| Якість | Вбудовувати якість у процес і в результати, а не перевіряти наприкінці, коли знайдений дефект коштує найдорожче. |
| Складність | Складність постає з людської поведінки, взаємодій систем і неоднозначності, і її неможливо заздалегідь спланувати. Розпізнавайте її й адаптуйтеся, а не додавайте плану. |
| Ризик | Оптимізувати реакції, а не усувати ризик. Можливості теж є ризиками, а реакція, дорожча за саму загрозу, — погана реакція. |
| Адаптивність і стійкість | Закладати в підхід здатність поглинати зміни й відновлюватися після невдач, замість вважати кожне відхилення провалом планування. |
| Зміна | Уможливлювати ту зміну в поведінці, якої проєкт вимагає від людей, що житимуть із результатом. Поставлена система, яку ніхто не прийняв, — найпоширеніший дорогий «успіх». |
Вісім доменів результативності
Домен результативності — це область, яку треба тримати здоровою, щоб проєкт вдався. Вони не послідовні й не є чеклістом: усі вісім живі одночасно, а робота полягає в тому, щоб помічати, який зараз найслабший.
| Домен | Питання, яке він тримає відкритим | Провалений, коли |
|---|---|---|
| Стейкхолдери | Хто може на це вплинути і чи залучений він? | На останньому шлагбаумі виникає нове заперечення |
| Команда | Чи здатні ці люди виконати цю роботу разом? | Рішення чекають на одну людину |
| Підхід до розробки | Предиктивний, agile чи гібридний — і чому саме? | Підхід успадкували, а не обрали |
| Планування | Скільки деталей варто фіксувати вже зараз? | План перебазовують щомісяця |
| Проєктна робота | Чи справді працюють процеси й ресурси? | Команда витрачає тиждень на розблокування себе |
| Поставка | Чи постачаємо ми ту цінність, яку планували? | Обсяг за планом, а вигоду ніхто не міряв |
| Вимірювання | Звідки ми знаємо і чи чесний сигнал? | Статус зелений до місяця, коли він червоний |
| Невизначеність | Що може змінитися і як ми відреагуємо? | Реєстр ризиків не змінювався квартал |
Третя колонка — це і є практичне застосування моделі. Читання доменів як переліку тем не дає нічого; читання їх як восьми місць, де проєкт може тихо гнити, дає діагностику, яку можна провести за двадцять хвилин із тими, хто виконує роботу.
Поряд із доменами Guide несе каталог моделей, методів і артефактів — тих багаторазових деталей, які попереднє видання вбудовувало всередину процесів. Моделі — це способи мислення (ситуативне лідерство, рамки складності, моделі змін); методи — способи дії (техніки оцінювання, ретроспективи, аналіз освоєного обсягу); артефакти — те, що створюється (бізнес-кейс, реєстр ризиків, беклог, burndown). Подання їх каталогом, а не послідовністю, є свідомим: ви обираєте з них, і цей вибір і є налаштуванням.
Структура, яку ви, найімовірніше, носите
6-те видання варто знати точно з двох причин: значна частина організацій, контрактів і посадових описів досі працює за ним, а співбесідні питання часто його припускають. Воно організовувало управління проєктами як матрицю: п’ять груп процесів згори, десять областей знань збоку і 49 процесів у клітинках.
П’ять груп процесів: ініціація, планування, виконання, моніторинг і контроль, завершення. Їх масово читають як фази проєкту, а це не фази: моніторинг і контроль триває безперервно поруч з іншими, а проєкт із кількох фаз проходить усі п’ять груп у межах кожної з них.
Десять областей знань: інтеграція, обсяг, розклад, вартість, якість, ресурси, комунікації, ризики, закупівлі та управління стейкхолдерами. Інтеграцію звично пропускають у навчанні, а на практиці саме вона найважливіша: це робота з утримання решти дев’яти разом, коли вони конфліктують, — і саме нею проєктний менеджер здебільшого й займається.
PMBOK проти PRINCE2
Ці два подають як суперників, і здебільшого вони ними не є. Вони відповідають на різні питання, і організації, що використовують обидва, не є нерішучими: вони користуються методом врядування і зводом знань, а це різні речі.
PMBOK
- Звід знань — що знати і про що думати
- Майже нічого не каже про те, хто що вирішує
- Принципи й домени; процес проєктуєте ви
- Сертифікація — PMP, що перевіряє й досвід
- Сильний у техніці, слабкий у врядуванні
PRINCE2
- Метод — визначений спосіб ведення й контролю
- Визначає раду проєкту, ролі й повноваження рішень
- Сім процесів із іменованими управлінськими продуктами
- Сертифікація — Foundation, далі Practitioner
- Сильний у врядуванні, мовчазний щодо техніки
Практичне прочитання: PRINCE2 каже, хто затверджує межу етапу і який документ підписує; PMBOK каже, як оцінити роботу, прочитати ризик і залучити того стейкхолдера, чий це підпис. Жоден не покриває територію іншого — тому їх поєднання поширене в європейському публічному секторі, а суперечка про те, що «краще», зазвичай означає, що у двох людей різні проблеми.
Тепер суть — у налаштуванні
За старою моделлю налаштування означало вибір, які з 49 процесів пропустити. У 7-му виданні це центральна діяльність: ви проєктуєте підхід під цей проєкт, цю організацію й цих людей, а стандарт постачає питання, а не відповіді.
Це реальний виграш у чесності й реальна втрата в конкретиці. Процесний стандарт каже початківцю точно, що робити далі; стандарт принципів припускає достатній досвід для самостійних міркувань. Команди, які беруть 7-ме видання без такого досвіду, зазвичай усе одно тягнуться до процесів 6-го — і це розумний хід, доки він є свідомим вибором, а не невідрефлексованою звичкою.
Як це виявляється в реальній поставці
На практиці PMBOK проявляється у двох місцях: як словник PMO і як програма сертифікації PMP. Знати його найважливіше тоді, коли ви працюєте на цій межі: інженерній команді, що працює за Scrum усередині програми під управлінням PMO, потрібен хтось, хто зможе відобразити «ціль спринту» на «домен поставки», щоб жодна зі сторін не відчувала, що її перекладають.
Справедлива критика 7-го видання полягає в тому, що за стандартом принципів дуже важко провалити аудит — і, відповідно, важко когось до чогось зобов’язати. «Ми налаштували» є доступною відповіддю майже на будь-яке питання про те, чому щось не зробили. Це не аргумент за повернення назад — 49 процесів звично виконували як паперову роботу, — але це означає, що стандарт тепер повністю залежить від судження того, хто його застосовує, і більше не дає під цим судженням жодної підлоги.
Де він вироджується
- Цитувати групи процесів 6-го видання так, ніби це чинний стандарт.
- Читати п’ять груп процесів як фази проєкту, чим вони ніколи не були.
- Застосовувати всі домени в повному обсязі до двомісячного проєкту — це театр управління.
- Сприймати принципи як чекліст для галочок, а не як основу для міркувань.
- «Ми його налаштували» як відповідь на питання, чому пропустили щось потрібне.
- Закладати бюджет на результат і не закладати на зміну поведінки, якої він вимагає.
- Використовувати словник PMBOK, щоб перейменувати agile-процес, не змінюючи способу ухвалення рішень.
Коли це застосовувати
Застосовуйте, коли
- Ви працюєте з PMO або всередині нього і потребуєте спільного словника.
- Проєкти охоплюють кілька підходів до поставки й потребують спільної рамки.
- Клієнт або регулятор очікує визнаної практики управління проєктами.
- Ви йдете на сертифікацію PMP, де це і є програмою.
- Вам потрібна техніка — оцінювання, ризики, аналіз стейкхолдерів — поверх методу врядування, що її не дає.
Уникайте, коли
- Одна продуктова команда, що вже добре працює за Scrum, — це додасть словника, а не спроможності.
- Його впровадили б як процес для дотримання, а не як принципи для міркування.
- У команді немає досвідченого проєктного менеджера для налаштування, яке припускає 7-ме видання.
- Вам потрібні визначені повноваження рішень і точки затвердження — це метод врядування, а не звід знань.
- Робота є безперервною продуктовою розробкою, а не проєктом із завершенням.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.