Сутичка двох екодзун: ITIL vs PMBoK

Всім привіт, я Роман Резніков, працюю в Project Management Office компанії SoftServe. Один із напрямків моєї роботи — розвивати компетенцію Service Manager і підходи у компанії по роботі з сервісними проектами (SLA-проекти, support, etc.). У цій статті я зроблю короткий порівняльний огляд двох джерел best practices. Це дозволить вам зорієнтуватися, що варто додати в свій арсенал PM'а.

В чому проблема

Для більшості проектних менеджерів (навіть Agile) класичним джерелом best practices для ведення проектів є PMBoK. Ті, хто хоч раз заглядав в PMBoK, пам'ятають, що проект обмежений за часом, унікальна, має чіткий скоуп. Але якщо подивитися на більшість проектів в ІТ, особливо у сфері ІТ-аутсорсингу — найчастіше це T&M або Dedicated Team, така форма кооперації більше схожа на сервіс. По суті, ми надаємо клієнту послугу, сервіс розробки програмного забезпечення, а цим проектом можна вважати, швидше, Fixed-Price. Так що якщо у вас з клієнтом контракт, за яким ви надаєте ресурси, а не конкретний результат, сміливо можна вважати його сервісом. Не те щоб PMBoK в такому випадку вам не підходив, але це означає, що варто звернути увагу і пильно вивчити ще одне джерело знань — ITIL (особливо такі розділи, як Service Level Management, Capacity/Availability Management, Request Fulfilment і Incident Management).

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

Саме такий вид діяльності покривають практики з ITIL. ITIL (IT Infrastructure Library) — це найбільш широко використовуваний і загальноприйнятий підхід до управління ІТ-послугами в усьому світі. ITIL був розроблений відносно незалежно від керування проектами, втілює кілька цінних ідей управління і включає перевірені процедури, які можуть бути корисні також для практики управління проектами.

Порівняння процесів

PMBoK являє best practices у вигляді 49 процесів, кожний з яких складається з набору входів (Inputs), виходів (Outputs), інструментів і методів (Tools and Techniques). Приклад процесу з PMBoK:

ITIL побудований схожим чином, але все ж таки відрізняється за структурою. Відповідно до змісту основних книг (Core library), у ITIL 26 процесів, однак існують і так звані підпроцеси, наприклад Service capacity management або Component capacity management, які лише коротко описані у складі процесу Сapacity management, не маючи стандартною для ITIL структури опису процесів. Крім того, в ITIL є види діяльності, що згадуються в тексті як процеси, але не мають окремого опису взагалі. Загальна структура процесу в ITIL:

Як видно, структура процесу в ITIL чимось схожа на процес PMBoK. Із загального процесів у це входи і виходи, техніки і методи, ITIL, власне, це і називається процесом. Окремо в ITIL виділяють виконавців процесу і контроль за процесом, в той час як контроль і моніторинг виділені в PMBoK в окрему групу процесів. Так виглядає загальна картина процесів:

Як видно з таблиць, процеси в ITIL згруповані по 5 стадіями життєвого циклу сервісу (Service Strategy, Service Design Service Transition Service Operation, Continuous Service Improvement). Крім 26 процесів описується ще 4 функції. В PMBoK більше процесів і трохи складніша їх структура. 49 процесів об'єднані у 5 груп процесів (Ініціювання, Planning, Executing, Monitoring and Controlling, Closing); крім цього, 49 процесів класифіковані за галузями знань. Часто групи процесів плутають зі стадіями життєвого циклу проектів, але це помилково. З-за цього є упереджене ставлення до PMBoK = Waterfall, що теж невірно.

Таким чином PMBOK групує процеси в матрицю для зручності навігації. В ITIL і PMBoK немає однакових процесів, але є схожі. Приміром, менеджмент змін (Change management) в ITIL і інтегрований контроль змін (Integrated change control) в PMBoK.

Інтегрований контроль змін (Integrated change control) в PMBoK Менеджмент змін (Change management) в ITIL
Згідно PMBoK, інтегрований контроль змін — процес аналізу всіх запитів на зміни, їх схвалення і управління змінами поставляються результатів, а також надання інформації про їх стан.

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

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

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

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

Затверджені запити на зміни можуть зажадати створення нових або перегляду старих оцінок вартості, послідовностей операцій, дат, потреб у ресурсах і аналізу альтернатив реагування на ризики. Ці зміни можуть зажадати внесення поправок в план управління проектом або в інші документи проекту.

 У книзі Service Transition, яка входить до бібліотеки ITIL, менеджмент змін описується як процес контролю життєвого циклу всіх змін і прийняття необхідних змін з мінімальними негативними наслідками для ІТ-сервісів.

Ключова вигода цього процесу в тому, що він дозволяє вносити зміни в ІТ-сервіси, щоб вони відповідали вимогам бізнесу. Всі зміни повинні бути оцінені, записані і затверджені. У менеджмент змін не входять зміни в бізнес-процеси.

Зміною вважається будь-яка модифікація або видалення будь-якого компонента, який може вплинути на ІТ-сервіс. Запит про зміну зазвичай має стандартну, заздалегідь затверджену форму (RFC). ITIL виділяє 3 види змін:

  1. Нормальні зміни — перш ніж їх впроваджувати, вимагають оцінки і затвердження.
  2. Термінові зміни повинні бути впроваджені як можна швидше. Зазвичай проходять за особливою, прискореною процедурою і не завжди передбачають детальну оцінку наслідків.
  3. Стандартні зміни — як правило, це зміни, які відбуваються досить часто, мають низьку ступінь ризику і не вимагають додаткових тверджень і погоджень. Як правило, проходять за заздалегідь затвердженим сценарієм.

Для авторизації змін затверджується група (CAB — Change Advisory Board), яка допомагає менеджеру змін оцінити, пріоритезувати та затвердити зміни. Всі члени групи повинні мати авторитет і необхідним досвідом, щоб оцінити зміну. Окремо створюється група за твердженням термінових змін (Emergency Change Advisory Board). Така група часто збирається в терміновому порядку для оперативної оцінки термінових змін.

Як видно з опису, взятого з офіційних джерел, обидва процеси мають багато спільного. Обидва вимагають попередньої оцінки перед впровадженням будь-якої зміни, ретельного документування; обоє припускають процедуру затвердження, яка може здійснюватися як спеціально виділеною групою людей (CCB в PMBoK або CAB і ECAB в ITIL), так і окремо взятою людиною (керівник проектів або спонсор в PMBoK і менеджер змін в ITIL).

Інтегрований контроль змін (Integrated change control) в PMBoK:

Таким чином, можна помітити, що підходи в PMBoK і ITIL досить схожі.

Відмінності

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

User vs Customer

ITIL розрізняє замовників та користувачів. Замовник визначає вимоги, замовляє проект, оплачує його і затверджує (приймає) результати проекту, в той час як користувачі використовують результат проекту на щоденній основі, не маючи реальних повноважень для прийняття рішень (а вони можуть вплинути на замовника). Зазвичай замовник є лідером організації, а користувачі — її членами. Замовник і користувач можуть мати різні інтереси. Керівництво PMBoK в даний час не диференціює ці ролі. Насправді ці дві ролі часто плутають між собою або застосовують загальний до них підхід, що часто є помилкою.

Incident Management & Request Fulfilment

Проект за своєю природою не припускає, що ми отримуємо нові порції вимог або запити десь в середині проекту. Точніше, таке може статися, але кожен такий запит повинен пройти через Integrated Change Control — процес, у результаті якого повинні отримати модифікацію baseline'ів проекту (scope baseline, quality baseline, schedule baseline and cost baseline). Загалом, процедура непроста. Але як же бути, коли ми працюємо по Scrum або Kanban? Ми отримуємо нові порції роботи кожну ітерацію, а то й частіше. Як правильно поступати з такими запитами і обробляти їх, можна підглянути в ITIL у розділах Incident Management і Request fulfilment.

Problem Management

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

  1. Контрольна карта.
  2. Діаграма Парето.
  3. Гістограма.
  4. Контрольний лист.
  5. Діаграма Ісікави.
  6. Розшарування (стратифікація).
  7. Діаграма розсіювання.

Досить часто на практиці при аналізі проблем (як правило, на ретроспективах) я використовую діаграму Ісікави/"Риб'ячої Кістки" (Fishbone Diagram)

На малюнку представлений такий приклад з двома рівнями кісток. Червоним кольором позначено 1-й рівень — головні (корінні) — a, b, c, d, а синім — 2-й рівень — поглиблені (деталізуючі) причини (фактори) досліджуваного впливу на результат (серед факторів 2-го рівня як ті, які посилюють дію 1-го рівня: e, f, g, h, i, l, m, o, p, так і ті, що його послаблюють: k, n). Далі поглиблюють поділ виявлених факторів за їх зростаючої специфічність до тих пір, поки гілки проблеми піддаються додатковому розділу (при цьому необхідно виявляти справжні причини, а не симптоми).

Робота з діаграми Ісікави проводиться в кілька етапів:

Ще один корисний інструмент для роботи з проблемами, з якими можна ознайомитися на сторінках PMBoK, це афинити-діаграма (affinity diagram), або KJ Method. По суті, це доповнення до мозкового штурму, коли всі зібрані факти та ідеї організовуються в кластери в залежності від зв'язків між ними. Ця техніка добре підходить для воркшопів: необхідно зібрати потрібних stakeholders, які мають відношення до даної проблеми; запастися великою кількістю різнокольорових стікерів, які є «атомами» фактів чи ідей, які ви збираєтеся об'єднати в різні групи.

Далі кілька простих кроків:

Крок Фаза Опис
1. Ідентифікувати проблему Визначте свою проблему, або загальну тему. Приклад: чому рівень задоволеності клієнтів знижується?
2. Зібрати ідеї Перерахуйте відповідні факти, дані, ідеї, думки, що стосуються предмета, і помістіть їх на стікери або запишіть на дошці
3. Знайти зв'язку між ними Зверніть увагу, які з цих нотаток або карток схожі, і розташуйте їх у відповідності з шаблонами, заснованими на цих подібності
4. Згрупувати ідеї в кластери Позначте кожну групу схожих нотаток або карток ярликом для кожної групи Affinity. Це можуть бути аспекти розглянутої проблеми. Визначте пріоритетність проблем, які були виявлені
5. Проаналізувати результат Подивіться на створені групи і факти/ідеї, пов'язані з кожною ідеєю. Які ідеї це дає стосовно проблеми, викладеної спочатку? Пропонує це потенційні рішення?
6. Поділитися результатами Поділіться результатами з усіма зацікавленими сторонами

В PMBoK, інструменти, які дозволяють ефективно працювати з проблемами, не винесені в окремі процес або область знань, а розподілені по інших областях знань (більшість — в Quality Management). В ITIL це окремий процес. Управління проблемами — ще одна важлива голова, обговорювана в розділі «Сервісна підтримка» ITIL®. Мета цього процесу — «мінімізувати негативний вплив інцидентів і проблем на бізнес, викликаних помилками в ІТ-інфраструктурі, і запобігти повторенню інцидентів, пов'язаних з цими помилками». Проблема є невідомою основною причиною одного інциденту або більше. Відома помилка — це успішно діагностована проблема (відома основна причина), для якої були знайдені тимчасовий обхідний шлях або постійне рішення.

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

Етапи контролю проблеми:

Функції контролю помилок:

Одним з переваг ITIL порівняно з PMBoK для ІТ-проектів є те, що він орієнтований на ІТ, в той час як PMBoK не має профілізації (не рахуючи software extension to PMBoK Guide). В ITIL можна знайти корисні рекомендації по Information Security Release and Deployment Management. Ті ж процеси, що є в PMBoK, наприклад Knowledge Management або Change Management, також більш релевантні для ІТ.

PMBoK і ITIL мають відповідні сертифікації, деталі можна почитати тут . Також в Україні діє ком'юніті сертифікованих PMP-фахівців .

Висновки

Підбиваючи підсумки, варто зазначити, що у PMBoK і ITIL схожий підхід до деяких питань, але вони мають різні сфери застосування. Для проектів з фіксованою ціною та скоупом (Fixed-Price) PMBoK є більш підходящим джерелом практик. Для проектів, які мають SLA, проекти підтримки (Support, Maintenance) ITIL більше релевантне. Більшість проектів, які працюють за Kanban, можуть знайти багато корисного в Service Operations (одна з книг, яка входить до бібліотеки ITIL). ITIL також широко застосовують IT-відділи великих компаній, Service Design і Service Strategy відмінно підходять для запуску нових IT-сервісів. А ось уже розробка і реалізація нового сервісу може бути здійснена в рамках проекту, де будуть застосовуватися практики з PMBoK. Передача цього сервісу від розробки до підтримки і безпосередня підтримка сервісу і його поліпшення також описані в ITIL.

У проектах, в залежності від їх специфіки, можна використовувати практики як з PMBoK, так і з ITIL. В ІТ-проектах, які часто використовують гнучкі (Agile) підходи для вирішення окремих питань, які не вказані у тому ж Scrum або Kanban, можна сміливо користуватися процесами, пропонованими PMBoK або ITIL, дивлячись на те, що краще підходить. Наприклад, процес управління ризиками може бути побудований відповідно до рекомендацій PMBoK, а управління інцидентами — згідно ITIL. Варто мати обидва набору Best Practice у своєму арсеналі, щоб у потрібний момент використовувати потрібний інструмент.

Сподіваюся, ця стаття наштовхне вас на нові ідеї по управлінню вашими проектами.

Опубліковано: 11/04/19 @ 10:00
Розділ Різне

Рекомендуємо:

DOU Hobby: Стрільба – любов до зброї і ураження цілі
DOU Labs: як в Provectus створили ProPlanner – SMART-планувальник робочих завдань
Три історії про IT-шників, що займаються громадською діяльністю
Ruby/Rails дайджест #28: важливі оновлення для кількох версій Ruby on Rails, реліз Ruby 2.5.5 і 2.6.2
Прогнозування на стороні клієнта за допомогою TensorFlow.js