Чому провалюються ІТ-проєкти: політика в технологічних змінах

Привіт, мене звати Юлія, і я вже 18 років працюю в ІТ. За цей час упровадила багато десятків проєктів — як в Україні, так і за кордоном — для різних клієнтів: від стартапів до міжнародних корпорацій. Траплялося всяке. Деякі проєкти, хоч неймовірно складні й ризиковані, успішно запускалися. Бувало, що лідерами ринку ставали маленькі продукти. А іноді важливі трансформаційні проєкти так і залишалися на папері або не були запущені в експлуатацію, попри значні інвестиції та ризики утраченої вигоди.

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

На посаді Delivery Director я впроваджую великі програми для міжнародних клієнтів. З часом прийшло усвідомлення, наскільки впливовий людський фактор, або те, що називають «політикою». Культура організації їсть стратегію на сніданок, а політичні фактори з’їдають технологічні проєкти навіть раніше. Неважлива складність проєкту і наскільки професійною є команда — завжди може виникнути ситуація, яка лежить поза стандартним поняттям управління проєктами. І якщо менеджеру або команді не до снаги її обробити, то проєкт може зазнати невдачі. Коли на співбесідах у менеджерів питають, чи працювали вони з клієнтами, то часто мають на увазі саме навички менеджера працювати з політикою на стороні замовника.

Цей блог — моя спроба поділитися досвідом і допомогти іншим професіоналам зрозуміти не лише технічні аспекти, але й політичні чинники успішності проєкту. Тут наведено найчастіші проблеми, з якими я стикалася в розробці, впровадженні й запуску проєктів у корпоративній сфері. А наприкінці кожного блоку — способи мінімізувати вплив «політики».

Стаття буде цікава проєктним менеджерам, тимлідам, аналітикам, а також усім, хто бере участь у розробці та впровадженні ІТ-проєктів.

Політичний опір змінам

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

Наприклад, під час упровадження ERP-системи я стикалася з тим, що завданням автоматизації процесів було зменшення ручної праці. Як наслідок — звільнення працівників, які раніше виконували ці завдання. Проте саме вони, носії знань бізнес-процесів, могли запропонувати посутні вимоги до функціонування ERP. Звичайно, такі працівники не виявляли ентузіазму долучатися до створення системи, що призначена їх замінити.

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

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

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

Впровадження ІТ-системи може суперечити KPI менеджерів, особливо у великих корпораціях, де зміни в системи мотивації вносять дуже повільно.

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

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

Що можна зробити:

• Прийняти наявність політичних проблем, адже рідко який суттєвий проєкт не стикнеться з такими проблемами.
• Заручитися підтримкою керівництва компанії клієнта й обговорити з ними ці ризики. Разом спланувати важелі впливу.
• Налаштувати постійний комунікаційний канал з керівництвом для надання звітів і обміну зворотним зв’язком.
• Запропонувати керівництву замовника мотивацію для їхнього менеджменту на впровадження системи.
• Дотримуватися принципу: анонсувати зміни в організації клієнта (як-от зміна ролей, позицій, процесів) має замовник, а не постачальник.
• Відразу запровадити метрики оцінки якості вашої роботи та звітувати за ними, навіть якщо цього не вимагають.
• Не брати участі у внутрішніх конфліктах клієнта і не ставати ні на чий бік.
• Не уникати стейкхолдерів, які проти вашого проєкту, а навпаки — залучати їх до зустрічей.

Ці кроки допоможуть зменшити політичний опір і підвищити шанси на успішне впровадження ІТ-проєкту.

Відсутність політичної волі

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

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

Часто ситуації такого штибу виникали під час автоматизації бекофісних процесів (внутрішній документообіг, HR-процеси тощо), що не є ключовими в бізнесі. Такі проєкти замовляють, щоб зменшити витрати на бекофіс. Проте для власників бізнесу вони не цікаві, оскільки не створюють конкурентної переваги. Тому клієнти сподіваються, що проєкт «зробиться» без їхньої уваги.

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

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

Що можна зробити:

• Якщо втрата інтересу була суто суб’єктивна (тобто керівник утратив цікавість, але проєкт потрібен), треба шукати підходи до клієнта і «розважати» його. Показувати, що конкуренти працюють у цьому ж напрямку, що впровадження надає певного статусу тощо.
• Організовувати публічні події та запрошувати виступати клієнта, розказувати про цілі й прогрес проєкту.
• Шукати союзників серед менеджменту. Знайти тих, кому проєкт цікавий і хто може вас підтримати.
• Якщо він дійсно не становить цінності, треба по змозі переформатувати проєкт так, щоб віднайти його значущість.
• Іноді є сенс зупинитися, сказати клієнту, що він марно витрачає гроші, і запропонувати інші сервіси або доречні покращення (з огляду на відому про замовника інформацію). Ви можете втратити прибуток цього разу, проте здобудете довіру клієнта, що окупиться в майбутньому.

Зміна керівництва

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

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

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

Що можна зробити для того,..

...щоб дізнатися про зміни:

• Пізнати свого клієнта, щоб розуміти, що відбувається в індустрії, організації, департаменті замовника.
• Довідатися все можливе про стейкхолдерів: їхні кар’єрні плани, структуру KPI, хобі, інтереси. Слухати більше, ніж говорити. Підтримувати дружні стосунки.
• Налаштувати сповіщення про зміни в новинах (якщо вони публічні), питати у своїх стейкхолдерів про зміни, зробити звичкою обмінюватися апдейтами про стан справ.

...щоб зменшити проблеми з новими стейкхолдерами:

• Документувати всі рішення, ухвалені впродовж проєкту. Це допоможе вам аргументувати свою позицію перед новим керівництвом. Ведіть реєстри ризиків і ескалацій.
• Налагодити стосунки всередині компанії клієнта, щоб новий менеджер міг отримати про вас позитивні відгуки від своїх колег.
• Після зміни керівництва сприймати це як роботу з новим клієнтом у новому проєкті. Не припускайте, ніби все налагодиться само собою. Активно будуйте стосунки з новим менеджером. «Продайте» себе знову, спитайте про плани, передивіться цілі проєкту, поцікавтеся вподобаннями в комунікації та інше.

Психологічний опір змінам

Або іншими словами — «ми завжди так робили». Під час автоматизації процесів у банках я нерідко запитувала, чому бізнес-процес побудований саме так. Відповідь — так колись було заведено або так вимагали регулятори чи керівництво. Хоча умови відтоді давно змінилися.

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

Що можна зробити:

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

Зміни в процесах та управлінні

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

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

Що можна зробити:

• З’їсти слона частинками. Уникайте підходу «все і зразу». Важливо правильно поділити впровадження на етапи. Дуже рекомендовано дотримуватися value chain, тобто робити це через відокремлені бізнес-процеси, на противагу впровадженню «подепартаментно».
• Описати процеси AS-IS і TO-BE. Необхідно мати опис поточних процесів (AS-IS) і бажаних процесів (TO-BE), щоб розуміти різницю й коректно спланувати зміни.
• Підготувати детальний план змін. Бажано, щоб він був відрепетируваний, аби запобігти негативному впливу на бізнес клієнта.
• Виділити час для персоналу, щоб вони могли ефективно впроваджувати зміни.
• Сформулювати процеси (якщо вони не описані взагалі). Це не завжди можливо, тому можна використовувати поступову автоматизацію, починаючи з базових завдань, і плавно підштовхувати клієнта до усвідомлення необхідності формалізації.

Відсутність стратегії розвитку

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

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

Що можна зробити:

• Установити жорстке управління вимогами і їхніми змінами. Хоч ви й не визначите стратегію за клієнта, однак можете створити умови для оплати вашої роботи з імплементації цих змін і для уникнення перевантаження команди.
• Налагодити процеси пріоритезації завдань та затвердити ці пріоритети. Встановлення структурованих процесів для пріоритезації й схвалення завдань допоможуть уникнути ситуацій, коли різні зацікавлені сторони мають відмінні уявлення про пріоритети. Це також допоможе відсіяти деякі завдання під час узгодження.
• Спробувати ітеративне впровадження зі «швидкими перемогами». Так можна демонструвати клієнту успіх проєкту і повернення інвестицій у їхньому фінансовому циклі. Завдяки цьому підходу ви мінімізуєте ризик розходження зі стратегією і зможете регулярно виправляти курс.
• Домовитися з клієнтом про відсоток часу, заздалегідь виділений на технічні стратегічні покращення. Уникайте дискусій на рівні окремих завдань, фокусуючись на загальному концепті.
• Ввести критерії якості, definition of done, acceptance criteria на початку і не допускати прецедентів їх недотримання. Це забезпечить високу якість продукту навіть у нестабільних умовах.

Відсутність кваліфікованого персоналу

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

Також важливо мати на боці клієнта спеціалістів, що розуміються на ІТ і що беруть участь у проєкті. Колись я витратила три незабутні тижні в ескалаціях від замовника, бо наша система документообігу «не розшивала і не зшивала» фізичні документи. Пояснити, чому ERP-система не може цього зробити, було важко.

Клієнт може помилково вважати, що достатньо мати лише керівника проєкту на стороні постачальника, і не бачити потреби виділяти додаткові ресурси.

У такій ситуації постачальник може взяти ініціативу та запропонувати варіанти рішень на кшталт:

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

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

Резюме

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

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