Najpierw jest niewinnie: tydzień obsuwy, potem dwa. „To normalne w IT” – słyszysz. Są statusy, spotkania, tablice i raporty. Zespół wygląda na zajęty. Tylko że efekt biznesowy… nie przychodzi.
I wtedy pojawia się odruch, żeby „przycisnąć”: dołożyć ludzi, dosypać budżetu, dorzucić funkcje „bo klient czeka”. Problem w tym, że to często działa jak dolewanie paliwa do źle ustawionego silnika – przez chwilę jest głośniej, ale wcale nie szybciej.
Jeśli chcesz odzyskać kontrolę, zacznij od prostszego kroku: zamiast leczyć objawy, znajdź przyczynę. W zarządzaniu mówi się na to RCA (analiza przyczyn źródłowych), ale po ludzku chodzi o pytanie: co konkretnie blokuje dowożenie i dlaczego to się powtarza?
Skąd wiesz, że projekt naprawdę utknął?
Projekt jest „trudny”, gdy wymaga czasu, ale postęp jest widoczny. Projekt jest „utknięty”, gdy koszty rosną, a Ty wciąż nie masz czego pokazać klientom ani użytkownikom.
Zwróć uwagę na te sygnały:
- Terminy się przesuwają, ale nikt nie umie jasno powiedzieć: „co dowieziemy w nowym terminie?”
- Od tygodni słyszysz „jesteśmy na 80%” – zawsze na 80%.
- Lista zadań rośnie, a liczba domkniętych tematów nie rośnie razem z nią.
- Jest dużo spotkań i „gaszenia pożarów”, a mało decyzji.
Jeśli widzisz 2–3 punkty naraz, przestaje to być „urok IT”. To znak, że projekt wymaga diagnozy.
Dlaczego dokładanie ludzi i presji zwykle pogarsza sytuację?
Bo gdy projekt jest w chaosie, dokładanie zasobów rzadko go porządkuje. Zwykle robi odwrotnie:
- więcej osób = więcej ustaleń, przekazywania informacji i ryzyka nieporozumień,
- większa presja = więcej skrótów i więcej poprawek,
- więcej „pilnych tematów” = mniej kończonych rzeczy.
Efekt bywa brutalny: firma płaci więcej, a projekt nadal stoi. Dlatego zanim dołożysz budżet, sprawdź, czy nie finansujesz problemu, który ma inne źródło.
RCA w wersji dla przedsiębiorcy: jak to zrobić bez wielkiego audytu?
Nie potrzebujesz rewolucji ani „metodyk”. Wystarczy, że zamiast rozmawiać ogólnie („komunikacja kuleje”, „dostawca słaby”), weźmiesz jeden konkretny przypadek, który wszyscy pamiętają.
Przykłady:
- „Od miesiąca nie możemy domknąć płatności / faktur / logowania.”
„Wdrożenie z piątku się posypało.” - „Trzy tygodnie pracujemy, a nic nie trafia do klientów.”
I zrób trzy kroki.
1) Nazwij problem jednym zdaniem (bez emocji)
Nie „jest dramat”, tylko np.:
„Przez 6 tygodni nic nie weszło do użycia, mimo że zespół pracuje.”
2) Zbierz kilka faktów, które każdy zrozumie
Wystarczą odpowiedzi na pytania:
- kiedy ostatnio coś realnie trafiło do użytkowników/klientów,
- co było największą przeszkodą,
- ile razy wracaliście do poprawek,
- na co najczęściej „czekacie” (dane, decyzję, partnera, akceptację).
To często w 15 minut pokazuje, czy problem jest w decyzjach, zakresie, jakości czy zależnościach.
3) Zapytaj „dlaczego?” kilka razy – aż dojdziesz do źródła
Przykład:
- Dlaczego nie dowieźliśmy? → bo temat wrócił do poprawek.
- Dlaczego wrócił? → bo „gotowe” znaczyło co innego dla zespołu i dla biznesu.
- Dlaczego znaczyło co innego? → bo nie było jasnych kryteriów odbioru.
- Dlaczego nie było? → bo priorytetem było „szybciej”, więc omijaliśmy ustalenia.
I nagle problem przestaje brzmieć „nie dowożą”, tylko: „płacimy za poprawki, bo nie mamy wspólnej definicji gotowości”.
Trzy najczęstsze powody, dla których projekty IT stają
1) Brak jasnej decyzji: co jest najważniejsze
Gdy każdy interesariusz ma „swoje must-have”, projekt zaczyna robić wszystko po trochu. A to kończy się tym, że nic nie jest domknięte.
Co pomaga: jedna osoba po stronie biznesu, która ustala priorytety i potrafi powiedzieć „nie teraz”.
2) Zakres rośnie, bo „to tylko drobiazg”
Najbardziej zabójcze są małe dokładki, które „przecież nie powinny potrwać długo”. Po kilku tygodniach masz projekt dwa razy większy – bez dwóch razy większego czasu i budżetu.
Co pomaga: prosta zasada wymiany: jeśli coś dochodzi, coś spada.
3) Projekt stoi, bo czeka na innych
„Czekamy na API”, „czekamy na dane”, „czekamy na akceptację”. Często projekt nie stoi przez samą realizację, tylko przez zależności od innych firm albo działów.
Co pomaga: szybkie sprawdzenie zależności na początku i jasna ścieżka eskalacji.
Ratować projekt czy ciąć straty? Krótki test
Ratowanie ma sens, jeśli:
- cel biznesowy nadal jest aktualny,
- da się przyciąć zakres do minimum, które daje wartość,
- można wrócić do regularnego dowożenia małych elementów,
- ktoś po stronie biznesu bierze odpowiedzialność za priorytety.
Kontrolowane cięcie strat bywa rozsądne, jeśli:
- nikt nie ma mandatu do decyzji i nie ma woli, by to zmienić,
- projekt nie potrafi niczego „dowieźć do użycia” i nie ma planu, jak to odwrócić,
- zależności zewnętrzne blokują wszystko miesiącami.
Plan na 14 dni: jak odzyskać kontrolę bez rewolucji
Dni 1–3: diagnoza
- wybierz 1–2 problemy i zrób szybkie RCA,
- zbierz fakty: co weszło do użycia, co wraca do poprawek, na co czekacie.
Dni 4–7: decyzje i cięcie zakresu
- jeden cel biznesowy na najbliższe tygodnie,
- obcięcie wszystkiego, co nie jest krytyczne,
- prosta definicja „gotowe”.
Dni 8–14: stabilizacja
- małe, regularne dostawy zamiast wielkiej „premiery”,
- usunięcie największych blokad,
- częsty feedback od biznesu/użytkownika.
Po dwóch tygodniach najważniejsze jest jedno: wraca przewidywalność. Nawet jeśli zakres jest mniejszy, firma znów wie, na czym stoi.
Podsumowanie
Jeśli projekt IT utknął, nie chodzi o to, żeby „pracować więcej”. Chodzi o to, żeby zrozumieć dlaczego utknął – i naprawić przyczynę, a nie objawy.
- Metodyczne dojście do „dlaczego” znajdziesz tu: analiza przyczyn źródłowych (RCA) – kompleksowy przewodnik.
- A jeśli sytuacja jest już kryzysowa: ratowanie projektów technologicznych.
- Więcej o nas jako partnerze produktowym: Pragmatic Coders.
