Sign in Subscribe
Cynefin

PMBOK® 7

Zosym Maxym

• 13 min read

PMI радикально переглянув структуру Збірника знань з управління проектами. По суті PMBOK® 7 складається з 2х великих документів:

  • Стандарт з управління проектами (Вступ, Система постачання цінності, Принципи управління проектами, та Вказівник)
  • Настанова до зводу знань з управління проектами (настанова PMBOK® "PMBOK® Guide") складається з (Вступ, Сфери використання проекту, Припасування, Моделі, методи та артефакти, Додатки)
Якщо ви просто хочете ознайомитись з стандартом то зараз доступна для безкоштовного скачування українська версія https://pmiukraine.org/pmbok7/

На малюнку нижче показані відмінності в структурі PMBOK® 6 і 7 версії:

Для розгляду в рамках даної статті послідовно буду додавати розділи але без надто глибокої деталізації, всі відсилки будуть винесени в окремі статті. Ми послідовно розберемо:

  • Систему постачання цінності,
  • Принципи управління проектами,
  • Сфери використання проекту,
  • Припасування,
  • Моделі, методи та артефакти та деякі цікаві Додатки.

Поїхали:

Стандарт з управління проектами

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

Розділ 1. Вступ (Introduction)

У цьому вступному розділі описано мету цього стандарту, визначено ключові терміни та поняття, а також визначено аудиторію стандарту.

1.1 Мета стандарту з управління проектами

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

1.2 Ключові терміни та поняття

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

  • Результат (Outcome). Кінцевий результат або наслідок процесу або проекту. Результати можуть включати результати та артефакти, але мають ширше значення, оскільки зосереджуються на вигодах та цінності, для досягнення яких було здійснено проект.
  • Портфель (портфоліо) (Portfolio). Проекти, програми, дочірні портфелі та операції, якими керують як групою для досягнення стратегічних цілей.
  • Продукт (Product). Артефакт, який виробляється, піддається кількісній оцінці і може бути як кінцевим продуктом, так і складовою частиною.
  • Програма (Program). Пов'язані між собою проекти, допоміжні програми та програмні заходи, які управляються скоординовано для отримання переваг, недоступних при управлінні ними окремо.
  • Проект (Project). Тимчасова діяльність, спрямована на створення унікального продукту, послуги або результату. Тимчасовий характер проектів вказує на початок і кінець проектної роботи або на фазу проектної роботи. Проекти можуть бути самостійними або частиною програми чи портфоліо.
  • Управління проектами (Project management). Застосування знань, навичок, інструментів і методів до проектної діяльності для виконання вимог проекту. Управління проектом - це керівництво роботою над проектом для досягнення запланованих результатів. Проектні команди можуть досягати результатів, використовуючи широкий спектр підходів (наприклад, прогностичні, гібридні та адаптивні).
  • Керівник проекту (Project manager). Особа, призначена організацією-виконавцем для керівництва проектною командою, яка відповідає за досягнення цілей проекту. Керівники проектів виконують різноманітні функції, такі як сприяння роботі команди проекту для досягнення результатів та управління процесами для досягнення запланованих результатів. Додаткові функції визначені в Розділі 2.3.
  • Команда проекту (Project team). Сукупність осіб, які виконують роботу в рамках проекту для досягнення його цілей.
  • Система створення цінності (System for value delivery). Сукупність стратегічних видів діяльності, спрямованих на розбудову, підтримку та/або розвиток організації. Портфелі, програми, проекти, продукти та операції можуть бути частиною системи створення цінності організації.
  • Цінність (Value). Цінність, важливість або корисність чогось. Різні зацікавлені сторони сприймають цінність по-різному. Клієнти можуть визначати цінність як можливість використовувати певні властивості чи функції продукту. Організації можуть зосередитися на бізнес-цінності, визначеній за допомогою фінансових показників, таких як вигоди за вирахуванням витрат на досягнення цих вигод. Суспільна цінність може включати внесок у розвиток груп людей, спільнот чи довкілля.

Інші терміни, що використовуються в цьому стандарті, дивись у Глосарії та Лексиконі термінів PMI з управління проектами

1.3 Аудиторія цього стандарту

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

  • Відповідають або підзвітні за досягнення результатів проекту;
  • Працюють над проектами повний або неповний робочий день;
  • Працюють в офісах управління портфелями, програмами або проектами (PMOs);
  • беруть участь у спонсоруванні проектів, володінні продуктом, управлінні продуктом, виконавчому керівництві або управлінні проектами;
  • Займаються управлінням портфоліо або програмами;
  • Надають ресурси для роботи над проектами;
  • Зосереджуються на створенні цінності для портфелів, програм та проєктів;
  • Викладають або вивчають управління проектами; та
  • Залучені до будь-якого аспекту ланцюжка створення цінності проекту.

Розділ 2. Cистема Постачання Цінності (A System for Value Delivery)

Розділ 3. Принципи управління проектами у PMBOK®

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

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

Принципи можуть, але не обов'язково, відображати мораль. Етичний кодекс пов'язаний з мораллю. Етичний кодекс для професії може бути прийнятий окремою особою або професією для встановлення очікувань щодо моральної поведінки. Кодекс етики та професійної поведінки PMI [2] базується на чотирьох цінностях, які були визначені як найбільш важливі для спільноти управління проектами:

  • Відповідальність (Responsibilityv),
  • Повага (Respect),
  • Справедливість (Fairness) та
  • Чесність (Honesty).

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

Принципи управління проектами були визначені та розроблені шляхом залучення глобальної спільноти практиків проектного менеджменту. Ці практики представляють різні галузі, культурне середовище та організації, виконують різні ролі та мають досвід роботи в різних типах проектів. Результатом численних раундів зворотного зв'язку стали 12 принципів, які слугують керівництвом для ефективного управління проектами.

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

Принципи управління проектами також можуть перетинатися із загальними принципами управління. Наприклад, як проекти, так і бізнес в цілому зосереджені на створенні цінності. Методи можуть дещо відрізнятися в проектах на відміну від операційної діяльності, але основний принцип, пов'язаний з фокусуванням на цінності, може бути застосований і до тих, і до інших. Рисунок 3-1 демонструє цей збіг.

Рисунок 3-1. Збіг проектного менеджменту та загальних принципів управління

Принципові положення перераховані тут без будь-якої конкретної ваги або порядку. Принципові положення представлені та описані в розділах 3.1 - 3.12. Кожен розділ починається з рисунка, на якому вгорі розміщено позначення принципу, а під ним - сам принцип і ключові моменти. Після рисунка кожен принцип розкривається в тексті.

Позначення принципів такі:

  1. Будьте старанним, шанобливим і турботливим управителем (3.1 Be a diligent, respectful, and caring steward).
  2. Створіть середовище для спільної роботи в проектній команді (3.2 Create a collaborative project team environment).
  3. Ефективно взаємодіяти зі стейкхолдерами (3.3 Effectively engage with stakeholders).
  4. Фокусування на цінності (3.4 Focus on value).
  5. Розпізнавати, оцінювати та реагувати на системні взаємодії (3.5 Recognize, evaluate, and respond to system interactions).
  6. Демонструвати лідерську поведінку (3.6 Demonstrate leadership behaviors).
  7. Пристосувати до контексту (3.7 Tailor based on context).
  8. Вбудовуйте якість у процеси та результати (3.8 Build quality into processes and deliverables).
  9. Навігація складністю (3.9 Navigate complexity).
  10. Оптимізуйте реагування на ризики (3.10 Optimize risk responses).
  11. Прийміть адаптивність та стійкість (3.11 Embrace adaptability and resiliency).
  12. Уможливити зміни для досягнення передбачуваного майбутнього стану (3.12 Enable change to achieve the envisioned future state).

Настанова до зводу знань з управління проектами (настанови PMBOK®)

Сфери виконання проекту у настановах PMBOK® 7

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

Десять «галузей знань» (Knowledge Areas) з PMBOK 6 замінені на вісім «сфер діяльності» (Performance Domain):

  1. Робота з зацікавленими сторонами (2.1 Stakeholders)
  2. Сфера виконання "Команда" (2.2 Team Performance Domain)
  3. Сфера виконання "Підхід до розробки та життєвий цикл" (2.3 Development Approach and Life Cycle Performance Domaine)
  4. Сфера виконання "Планування" (2.4 Planning Performance Domain)
  5. Сфера виконання "Проектна робота" (2.5 Project Work Performance Domain)
  6. Сфера виконання "Постачання" (2.6 Delivery Performance Domain)
  7. Сфера виконання "Вимірювання" (2.7 Measurement Performance Domain)
  8. Сфера виконання "Невизначеність" (2.8 Uncertainty Performance Domain)

Пристосування в PMBOK® 7 (3 Tailoring)

Загальний огляд (3.1)

Пристосування (Tailoring) - це цілеспрямована адаптація підходу до управління проектами, керівництва та процесів, щоб зробити їх більш придатними для конкретного середовища і конкретної роботи.

У проектному середовищі пристосування враховує підхід до розробки, процеси, життєвий цикл проекту, результати та вибір людей, з якими можна співпрацювати. Процес пристосування керується керівними принципами управління проектами, викладеними в Стандарті управління проектами [1], організаційними цінностями та організаційною культурою. Наприклад, якщо основною організаційною цінністю є "клієнтоорієнтованість", то заходи, обрані для з'ясування вимог та перевірки обсягу робіт, сприяють клієнтоорієнтованим підходам.

Це відповідає принципу "Ефективна взаємодія із зацікавленими сторонами". Аналогічно, організація з низьким апетитом до ризику може мати багато процесів і процедур для управління проектами протягом усього їх життєвого циклу. Аналогічна компанія, що працює на тому ж ринку, але з високою толерантністю до ризику, може мати менше процесів і процедур. В обох цих прикладах організації дотримуються принципу "Оптимізація реагування на ризики", хоча їхні апетити, процеси та процедури відрізняються.

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

Моделі, методи та артефакти в PMBOK® 7 (4)

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

  • Модель - це стратегія мислення для пояснення процессу, структури або явища;
  • Метод - це засіб для досягнення кінцевого результату, виходу, проміжного результату або доробку;
  • Артефакт - може бути шаблоном, документом, виходом або доробком.

Завдання команди проекта полягає в тому щоб на стадії Припасування ухвалити рішення щодо потрібних для використання моделей, методів та артефактів. Припасування відповідно до контексту проекту зоражено на схемі:

Загальновживані моделі в PMBOK® 7 (4.2)

В дужках відмічені розділи як вони йдуть в PMBOK® 7 але назви в деяких випадках відрізняються.

Моделі ситуативного лідерства в PMBOK® 7 (4.2.1)

Моделі комунікації в PMBOK® 7 (4.2.2)

Моделі мотивації в PMBOK® 7 (4.2.3)

Моделі змін в PMBOK® 7 (4.2.4)

(Інші моделі змін які не увійшли до PMBOK® 7: McKinsey’s 7-S Change Management Model)

Моделі складності в PMBOK® 7 (4.2.5)

Моделі розвитку команди проекту в PMBOK® 7 (4.2.6)

Інші моделі в PMBOK® 7 (4.2.7)

Застосування моделей в PMBOK® 7 (4.3)

Загальновживані методи в PMBOK® 7 (4.4)

Збір та аналіз даних в PMBOK® 7 (4.4.1)

Оцінювання в PMBOK® 7 (4.4.2)

Наради та події в PMBOK® 7 (4.4.3)

  • Опрацювання беклогу (Управління бэклогом (Backlog Management))
  • Конференція учасників тендеру
  • Рада контролю змін
  • Щоденна зустріч
  • Планування ітерації
  • Огляд ітерації
  • Стартова нарада
  • Нарада щодо засвоєних уроків
  • Нарада з планування
  • Закриття проекту
  • Огляд проекту
  • Планування випуску
  • Ретроспектива
  • Огляд ризиків
  • Нарада щодо статусу
  • Керівний комітет

Інші методи в PMBOK® 7 (4.4.4)

Застосування методів в PMBOK® 7 (4.5)

Часто використовувані артефакти (4.6 Commonly Used Artifacts)

Артефакт (Artifacts) - це шаблон, документ, результат або результат проекту. Існує багато документів або результатів, які не описані тут, тому що

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

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

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

Артефакти стратегії (4.6.1 Strategy Artifacts)

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

  • Business case
  • Business model canvas
  • Project brief
  • Project charter
  • Project vision statement
  • Roadmap

Журнали та реєстри (4.6.2 Logs And Registers)

Журнали та реєстри використовуються для запису аспектів проекту, що постійно змінюються. Вони оновлюються протягом усього проекту. Терміни "журнал" і "реєстр" іноді використовуються як взаємозамінні. Нерідко можна побачити, що терміни "реєстр ризиків" і "журнал ризиків" відносяться до одного і того ж артефакту.

  • Assumption log
  • Backlog
  • Change log
  • Issue log
  • Lessons learned register
  • Risk-adjusted backlog
  • Risk register
  • Stakeholder register

Плани (4.6.3 Plans)

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

  • Change control plan
  • Communications management plan
  • Cost management plan
  • Iteration plan
  • Procurement management plan
  • Project management plan
  • Quality management plan
  • Release plan
  • Requirements management plan
  • Resource management plan
  • Risk management plan
  • Scope management plan
  • Schedule management plan
  • Stakeholder engagement plan
  • Test plan

Діаграми ієрархії (4.6.4 Hierarchy Charts)

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

  • Organizational breakdown structure
  • Product breakdown structure
  • Resource breakdown structure
  • Risk breakdown structure
  • Work breakdown structure

Базові плани (4.6.5 Baselines)

Базовий план - це затверджена версія робочого продукту або плану. Фактичні показники порівнюються з базовими для виявлення відхилень.

  • Budget
  • Milestone schedule
  • Performance measurement baseline
  • Project schedule
  • Scope baseline

Візуальні дані та інформація (4.6.6 Visual Data And Information)

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

Звітність (4.6.7 Reports)

Звіти - це офіційні записи або узагальнення інформації. Звіти передають відповідну інформацію (зазвичай на рівні резюме) зацікавленим сторонам. Часто звіти надаються зацікавленим сторонам, які зацікавлені в статусі проекту, наприклад, спонсорам, власникам бізнесу або PMOs.

  • Quality report
  • Risk report
  • Status report

Угоди та контракти (4.6.8 Agreements And Contracts)

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

Контракт (Contracts) - це взаємно зобов'язуюча угода, яка зобов'язує продавця надати визначений продукт, послугу або результат, а покупця - оплатити його. Існують різні типи контрактів, деякі з яких належать до категорії контрактів з фіксованою ціною або контрактів з відшкодуванням витрат.

  • Fixed-price contracts
  • Cost-reimbursable contracts
  • Time and materials (T&M)
  • Indefinite delivery indefinite quantity (IDIQ)
  • Other agreements

Інші артефакти (4.6.9 Other Artifacts)

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

  • Activity list
  • Bid documents
    - Request for information (RFI)
    - Request for quotation (RFQ), and
    - Request for proposal (RFP)
  • Metrics
  • Project calendar
  • Requirements documentation
  • Project team charter
  • User story

Артефакти, що застосовуються в різних сферах використання (4.7 Artifacts Applied Across Performance Domains)

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

У Таблиці 4-3 наведено сфери діяльності, в яких кожен артефакт може бути найбільш корисним; однак остаточну відповідальність за вибір і адаптацію артефактів для свого проекту несе керівник проекту та/або команда проекту.

Таблиця 4-3. Мапування артефактів, які, ймовірно, будуть використовуватися в кожній сфері виконання
Таблиця 4-3. Картування артефактів, які, ймовірно, будуть використовуватися в кожній сфері виконання (продовження)
Таблиця 4-3. Картування артефактів, які, ймовірно, будуть використовуватися в кожній сфері виконання (продовження)