Симптоми, які свідчать про готовність компанії будувати PMO

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

Рятівним колом для компаній, які борються з цими викликами, може стати PMO (Project Management Office). PMO – це стратегічний підрозділ, що допомагає стандартизувати та вдосконалювати процеси управління проєктами в межах всієї організації.

У дослідженні від PMSolutions за 2022 рік вказано, що більшість організацій, від малих до великих, вже мають PMO.

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

В матеріалі розглянемо:

• 5 рівнів зрілості проєктного управління в компанії за моделлю CMMI.
• 10 симптомів, які сигналізують про те, що компанія готова до створення PMO.

Рівні зрілості проєктного управління в компанії

Модель CMMI (Capability Maturity Model Integration) є структурованою системою оцінювання, що визначає зрілість процесів управління проєктами в організації. Згідно з нею, пропонується 5 рівнів зрілості компанії:

Зрозуміло, що на етапі старту, коли у project-менеджерів активних практик небагато, побудова PMO не є доцільною. Тож думати про запуск повноцінної PMO-функції компанії починають, коли:

• вже знаходяться між Managed та Defined рівнями;
• намагаються перейти на Defined рівень.

Це пояснюється тим, що, досягнувши Managed рівня CMMI, управлінські процеси стали керованішими. А це створює сприятливий ґрунт для впровадження PMO, що має на меті стандартизувати та вдосконалити ці процеси, щоб досягти наступного вищого рівня.

Отож, поговоримо детальніше про кожний рівень окремо.

1 рівень: Initial

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

На цьому рівні:

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

Чи виконуються проєкти? Так, вони виконуються. Та чи успішно? Це залежить від випадку. Деякі з них можуть бути завершені вчасно та в рамках бюджету, інші ж можуть зазнати невдачі через брак чіткої організації та контролю.
На початковому етапі часто виникають легенди про project-менеджерів, які змогли врятувати проєкти від краху завдяки винахідливості та самовіддачі. Потім це активно обговорюється на FuckUp Nights.
Зростаючи, у компанії збільшується обсяг та складність проєктів, і подібний підхід стає неефективним.

2 рівень: Managed

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

За часту це відбувається завдяки кільком вмотивованим РМ’ам, які об’єднують зусилля та намагаються з хаосу, панівного на початковому рівні, визначити кращі практики. У процесі цього відбувається обмін досвідом – project-менеджери комунікують та дізнаються, як інші будують процеси управління, які техніки та методології використовують. Подібний обмін знаннями веде до розуміння того, що виконання багатьох процесів відбувається за схожими принципами.

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

• Визначенні термінів «команди», «проєкту», «програми», «операційної діяльності» та ін.
• Інвентаризації проєктів, а саме зборі інформації про всі чинні проєкти компанії.
• Розробці планів, створенні перших шаблонів та стандартів.

Лише за умови успішної структуризації вашої проєктної діяльності, певний працівник компанії може задуматись про те, що для ефективного управління проєктами на рівні всієї компанії потрібна централізована PMO-функція.
Багато компаній намагаються створити PMO силами вільних на бенчі або тимчасово незалучених project-менеджерів. Однак така ідея майже завжди зазнає невдачі. Чому так? Відповідь проста. PMO завжди потребує гнучкої «dedicated team» з чітко визначеними ролями, досвідом та мотивацією.

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

Отже, в основному PMO на керованому рівні виконує загальну функцію – підвищення ефективності проєктного менеджменту (завдяки появі ризик-менеджменту), та вужчі, як-от: покращення комунікаційних та координаційних процесів та забезпечення якнайкращого задоволення клієнтських очікувань.
Проте для досягнення максимального ефекту PMO необхідно перейти на наступний рівень зрілості.

3 рівень: Defined

Створення PMO – це не про те, щоб одразу зануритись у написання документації. Натомість це про визначення потреб компанії та створення зручних інструментів та процесів, які їм відповідають.

На ілюстрації нижче один із прикладів побудови цього ядра – організаційних стандартів (як це зветься в CMMI). Ми називаємо це IDEAbook (Intellias Delivery Excellence Accelerator), що включає набір різних практик, розроблених нашою PMO.

Вони охоплюють різні аспекти проєктного менеджменту, і, звісно, підтримуються міжнародними стандартами ISO, CMMI, TSX та іншими.

Рівні зрілості проєктів, що підв’язані під CMMI, лягають в основу регламентованого процесу контролю якості. І, власне, однією з основних задач PMO стає вирівнювання рівня якості по всіх проєктах, які є в компанії, а також визначення для кожного з них відповідного рівня якості.

Наприклад, якщо ви працюєте в аутсорсингу, то рівень якості для проєктів team extension та для розробки продуктів будуть відрізнятися. І відповідно це важливо також брати до уваги. PMO враховує нюанси та несе відповідальність за те, щоб якість проєктів відповідала найвищим стандартам.

4 рівень: Quantitatively Managed

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

Цей рівень характеризується:

• Різними показниками KPI. Кожен процес, кожна задача, кожен проєкт має свої чітко визначені метрики для оцінки ефективності.
• Аналітичними моделями. PMO використовує дані та аналітику для прогнозування ризиків, виявлення проблем та прийняття кращих рішень.
• Автоматизацією. Завдяки аналітиці та машинному навчанню багато рутинних завдань PMO автоматизуються, що звільняє час для інших задач.

Досягнення кількісно керованого рівня потребує часу та ресурсів. Зазвичай організації, де працює до 2000 співробітників, на це потрібно не менше 1,5-2 років. І тільки тоді в компанії з’являються процеси, описані у вашому плейбуці, health checks (т. зв. перевірки здоров’я) або аудити проєктів – і ви переходите на наступний рівень.

5 рівень: Optimizing

5-й рівень PMO, який ми називаємо рівнем оптимізації, – це найвищий рівень вдосконалення. Досягти його можна лише за допомогою Kaizen – японської філософії безперервного покращення процесів виробництва.

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

Що ще входить до функцій PMO?

• Періодичне проведення оцінки стану проєктів (health check), щоб переконатися в їх ефективності.
• Вдосконалення системи через пошук «гепів», які не встигли закрити раніше (через брак інвестицій або завантаженість) та впровадження інноваційних підходів (наприклад, моделі AI) для оптимізації роботи PMO.

Таким чином, PMO виходить за межі операційного менеджменту проєктів і стає стратегічним партнером керівництва компанії. Варто сказати, небагато компаній досягають 5 рівня, але ті, хто це робить, вже замислюються про впровадження найсучасніших практик, до прикладу lean-практик – ощадного виробництва.

При переході з 4-го рівня на 5 вкрай важливо не втратити вибудовану структуру. Буває, що PMO вже знаходиться на lean-практиках, а project-менеджери губляться в елементарних речах: не розуміють як створити Communication Plan або куди ескалювати, коли виникає проблема на проєкті.

В такому випадку PMO має чітко донести нові принципи роботи, властиві 5-му рівню, а також постійно підтримувати та моніторити, щоб переконатися у правильному застосуванні практик.

10 симптомів, що компанія доросла до побудови PMO

Побудувати PMO – теж нелегке завдання. Адже він завжди будується навколо спонсора – сильного лідера в організації, який розуміє, для чого це потрібно. На жаль, багато CEO в компаніях не розуміють цінності PMO, вважаючи його зайвими витратами.
Звичайно, PMO потребує інвестицій. Однак вони окупляться багаторазово завдяки покращенню ефективності проєктів. Навіть на 3-му рівні PMO, надаючи додаткові послуги, може приносити опосередкований прибуток компанії, правда значно менший, ніж те, скільки PMO коштує для компанії (а коштує немало).

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

Симптом 1. Є стратегія, немає реалізації

Багато великих компаній стикаються з парадоксом: є чітко прописана 3-річна стратегія, амбітні OKR щокварталу, але цілі не досягаються. Це свідчить про те, що стратегія не втілюється в життя. Чому це відбувається? Можливо немає чіткої структури та процесів для реалізації стратегії, можливо не вистачає моніторингу та контролю за прогресом, чи не виділено достатньо ресурсів.

І ось тут PMO може допомогти подолати цей розрив, розробивши Framework – набір методологій та підходів для управління проєктами, програмами та командами, тобто на всіх рівнях.
Ця функція PMO, незалежно від назви офісу (CO, Transformation Office, Change management Office), дає можливість project-менеджерам ефективно працювати над стратегією компанії.

Симптом 2. Велика кількість проєктів, різний рівень якості

Ця проблема посідає друге місце за поширеністю, змушуючи компанії задуматися про створення PMO. Яскраво її ілюструє RAG Report (в українській адаптації «Світлофор»), де оцінка різних напрямків роботи компанії позначається трьома кольорами:
червоний – низький рівень;
жовтий – середній;
зелений – високий.

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

Якщо думаєте, що цю задачу візьмуть на себе project-менеджери, ви помиляєтесь.

• По-перше, в IT, незалежно від продукту чи сфери (власний продукт чи аутсорсинг), проєктні менеджери постійно зайняті оперативними завданнями (стендапи, пленінги, рефайнменти), ескалаціями тощо. Їм просто не вистачає часу на аналітику.
• По-друге, у project-менеджерів зміщений фокус: їхня основна функція – управління проєктами, і аж ніяк не виправлення системних проблем.

Але ж хтось має взяти на себе відповідальність, і цим кимось може стати PMO.
RAG Report – must-have для будь-якої компанії з проєктною структурою. Радимо не нехтувати його заповненням, адже це хребет вашої компанії, що показує, наскільки вона стійка та має потенціал підтримувати в кризових ситуаціях.

Симптом 3. Є проєкти, немає пріоритетів або багато залежностей

Багато проєктів розпочато, але їхня важливість не визначена, що призводить до хаосу та неефективного використання ресурсів. Всі вони тісно переплетені між собою, утворюючи заплутану мережу залежностей, що ускладнює їхню координацію та своєчасне виконання. Члени команд не володіють загальною картиною (Big Picture), не знаючи про їхні цілі, терміни та взаємозв’язки.

До чого це призводить?

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

В такій ситуації PMO також гарно себе покаже. Зокрема, він може допомогти звичайно з:

• Побудовою системи, де все відслідковується. PMO створить централізовану систему відстеження, де буде зафіксовано всі аспекти проєктів (цілі, строки, пріоритети, залежності). Це дозволить бачити загальну картину та уникати дублювання зусиль.
• Побудовою фреймворків, як-от SAFe Program Board. Так можна буде візуалізувати зв’язки між проєктами, визначити їхні пріоритети для кращої координації та синхронізації між командами.
• Побудовою ризик-менеджменту. PMO проведе ретельний аналіз проєктів, щоб виявити потенційні ризики, шукатиме план їх мінімізації та зведення нанівець.

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

Симптом 4. Топменеджмент не розуміє, що відбувається

Успіх організації залежить від чіткої координації та ефективного управління проєктами. Однак, на жаль, часто менеджмент не володіє чіткою картиною того, що відбувається з проєктами.
Тому, помітивши у своїй компанії цей симптом, варто подумати про прозорість, звітність, дорожні карти (Roadmaps) та карти стану програм проєктів (Project Program Health Maps). Здавалось би прості речі, але часто ігноруються.

Допоки не відбудована чітка система трекінгу, у топменеджменту завжди виникатимуть питання:

• Де гроші, які були інвестовані?
• Які у нас ROI?
• Чому ми багато інвестуємо, а наші конкуренти попереду?

Важливо зазначити, що керівництво не повинно очікувати, що project-менеджери будуть постійно заходити в складні системи для команди та проєктів, налаштовані PMO. Натомість інформація, представлена ​​у простому та доступному форматі, наприклад, у презентаціях PowerPoint або Power BI дашбордах дозволить топменеджменту швидко отримати та трекати потрібні дані.

Симптом 5. Найняли PMів, коли зростали, але зараз розуміємо, що вони незрілі

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

Насправді для успішного втілення цих програм необхідні профільні експерти. Вони наповнять ту канву процесів, яку створили HR-менеджери, після чого запрацює система. Тому такі речі, як: матриці компетенцій, перевірки навичок (Skill Checks), оцінювання, коучинг-навчання, академії, конференції, ком’юніті – все це є функціями PMO.

Симптом 6. Клієнт незадоволений, хоче перебудувати управління програмою, з ким порадитись?

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

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

Знайти людей, які б відповідали усім цим критеріям, дуже складно. Мало з них зацікавлені змінити своє неспокійне, але звичне виробництво на повний розфокус у роботі та розв’язування ста задач різного профілю. Тому, з погляду PMO, у складі мають бути фахівці з абсолютно різних напрямів – competence-менеджменту, process-менеджменту, власне консультування.

І, звісно, консультантів слід постійно розвивати, запрошувати заходити в проєкти, особливо кризові, для оновлювання практичних знань. Таким чином прокачуються м’язи PMO-консалтингу.

Симптом 7. Отримали RFI: там просять показати приклади, як ми будуємо делівері, кількість PMів, сертифікованих РМР, SAFe, Prince 2 тощо

Отримавши такий запит від клієнта, куди йдуть, як правило, менеджери? Правильно – до PMO.

Уявіть, що у вас 200 або 1000 project-менеджерів, які працюють над різними проєктами в різних місцях та доменах. Тим часом для PMO це не проблема, офіс повинен знати, де і хто, які сертифікації та навички має.

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

Симптом 8. Потреба впровадження ризик менеджменту

• Чому ми не менеджимо ризики?
• Чому не проводимо ретроспективи, різні KPRC аналізи?
• Чому ми мали проблему, про яку не знали й знову її повторюємо?

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

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

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

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

Симптом 9. Стейкхолдери не спілкуються між собою, департаменти воюють за KPI, бізнес не розуміє IT

З такими симптомами нерідко стикаються компанії, і вони матимуть серйозні наслідки. Коли бізнес не розуміє можливостей та обмежень IT, це призводить до нереалістичних очікувань, розчарувань та невдалих проєктів.
Або ж, наприклад, департаментам розставили різні KPI, комусь швидкість виснаження (Attrition Rate), іншому – дохід (Revenue). Це зумовлює справжні війни: яку фічу розробляти чи який продукт випускати. Немає узгодженості, оскільки немає централізованої функції управління.

А PMO може відіграти ключову роль у вирішенні цих проблем. Раніше ми згадували про competence-менеджмент, консалтинг, як про функції, що зароджуються в офісі. З часом зароджується й operations і process management. Операційні задачі, типу відбудови процесів трекінгу, інвойсингу, теж можуть вирішуватися в PMO. Позаяк там працюють системні люди, які здатні побудувати тактичні, стратегічні дашборди та допомагати департаментам чітко колаборувати.

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

• Зібрати за одним столом представників різних департаментів: CEO, CFO, VP of HR та інших.
• Провести продуктивні дискусії, які допоможуть досягти компромісу.
• Сприяти прийняттю спільних рішень, які відповідають інтересам усіх сторін.

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

Симптом 10. Відсутність Change Managementʼу. Живемо в постійній трансформації, але нічого не доводимо до кінця.

Проблема, коли проєкти та ініціативи постійно запускаються, але ніколи не доводяться до кінця, знайома багатьом. Але як побороти симптом «вічного завтра»? І знову на горизонті з’являється PMO.

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

Та PMO не є панацеєю. Не всі процеси, які він створює, працюватимуть як швейцарський годинник. Деякі з них:

• з часом втрачають свою актуальність та потребують трансформації;
• просто «вмирають», що теж добре, адже виходить, що компанії вони вже не потрібні.

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

Підсумки

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

PMO є на цьому шляху потужним інструментом оптимізації роботи компанії, адже здатний:

• Визначити чіткі цілі та пріоритети проєктів.
• Застосовувати ефективні методи управління проєктами.
• Забезпечити достатні ресурси для проєктів.
• Отримати підтримку з боку керівництва проєктами.
• Впровадити Change Management.

Однак, щоб PMO функціонував ефективно, важливо, щоб компанія була до цього готова. Основними ознаками ми визначили:

• Стратегія без реалізації.
• Багато проєктів різної якості.
• Проєкти без пріоритетності, але із залежностями.
• Розгублений топменеджмент.
• Синдром «недосвідчених» PMів.
• «Бунт» клієнта з намаганням змінити говерненс програми.
• Нерозуміння, що робити з RFI.
• Прогалини в ризик-менеджменті.
• Тотальна роз’єднаність між різними рівнями компанії.
• Рух на місці під маскою змін.

Якщо ви спостерігаєте бодай якийсь із цих симптомів у компанії, можливо, настав час задуматися про створення PMO.
Хочете зробити стрибок у розвитку вашої компанії завдяки ефективному PMO? Тоді реєструйтеся та долучайтеся на нашого курсу «PMO Studio».