Zakończenie projektu, które nie kończy historii

Zakończenie projektu, które nie kończy historii

W idealnym świecie projekty IT kończą się zgodnie z planem: zakres dowieziony, system działa, użytkownicy zadowoleni, a na koniec symboliczne „go‑live” i wspólne zdjęcie zespołu. Rzeczywistość bywa jednak znacznie bardziej złożona — szczególnie wtedy, gdy w grę wchodzą duże systemy operacyjne.

Ostatnio braliśmy udział w projekcie konsultacyjnym dotyczącym koordynacji wdrożenia całej gamy systemów. I choć nasza rola dobiegła końca, sam projekt u klienta toczy się dalej. To dobry moment, by podzielić się kilkoma obserwacjami z perspektywy konsultanta zewnętrznego — bez wskazywania winnych, za to z naciskiem na wnioski.

Konsultant jako „zewnętrzne lustro”

W tego typu projektach rola konsultanta rzadko polega na podejmowaniu decyzji za klienta czy dostawcę. Znacznie częściej jest to funkcja katalizatora:

• porządkowanie komunikacji,
• zadawanie niewygodnych pytań,
• weryfikowanie założeń, które na początku projektu były traktowane jak pewniki.

W tym przypadku już na etapie analizy i koordynacji prac zaczęło się klarować, że standardowe funkcjonalności systemu nie odpowiadają realnym potrzebom operacyjnym klienta. Nie w sensie „braku kilku raportów”, ale w kluczowych procesach biznesowych.

I to jest moment, który w projektach IT bywa przełomowy.

„AS IS teraz, dopasowanie później” — klasyczny dylemat

Po stronie dostawcy pojawiła się propozycja dobrze znana wszystkim, którzy pracowali przy wdrożeniach:

„Wdróżmy system AS IS, a brakujące elementy dopracujemy w kolejnych etapach rozwojowych.”

Z perspektywy dostawcy — logiczne. Z perspektywy klienta — ryzykowne.

Dla klienta oznaczało to bowiem:

• konieczność zmiany kluczowych procesów operacyjnych „pod system”,
• brak gwarancji, że przyszłe customizacje faktycznie powstaną,
• ryzyko, że etap „rozwojowy” nigdy nie dostanie odpowiedniego priorytetu.

W efekcie klient nie był gotowy zaakceptować takiego scenariusza. I nie była to decyzja emocjonalna — raczej świadomy sygnał ostrzegawczy.

Projekt nie został zatrzymany — zmienił się jego układ sił

Warto to jasno podkreślić: projekt nie upadł. Zamiast tego nastąpiła istotna zmiana organizacyjna.

Po stronie dostawcy pojawił się nowy Project Manager — bardzo doświadczony, mocny zawodnik, który potrafi trzymać projekt twardą ręką i porządkować chaos.

Po stronie klienta… nadal brakuje osoby o porównywalnym poziomie decyzyjności i doświadczenia projektowego.

A to prowadzi do jednej z najczęściej pomijanych prawd o projektach IT:

nierównowaga kompetencji projektowych między stronami zawsze wpływa na kierunek projektu.

Nie od razu. Nie spektakularnie. Ale systematycznie.

Kilka lekcji, które warto zapamiętać

Z perspektywy konsultanta ten projekt zostawił kilka bardzo uniwersalnych wniosków:

1. Technologia nie rozwiązuje problemów organizacyjnych

Jeśli procesy są niejasne, odpowiedzialności rozmyte, a decyzje odkładane — żaden system informatyczny tego nie naprawi.

2. „Wdrożymy teraz, poprawimy później” to strategia wysokiego ryzyka

Czasem konieczna, ale zawsze wymagająca silnego zarządzania i jasnych zobowiązań po obu stronach.

3. Brak silnego Project Managera po stronie klienta to realne zagrożenie

Nawet najlepszy dostawca i najlepszy PM po jego stronie nie zastąpią właściciela biznesowego projektu.

4. Sukcesem konsultacji nie zawsze jest wdrożenie

Czasem największą wartością jest moment zatrzymania się i powiedzenia: „to nie jest jeszcze ten etap”.

Co dalej?

Nasza rola w tym projekcie dobiegła końca. Projekt idzie dalej — w zmienionej konfiguracji i z nową dynamiką. Trzymamy kciuki, by finalnie dostarczył realną wartość biznesową, a nie tylko „działający system”.

Dla nas to kolejne potwierdzenie, że dojrzałość projektowa to nie brak problemów, ale umiejętność ich nazywania w odpowiednim momencie.

Jeśli pracujesz przy wdrożeniach WMS, ERP, PIM lub innych systemów core’owych — być może część tych obserwacji brzmi znajomo.

I to właśnie dlatego warto o nich mówić głośno.