W świecie zarządzania projektami sukces coraz częściej nie oznacza realizacji celu „na czas i w budżecie”, ale poczucie, że… było warto. O tym, jak odróżniać błędy od porażek, wyciągać mądre wnioski i nie tracić zaufania zespołu – opowiada doświadczona kierowniczka projektów, Jolanta Kuruc, Senior Project Manager w Kyndryl, prowadząca kursu Project Management w Labie.
Błędy są nieuniknione, ale nie muszą prowadzić do porażki. Kluczowe jest to, jak je traktujemy: czy jako pretekst do szukania winnych, czy jako okazję do uczenia się. W tej rozmowie usłyszysz o tym, czym jest „fail fast”, dlaczego warto robić retrospektywy błędów bez strachu, jak kierownik projektu może odzyskać sterowność w sytuacji kryzysowej – i jak nie dopuścić, by zespół utkwił w mentalnym półfinale.
Czy po nieudanym projekcie powinniśmy wszystko wyrzucić do kosza i zaczynać od zera? Czy porażka to znak, że czas na radykalne zmiany?
Zanim odpowiem, proponuję najpierw rozróżnić, czym właściwie jest porażka, a czym błąd – bo to wcale nie jest to samo. W zarządzaniu projektami błędy są czymś naturalnym. To środowisko, w którym eksperymentujemy, testujemy różne podejścia. Dlatego tak ważne jest, aby nie stygmatyzować błędów, tylko tworzyć przestrzeń, w której można je popełniać bezpiecznie.
Jest takie powiedzenie: fail fast & cheap – czyli popełniaj błędy szybko i tanio. To esencja podejścia projektowego. Aby coś zadziałało bezbłędnie, trzeba to wcześniej przetestować, przećwiczyć – a to przecież kosztuje. W wielu przypadkach musimy więc założyć, że błędy będą, bo są wpisane w proces. Ważne, byśmy potrafili je kontrolować i nie dopuścić do takich, które są zbyt kosztowne – kiedy dowiadujemy się o czymś za późno, działamy reaktywnie, ryzyko rośnie i przekracza to, co jesteśmy w stanie zaakceptować. Pamiętajmy jednak, że błędu nie utożsamiamy z porażką.
Czym w takim razie jest nieudany projekt?
Dawniej sukces projektu oceniano przez pryzmat tzw. potrójnego ograniczenia: zakres, czas i budżet. Jeśli wszystko się zgadzało – projekt uznawano za sukces. Dziś ta definicja już nie wystarcza.
Zgodnie z aktualnym podejściem, np. według Project Management Institute (PMI), o sukcesie decydują dwa kluczowe elementy:
- Czy było warto? Czyli tzw. value for money. Bez względu na to, co wydarzyło się w trakcie realizacji, klient ma poczucie, że efekt końcowy był wart inwestycji.
- Subiektywna ocena klienta. to naprawdę klienta – nie sponsora, nie kierownika projektu, nie zespołu. Dzisiaj więc projekt może być opóźniony albo przekroczyć budżet, ale jeśli klient czuje, że było warto – to nadal jest sukces.
W tym podejściu kluczowe jest rozumienie kontekstu biznesowego. Bez tego działamy na oślep. Organizacje mają mechanizmy nadzoru nad celami krytycznymi – nie pozwolą, by przestały być realizowane. Sama przejmowałam projekty w krytycznym momencie, żeby je uratować. To często oznacza przebudowanie całego podejścia, ale z zachowaniem ciągłości operacyjnej i osiągnięciem kluczowych celów. Dopiero później przychodzi czas na refleksję: czy było warto? I nie zawsze można odpowiedzialnie powiedzieć, że ktoś coś zaniedbał – nie wszystko da się przewidzieć. Czasem projekt z założenia był ambitny i ryzykowny. A mimo trudności – osiągnięcie celu końcowego daje poczucie sensu. To nie jest czarno-białe. Są też sytuacje, w których sponsor sam zgłasza potrzebę zakończenia prac – choć projekt jest dochodowy, to nie ma aż tak wysokiego priorytetu dla organizacji. I to też bywa mądra decyzja.
Jak odróżnić błąd, z którego warto się uczyć, od zwykłego przypadku albo czynnika zewnętrznego?
Niezależnie od tego, czy mamy do czynienia z błędem, przypadkiem czy czynnikiem zewnętrznym – zawsze warto potraktować to jako sygnał do przemyślenia procesu, a nie do szukania winnych. Naturalnym założeniem w pracy z ludźmi powinno być to, że błędy się zdarzają. I dlatego projektowo zarządzamy ryzykiem – mamy systemy nadzorcze, mechanizmy zabezpieczające, rozwiązania redukujące skutki potencjalnych pomyłek. Najważniejsze jest jednak to, że z każdego zdarzenia – niezależnie od jego przyczyny – możemy się czegoś nauczyć.

Inny przykład: klient przez pomyłkę usunął całą bazę danych, co uniemożliwiło planowaną migrację. Replikacja zajęła 24 godziny. Problem był poważny, ale wnioski również były oczywiste: błąd systemowy po stronie producenta aplikacji – użytkownik nie powinien mieć takich uprawnień.
Czasem przyczyną są błędy ludzkie – wynikające z przeciążenia czy zmęczenia. Wtedy to też jest informacja zwrotna: może potrzebujemy kogoś dodatkowego w projekcie, a może powinniśmy inaczej zaplanować czas. Bo ostatecznie nie chodzi o to, kto zawinił – tylko co możemy zrobić, żeby w przyszłości uniknąć podobnej sytuacji.
Jak przeprowadzić retrospektywę, która nie zamieni się w szukanie winnych?
W organizacjach, które są skoncentrowane na ludziach, retrospektywa to nie moment rozliczeń – tylko okazja do wspólnego uczenia się. Zamiast pytać: „Kto zawinił?”, ja proponuję zadać pytanie: „Jak często naprawdę zdarza się, że ktoś przychodzi do pracy z intencją, by coś popsuć?” Z mojego doświadczenia – niemal nigdy. Pracowałam z ludźmi, którzy naprawdę dawali z siebie wszystko. I nawet jeśli ktoś „nie dowoził”, to najczęściej nie była to kwestia złej woli – tylko systemu, przeciążenia, nieadekwatnych narzędzi, braku dopasowania do zadania albo stylu zarządzania.
Jeśli chcemy, żeby ludzie byli maksymalnie produktywni, musimy im dać odpowiednie warunki:
- poczucie sprawczości,
- przestrzeń na wybór,
- czas,
- sens zadania,
- możliwość kreatywności.
Bo to właśnie sprawczość jest naszym naturalnym stanem. Gdy ją mamy – pojawia się radość, zaangażowanie, motywacja. Dlatego retrospektywa powinna być przede wszystkim rozmową o relacjach, dynamice, systemie – a nie o winie. To także kwestia zaufania. A zaufanie nie pojawia się samo – buduje się je z obu stron.
Jak zarządzać przejętym zespołem w sytuacji kryzysu projektowego?
Z perspektywy kierownika projektu pierwszym krokiem powinna być inwentaryzacja, czyli rzetelna ocena stanu, w jakim przejmujemy projekt. Niezależnie od tego, czy mamy kontakt z poprzednim kierownikiem projektu, czy też nie, musimy dokładnie sprawdzić i udokumentować, gdzie jesteśmy i z jakiego punktu startujemy.
Drugim kluczowym elementem jest określenie świadomych, dobrze przemyślanych celów w czasie – tak, aby zarząd i kluczowi interesariusze mieli pełną jasność co do bieżącej sytuacji. W przypadku zagrożenia realizacji celów biznesowych często podejmowane są kompromisy, na przykład w obszarze kosztów, aby doprowadzić projekt do końca. Inne aspekty schodzą wówczas na dalszy plan. Jednak po wyjściu z kryzysu wcześniejsze ustalenia bywają pomijane i pojawiają się oczekiwania nieuwzględniające wcześniejszych czynników sytuacyjnych.
Właśnie dlatego w projektach kryzysowych należy ze szczególną starannością dbać o formalności: dokumentować decyzje, uzasadniać odstępstwa od pierwotnych założeń i rejestrować zmiany. Paradoksalnie, to właśnie w sytuacjach dużego napięcia i konieczności szybkiego działania wzrasta potrzeba zachowania wysokiego poziomu dyscypliny projektowej. Jest to niezbędne nie tylko do odzyskania kontroli nad projektem, lecz także po to, by móc rzetelnie rozliczyć się z działań, gdy projekt wróci na właściwe tory.
Co dzieje się z zespołem po porażce projektu? Jakie emocje są wtedy najtrudniejsze – i jak nie przenieść ich na kolejne projekty?
Zespół funkcjonuje zupełnie inaczej, gdy projekt idzie ku sukcesowi. Widzimy wtedy postęp, mamy poczucie sprawczości, robimy coś trudnego, ale osiągalnego. To działa niezwykle motywująco – zarówno na zespół, jak i na interesariuszy. Już samo raportowanie – pokazywanie, ile zostało zrobione, że projekt jest stabilny, że da się przewidzieć tempo – daje dużą satysfakcję. To momenty, w których mamy naturalny zastrzyk dopaminy i całą gamę pozytywnych wzmocnień.
Jednak kiedy wiemy, że projekt zmierza ku porażce, a mimo to trzeba jeszcze domknąć pewne rzeczy, uratować minimum, zabezpieczyć organizację – wchodzimy w zupełnie inną dynamikę. Wtedy naprawdę trudno utrzymać motywację, zaangażowanie ludzi i koncentrację zasobów.
Jeśli ktoś w zespole ma za sobą wiele doświadczeń z projektami, które się nie udały, to często – zupełnie nieświadomie – zaczyna wprowadzać reakcje obronne: zamiast szukać rozwiązań, przygotowuje się mentalnie na tłumaczenie się z porażki. Jeżeli ktoś ma częste doświadczenia z takich projektów, to pojawia się sytuacja, znana np. ze świata sportu, że sportowcy, którzy kilka razy pod rząd odpadali z półfinałów, nie są w stanie przełamać tego mentalnego sufitu. W projektach działa ten sam mechanizm: wyuczona bezradność.
To pojęcie opisane przez Martina Seligmana – kiedy po wielu doświadczeniach braku wpływu i kontroli, nawet w sytuacjach, gdy realnie możemy coś zmienić, nie podejmujemy już działania. Zadaniem kierownika projektu jest to rozpoznać i tym zarządzać. I to bardzo indywidualnie — bo każdy człowiek ma inne doświadczenia i inne rzeczy go motywują.

Co może zrobić Project Manager przed kolejnym projektem, aby uniknąć tych samych błędów?
Przede wszystkim – uczyć się na wszystkim. Zarówno na sukcesach, jak i potknięciach. Nie tylko na własnych doświadczeniach, ale też na analizie cudzych projektów. Kluczowy jest moment – trzeba wyczuć, kiedy powinniśmy zadziałać. Dlatego retrospektywy nie powinny być czymś, co robimy tylko „na koniec”. Najlepiej, gdy stają się częścią codziennego rytmu – prowadzone na bieżąco, wtedy, gdy coś się wydarza.
Oczywiście, w strukturze procesu zawsze znajdzie się przestrzeń na podsumowanie: adresujemy kluczowe punkty projektu, wyciągamy wnioski. Ale równie dużo możemy wynieść z dzielenia się case’ami – na przykład w trakcie wewnętrznych szkoleń, w których analizujemy projekty z różnych perspektyw. To cenna nauka – nawet jeśli nie bazuje na własnych błędach.

Jakie sygnały ostrzegawcze powinny zapalić czerwoną lampkę przy kolejnym projekcie?
Czasem pojawia się dużo obaw, dużo niepotrzebnego stresu, ale trzeba mieć na uwadze, że kiedy działamy w większych systemach, w większej skali, to przychodzą nam z pomocą standardy i metodyki pracy nad projektami. W moim ostatnim programie pracowało ponad 100 osób – wielu z nich nigdy nie spotkałam osobiście. Program był złożony i trudny technicznie, a harmonogram bardzo napięty. Właśnie w takich warunkach dobre praktyki i uporządkowane podejście stają się kluczowe.
Budujemy wtedy system zarządzania projektem, który pozwala nam na to, że kiedy dojdziemy do rozdroża, możemy podjąć właściwą decyzję – w którą stronę dalej iść. W każdej sytuacji mamy pewną praktykę, zasadę, która pokazuje nam wartość działań, dzięki czemu możemy działać kreatywnie i bezpiecznie. Mamy metodyki, które pozwalają działać systematycznie i powtarzalnie, nawet gdy pojawiają się nowe, nieprzewidziane problemy.
System zarządzania projektem to jednocześnie system wczesnego ostrzegania. Wchodząc w którykolwiek obszar, mamy konkretne narzędzia, techniki analityczne i systemy monitorowania. To wszystko razem pozwala nam badać „zdrowie projektu”.
Trzeba pamiętać, że projekt z założenia jest tymczasowy. Więc jeśli w jego trakcie pojawia się problem, na przykład w zespole, to ja zadaję sobie pytanie: czy jesteśmy w stanie dokończyć ten projekt w takim składzie i w takim stanie, czy jednak trzeba coś przesunąć, zmienić, wzmocnić?
I właśnie przez cały czas trwania projektu staram się budować tzw. odporność – na przykład na wypadek, gdyby zabrakło któregoś członka zespołu, żeby prace nie zostały zatrzymane. Mamy różne opcje działania w różnych sytuacjach. Chodzi więc o to, żeby zbudować taki system, który pozwoli nam na bieżąco obserwować różne obszary projektu i zauważać, które z nich wymagają większej uwagi i działania.
Czy z perspektywy czasu, patrząc na swoje doświadczenie, uważasz, że niektóre porażki były potrzebne?
Nie zdarzyło mi się, żeby projekt się nie udał. Kluczowe jest jednak zrozumienie, że rola kierownika projektu to także analiza układu zespołu – i świadoma decyzja, czy w danym składzie jesteśmy w stanie zrealizować cel. Jeśli widzę, że nie mam odpowiednich zasobów, żeby poprowadzić projekt, to bardzo szybko to komunikuję. System pozwala mi to wychwycić na wczesnym etapie. Dla mnie najważniejszy zawsze jest cel biznesowy. Nie kieruję się ambicją, żeby „za wszelką cenę coś dokończyć” – to nie ten sposób myślenia. Czasami zapada decyzja, by projekt wstrzymać – i to też jest w porządku.

Porażką byłoby dla mnie co innego – na przykład brak zrozumienia kontekstu biznesowego, albo niedostateczna komunikacja na różnych poziomach. Albo sytuacja, w której zamykamy oczy i patrzymy tylko na metryki. Najważniejsze jest, by dostarczać wartość klientowi, rozumieć otoczenie projektu i elastycznie dostosowywać system, który nas wspiera – ale nie może stać się sztywną instrukcją. On służy do utrzymania kontroli, ale nie powinien definiować sukcesu. Trzeba też unikać izolacji – zadbać o bezpośrednie, sprawne kanały komunikacji, angażować właściwe osoby we właściwym czasie. A jeśli dochodzi do zmiany ról w projekcie – to nie jest porażka. To naturalny proces.
Jeden z moich mentorów powiedział mi kiedyś coś, co do dziś mam w pamięci: „Jeśli nie wiesz, co robić – skup się na celu biznesowym. Jeśli robisz to, co naprawdę ważne dla biznesu, nic złego się nie wydarzy.”
Chcesz być na bieżąco?