Використовуючи цей стандарт, більшість керівників проектів в Росії змогли підвищити свою професійну компетенцію і використовувати в своїх компаніях і проектах передові управлінські технології. Ухвалення PMBoK як базового джерела компетенції по УП дозволило підвищити культуру управління на багатьох російських підприємствах, які в даний момент є лідерами в своїх бізнес - областях.
Олексій Полковников, PMP, Віце-президент Московського відділення PMI, Віце-президент Російської асоціації управління проектами СОВНЕТ
В цілому концепція документа залишилася колишньою - структурований опис управлінських процесів на рівні окремого проекту. Однак з'явилася додаткова інформація по зв'язаних об'єктів управління програмою і портфелі проектів. Значно перероблена структура розділів описують організацію виконання проектів. Опис офісу управління проектами з'явилося аж в двох місцях. Значно розширено і структуровано опис сутності та ролі учасників проекту та зацікавлених сторін.Процеси управління проектом
PMBoK збільшився в обсязі (приблизно на 50 сторінок). В основному це відбулося за рахунок розвитку розділу, що описує послідовність управлінських процесів (Глава 3 зросла з 9 до 27 сторінок). По суті, з'явилося досить добре структуроване посібник з послідовності управлінських процедур з описом входів і виходів, яке має самостійну цінність для читача. У попередній версії PMBoK процеси ділилися на основні та допоміжні, причому тільки основні процеси були взаємопов'язані, а допоміжні були представлені непов'язаним підмножиною. Спірним було виділення організаційного планування та планування комунікацій з основних процедур розробки плану проекту, а також розрив в процедурах планування ризиків і ін. Доводилося пояснювати це загальним характером документа, що передбачає високу ступінь гнучкості при описі процедур управління конкретним проектом. У новій версії схеми, що відображають послідовність процесів, значно перероблені - всі процеси об'єднані в єдину послідовність, додані основні результати. Процес ініціації проекту тепер, крім розробки статуту проекту, включає і процедуру розробки попереднього визначення проекту (scope statement).
Результати процесів управління (outputs, deliverables)
Має сенс також звернути увагу на зміни в описі результатів процесів управління. У більшості процесів є зміни в описі входів і виходів. Загалом, є тенденція до зменшення описуваних результатів. Наприклад, якщо раніше в результаті ініціації проекту на виході, крім випуску статуту проекту, описувалися також такі результати як призначення менеджера проекту, опис припущень і обмежень, то в новій версії залишився тільки статут. Схожа ситуація і з іншими процесами. Наприклад, в процесах планування управління ризиками замість значної кількості результатів пропонується єдиний інтегруючий документ - "регістр ризиків". Звертає на себе увагу також зміна назви документа "План проекту" на "План управління проектом". В принципі обидва терміни використовуються на практиці. Іноді під планом управління проектом розуміється вужче документ, що входить в план проекту. У Росії більш поширений термін План проекту.
Галузі знань управління проектами
Менш значні зміни управлінських процесів є майже у всіх інших розділах знань. Я б звернув Вашу увагу на нові процеси "Управління зацікавленими сторонами" (Manage Stakeholders) і "Оцінка потреби завдання в ресурсах" (Activity Resource Estimating).
Ще одним приємним нововведенням є схеми взаємозв'язку процесів всередині областей знань, що дозволяє отримувати більш цілісну картину по кожній області.
Сергій Вратенков, PMP, Віце-президент Московського відділення PMI
Олександр Кутузов, PMP
У новій версії стандарту (а точніше поки тільки в його драфті), помітно подальший рух до його раціональності, конкретності і прагматичності, виключенню двозначності і спрощення. З іншого боку, приділено більшу увагу до так званим "soft skills"; управління командою проекту, управління очікуваннями зацікавлених сторін (стейкхолдерів) проекту (розміщений окремий процес Manage Stakeholders), які на мій погляд є одними з найбільш важливих компетенцій і навичок керівників проектів (і які так часто ними в проектах ігноруються!).
Порадувало те, що, більш ретельно опрацьована ініціація проекту - нарешті наведено порядок в поняттях Project Charter, Scope Statement, (detailed preliminary), Project management Plan.
Із серйозних змін також слід відзначити те, що зроблений акцент на корпоративному управлінні проектом і проектному офісі.
Керівникам проекту зроблений подарунок у їх спілкуванні з аудиторами або проектним офісом - в самому початку 3-го розділу жирним шрифтів виділено, що в кожному конкретному проекті повинні використовуватися не всі 46 процесів описаних в стандарті, а тільки ті, які вважатиме за потрібне керівник проекту разом зі своєю командою (відповідальність за вибір процесів управління накладається на того ж керівника проекту).
Це, звичайно являє лазівку менеджерам проекту, тому, я вважаю, що повинні бути визначений набір обов'язкових процесів (і можливо документів) для всіх проектів (такі, як наприклад Scope Definition) і допоміжних, які вибираються самим керівником проекту. Хоча, звичайно, при корпоративному управлінні проектами це може бути визначено в методології управління проектами компанії.
Стандарт став істотно краще, зрозуміліше і конкретнішим (чого, звичайно, сприяє також і зміни самого стилю викладу, додавання графічних схем взаємодії процесів) і поки я не побачив того, що стало гірше.
Олексій Суботін, член Правління СОВНЕТ
PMBoK зробив великий крок вперед до "процесного" підходу. На сьогоднішній день цей підхід реалізований в стандартах серії 9000, в сучасних стандартів з інформаційних технологій і таке вдосконалення PMBoK безсумнівно спростить його застосування. Особливо хочеться відзначити появу процесних діаграм - в попередніх версіях їх практично не було і доводилося витрачати час і відновлювати їх по тексту своїми силами.
Радує і увагу приділену структуризації - розробка WBS винесена в окремий процес, в стандарті нарешті з'явилася Risk Breakdown Structure.
І, звичайно, поява поняття портфеля проектів дає надію на те, що в наступних редакціях з'являться і процеси управління портфелем проектів.
У висновку хочеться відзначити, що стандарт став більш зручним для застосування.
Андрій Білозеров, СPMP, Віце-президент Московського відділення PMI
Артем Терпугов, директор напрямку Московського відділення PMI
Слід зазначити, що тепер у стандарті приділяється більше уваги управлінню не тільки одного проекту, а й портфелю проектів, про що свідчить виник акцент уваги на ролі проектного офісу і процесів моніторингу.
Зазнало сильна зміна управління інтеграцією проекту, що ще раз підтверджує життєву необхідність цих процесів. В даному розділі слід відзначити появу таких життєво необхідних процесів УП як Direct and Manage Project Execution, Monitoring and Control Project Work.
У новій версії посилено увагу важливості команди проекту і тут ми вже можемо знайти вимоги до компетенції команди проекту, чого раніше не було. Ми можемо побачити нові процеси, що акцентують свою увагу на команді проекту: управління командою проекту (manage project team) і управління очікуваннями замовника (manage stakeholders).
В цілому нова версія все більше акцентує свою увагу на наступні речі:- поліпшення інтеграції проекту, як однієї з основних галузей знань критично важливих для реалізації проектів компанії;
- поява процесів пов'язаних з визначенням компетенцією і вимогам до команди проекту;
- поява і зміна вже існуючих ряду процесів пов'язаних з комунікаціями команди проекту, для поліпшення взаємодії.
- посилення уваги управлінню портфелем проектів, що на мою думку було сильним недоглядом попередніх версій.
Версія для друку