Зомбі бувають не лише у фільмах, але й в бізнесі. Це проєкти, які колись, може, й були хорошими ідеями, проте наразі від них залишилася сама оболонка. Вони тягнуться роками, дарма споживають ресурси компанії, але не дають нічого натомість.
Поставити крапку часто заважає страх визнати невдачу, а іноді в команди просто немає чіткого регламенту, як це зробити. В опитуванні Wellspring лише 15% компаній заявили, що мають чіткий та послідовний процес завершення неефективних проєктів.
Джеральд Леонард, консультант з управління портфелями проєктів та сертифікований експерт PMI, розробив фреймворк 4R’s (Retire, Redirect, Repackage, Reflect). Він допоможе раз і назавжди попрощатися з зомбі — без болю для команди й з користю для бізнесу.
«Це означає, що нам не вдалося…» — чому проєкти залишаються у підвішеному стані
Є чимало обставин, за яких проєкт може зупинитися і втратити свою актуальність: зміна пріоритетів стейкхолдерів, конкуренти утнули щось несподіване, дефіцит бюджету, фахівців або технологій. І врешті-решт — слабке управління та накопичення ризиків.
Однак замість того щоб чесно визнати, що проєкт більше немає сенсу, зробити висновки та йти далі, команди часто відкладають його в дальню шухлядку. І там він відлежується, чекаючи на свій зірковий час, який зазвичай так і не настає.
Такі проєкти неофіційно називають «зомбі» — занадто мертві, щоби бути корисними, але все ще достатньо живі, щоб «смоктати» ресурси компанії. Вони час від часу спливають на зустрічах і нагадують про себе на ретроспективах примарним шепотом «ми зробимо це наступного кварталу…».
Ніхто не розуміє, навіщо вони ще існують, але й сміливців офіційно попрощатися з ними теж немає. Чому так відбувається — пояснюють дослідники PMI:
- Ефект незворотних витрат (Sunk Cost Effect)
Учасники часто думають так: «Ми вклали купу ресурсів, тому треба продовжувати». Ця пастка змушує тримати проєкт на плаву, навіть якщо це зовсім не вигідно організації. - Самовиправдання (Self-Justification)
Закриття часто сприймається як невдача. Керівники не хочуть визнавати, що їхні попередні рішення були помилковими, бояться, що остаточна відмова від проєкту нашкодить їхній репутації. - Оптимістичне упередження (Optimism Bias)
Люди схильні переоцінювати свої можливості й недооцінювати ризики. Це створює ілюзію контролю: навіть коли все свідчить про провал, здається, що «треба трохи почекати — і проблеми якось розв’яжуться».
Буває, що команда сприймає проєкт як своє «дітище» або топменеджмент/спонсори сліпо закохані в ідею — тоді проєкт банально шкода закривати й зомбі продовжує блукати. Іноді офіційного закриття не передбачає культура організації — не наголошує на формальних процесах, команді бракує для цього повноважень або немає чіткого алгоритму, як це зробити.
Чому чіткий фінал все ж потрібен
Закриття проєктів — це не просто «прибирання» або формальність, а стратегічна необхідність, яка дозволить перенаправити капітал і зусилля команди на щось важливіше.
За даними PMI, через слабке управління проєктами компанії втрачають у середньому 11,4% інвестицій. Однак рідко хто рахує «прибуток від зупинки» — скільки ресурсів звільнилося, яких ризиків вдалося уникнути та які нові можливості відкрилися завдяки тому, що команда перемкнулася на інші завдання.
Уявіть дашборд, де замість «ще один закритий проєкт» ви бачите:
Такі показники точно б дозволили «відпустити» проєкт-зомбі зі спокійною душею. А також перетворити фінал з «крапки у звіті» на цінний актив, щоб рухатися вперед з чітким фокусом, а не за інерцією.
Модель 4R’s — фреймворк для закриття проєктів
4R’s Framework розшифровується як Retire, Redirect, Repackage, Reflect (Завершити, Перенаправити, Перепакувати, Осмислити). Це авторська модель Джеральда Леонарда, яка поєднує:
- ідеї з нейронауки (наприклад, про те, як мозок потребує «закриття гештальтів» і страждає від перевантаження вибором)
- стандарти PMBOK / PMI Closing
- власний досвід консалтингу Джеральда в корпораціях Fortune 100, держструктурах і tech-компаніях
Retire — все має свій початок і кінець
Згадайте, скільки уваги ви приділили старту проєкту — стільки ж треба приділити його завершенню. Це означає:
— підбити фінанси
— закрити звіти
— оновити дашборди
— чітко донести рішення до всіх стейкхолдерів
Таке завершення не тільки наводить порядок, але й показує повагу до команди. Це сигнал «Наша робота мала цінність, навіть якщо проєкт пішов іншим шляхом».
З погляду психології, мозку важливо «закрити гештальт». Незавершені справи нас напружують і відволікають від нових цілей. Коли проєкт офіційно закрито, когнітивні та емоційні ресурси вивільняються, що дозволяє впевнено рухатися далі.
Що варто зробити:
— Оголосити про закриття. Пояснити причини, підсумувати здобутки та розповісти про наступні кроки.
— Залучити команду. Разом підсумувати ключові моменти, відзначити внесок кожного і поділитися висновками. Це додає прозорості й закріплює культуру відповідальності.
Redirect — не бійтеся жонглювати ресурсами
Суть цього кроку — в тому, щоби перенаправити зусилля команди зі «сплячих» проєктів на нові, де фахівці матимуть більший вплив.
Це може бути:
— передоручення завдань співробітникам
— повернення невикористаних бюджетів
— концентрація уваги керівництва на перспективніших проєктах
За даними McKinsey, компанії, які гнучко перерозподіляють ресурси залежно від потреб, за 10 років отримують на 30% більшу віддачу для акціонерів, ніж ті, що працюють за жорстким планом. А менеджери, які протягом перших трьох років роботи здебільшого нехтували перерозподілом ресурсів, мали більшу ймовірність звільнення, ніж їхні активніші колеги.
Що варто зробити:
— Створіть простий «дашборд ресурсів», щоби бачити, які люди, бюджети та інструменти звільняються після завершення проєктів.
— Якщо переводите працівників на інші завдання — поясніть, як їхня нова робота допоможе досягти стратегічних цілей компанії. Це дозволить зберегти довіру та мотивацію команди.
Repackage — збережіть те, що ще має цінність
Завершення проєкту не означає, що «більше нічого не працює». Код, дизайни, набори даних, інсайти від партнерів, відносини з постачальниками, результати досліджень — це інтелектуальний капітал, який можна зберегти й використати повторно.
Наприклад:
1. Бульбашкова плівка (той самий поп-іт міленіалів) у 1950-х роках задумувалась як текстуровані шпалери, однак у засновників виникли труднощі з просуванням, тож ідея не прижилася. Замість того щоби повністю відмовитися від технології, вони почали думати, як дати їй друге життя. І згодом почули, що IBM потрібен захисний матеріал для транспортування нового обчислювального блоку 1401. «Бульбашки» успішно пройшли випробування і досі використовуються для пакування.
2. Сервіс для онлайн-спілкування та співпраці Google Wave (2009–2010) вважають одним із найгучніших провалів компанії, але його спадщина виявилася вагомою. Попри закриття проєкту, деякі технології були повторно використані в Google Docs:
- character-by-character editing («редагування символ за символом») — дозволяє бачити в реальному часі кожну зміну тексту, яку вносить інший користувач
- live editing — одночасне редагування документа кількома людьми онлайн
- вбудовані чати — текстові обговорення всередині самого документа без потреби переходити в інший месенджер
Ці інновації могли зникнути, але натомість знайшли своє місце в інших продуктах і прискорили роботу над ними.
Що зробити:
— Проведіть reuse sprint (пошук рішень, які можна повторно використати) одразу після завершення. Долучіть до цього розробників, стратегів, операційні команди.
— Створіть базу знань та інтегруйте її в онбординг, інноваційні лабораторії та міжфункціональні воркшопи.
— Відзначайте повторне використання в performance review, щоб дати сигнал команді: «наявним/готовим рішенням можна дати друге життя, і це також цінується».
Reflect — витисніть з помилок максимум користі
Команді потрібно зупинитися, обговорити, що вдалося, що ні та які уроки можна винести. Це не пошук винних, а спосіб разом підсумувати досвід і зняти напругу.
Якщо цього не робити, «незакриті» емоції та проблеми перетягуються у нові проєкти. Люди стають більш обережними або навіть цинічними. А коли команда обговорює досвід, вона стає впевненішою: всі розуміють, що проєкт справді завершився — і тепер вони знають, як зробити краще наступного разу.
Що можна робити:
— додати sunset review (обговорення після завершення) в процес керування проєктами, а не тільки контрольні точки та запуски
— робити рефлексію стандартною частиною роботи — відверті розмови, спільне навчання
— збирати висновки у спільну базу знань, яка стане в пригоді для майбутніх проєктів
— залучати учасників з різних команд, щоб обмінюватися досвідом
Коли лідери самі відкрито аналізують результати, це створює атмосферу довіри. Тоді команди перестають боятися помилок і сприймають їх як нормальну частину шляху. А часом вони стають початком нових ідей.
Бажаєте отримувати дайджест статей?
