Jak realizować projekty, jakich błędów unikać?

Realizacja projektów to nieustająca walka z różnego typu problemami. Gdyby nie one zarządzanie projektami byłoby niezmiernie proste. Ale takie nie jest. Ilość nieprzewidzianych sytuacji, które mogą się wydarzyć w projekcie, jest nie do opisania. Tak samo jak ilość błędów, które można popełnić.

W trakcie projektu podejmowanych jest szereg decyzji. Ale dopiero z perspektywy czasu okazuje się, że nie każda z nich była prawidłowa. Niestety o tym dowiadujemy się z opóźnieniem – parudniowym, a czasem nawet paroletnim.

Błędy, które popełniane są w tracie realizacji projektów mają rozmaitą postać i konsekwencje. Niektóre z nich wpływają tylko na niepotrzebne zamieszanie i drobne opóźnienia. Inne z kolei są gwoździem do trumny całego projektu oraz zapalnikiem do bomby, która „wysadza” z firmy (delikatnie mówiąc) kierownika projektu. Zdarza się, że wraz z nim ten sam los wkrótce spotyka także dużą część zespołu projektowego. Ale tak już jest. Tam gdzie występuje ryzyko – tam też muszą być osoby, które będą ponosiły odpowiedzialność za nieprawidłowe decyzje.

Jak wiadomo jedną z lepszych metod kształcenia jest nauka na błędach. Uczyć można się na błędach własnych, które się potem pamięta na lata (z oczywistych powodów wszyscy woleliby tego uniknąć); a także tych cudzych. W tym drugim przypadku zdarza się, że słysząc historię pewnych decyzji, poczynań lub wydarzeń, jesteśmy przekonani, że nigdy w życiu byśmy nie zachowali się w taki sposób. Z perspektywy czasu, znając zakończenie, cudze postępowanie wydają się przecież takie łatwe do przewidzenia. Niestety bardzo łatwo jest oceniać innych, nieco trudniej jest podjąć trudną decyzję w okolicznościach niepełnych informacji i ograniczonego czasu.

W trakcie już kilkunastu lat pracy zawodowej brałem udział w kilkudziesięciu projektach. Nie wszystkie oczywiście zakończyły się sukcesem. Poniżej spisałem te błędy, które najczęściej się powtarzały w trakcie projektów lub też te, których zaistnienie, ma moim zdaniem największe znaczenie przy końcowej ocenie projektu. Z pewnością każdy mógłby dodać po parę dodatkowych punktów z własnego doświadczenia; lista interesujących „przypadków projektowych” mogłaby być naprawdę długa i pouczająca. Ale może zacznijmy od tych, które uznałem za najbardziej istotne.

Kluczowe błędy popełniane w zarządzaniu projektem

Błędnie dobrane rozwiązanie, które nie realizuje celu biznesowego.

Przedmiotem projektu stają się często pomysły, które nie do końca są rozwiązaniem na zadany problem biznesowy. Skracany jest etap definiowania projektu i analiz, a przez to do realizacji trafiają projekty, których zaletą jest tylko to, że spełniają jedno z następujących kryteriów:

• wiąże się nimi najmniejsze ryzyko,
• można je szybko rozpocząć bez większych przygotowań,
• są najtańsze (chyba to powinno być na pierwszym miejscu tej listy ;),
• zdobyły uznanie wśród „ważnych” osób.

W konsekwencji takie wyboru rozwiązania, dochodzi zazwyczaj do sytuacji, kiedy projekt jest kończony z sukcesem, a problem biznesowy pozostaje.

Nieprecyzyjnie wskazany cel i zakres projektu.

Ten błąd to bardzo częsta przypadłość wszelkich projektów związanych z wdrożeniem nowej aplikacji IT. W drodze usilnych działań sprzedażowych ze strony dostawców, dochodzi do tego, że zapada decyzja o zakupie i wdrożeniu oprogramowania bez dokładnego zastanowienia się, czemu ono ma dokładnie służyć oraz co ma być osiągnięte dzięki niemu.

Najczęstszym objawem takiego stanu rzeczy jest całkowity brak mierników, których zadaniem jest ocena projektu w momencie jego zakończenia. W konsekwencji celem wdrożenia aplikacji staje się … wdrożenie aplikacji, a nie przykładowo: przyspieszenie procesów, polepszenie obsługi klienta, itd. Często się zdarza, że sponsor lub kierownik projektu otrąbiają sukces w momencie uruchomienia produkcyjnego aplikacji. A jak każdy pragmatyk wie, z ocenami należy poczekać przynajmniej parę miesięcy, a do tego jeszcze należy je zestawić z wcześniejszymi założeniami i oczekiwaniami, aby mieć punkt odniesienia, a nie dopiero go tworzyć.

Częste modyfikowanie zakresu projekt w trakcie jego trwania.

Duża część projektów trwa rok lub dłużej. W tym czasie kilkukrotnie może zmienić się zarząd firmy, strategia, koniunktura na rynku, budżet. Kluczem do pomyślnego zakończenia projektów jest niejednokrotnie elastyczność i umiejętność dostosowywania się do pojawiających się zmian. Jednakże dużym błędem jest popadanie w skrajności. Tak samo jak nie można usztywniać ram w raz zdefiniowanym projekcie, tak samo nie wskazane jest żonglowanie wymaganiami i zakresem projektu.

Wszystko ma swoje granice. Większość szczegółowych analiz jest realizowanych na etapie definiowania projektu. Na podstawie tych danych podejmowania jest decyzja o opłacalności lub niezasadności startu projektu. Natomiast w trakcie jego trwania wszelkim zmianom w projekcie towarzyszą już zwykle tylko szybkie analizy robione ad-hoc, które są pochodną napiętych terminów i presji wywieranych z różnych stron. Po kilku takich zmianach zakresu, cały bazowy plan finansowy projektu wraz ze wszystkimi aktualizacjami można wyrzucić do kosza – całość uprzednio można umieścić w folderze o nazwie „abstrakcja – nie dotykać”.

Minimalizacja kosztów projektu.

Projekt to kombinacja trzech elementów: czasu, zakresu, kosztu. Oddziałując na jeden z tych elementów, automatycznie wpływamy na pozostałe. Przystępując do realizacji projektu powinien być już zdefiniowany: zakres prac, ich budżet oraz czas w jakim zostaną wykonane (harmonogram projektu). Z niewiadomych powodów jednak, niektóre osoby, w trakcie prac jako dodatkowy cel projektu dopisują sobie minimalizowanie jego kosztów. I aby temu sprostać wprowadzają m.in. nieustanne modyfikacje do założeń projektu.

Dobrze pamiętam jeden projekt, w którym kierownik projektu na cyklicznych spotkaniach projektowych ze sponsorem (prezesem), chwalił się z kolejnych pomysłów, dzięki którym zaoszczędzi się trochę grosza. Problem tkwił w tym, że proponowane rozwiązania wiązały się zwykle ze znaczącym opóźnieniem prac oraz tworzeniem kolejnych obejść. Zapomniano, że każdy dzień opóźnienia projektu to także koszt. A jeżeli nie ma presji, aby go zrealizować w terminie to powstaje pytanie, czy w ogóle jest sens go robić.

Ciągnięcie projektu na siłę do końca, zamiast wstrzymania prac

… szczególnie, w momencie, gdy okazuje się, że stracił on swoją rację bytu. Projekt to wielomiesięczna praca wielu ludzi. A ludzie, jak wiadomo angażują się zazwyczaj w to, co robią. Powoduje to, że w pewnych aspektach projektu na znaczeniu zyskują emocje, które odsuwają w bok chłodną i obiektywną kalkulację. Wraz z postępem prac w ramach zespołu projektowego samoczynnie rośnie przekonanie o korzyściach wynikających z projektu i pomijanie są przy tym wszelkie negatywne informacje, które napływają z rynku, a które definitywnie przekreślają szanse powodzenia danego przedsięwzięcia. Temat z obszaru psychologii społecznej – ale bardzo ciekawy i często obserwowany w praktyce.

Nierealne oczekiwania.

Kilkukrotnie spotkałem się z sytuacją, kiedy projekt przebiegł prawidłowo a problemy pojawiły się dopiero w momencie jego rozliczenia. Po paru miesiącach od zakończenia prac okazywało się, że wobec projektu zostały stworzone oderwane od rzeczywistości oczekiwania, które w żaden sposób nie mogły być zrealizowane. Wszelakie prognozy sprzedaży oraz parametry opłacalności, które były podstawą do podjęcia decyzji o rozpoczęciu prac, były tworzone bez większej refleksji lub wręcz tak dobierane, aby projekt zdobył tylko wszelkie niezbędne akceptacje. Kwestie ich rzetelności miały drugorzędne znaczenie.

Samospełniające się przepowiednie to niestety niezmiernie rzadkie przypadki. A w końcu każdy projekt przyjdzie kiedyś rozliczyć. Dlatego na etapie analiz przedprojektowych w ruch muszą iść odpowiednie metody prognozowania, a nie „sufit” (tj. alternatywne źródła danych niewiadomego pochodzenia).

Błędne analizy kosztów.

Podobnie jak można przestrzelić prognozy sprzedaży, tak samo można niedoszacować kosztów. W tym drugim przypadku różnica jest jednak taka, że wiedza o tym może się ujawnić już w trakcie trwania projektu i doprowadzić do jego: opóźnienia, wstrzymania, modyfikacji, zamknięcia. Błąd ten wynika zwykle z:

• minimalizowania pozycji kosztowych uwzględnianych w kosztorysie (np.: wszelkie drobniejsze wydatki finansowe wrzuca się w kategorię „pozostałe”, pomija się koszty pracowników odciągniętych od innych zadań, itd.),
• przyjmowania bardzo optymistycznych założeń, co do kształtowania się cen niektórych towarów lub usług,
• celowego pomniejszania kosztów (szczególnie wtedy, gdy trudno już podkręcać część przychodową), aby opłacalność projektu wydawała się bardziej atrakcyjna dla decydentów.

Zbyt duży zespół projektowy.

Czasami naprawdę trudno pojąć, dlaczego przy dość nieskomplikowanych projektach, podczas spotkań statusowych z kierownikiem projektu zasiada niemal cała firma. Niektórzy kierownicy projektu zapewne w obawie przed ryzykiem nieprecyzyjnego określenia interesariuszy zdecydowali się zaangażować w projekt wszystkich managerów z firmy, aby przypadkiem nikt nie poczuł się pominięty.

W końcu nie da się ukryć, że realizując projekt należy liczyć się z tym, że przypadkowo nadepnie się na czyjeś ego. W każdej większej organizacji są przecież osoby, które pod byle powodem są zainteresowane wstrzymaniem projektu. Ale z drugiej strony, wraz ze wzrostem zespołu projektowego maleje odpowiedzialność poszczególnych osób. Zatem albo się politykuje, albo się pracuje.

Nadmierne skomplikowanie wymagań.

Swego czasu brałem udział w projekcie, którego celem było zbudowanie od zera pewnej aplikacji. Miała ona za zadanie: gromadzić informacje na temat ofert, dokonywać różnych wyliczeń, które to z kolei miały określać opłacalność i być podstawą do definiowania strategii cenowej. Pech chciał, że kierownik tego projektu zapragnął, stworzyć aplikację, która będzie zawierała wszelkie możliwe stany i ewentualności. Pewnie chciał w ten sposób uniknąć w przyszłości zarzutu, że do tej aplikacji nie da się czegoś wprowadzić. Specyfikacja wymagań pod ten program miała chyba z kilkaset stron.

Oczywiście nie mogło się to dobrze skończyć. Proszę sobie wyobrazić tylko: formularze, które zawierały po kilkadziesiąt pól do każdorazowego wypełnienia; listy rozwijane liczące nawet po 50 i więcej pozycji do wyboru; opasłe instrukcje obsługi. Mówiąc krótko, zapomniano o tym, że z aplikacji mają korzystać ludzie, którzy niekoniecznie marzą o doktoryzowaniu się z obsługi oprogramowania. Jaka była przyszłość tej aplikacji łatwo się domyślić.

Stawianie na ludzi tylko z wewnątrz organizacji.

Wraz z rozpoczęciem analiz nad projektem, pojawia się często pytanie, jakimi zasobami będą te prace realizowane. Zaskakujące jest jednak to, że w wielu firmach na dzień dobry przyjmuje się, że prace mają być realizowane tylko przez obecnych pracowników. Zakłada się, że wszyscy mają wystarczające kompetencje, a nawet jeśli ich nie mają, to są na tyle wspaniali, że w trakcie szybkiego przeszkolenia je zdobędą. Co otrzymujemy w efekcie takiej decyzji? Listę negatywnych skutków obejmuje m.in.:

• zwiększenie kosztów realizacji projektu, w porównaniu z tymi, które by zostały poniesione, gdyby część zadań została powierzona firmie zewnętrznej;
• wydłużenie czasu prac – pracownikom wewnętrznym z różnych powodów nie zawsze zależy na szybkim zakończeniu projektu;
• ograniczona innowacyjność – osoby spoza firmy mają często świeższe spojrzenie wobec niektórych zagadnień, niż pracownicy, którzy od kilkunastu lat pracują w firmie.

Brak przypisanych odpowiedzialności.

Wielokrotnie spotkałem się z sytuacją, kiedy do projektu zostały dołączone osoby, które nie do końca były świadome swoich obowiązków oraz oczekiwań wobec nich postawionych. W pewnych firmach jest tak, że kiedy jest uruchamiany projekt to kierownik projektu kontaktuje się z szefem działu X, aby ten wyznaczył jakąś osobę Y do projektu. A ten ją „wyznacza” i … koniec – co dokładnie ma robić, kiedy będzie potrzebna, na ile czasu będzie wyciągnięta ze swoich rutynowych obowiązków, itd. – tego już nikt nie wie.

W rezultacie, gdy w ramach projektu przychodzi moment, że potrzebna jest pomoc wskazanej osoby Y, okazuje się, że ma ona 5 innych priorytetów i generalnie to sama nie wie, czy to ona ma się akurat tymi pracami projektowymi zajmować.

Krótkowzroczność zakresu projektu.

Zdarza się, że projekty realizowane są pod kątem konkretnych problemów i wymagań. Nikomu jednak przy tym nie przychodzi do głowy, aby na zaproponowane rozwiązanie spojrzeć z nieco innej perspektywy. I przykładowo postarać się przewidzieć przyszłe oczekiwania, które z dużym prawdopodobieństwem mogą się pojawić.

„Problemy będziemy rozwiązywać na bieżąco, w momencie kiedy będą się pojawiały” – takie nastawienie powoduje w krańcowych przypadkach, że przedmiot projektu okazuje się niemodyfikowalny pod kątem rozwoju. Oznacza to zwykle tylko to, że łatwiej jest zbudować coś zupełnie od początku niż modyfikować efekt poprzednich prac projektowych.

Kierownik projektu – wszystko wiedzący teoretyk.

Niestety tacy są… o dziwo uważani są nawet za dobrych PM-ów, do czasu oczywiście, aż nie zostanie im powierzony trudny projekt. Taki wyedukowany i wyposażony w niemal wszystkie możliwe certyfikaty z tematyki zarządzania projektami osobnik doskonale czuje się w:

• przesadnie dokładnym określaniu, jak mają przebiegać prace,
• organizowaniu kolejnych niepotrzebnych spotkań,
• szczegółowym analizowaniu wszelkich alternatywnych możliwości,
• narzucaniu, a potem kompletowaniu nadmiernej dokumentacji projektowej.

Ale niestety jest niezdolny do podejmowania decyzji. Wszystko co tylko może to odwleka i opóźnia. W tym czasie do granic wytrzymałości testuje cierpliwość pozostałych uczestników zespołu projektowego, a przy tym doskonali się w tworzeniu coraz to barwniejszych wytłumaczeń, dlaczego termin realizacji projektu po raz kolejny się przesuwa.

Nieodpowiednie szablony dokumentacji projektowej.

Wraz z rozwojem idei zarządzania projektami w firmie, której zwieńczeniem jest nieraz powołanie biura projektowego, objętości nabierają różnego rodzaje formularze, karty projektu, szablony dokumentów. W skrajnych przypadkach dochodzi do tego, że aby powołać projekt w firmie należy uzupełnić kilkadziesiąt stron dokumentów oraz przebrnąć przez kilkadziesiąt stron instrukcji mówiących o tym, co należy zrobić i jak poszczególne dokumenty wypełnić.

Gdy pojawia się jakiś nieszablonowy projekt, wtedy okazuje się, że większość wzorcowych dokumentów nie da się wypełnić, gdyż dotyczą zupełnie czego innego. Skutkiem takiej biurokracji jest także to, że wszelkiego rodzaju materiały projektowe wypełniane są skrótowo, wszędzie gdzie się da stosuje się zasadę kopiuj-wklej, wiele stron do wypełnianie pozostaje pustych, a przede wszystkim większość pracowników przestaje czytać te dokumenty.

Brak jasno sprecyzowanego deadline’u.

Zazwyczaj większość projektów ma wskazaną datę ukończenia prac. Problem pojawia się natomiast w momencie, gdy cały zespół projektowy od samego początku traktuję ją dosyć luźno i generalnie nie widzi żadnych negatywnych dla siebie konsekwencji w przypadku, gdyby została ona przesunięta. Po części jest to konsekwencją innego błędu – braku rozliczania projektów przez sponsora. Są firmy, w których się tylko projekty uruchamia i nie traci się czasu na tak zbędne rzeczy, jak analiza terminowości i wykonalności innych projektów.

Brak back-upu.

Nie ma ludzi niezastąpionych. I tak samo powinno być w każdym projekcie. Nie można dopuszczać do sytuacji, aby w momencie odejścia kierownika projektu lub kluczowej osoby z zespołu projektowego prace były wstrzymywane. A tak niestety się dzieje.

Dlaczego? Otóż projekty powierzane są osobom, które dość oszczędnie dzielą się informacjami. Realizowany projekt staje się czarną skrzynką – nie wiadomo do końca co się dzieje, jaki jest status, itd. Zdarza się także, że takie działania są celowe – opisywane zachowanie to przecież sposób na to, aby pokazać potem kto jest jedynym ojcem sukcesu, a także do tego, aby zmniejszyć zagrożenie zwolnienia.

Niepoprawna komunikacja w ramach zespołu projektowego.

Ostatni na liście, ale nie oznacza, że najmniej istotny – wręcz przeciwnie. Sytuacji, w których za opóźnienia projektu odpowiadała błędna komunikacja, świadkiem byłem wielokrotnie. W jednych przypadkach wynikało to z nieumiejętności wytłumaczenia innym przez kierownika  idei i celu projektu; w innych przypadkach powodem kłopotów były opóźnienia w przekazywaniu przez członków zespołu projektowego kluczowych informacji, które wpływają na terminowość i przebieg projektu (zwykle tych negatywnych).

Generalnie to zadaniem kierownika projektu jest poinformowanie wszystkich, na jakiej zasadzie będzie przebiegała komunikacja w projekcie oraz kiedy, jak i z kim należy się kontaktować. Rzecz niby oczywista, ale nie dla każdego.