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

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

Максим Прохоров, власник та засновник PM PARTNERS розповів про те, як управляти проєктами, коли навколо відбуваються постійні зміни, як вибудовувати стратегію та працювати з довгостроковими проєктами, щоб досягати поставлених результатів.

1) Що таке управління проєктами?

Управління проєктами — це насамперед управління очікуваннями один одного. І часом йдеться не про двостороннє спілкування (клієнт-замовник), а відразу про кілька стейкхолдерів. При такому управлінні виникають принципи прозорості, довіри, колективного зворотного зв’язку про виконану роботу. Хто керує очікуваннями, той, в принципі, керує всім. Окрім очікувань, управління проєктами — це історія про бізнес, а отже, й про гроші. Тут важливо вміти керувати ресурсами, завданнями, адже якщо цього не робити, бізнес стає збитковим та аморальним.

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

Кожен згодом знаходить своє трактування того, що таке управління проєктами. У випадку PM Partners — це управління очікуваннями та управління ресурсами.

2) Які види управління проєктами виділяєте?

Є кілька видів методологій — Waterfall та Agile. Але, якщо чесно, немає 100% виду, бо насправді все міксується. Waterfall (каскадний метод) — за послідовність виконання завдань. Найчастіше він присутній у великих інженерних проєктах, державних проєктах. Якщо ти не вивчиш усю нормативну документацію й підеш за методологією Agile (гнучка методика), у тебе не буде розуміння, куди ти прийдеш.

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

3) Які проєкти можна вважати довгостроковими?

Короткострокові — проєкти, що тривають до 3 місяців. Вони не потребують великого ефективного налаштування. Команда не перевантажена й складається з 6 осіб максимум. Зазвичай такі проєкти — це пітчі, це швидкість та сервіс.

Середньострокові проєкти — від 3-х до 12 місяців. Якщо такий проєкт не перевищує календарний план, він не несе за собою певної фінансової звітності та несуттєво впливає (не перебудовує) на внутрішню діяльність компанії. Відбувається трансформація, але на окремих ділянках. Зазвичай це проєкти на якийсь відділ чи підрозділ.

Довгострокові — проєкти, тривалість яких від 12 місяців до 3-х років. Такі проєкти суттєво змінюють та трансформують всю компанію.

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

4) Чи існують методики управління довгостроковими проєктами? Чим відрізняються від управління короткостроковими?

Перша методика — це побудова з клієнтом максимально довірливих стосунків.

Друга методика — це розв’язання проблем. Проєктна робота — це регулярна ідентифікація проблем та визначення підходу до їх вирішення. Таких проблем, виходячи з нашого досвіду, виявилося 4: проста, складна, динамічна та хаотична.

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

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

Такі методики управління проєктами можна використовувати як для довгострокових, так і короткострокових проєктів.

5) Як будувати стратегію нового проєкту з огляду на постійні зміни на ринку?

Для початку під час запуску проєкту визначити його межі. Методологія Waterfall саме про це: потрібно намітити цілі та рухатися ними як сходами.

Довгострокові та середньострокові проєкти краще поділити на етапи, щоб можна було зупинятися, переглядати плани, вносити зміни. Ідеальний відрізок часу, який ми для себе обрали — це 3-4 місяці.

Ми йшли до такої методології шляхом спроб та помилок протягом 5 років. Власники хочуть бачити результати, й коли робота йде етапами — завжди є можливість його показати.

Крім цього, існує важлива штука — моделювання або візуалізація проєкту. Іншими словами, створити за $5 модель та показати замовнику. Так, вона може бути максимально негарною, але кращого тестувальника ніж кінцевий користувач не існує. Не чекайте ідеального продукту, покажіть його на початковій стадії, навіть якщо він ще не до кінця працює. Важливо дати модель продукту та отримати зворотний зв’язок. Етап моделювання — дуже важливий перед запуском основних процесів.

6) На якому етапі слід переглянути стратегію розвитку, що існує? Які «дзвіночки» для цього мають бути?

• Перший «дзвіночок» — коли ти розумієш, що робиш автоматизацію лише заради автоматизації. Коли ресурси, витрачені на певні дії з трансформації, не дали пропорційно більшого результату: ти витратив мільйон, а на виході він тобі дав 10 тисяч.
• Другий “дзвіночок” стосується того, що ти робиш: коли повертаєшся до проєкту через 3 місяці подивитися, хто цим користується, а виявляється, що ніхто.
• Третій «дзвіночок» — коли змінилася операційна команда. Випадків, коли нова команда йде за старою стратегією, дуже мало. Швидше за все, якщо проєктна команда змінюється, то зі стратегією не було все добре. В такому разі краще взяти паузу й загалом переглянути напрямок, у якому компанія рухається.

В нашій практиці були випадки, коли у довгостроковому проєкті змінювався і замовник, і виконавець. Ми брали паузу на 2-3 місяці, пояснювали власнику, що такий крок варто зробити, інакше є велика ймовірність на виході отримати зовсім не те, що хотілося б.

Поділюся кількома кейсами PM PARTNERS.

Кейс 1 — девелоперська компанія:

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

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

Кейс 2 — компанія з виробництва вина:

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

Через 3 місяці власник «відчув» свою компанію. Але з самого початку замовник не мав проєктної команди. Вона з’явилася через рік роботи над проєктом, тоді ж суттєво змінився акцент в його управлінні. Почалися конфлікти, і ми вирішили зробити паузу на 3 місяці, щоб стабілізувати ситуацію. В результаті розділили проєкт на дві частини: те, що компанія робить самостійно, і те, чим займаємося ми — проєктною історією з розвитку компанії.

7) Які фактори можуть призвести до змін у проєкті?

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

8) Як аналізувати та впроваджувати зміни до проєкту?

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

Для початку необхідно визначити ціль — що ми хочемо отримати в результаті роботи. Якщо є мета, має з’явитися статут — хто і чим займається у проєкті, хто які має завдання. Важливо розуміти, що є дві проєктні команди: внутрішня та зовнішня. Варто визначити їхні повноваження, це значно спрощує комунікацію. Кожні 1-2 тижні необхідно фіксувати результати та зміни, які ці результати принесли. У жодному разі зміни не повинні відхилятися від цілі й тим більше впливати на неї.

Для детального розуміння проєкту ми проводимо діагностику. Це наше внутрішнє ноу-хау. Навіщо вона потрібна? 99,9% клієнтів самі не знають, чого вони хочуть і приходять за вже готовим рішенням. Завдяки діагностиці клієнт розуміє, чого насправді хоче від проєкту, він пропускає цей проєкт через себе. Тоді витрачені ресурси, час та гроші не будуть марними.

Найкращі клієнти — це ті, що розуміють свої бажання: вони знають, чого хочуть, скільки це коштує й готові керувати процесом. Але таких 1 зі 100. Є клієнти, які не знають чого хочуть, але готові з цим щось робити, розбиратися. А є ті, котрі не знають та не хочуть, бо їм здається, що думають, що знають і хочуть. Вони найскладніші й часто робота з такими закінчується на етапі діагностики. З кожним таким типом клієнтів ми маємо різні фінансові відносини, тому що різний ступінь відповідальності за проєкт.