Jak uniknąć porażki projektu w 3 krokach + 4 studia przypadków
Istnieje wiele powodów, dla których projekty kończą się niepowodzeniem, ale w zasadzie wszystkie sprowadzają się do jednej z dwóch rzeczy (czasami do obu):
- Istniało ryzyko, którego nikt nie rozpoznał, i/lub
- Nie zareagowaliśmy właściwie, gdy pojawił się problem
W tym artykule chcę skupić się na szerszej perspektywie, aby pomóc wyeliminować główną przyczynę niepowodzeń projektów — a często także niepowodzeń zarządzania projektami.
Oto jak uniknąć niepowodzenia projektu oraz co zrobić, jeśli dojdzie do tej katastrofalnej sytuacji, której nie przewidziałeś (nadal możesz wyjść z tego obronną ręką, jeśli zareagujesz szybko i rozsądnie!).
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Czym jest niepowodzenie projektu?
Dokładnie tym, na co wskazuje nazwa — sytuacją, w której projekt nie realizuje celów ustalonych przez zespół na początku, nie spełnia oczekiwań klienta lub kluczowych interesariuszy albo nie jest realizowany zgodnie z harmonogramem, budżetem lub zakresem.
Dlaczego projekty kończą się niepowodzeniem?
Jak wspomniałem we wstępie, istnieje wiele częstych powodów, dla których projekty mogą zakończyć się niepowodzeniem. Zwykle jest to spowodowane ryzykiem, które nie zostało odpowiednio ocenione, i/lub tym, że zespół (w tym kierownik projektu) nie zareagował na nie właściwie.
Inne częste przyczyny niepowodzeń projektów to między innymi niewłaściwa komunikacja dotycząca statusu, problemów lub ryzyka; nieprzestrzeganie przez członków zespołu zakresu projektu (lub jego niewłaściwe rozumienie), produktów projektu (np. niekontrolowanego rozszerzania zakresu) lub ram czasowych; brak zasobów albo nieprzestrzeganie wyznaczonych procesów lub metodyk.
Jak uniknąć niepowodzenia projektu: 3 kroki
Zarządzanie ryzykiem jest kluczowym działaniem w zarządzaniu projektem. Jest tak ważne, że brak zarządzania ryzykiem często oznacza niepowodzenie w zarządzaniu projektem. Zarządzanie ryzykiem składa się z trzech istotnych elementów:
- Zidentyfikuj ryzyka.
- Oceń to, co zidentyfikowałeś: Jak prawdopodobne jest wystąpienie danego zdarzenia i jak poważne będą jego konsekwencje? Jakie jest prawdopodobieństwo i wpływ?
- Przygotuj plany ograniczania ryzyka i plany awaryjne dla tych zagrożeń, które mogłyby przekreślić powodzenie projektu. Rejestry ryzyka pomagają śledzić wykonane działania.
1. Zidentyfikuj ryzyka
Najpierw zidentyfikuj ryzyka. Dobre wykonanie tego zadania znacznie zwiększy szanse na powodzenie projektu. Choć trudno wychwycić je wszystkie, systematyczna analiza projektu zazwyczaj pozwala określić największe ryzyka. Jest to zwykle część procesu tworzenia planu projektu.
Moje doświadczenie obejmuje tworzenie oprogramowania — zarówno produktów, jak i rozwiązań informatycznych — oraz związane z tym procesy. Projekty programistyczne są złożone i podatne na problemy, a poza kilkoma rzadkimi przypadkami nie mają wbudowanych takich mechanizmów zabezpieczających i kontroli, jakie stosuje się na przykład w budownictwie lub przy produkcji urządzeń medycznych.
Powinieneś określić cele projektu dla każdego z czterech parametrów:
- Harmonogram
- Zakres
- Koszt
- Jakość
Jeśli nie wiesz, jakie one są, od tego powinieneś zacząć. Zwykle dwa z tych czterech parametrów nieco się zmieniają, ale im lepiej rozumiesz, dokąd zmierzasz, tym łatwiej będzie zidentyfikować przeszkody.
Zrozumienie, który z tych czterech parametrów ma najwyższy priorytet, pomoże ograniczyć ryzyko poprzez dokonywanie odpowiednich kompromisów na małą skalę.
Łatwo skupić się na parametrze związanym z harmonogramem projektu i przeoczyć ryzyka, które mogą wpłynąć na pozostałe parametry, ale wszystkie są ze sobą powiązane i wszystkie należy zidentyfikować.
Osiągnięcie celów harmonogramu za pomocą produktu pełnego błędów zwykle nie jest dobrym rozwiązaniem — nawet jeśli go wydasz, ostatecznie będziesz musiał przygotować wydania naprawcze, które opóźnią dostarczenie odpowiedniego produktu bardziej, niż miałoby to miejsce w przypadku rozwiązania problemu od razu.
Poza 4 parametrami
Oprócz czterech parametrów musisz równoważyć trzy aspekty projektu:
- Produkt, który zwykle obejmują parametry
- Proces
- Ludzie
Ryzyka procesowe występują w dwóch postaciach: istniejący, niewystarczający proces, który nie zaspokaja potrzeb projektu, oraz brak procesu dla czegoś kluczowego dla działań zespołu. Ryzyka procesowe można dość łatwo ograniczyć, tworząc proces lub naprawiając go.
Aspekt związany z ludźmi jest często ignorowany, ale to Twój zespół oraz zespoły, z którymi współpracuje, zdecydują o powodzeniu lub porażce projektu. Trudni lub niezainteresowani interesariusze projektu utrudnią uzyskanie tego, czego potrzebujesz, aby posunąć projekt naprzód.
Przepracowani, zestresowani lub niezadowoleni członkowie zespołu nie wykonają pracy. Niektóre potencjalne problemy dotyczące ludzi można wskazać publicznie, inne być może zechcesz omówić prywatnie, ale nie popełniaj błędu polegającego na ich ignorowaniu.
2. Oceń zidentyfikowane ryzyka
Po zidentyfikowaniu ryzyk określ, jak prawdopodobne jest ich wystąpienie. Zwykle używam wartości procentowej — 100% oznacza, że mam pewność, iż dane ryzyko wystąpi. Ważne jest również określenie, jak poważne będą konsekwencje, jeśli ryzyko rzeczywiście się pojawi. Najłatwiej zrobić to, kategoryzując ryzyka jako wysokie, średnie lub niskie.
Po przeprowadzeniu tej analizy nadszedł czas, aby zaangażować zespół. Zapytaj każdego członka zespołu projektowego lub współpracownika, czym się martwi, dodaj te kwestie do listy ryzyk i przedstaw ją do omówienia:
- Czy zespół potrafi wskazać inne ryzyka, których nie uwzględniliście?
- Co zespół sądzi o analizie prawdopodobieństwa i wpływu?
Na podstawie tego spotkania możesz wprowadzić zmiany w planie zarządzania ryzykiem. Części pierwsza i druga są na razie zakończone. Musisz co najmniej raz w tygodniu przeglądać ryzyka, aby sprawdzić, czy pojawiły się nowe, czy niektóre z nich nie są już aktualne oraz czy zmieniło się ich prawdopodobieństwo lub wpływ.
3. Przygotuj plany ograniczania ryzyka i awaryjne
Na koniec, jeśli połączenie prawdopodobieństwa i wpływu któregokolwiek z ryzyk może doprowadzić do wykolejenia projektu, wspólnie z zespołem opracuj udokumentowane plany ograniczania ryzyka i plany awaryjne.
Ograniczanie ryzyka polega na zmniejszeniu prawdopodobieństwa jego wystąpienia lub ograniczeniu jego wpływu, jeśli już do niego dojdzie. Plan awaryjny koncentruje się na działaniach, które podejmiesz, jeśli ryzyka nie da się uniknąć i rzeczywiście wystąpi.
Upewnij się, że plany są udokumentowane i że wszyscy o nich wiedzą. Dobrym pomysłem jest również zaplanowanie działań na wypadek potencjalnych problemów dotyczących ludzi, oprócz 4 obszarów i procesu, ale analizę prawdopodobnie będziesz chciał przeprowadzić samodzielnie i zachować ją w poufności.
Jak przetrwać niepowodzenie projektu
Drugim powodem niepowodzeń w zarządzaniu projektami jest niewłaściwa reakcja na wystąpienie ryzyka projektowego — przewidzianego lub nie. To przede wszystkim zależy od ciebie jako kierownika projektu. Zanim wykonasz którykolwiek z poniższych kroków, zacznij od tych 2 wskazówek:
- Nie panikuj. Pamiętaj, żeby oddychać.
- Nie szukaj winnych i nie pozwól, aby ktokolwiek inny zaczął obwiniać innych.
1. Odwołaj się do planu awaryjnego
Jeśli masz przygotowany plan awaryjny, natychmiast zwołaj spotkanie albo przynajmniej wyślij wiadomość e-mail uruchamiającą ten plan. Przypomnij wszystkim, na czym polega plan, oraz powiedz, kiedy i jak należy przekazywać informacje o stanie realizacji.
Jeśli pominiesz ten krok lub go opóźnisz, okaże się, że osoby chętne do pomocy zaczęły działać w panice; w takiej sytuacji tracisz kontrolę nad tym, co zostało zrobione, a problem często się pogłębia.
Jeśli nie masz planu awaryjnego, natychmiast zbierz wszystkich na spotkaniu i wydaj ścisłe polecenie, aby do jego zakończenia NIE ROBILI NICZEGO INNEGO.
W przeciwnym razie wszyscy będą próbowali pomóc i nie będziesz wiedzieć, co zostało zrobione. Podczas spotkania jasno przedstaw problem — zawsze zdumiewa, jak wiele różnych wyobrażeń na temat problemu mogą mieć ludzie.
Przeprowadź wspólną analizę przyczyn źródłowych, aby dotrzeć do sedna problemu i opracować plan naprawczy — kto, co i jak ma zrobić. Podczas analizy przyczyn źródłowych musisz zrozumieć, kto i co zrobił przed wystąpieniem problemu, ale utrzymuj dyskusję na tym poziomie.
Innymi słowy, trzymajcie się wyłącznie faktów. Nie przypisuj winy, ponieważ wzajemne oskarżenia odwracają uwagę od problemu. Jeśli zespół nie jest w stanie znaleźć rozwiązania, masz kilka możliwości.
Po pierwsze, możesz zaangażować osobę, która zna ogólną tematykę, ale nie pracuje przy tym konkretnym projekcie — na przykład jeśli problem wydaje się dotyczyć bazy danych, poproś o pomoc administratora baz danych, który obecnie nie pracuje przy projekcie, aby uzyskać inną perspektywę.
Inną techniką jest zaangażowanie osoby, która nie ma żadnej praktycznej wiedzy o projekcie. Czasami konieczność dokładnego wyjaśnienia każdego kroku ujawnia błędne założenia lub coś, co wcześniej było pomijane.
2. Rozwiąż problem
Zdobądź poparcie wszystkich dla ustalonego sposobu działania i przydziel zadania. Poproś członków zespołu o przekazywanie ci informacji o postępach i powiedz, jak często mają przesyłać raporty — co godzinę, po zakończeniu zadania, pod koniec dnia lub w innym rytmie odpowiednim do sytuacji.
Raportowanie może wydawać się oczywiste dla ciebie, ale nie dla wszystkich. Regularne aktualizacje pomogą zespołowi zachować właściwy kierunek. Regularnie przekazuj całemu zespołowi zbiorcze informacje o postępach.
Członkowie zespołu, którzy nie mają w danym momencie żadnych zadań, zaczną się niecierpliwić i w końcu spróbują się zaangażować oraz pomóc, chyba że będziesz przekazywać im informacje o stanie prac i inne informacje.
Równie ważne jest informowanie kierownictwa. Kierując się własną oceną, ustal, kto i na jakim etapie potrzebuje aktualizacji, ale regularnie przekazuj całemu zespołowi zbiorcze informacje o postępach.
3. Ogłoś zakończenie
Oczywiście dopiero wtedy, gdy projekt rzeczywiście zostanie ukończony. Przygotuj raport końcowy i przejdź do następnego kroku. Daj zespołowi trochę czasu na odzyskanie sił.
4. Przeprowadź analizę po projekcie lub retrospektywę
Ważne jest przeprowadzenie oceny projektu, aby zebrać wnioski. Oto jak to uporządkować:
- Przedstaw problem, aby wszyscy mieli takie samo zrozumienie sytuacji
- Zacznij od tego, co poszło dobrze. Nawet w najtrudniejszej sytuacji coś musiało się udać. Nadaje to spotkaniu zupełnie inny ton.
- Porozmawiaj o tym, co wymaga poprawy. Jeśli jest na to czas, przeprowadź burzę mózgów nad sposobami wprowadzenia usprawnień; w przeciwnym razie przydziel zadania, wyznacz terminy i wróć do nich w tych terminach.
Jeśli rzeczywiście była to czyjaś wina, porozmawiaj z tą osobą — prywatnie. Jeśli zrobisz to publicznie, cały zespół zacznie się zastanawiać, kto następny zostanie publicznie zawstydzony.
Jeśli całkowicie pominiesz ten etap, Twój zespół poczuje, że komuś coś uszło na sucho, a problem nie został rozwiązany. Trzymaj się faktów i wróć do wszelkich zmian w osobistych procesach, które ktoś powinien wprowadzić. Chodzi tu o odpowiedzialność i doskonalenie, a nie o znalezienie kogoś, kogo można obwinić.
3 przykłady rzeczywistych niepowodzeń projektów
Nie uniknąłem niepowodzeń projektów IT, choć na szczęście — ale z trudem — udało się je naprawić.
Oto kilka moich własnych nieudanych projektów IT i projektów programistycznych, a także przykład słynnego nieudanego projektu.
Te przykłady niepowodzeń projektów i analizy przypadków nieudanych projektów powinny również dać Ci konkretny obraz sposobów, w jakie projekty mogą zakończyć się niepowodzeniem, oraz tego, jak można sobie z tym poradzić.
1. System księgowy
Na początku swojej kariery pracowałem w firmie IBM. Moją pierwszą prawdziwą pracą było przejęcie dość małego systemu, który zasilał korporacyjne systemy księgowe. Ktoś w IBM napisał go w mało znanym języku programowania o nazwie RPG, na niewielkim systemie.
Nie tylko zarządzałem projektem — zarządzałem całym systemem (choć był administrator), w tym zbieraniem wymagań projektowych, rozwiązywaniem problemów i programowaniem.
Pewnego pięknego dnia wprowadziłem nowy program, uruchomiłem go i znalazłem błąd. Poprawiłem go i ponownie uruchomiłem program. Następnego ranka zadzwonili do mnie pracownicy działu księgowości, informując, że pojawiły się podwójne wpisy (w świecie księgowości to bardzo zła wiadomość).
Po pierwsze, nikt nie sprawdził mojej pracy. Po drugie, nie zaangażowałem osób odpowiedzialnych za systemy zależne, aby sprawdziły wpisy przed ich przekazaniem dalej. Po trzecie, nie poświęciłem czasu na przeanalizowanie niektórych starych programów, które nadal działały i tworzyły podwójne wpisy. Nie istniał też żaden proces poza tym, co wymyślałem na bieżąco.
A potem przyszła moja reakcja — panika. O rany, ledwo skończyłem studia, a już niszczę system księgowy IBM. Nie poinformowałem właściwych osób — administrator nie wiedział, co się dzieje — i nieświadomie wygenerował kolejny zestaw wpisów. Ostatecznie pracowałem przez 48 godzin bez przerwy, aby dotrzeć do głównej przyczyny problemu, naprawić ją oraz napisać i uruchomić programy korygujące błędy księgowe.
I wyciągnąłem z tego lekcję — przyglądaj się uważnie, zlecaj przeglądy, zastanawiaj się, co może pójść nie tak, i zatrzymaj się oraz pomyśl, zanim rzucisz się do naprawiania problemów (we wszystkim tym może pomóc oprogramowanie do zarządzania projektami księgowymi). A teraz wyobraź sobie, że zarządzałem dziesięcioosobowym zespołem i każdy próbował naprawić problem w ten sam sposób. Bez wyłączenia systemów księgowych IBM i dokładnego zbadania sprawy naprawdę nie dałoby się tego uratować.
2. Nowy produkt wewnętrzny
Jako konsultant prowadziłem nowy, duży projekt, w którym wiele osób miało wpływ na wymagania, powodując niekończące się zmiany priorytetów funkcjonalnych. Korzystaliśmy z zwinnego procesu zarządzania projektem, którego ta firma wcześniej nie stosowała. Dział QA bardzo dobrze radził sobie z testowaniem, ale nie rozumiał jeszcze sposobu myślenia użytkowników końcowych ani ich przepływu pracy.
Wiedziałem o tym wszystkim i od czasu do czasu o tym mówiłem, ale nie miałem rejestru ryzyka, oceny wpływu i prawdopodobieństwa, planu awaryjnego ani planów ograniczania ryzyka. Nie byłem też głównym źródłem informacji dla sponsorki projektu, choć od czasu do czasu się z nią spotykałem.
Dodaliśmy jeden sprint. Potem kolejny. Następnie, gdy stało się jasne, że nie jesteśmy jeszcze w miejscu, w którym moglibyśmy przeprowadzić testy beta, dodaliśmy trzeci sprint.
Ponieważ to nie ja przekazywałem informacje sponsorowi projektu, nie miałem pojęcia, że nie wiedziała o tym wszystkim. Osoba odpowiedzialna popełniła poważny błąd, nie informując sponsorki i licząc na to, że uda nam się zrealizować plan.
Żeby jednak zachować sprawiedliwość, choć mówiłem o ryzyku, nie przekazałem mu konkretnego zestawu zagrożeń, które mógłby przedstawić, aby przygotować sponsorkę na możliwość opóźnienia harmonogramu.
W środku tego wszystkiego spotkałem się ze sponsorką i mimochodem wspomniałem o tym, że dodamy ostatni sprint. Przerwała mi. Nic o nim nie wiedziała i nie była zadowolona.
Jak się okazało, bardziej zdenerwowała ją niespodzianka niż opóźnienie harmonogramu. Pojawiły się publiczne konsekwencje, a ostatecznie osoba odpowiedzialna za projekt przeniosła się do innej części firmy, ponieważ zaufanie zostało utracone.
Po raz kolejny wyciągnąłem ważne wnioski z porażki. Sama świadomość ryzyka nie wystarczy — trzeba je zebrać, ocenić, przygotować plany ograniczania ryzyka i awaryjne, a następnie upublicznić je i stale mieć je na uwadze.
Nigdy nie byłem zwolennikiem ukrywania ryzyka i problemów, ale znaczenie przejrzystości projektu stało się wtedy całkowicie oczywiste.
3. Pamiętasz OS2?
Nie? Nikt nie pamięta. To jeden z wielu nieudanych projektów związanych z tworzeniem systemów. Pracowałem w IBM, gdy pojawił się oryginalny OS2 — konkurent systemu Windows. Nie wypróbowałem nawet tej pierwszej wersji, ponieważ w IBM wszyscy wiedzieliśmy, że była pełna błędów. Reszta świata szybko przekonała się, że miała zbyt wiele awarii, aby warto było się nią zajmować.
Liczba błędów była tak duża, że zespół projektowy nie mógł uważać produktu za w pełni dopracowany, ale z jakiegoś powodu nie dokonał właściwego wyboru i nie wstrzymał wydania. Nieuwzględnienie czynnika ludzkiego — zarówno członków zespołu, jak i klientów — szybko zniweczy nawet piękny plan.
W przypadku oprogramowania istnieje wiele alternatyw dla takiej sytuacji — można przeprowadzić ograniczone wydanie dla osób, które będą tolerować błędy w zamian za dostęp do nowego, najnowocześniejszego oprogramowania, publicznie poinformować, że czekasz, aby niezawodność spełniała twoje wysokie standardy, i tak dalej.
Byłem wtedy jeszcze na tyle początkujący w swojej karierze, że mogłem wyciągnąć cenne wnioski z faktu, iż produkt, który uwielbiałem, znalazł się w ślepym zaułku już przy drugim wydaniu.
Jasno określaj swoje priorytety — istnieje kilka przypadków, w których wydanie produktu w określonym terminie jest ważniejsze niż jego jakość, ale nie ma ich wiele.
Korzystaj ze swoich 4 pokręteł, przyznawaj się do błędów i pokazuj wprowadzane poprawki, aby ludzie mieli pewność, że rozumiesz problem i nie popełnisz tego samego błędu po raz drugi.
Uwzględniaj czynnik ludzki — jest on równie istotny jak technologia. Od tamtej pory stosowałem te wnioski w projektach związanych z oprogramowaniem i IT, a okazały się bezcenne.
Najważniejszy wniosek
Ogólnie pamiętaj, że choć ostatecznie to ty ponosisz odpowiedzialność, nie musisz wykonywać całej pracy. W rzeczywistości zdecydowanie nie powinieneś próbować robić wszystkiego samodzielnie. Możesz skorzystać z szerokiego zakresu doświadczeń i wiedzy swojego zespołu. Jesteś liderem, ale nie musisz stanowić całego zespołu.
Oprogramowanie do zarządzania projektami i inne narzędzia do zarządzania projektami mogą pomóc ci śledzić ryzyko, kamienie milowe, alokację zasobów i inne kluczowe wskaźniki pokazujące, czy zmierzasz w stronę pomyślnej realizacji projektu.
