Зміни в 5-му виданні PMBOK

31 грудня 2012 року PMI зробив новорічний подарунок усій проектно-менеджерській спільноті – випустив нову редакцію Посібника до зводу знань з управління проектами(PMBOK® Guide – 5th Edition).

Що ж нового в новому PMBOK#5?

Розділ X1 “Зміни в п’ятому виданні” якраз оповідає нам про це. Серед усієї інформації з класу “бла-бла-бла” (на кшталт, “переглянуто весь текст і графіку в документі, щоб інформація стала точнішою, яснішою, повнішою та актуальнішою” або “главу Групи процесів було перенесено до Додатка A1“) є й корисна:

Автори з гордістю стверджують, що всю термінологію приведено у відповідність до PMI Lexicon of Project Management Terms. При цьому за пріоритет взято саме термінологію з PMI Lexicon. Якщо ще й переклад PMBOK#5 російською мовою почнеться зі створення правильної термінології, то є надія отримати грамотно перекладений звід знань.

Також PMBOK#5 приведено у відповідність до стандарту ISO 21500:2012 “Guidance on project management” і забезпечено узгодження назв, процесів, входів, виходів, інструментів і методів з іншими стандартами PMI (на кшталт “The Standart for Portfolio Management” та ін.).

Нарешті перестали ставити народ у ступор своїм “позитивним ризиком“. Адже що таке ризик? Це можливість небезпеки або невдачі! Термін походить від грецького risikon, тобто “круча” або “скеля“. За часів величі й могутності Стародавньої Греції “ризикувати” означало “лавірувати на судні між скелями“, тобто “лавірувати на судні між скелями“. потенційну небезпеку невдачі.

У PMBOK#5 було внесено зміни в опис управління ризиками проєкту та зміщено акценти з терміна “позитивний ризик” до терміна “можливість“. До тексту також було додано такі поняття як ставлення до ризику, схильність до ризику, толерантність до ризику і ризикові пороги.

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

Але динаміка зміни вимог у сучасних проєктах настільки висока, що до свого фіналу проєкт вилазить за всі мислимі й немислимі обмеження. Тому управління вимогами, що змінюються, фіксація їх у документах проєкту і переузгодження базових планів стає дедалі більш затребуваною навичкою керівника проєкту. Це знайшло відображення в PMBOK#5 у реченні “Успіх проєкту слід віднести до реалізації останніх базових планів, затверджених уповноваженими зацікавленими сторонами“. По-моєму, краще й не скажеш. Якщо примудрився узгодити із замовником збільшення термінів і бюджету проєкту за два дні до закінчення проєкту, то проєкт успішний, не дивлячись на 2-кратне перевищення термінів і 3-кратне збільшення бюджету.

У PMBOK#4 частина допоміжних планів з’являлася ніби з повітря. Наприклад, опис Плану управління змістом було наведено прямо в описі царини знань “Управління змістом проєкту“, а в якому процесі він створюється – не вказано. Тепер додано чотири нові процеси планування: Планування управління змістом, Планування управління розкладом, Планування управління вартістю і Планування управління зацікавленими сторонами. Це забезпечує чітке керівництво команді проєкту активно продумувати і планувати підходи до управління всіма областями знань.

Хоча не обійшлося тут і без недоробок. Так і залишилися “без нагляду” два плани – План управління змінами і План управління конфігурацією. За логікою зрозуміло, що План управління конфігурацією має з’явитися разом із Планом управління змістом, а План управління змінами – під час розроблення загального Плану управління проєктами, але в PMBOK#5 це тільки мається на увазі.

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

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

Смішно, але в PMBOK#4 був не дуже коректний переклад “Verify Scope“, як “Підтвердження змісту“. Тепер це призведе до того, що в російській PMBOK#5 цей процес не змінить назву. Тільки цікаво, як перекладачі викрутяться, перекладаючи розділ про зміни?

У всіх минулих PMBOK-ах, разом узятих, слово “agile” жодного разу не вживалося. У нинішньому PMBOK воно зустрічається аж 10 разів.

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

Тому і концепція гнучкого управління проєктами “agile” була включена в процес розробки розкладу проєкту.

Правильно, потрібно тримати ніс за вітром! Це і сучасно, і модно, і комерційно затребувано.

Давно назрівало впорядкування інформації та знань, що генеруються під час реалізації проєкту. Однією з найбільш революційних змін у PMBOK#5 є застосування моделі DIKW (data, information, knowledge, wisdom) – інформаційної ієрархії, де кожен рівень додає певні властивості до попереднього рівня:

• У підставі містяться дані.
• Інформація додає контекст.
• Знання додає відповідь на запитання “як?” (механізм використання).
• Мудрість додає відповідь на запитання “коли?” (умови використання).

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

1. 
   Дані про виконання робіт
   . “Сирі” спостереження і вимірювання, виявлені під час виконання проєктних робіт.
2. 
   Інформація про виконання робіт
   . Дані про виконання робіт аналізуються та інтегруються на підставі взаємозв’язків між різними областями/етапами проєкту.
3. 
   Звіти про виконання робіт
   . Фізичне або електронне подання інформації про виконання робіт, призначене для ухвалення рішень, висвітлення питань і проблем, вироблення дій або усвідомлення ситуації.

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

Ну, а процеси, які плутали багатьох розмитістю своїх кордонів і незрозумілою послідовністю: “Розповсюдження інформації” і “Підготовка звітів про виконання“, перейменовані, відповідно, на “Управління комунікаціями” і “Контроль комунікацій” із логічними входами і виходами.

Величезне значення в PMBOK#5 приділено управлінню стейкхолдерами. Порушено майже всі розділи, щоб краще висвітлити, хто ж такі зацікавлені сторони проєкту та їхній вплив на проєкт. Додано нову (10-ту) царину знань “Управління зацікавленими сторонами проєкту“, до якої увійшли два процеси з “Управління комунікаціями проєкту“, а також додано два нові процеси.

Основні причини такого брунькування галузі знань з комунікацій такі:

1. Було потрібне чіткіше фокусування управління комунікаціями проєкту на плануванні комунікаційних потреб проєкту, на збиранні, зберіганні та поширенні інформації в проєкті, а також на моніторингу загальних взаємозв’язків проєкту з метою забезпечення їхньої ефективності.
2. Реальне управління стейкхолдерами охоплює не тільки аналіз їхніх очікувань, їхнього впливу на проєкт і розроблення відповідних стратегій управління ними, а й постійний діалог із зацікавленими сторонами для задоволення їхніх потреб і очікувань, розв’язання питань у міру їхнього виникнення, а також залучення зацікавлених сторін до ухвалення рішень і діяльності проєкту.
3. Планування та управління комунікаційними потребами проєкту, з одного боку, а також потреб зацікавлених сторін, з іншого, – це два різні ключі до успіху проєкту.

Виокремлення Управління зацікавленими сторонами проєкту з Управління комунікаціями проєкту, крім розв’язання 3-х описаних вище проблем, забезпечує відповідність PMBOK#5 новим тенденціям, які зростають в управлінні проєктами, і великому інтересу дослідників і керівників проєкту, які практикують, до взаємодії зі стейкхолдерами, як одного з ключів до загального успіху проєкту. Ці тенденції вже відображені в “The Standart for Program Management” та ISO 21500:2012 “Guidance on project management”. Ось і PMBOK надолужив згаяне.

Отже, нова галузь знань включає процеси:

• Визначення зацікавлених сторін,
• Розроблення Плану управління зацікавленими сторонами,
• Управління залученням зацікавлених сторін,
• Контроль залучення зацікавлених сторін.

До навичок міжособистісної взаємодії додано Вибудовування довіри, Управління конфліктами та Наставництво. Ба більше, до розділу 1 “Вступ” додано новий розділ, який вказує на важливість міжособистісних навичок менеджера проєкту і відсилає читача до Додатка X3 з детальним описом цих навичок.

Ну, і найважливіше для
проєкту PMDoс
– загальне впорядкування документів, розпочате в PMBOK#4, продовжилося і в 5-му. Тепер входами процесів є тільки документи, які відіграють ключову роль у виконанні процесу. Документи та їхній склад стали зрозумілішими і конкретнішими. Хоча самі назви документів у тексті написали скрізь з маленької літери, через що візуально знаходити документи в тексті складно і, для роботи з документами, потрібно добре знати PMBOK-івську термінологію або використовувати пакет наших шаблонів.

У зв’язку з виходом PMBOK#5 ми вже почали переробку шаблонів ЗСУП.Комплект. Ці шаблони можна придбати та погортати на нашому сайті за адресою pmdoc.ua/ru/pmbok5kit.html.

Не звертайте уваги на мій стьоб протягом усієї статті. Загалом PMBOK#5 став краще структурований, послідовний, з нормальними взаємозв’язками між процесами, вивіреною термінологією. Загальне враження – 5 балів. Команді розробників – величезне спасибі! Так тримати!