Перевитрати бюджету проекту: Як PMI пояснює 9,4% перевитрат - і як їх закрити за допомогою плану, ризиків та портфеля

Перевиконання бюджету проекту – це операційний симптом, а не симптом планування. Більшість керівників ОУП, які ведуть 30 і більше проектів паралельно, знають цю схему: відхилення з’являються пізно, реєстри ризиків застарівають на другий місяць, а портфоліо – це квартальна презентація PowerPoint, зшита з електронних таблиць. Цікаве питання не в тому, чому трапляються перевитрати, а в тому, чому деякі організації постійно утримують їх на рівні нижче 9% від загального обсягу інвестицій, тоді як інші тримаються ближче до 11%. У наступних розділах ми розглянемо три операційні практики, які пояснюють цей розрив, що говорять дані PMI про їхній спільний ефект і як керівник ОУП може розпізнати, чи працює система у його власному портфелі.

У цій статті ви дізнаєтеся:

Що насправді вимірює цифра 9,4% проектних відходів з PMI і чому вона важлива в масштабі портфеля
Три типи структурних помилок, які є причиною більшості перевитрат бюджетів проектів
Як затвердження планів, управління ризиками та управління портфелем працюють як одна система, а не три функції
Як керівник ОУП може розпізнати операційні сигнали про те, що система працює – або що вона ще не працює

PMI Pulse of the Profession®: що насправді показали 3950 керівників проектів

У звіті PMI Pulse of the Profession® “За межами Agile: Імператив гнучкості” опитав 3950 керівників проектів у різних галузях та регіонах. Його основний висновок – одна з небагатьох статистичних даних з управління проектами, яку варто запам’ятати: марно витрачені інвестиції через низьку ефективність проектів знизилися до 9,4% у всьому світі, порівняно з 11,4% у попередньому році. У портфелі активних проектів на 100 мільйонів доларів США це зниження на два відсоткові пункти означає два мільйони доларів США відшкодованої вартості – щороку.

Звіт PMI не зупинився на заголовку. Він сегментував організації за їхніми операційними практиками і виявив чітку закономірність: організації, які послідовно застосовують стандарти – те, що PMI називає “гімнастичними підприємствами”, використовуючи метафору гімнаста, який поєднує дисципліну тренувань з гнучкістю рухів, – втрачають 9% інвестицій порівняно з 10,5% у традиційних організаціях. Ця ж група значно частіше мала високу організаційну гнучкість (48% проти 27%), використовувала стандартизовані практики управління ризиками (68% проти 64%) і досягла високої зрілості в управлінні проектами (52% проти 45%).

Цифра 9,4% відходів – що вона насправді вимірює

PMI визначає марно витрачені інвестиції як частку бюджетів проектів, втрачену через недотримання термінів, перевиконання бюджету та scope creep. Це ретроспективний показник, який розраховується на основі завершених проектів за попередні дванадцять місяців і про який звітують керівники проектів у своїх організаціях. Для керівників ОПП мають значення два наслідки. По-перше, ця цифра є нижньою межею, а не стелею – галузі з довшими проектними циклами та жорсткішим регулюванням, такі як будівництво, фармацевтика або великі ІТ-трансформації, часто повідомляють про більший обсяг відходів, якщо врахувати складні ефекти. По-друге, це сигнал на рівні портфеля, а не проекту. На цьому рисунку не показано окремий випадок перевитрат; на ньому показано закономірність перевитрат по всьому портфелю, і саме ця закономірність відокремлює організації, які утримують інвестиції, від тих, які їх втрачають. Для керівника ОУП це означає, що показник не можна покращити, виправивши один поганий проект – його потрібно покращувати структурно, по всьому портфелю.

Розрив зумовлений стандартами, а не культурою

Різниця в 1,5 відсоткових пункти між організаціями з високими стандартами та рештою виглядає невеликою в рамках одного проекту. У масштабі портфеля вона швидко зростає. ОУП, що управляє 50 проектами вартістю в середньому 2 мільйони доларів США на рік, має 100 мільйонів доларів США активних витрат; розрив між 9% та 10,5% втрат становить 1,5 мільйона доларів США щорічно, і за три роки цього достатньо, щоб профінансувати невеликий портфель нових ініціатив без додаткового залучення капіталу. Дані PMI показують, що розрив закривають три практики, які застосовуються послідовно, а не вибір методології. Waterfall-ОУП, які затверджують плани, ведуть реєстри ризиків і працюють з панелями керування для портфелів, перевершують Agile -команди, які цього не роблять. Заголовок простий: методологія – це рішення щодо надання послуг, управління – це інвестиційне рішення, а дані вказують на те, що управління є важелем для зменшення перевитрат бюджету.

Чому бюджети перевиконуються: три типи структурних збоїв

Перевитрати бюджету проекту в масштабі портфеля рідко спричинені однією поганою оцінкою або одним неочікуваним ризиком. Вони спричинені прогалинами в трьох операційних рівнях, які повинні підсилювати один одного: План, Ризики та видимість портфеля. Коли один з цих рівнів відсутній або застарілий, інші два не можуть його компенсувати. У наступних розділах діагностується кожен тип збою, використовуючи дані PMI, Wellingtone та KPMG; три наступні розділи пропонують операційні заходи реагування.

Відсутність робочого плану означає відсутність вимірюваного відхилення

Згідно зі звітом Wellingtone про стан управління проектами за 2024 рік, лише 48% організацій “зазвичай або завжди” складають плани графіків. Висновок простий: більше половини всіх звітів про стан проєкту описують поточний план, а не відхилення від початкового плану. Без фіксованої точки відліку “ми йдемо за планом” перетворюється на “ми йдемо за тим, чим став план”. Перевитрати зникають, бо їх неможливо виміряти, а те, що не можна виміряти, не можна виправити. Ця закономірність підтверджується тим же звітом Wellingtone, який показує, що близько половини керівників проектів витрачають щонайменше один день щомісяця на ручне звітування про стан справ; ці зусилля призводять до створення звітів про діяльність, а не звітів про відхилення, тому що в першу чергу відсутній план, який б дозволив виміряти відхилення.

Реєстри ризиків, які існують на папері, а не в операціях

Глобальне опитування KPMG щодо будівництва у 2023 році показало, що 37% респондентів пов’язують перевиконання бюджету або графіку безпосередньо з неналежним управлінням ризиками. У тому ж опитуванні KPMG повідомляється, що лише близько половини власників проєктів стверджують, що їхні проєкти завершуються вчасно, тоді як 87% відзначили зростаючу увагу до виконання проєктів з боку спонсорів та рад директорів. Домінуючою тенденцією, що спостерігається в усіх галузях, є не відсутність реєстру ризиків – це реєстр, який заповнюється на початку проекту і ніколи не оновлюється. Ризик, який був оцінений як “середній” на другому тижні, залишається “середнім” і на шостому місяці, незалежно від того, що сталося з основними умовами. Реєстр ризиків, який не переглядається, є документом, а не операційним інструментом, і документ не може спричинити прийняття рішення до того, як ризик матеріалізується.

Невидимість на рівні портфеля приховує накопичені перевитрати

Відхилення за окремими проектами часто досить малі, щоб виглядати прийнятними окремо. Перевиконання бюджету на 6% за одним проектом, перевиконання на 8% за іншим, відставання від графіка за третім – кожен з них виглядає як керований виняток, такий тип відхилення, який буде мати будь-який активний портфель у будь-якому кварталі. За відсутності єдиного портфеля, який би агрегував ці сигнали в режимі, близькому до реального часу, закономірність проявляється лише під час щоквартального огляду, коли кумулятивний ефект вже помітний у фактичному виконанні Бюджету. До того часу ОУП реагує на перевитрати, які вже відбулися, не запобігаючи наступним, а розмова зі спонсором переходить від “чи варто нам змінити пріоритети” до “як ми пояснимо розрив правлінню”. Структурна проблема полягає не в тому, що даних не існує – вони є в кожному проекті – а в тому, що вони не збираються достатньо швидко, щоб на них можна було реагувати.

Почати

План як перший важіль - як зробити його дієвим

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

Як виглядає робочий план на практиці

Операційний план містить три артефакти: затверджений графік із зафіксованими датами контрольних подій, узгоджений план витрат і еталонний обсяг, щодо якого має вимірюватися будь-яка зміна. Затвердження фіксується в системі – хто затвердив, коли і щодо якої версії плану. Без цього запису “що було затверджено” стає питанням пам’яті та археології електронної пошти, які, як правило, надають перевагу версії, що пояснює перевитрати, а не тій, що їм суперечить. Дисципліна має найбільше значення в момент змін. Коли нова вимога з’являється на четвертому місяці, питання не в тому, “чи це гарна ідея”, а в тому, “як це впливає на затверджений План, хто має затвердити зміну, і як це вплине на вартість і Графік”. Без чітко зафіксованого посилання така розмова ніколи не відбувається; зміни приймаються мовчки, а перевитрати з’являються через два місяці як несподіванка.

Як FlexiProject управляє затвердженням плану та відстеженням відхилень

FlexiProject розглядає затвердження плану як робочий процес, а не як прапорець. Графік і план витрат проходять шлях затвердження, перш ніж стати планом; після затвердження план фіксується як еталонний, і будь-яка подальша модифікація вимагає запиту на зміну з чітким повторним затвердженням призначеним органом влади. Відхилення від Плану автоматично з’являється на Панелі керування проектом – відхилення у графіку, вартості та обсязі відстежуються безперервно, а не вносяться до Звітів вручну. Для ОУП, які керують великими портфелями проектів, операційний ефект полягає в тому, що звітність про відхилення перетворюється з щомісячної вправи зі зшивання електронних таблиць на безперервний сигнал, доступний на вимогу. Керівник проекту витрачає менше часу на підготовку статусу і більше часу на дії відповідно до нього, спонсор отримує дані про відхилення в день відхилення від контрольної події, а не на наступному керівному комітеті, а аудиторський слід про те, хто, що і коли затверджував, фіксується системою, а не відновлюється постфактум. Повна механіка затвердження плану та відстеження відхилень описана в графіку FlexiProject і документації Ганта.

Управління ризиками як другий важіль - реєстри, які вижили після старту

Висновок PMI про те, що 68% організацій з високими стандартами використовують стандартизовані практики управління ризиками порівняно з 64% решти, виглядає як невеликий розрив. Ефект кумулятивного ефекту в рамках портфеля розповідає зовсім іншу історію. Реєстр ризиків, який функціонує – регулярно проводиться огляд, належить конкретним особам, пов’язаний з Графіком і впливом на Бюджет, – виявляє проблеми за кілька тижнів до того, як вони стануть перевитратами. Реєстр, який існує лише як документ, цього не робить.

Від театру ризиків до ризикованих операцій

Три конкретні зміни відрізняють роботу з реєстром ризиків від його ведення. По-перше, періодичність оглядів: раз на два тижні зі спонсором проекту , а не щоквартально на засіданні керівного комітету – до моменту проведення щоквартального огляду деякі з ризиків, перелічених під час попереднього огляду, або матеріалізувалися, або втратили актуальність, і огляд є реакцією, а не прогнозуванням. По-друге, відповідальність: кожен ризик має власника, який не є Керівником проекту, з чіткими заходами реагування та дедлайном; коли власником за замовчуванням є “Керівник проекту”, реакція ніколи не є достатньо конкретною, щоб її можна було відстежити, і ризик стає скоріше записом у документації, аніж об’єктом для дій. По-третє, спрацьовує ескалація: статус ризику прив’язаний до прогресу у виконанні контрольної події, тому відставання від контрольної події автоматично підвищує відповідні ризики, замість того, щоб чекати на наступний огляд, щоб виявити їх вручну. Кожна з цих трьох змін є незначною сама по собі, але разом вони перетворюють реєстр ризиків із запису, який заповнюється, на систему, що стимулює прийняття рішень.

Як FlexiProject стандартизує практики управління ризиками в портфелі проектів

FlexiProject зберігає реєстри ризиків як структуровану частину запису проекту, пов’язану з графіком і паспортами проекту. Ризики мають власників, заходи реагування та оцінки впливу, які згортаються у звіти про ризики на рівні портфеля – керівник ОУП може бачити по всьому портфелю, які категорії ризиків зростають, які проекти піддаються яким загрозам, і які заходи реагування прострочені. Рівень звітності будується на основі даних реєстру ризиків, а не збирається окремо для кожного засідання керівного комітету; звіт про ризики портфеля в день огляду – це той самий звіт, який був доступний тижнем раніше, а це означає, що рішення можуть бути прийняті до засідання, а не під час нього. Така структура також дозволяє порівнювати проекти між собою: ризики, що виникають одночасно в трьох проектах, розглядаються як портфельні ризики, а не як три ізольовані проектні ризики, і реакція на них може бути стандартизованою, а не імпровізованою. Детальні механізми реєстрів ризиків та звітності на рівні проекту описані в документації щодо звітів FlexiProject та в документації щодо паспортів проекту.

Проекти, організовані за портфоліо проектів у системі управління проектами FlexiPorject PPM

Управління портфелем як третій важіль - раннє виявлення перевитрат

Практики плану та ризиків є необхідними, але недостатніми. Вони діють на рівні проекту і відповідають на питання “Чи йде цей проект за планом?” Рівень портфеля відповідає на інше питання: “враховуючи все, що ми знаємо про всі наші проекти, які рішення ми повинні приймати зараз?” Висновок PMI щодо зрілості PM (52% проти 45%) відображає цей розрив. Організації, які подолали цей розрив, не є кращими у виконанні окремих проектів – вони краще приймають рішення на рівні портфеля на основі даних на рівні проекту.

Що насправді показує видимість портфоліо керівника PMO

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

Як рівень портфеля FlexiProject пов’язаний з планами проекту та реєстрами ризиків

Подання портфеля FlexiProject об’єднує дані, які вже існують у проектах: план, відхилення, реєстр ризиків, статус контрольних подій, вартість. Ніщо не вводиться двічі – керівник проекту оновлює проект, а подання портфеля оновлюється автоматично, що усуває найпоширеніший тип помилок у портфелях на основі електронних таблиць, коли цифри на рівні проекту та портфеля непомітно розходяться між оглядами. Керівник ОУП бачить єдине представлення, яке пов’язує плани проекту з рішеннями на рівні портфеля: проект, що відхиляється від плану, негайно з’являється на тепловій карті портфеля; ризик, який перетинає поріг впливу, переходить до представлення ризиків портфеля; проект, який не досягає контрольної події реалізації вигод, з’являється в огляді вигод портфеля. Цикл – план проекту, відхилення, згортання портфеля, управлінське рішення – триває безперервно, а не щоквартально, що означає, що рішення можна приймати, коли вони все ще є превентивними, а не коригуючими. Детальна конфігурація представлень портфеля та оглядів проектів описана в документації щодо портфеля FlexiProject і документації щодо оглядів проектів.

Вкладка “Ризики” з реєстром ризиків у поданні портфоліо проектів у FlexiProject

Почати

Що змінюється, коли всі три важелі працюють разом

Дані PMI не показують трьох незалежних ефектів. Вони показують один кумулятивний ефект: організації, які використовують плани, ризики та портфельні практики як цілісну систему, втрачають 9% інвестицій, тоді як ті, що використовують їх непослідовно – або не використовують взагалі – втрачають 10,5% або більше. ОУП, яка веде від 30 до 50 проектів, може визначити, чи працює система, за кількома конкретними сигналами.

Три сигнали, що система працює

Звіти про відхилення створюються за лічені хвилини на основі системних даних, а не за дні на основі агрегації в електронних таблицях; керівник проекту, який раніше витрачав перший робочий день кожного місяця на підготовку пакету статусів, тепер використовує цей день для реагування на ризики та управління зацікавленими сторонами. Рішення щодо ризиків переходять від щомісячних керівних комітетів до щотижневих оглядів проєктів, оскільки дані підтримують швидші цикли, а вартість очікування стає вищою, ніж вартість прийняття рішення. Зміна пріоритетів портфеля відбувається на основі сигналів Панелі керування – відхилення проекту від Плану, перевищення ризиком порогового значення, зниження реалізації вигод – а не на основі того, хто голосніше за всіх виступає на щоквартальному огляді або який проект має найбільш високопоставленого спонсора. Розмова в керівному комітеті змінює характер: менше часу на “який статус проекту Х”, більше часу на “враховуючи дані портфоліо проектів, який проект слід призупинити, щоб вивільнити ресурси для проекту Y”.

Три сигнали, що це ще не так

Наради щодо стану справ все ще продукують дані, а не споживають їх: керівник проекту витрачає один день щомісяця на підготовку пакета статусів, і дані вже тижневої давнини, коли вони презентуються. Реєстр ризиків застаріває до кінця місяця; одні й ті ж ризики протягом трьох кварталів залишаються в списку “середнього” рівня без жодних записів про огляди, без відповідальності власників і без прив’язки до контрольних подій, які мали б стати приводом для переоцінки. Щоквартально під час огляду портфеля переглядаються ті самі п’ять проблемних проектів, оскільки базові дані не оновлюються між оглядами, і рішення, прийняті під час одного огляду, доводиться оскаржувати під час наступного, коли ситуація знову погіршується. Це не особистісні проблеми – керівники проектів і співробітники ОУП, як правило, старанно працюють в рамках системи, яку їм надали. Це сигнали про те, що один або більше з трьох рівнів не працює як система, і реакція на це є структурною, а не мотиваційною.

Поширені запитання про перевитрату бюджету проекту та управління ОУП

Що вважається прийнятним рівнем перевищення бюджету проекту?

Універсального порогового значення не існує, і відповідь залежить від типу проекту, галузі та зрілості системи управління. Дані PMI показують, що організації з високими стандартами в середньому втрачають близько 9% інвестицій у проект, тоді як решта втрачають 10,5% і більше – обидві цифри включають проекти, які завершуються в рамках бюджету, і ті, що перевиконуються, тому перевитрати на проект у проектах, які фактично перевиконуються, є значно вищими. На рівні окремих проектів більшість систем управління ОПУ розглядають відхилення понад 10% як такі, що вимагають офіційного огляду спонсором і прийняття задокументованого рішення, а менші відхилення відстежуються за допомогою стандартної звітності про відхилення. Більш корисним є питання не “який рівень перевитрат є прийнятним”, а “при якому рівні відхилень ОУП приймає рішення”, і цей поріг має бути визначений в системі управління ще до початку першого проекту.

Чим затвердження плану відрізняється від збереження діаграми Ганта?

Збереження діаграми Ганта зберігає поточний план. Затвердження плану створює фіксовану точку відліку, з якою порівнюється поточний план. Різниця полягає в операціях: збережену діаграму Ганта можна редагувати без запису того, що змінилося, тоді як затверджений план вимагає запиту на зміну і явного перезатвердження для внесення змін. Без цього запису відхилення від базової лінії неможливо виміряти, оскільки сама базова лінія рухається разом з планом – кожен звіт про стан проекту містить висновок про те, що проект рухається за планом, оскільки “план” – це те, що є на сьогодні. Ця ж відмінність пояснює, чому деякі організації звітують про послідовне і своєчасне виконання, в той час як їхні фактичні показники бюджету відрізняються від початкового бізнес-плану: план, який вони вимірюють, був змінений в процесі виконання проекту, часто без чіткого погодження, тому відхилення ніколи не було видимим в першу чергу.

Чи потрібно бути “Agile”, щоб зменшити перевитрати бюджету проекту?

Дані PMI свідчать про протилежне. Фактором, який корелює з меншими відходами, є послідовне використання стандартів – плану, управління ризиками, управління портфелем – а не вибір методології. Водоспадний ОПП, який затверджує плани, веде реєстри ризиків і використовує Панель керування портфелем, перевершить “Agile” команду, яка цього не робить. Методологія – це вибір способу надання послуг; стандарти – це вибір керівництва. Дані вказують на те, що управління, а не реалізація, є важелем зменшення перевитрат бюджету, що також є корисним для ОУП, які працюють у гібридних середовищах: однакові стандарти управління застосовуються до Waterfall, Agile та гібридних проєктів, тоді як методологія реалізації обирається для кожного проєкту залежно від типу роботи.

Як часто ОУП має проводити огляди реєстру ризиків?

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

У чому різниця між управлінням на рівні проекту та на рівні портфеля?

Управління на рівні проєкту відповідає на запитання “чи відповідає цей проєкт своєму Плану і ризикам?” Управління на рівні портфеля відповідає на питання: “З огляду на стан усіх наших проектів, які рішення організація повинна приймати зараз?” Ці два рівні вимагають різного представлення даних і різного ритму прийняття рішень – управління проектами працює в тижневому або двотижневому циклі і оперує детальними даними про контрольні події і ризики, в той час як управління портфелем працює в місячному або квартальному циклі і оперує агрегованими даними про відхилення, ризики і реалізацію вигод. Більшість ОУП, які борються з перевищенням бюджету, використовують один з двох рівнів, а не обидва. Найпоширенішою помилкою є сильне управління на рівні проектів – хороші плани, активні реєстри ризиків – без портфельного управління, яке перетворює ці сигнали на портфельні рішення; проекти добре управляються окремо, але портфель в цілому дрейфує.

Усунення розриву між стандартами та результатами

Дані PMI не вказують на Agile, методологію чи культуру як важелі зменшення перевитрат бюджету проекту. Вони вказують на три операційні практики, що застосовуються послідовно: затвердження плану, який фіксує еталон, відносно якого вимірюється відхилення, управління ризиками, яке діє між початком і завершенням проекту, а не лише на початку, та управління портфелем, яке об’єднує сигнали на рівні проекту в рішення на рівні портфеля. Розрив у 1,5 відсоткових пункти між організаціями, що дотримуються високих стандартів, і рештою виглядає скромно, доки його не помножити на активний портфель – і тоді він стає реальними грошима, що приносять рік за роком.

Найсильніші ініціативи ОПУ – це не ті, які додають четвертий інструмент, щоб виправити прогалину в третьому. Це ті, які керують планом, ризиками та портфелем проектів як єдиною системою, зі спільними даними, спільною каденцією та спільною відповідальністю. FlexiProject вирізняється тим, що поєднує всі три компоненти в одній платформі: робочі процеси затвердження планових показників, які створюють безперервні сигнали про відхилення, реєстри ризиків, пов’язані з Графіком і розгорнуті до рівня портфеля, та Панель керування портфелем, побудована на основі тих самих базових даних, а не на основі електронних таблиць, зшитих разом для наступного огляду. Для керівника ОУП, портфель якого налічує десятки мільйонів активних витрат, подолання навіть частини розриву в 1,5 відсоткових пункти багаторазово окупить операційні інвестиції – і шлях до його подолання пролягає через управління, а не методологію.

Dominik Wrzosek

General Manager at FlexiProject

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