10 zasad dowożenia projektów nierealnych

Zrobiliśmy nasz pierwszy kurs online! Zapraszamy do kursu: Wykres Gantta w Excelu - https://www.subscribepage.io/gantwexcelu

Proste zasady nie zawsze są proste w przestrzeganiu. Potrzeba wytrwałości i dyscypliny. Niektóre z zasad przedstawionych w tej książce są oczywiste i trywialne, inne już nie. Ile razy, będąc kierownikiem projektu, negocjowałeś jego warunki z klientem? W ilu przypadkach dostałeś już wynegocjowany projekt, który masz już tylko dowieźć?

Chcesz lepiej realizować projekty?

Chcesz dowozić projekty na czas i w budżecie? Chcesz czerpać radość z bycia kierownikiem projektu?

Chcesz coraz lepiej zarządzać?

Przeczytaj tę książkę!

Fragment książki – 10 zasad dowożenia projektów nierealnych

Zrobiliśmy nasz pierwszy kurs online! Zapraszamy do kursu: Wykres Gantta w Excelu - https://www.subscribepage.io/gantwexcelu

TYPOWE PROBLEMY PROJEKTÓW NIEREALNYCH

Lista problemów, z którymi najprawdopodobniej się zderzymy, prowadząc projekt nierealny, jest długa. Czego zatem możemy się spodziewać? Poniżej przedstawione są najbardziej charakterystyczne, najczęściej spotykane i najbardziej brzemienne w skutkach problemy:

powtarzające się chronicznie opóźnienia,
puchnący, „wybuchający” zakres prac,
straty finansowe na projekcie,
brak zasobów, brak zespołu,
brak kompetencji dziedzinowych w firmie nieokreślony i ciągle zmieniający się cel projektu,
nieprzychylne lub nawet wrogie nastawienie klienta,
ciągła presja klienta na „więcej i lepiej” (niezależnie od zakresu projektu),
unikanie podejmowania decyzji po stronie klienta,
zaskakujące, destrukcyjne i nieprzewidywalne decyzje oraz zachowania po stronie klienta,
naliczanie kar, groźba zatrzymania projektu czy nawet zerwania kontraktu przez klienta.

Realizując projekt nierealny, musimy zwykle pracować na bazie harmonogramu, którego obiektywnie nie można dotrzymać. Nie da się nadrobić straconego czasu. Każdy członek zespołu projektowego zdaje sobie sprawę, że nie ma fizycznej możliwości, aby w jakikolwiek sposób dowieźć projekt na czas w odniesieniu do terminów kontraktowych. Bardzo często mierzymy się z problemem „wybuchającego” zakresu. Krok po kroku rozpakowujemy kolejne funkcjonalności systemu i za każdym razem okazuje się, że nasze rozumienie zakresu było zbyt uproszczone, że dostarczyć trzeba o wiele więcej, że prace będą kosztować znacznie więcej, a nikt tego nie przewidział. Dzień po dniu ponosimy straty finansowe. Kierownictwo firmy jest poirytowane, redukuje nam zespół i ogranicza środki finansowe. To z kolei prowadzi do sprzężenia zwrotnego, jeszcze większych opóźnień, eskalacji klienta i w konsekwencji dalszego pogorszenia warunków pracy zespołu. Jakby tego było mało, cel takiego projektu często fluktuuje, klient zmienia priorytety, praca jest nieefektywna. Do tego wszystkiego mamy klienta, który pomimo złej sytuacji projektowej jeszcze naciska, aby dostarczać więcej za mniej, dodawać nowe funkcjonalności, których naszym zdaniem nie było w umowie. Kiedy chcemy dyskutować i rozwiązywać problemy, okazuje się, że po drugiej stronie nie ma partnera, a ludzie unikają odpowiedzialności. W takim projekcie bardzo często sytuacja eskaluje do takiego stopnia, że klient posuwa się do gróźb naliczania kar, czasem nawet je aplikuje, a nawet taki projekt zatrzymuje i ostatecznie zrywa kontrakt.

Spotkałem się z komentarzem, że „nie wszystkie projekty takie są”. Tak, oczywiście. Powyższy przypadek wydawać się może przejaskrawiony, przesadnie pesymistyczny. Z drugiej strony liczba projektów o powyższej charakterystyce jest jednak znacząca. Smutne jest to, że mało kto o tym pisze. W tej książce nie będziemy się zajmować projektami prostymi czy też prowadzonymi w środowisku gwarantującym sukces. Tutaj skoncentrujemy się na projektach trudnych — takich, w których szeroko znana teoria zarządzania projektami nie pomaga.

CECHY PROJEKTU NIEREALNEGO

Jakie zatem cechy projektu nierealnego powodują powstawanie wcześniej wspomnianych problemów? Poniższa lista przedstawia najważniejsze z nich.

Nierealny, niemożliwy do dotrzymania harmonogram. Mówimy tutaj o harmonogramie, którego realizacja jest obiektywnie nierealna, niezależnie od tego, jaką metodę zarządczą wybierzemy oraz jak nieograniczonymi zasobami będziemy dysponować. Taki harmonogram nie jest skutkiem błędów zespołu projektowego czy też obiektywnych problemów, jakie mogły się pojawić w projekcie w trakcie prac. Taki harmonogram jest niejako „dziedziczony” z umową. Mówiąc wprost i ogólnie rzecz ujmując — ktoś w firmie zdecydował, że zgadza się na takie, a nie inne warunki komercyjne, a następnie podpisał kontrakt na owych warunkach. To zaś w konsekwencji nie pozwala na realizację projektu na czas.

Zbyt ogólnie, niepoprawnie lub w ogóle niezdefiniowany zakres projektu. W praktyce klient wymaga tyle, na ile pozwalają mu zapisy umowy. Dlatego też, jeśli zakres projektu opisany jest słabo lub zbyt ogólnie, to kończy się to zwykle koniecznością wykonania większej pracy, niż początkowo planowaliśmy. Skala tego zjawiska zależna jest od wielu czynników, między innymi od nastawienia klienta oraz tego, jak bardzo w danym momencie rezultaty projektu odbiegają od jego oczekiwań. Z drugiej strony dostawcy również czynią pewne założenia co do zakresu i kosztu prac. Bardzo często okazuje się, że ich wyceny nie są trafione. Powody tego są również różnorakie, na przykład braki funkcjonalne produktu, który sprzedają (jeśli w ogóle istnieje), brak wystarczającej wiedzy dziedzinowej, źle przeprowadzona analiza przedsprzedażowa itd.

Zbyt niskie przychody, źle finansowo sprzedany projekt, zbyt niskie przychody w stosunku do nakładu prac. Projekt dobrze sprzedany ma szansę zakończyć się powodzeniem. Projekt źle sprzedany na pewno zakończy się stratami finansowymi (choć oczywiście z punktu widzenia klienta może się udać). Jedną z najczęstszych cech projektów nierealnych jest właśnie bardzo zła sytuacja finansowa projektu. W żadnym wypadku nie ma ona związku z „rozrzutnością” kierownika projektu czy firmy. Mówimy o sytuacji, w której projekt kosztuje dużo więcej, niż się spodziewaliśmy; więcej, niż obiektywnie powinien kosztować dobrze zwymiarowany projekt tej klasy. Skutki tego są zwykle opłakane. Brak zasobów, kompetencji, niski priorytet w organizacji, zabieranie ludzi do innych projektów, opóźnienia, eskalacje klienta i wiele innych.

Mgliście, ogólnie, źle lub w ogóle niesprecyzowany cel biznesowy projektu. Często się nam wydaje, że zdefiniowany w umowie zakres projektu wystarczająco określa, co powinno być jego rezultatem. Niestety zdarzają się takie sytuacje, kiedy klient, pomimo podpisanej umowy, nie do końca dobrze przemyślał sobie tzw. business case i to, co właściwie chce osiągnąć. Konsekwencje tego bywają tragiczne. Nawet poprawnie realizowany projekt, w którym dostarczane są oczekiwane rezultaty, może być kompletnie przeorganizowany czy wręcz zatrzymany. Przychodzi dzień, kiedy klient nas informuje, że priorytety się zmieniają, zakres podobnie, o harmonogramie nie wspomniawszy. Co więcej, takie sytuacje mogą powtarzać się w ramach jednego projektu. Przypomina mi się taki, w którym klient z dnia na dzień wpadł na pomysł, aby front-end systemu zrealizować jednak za pomocą innego produktu pudełkowego, a w projekcie skupić się „tylko na back-endzie”. Oczywiście łatwo można sobie wyobrazić, jak takie decyzje wpływają na poszczególnych ludzi, zespół, projekt i naszą firmę.

Nierealne założenia po stronie dostawcy. Wszelkiego rodzaju założenia, które od początku były nieprzemyślane, nietrafione lub zostały poczynione wbrew opinii specjalistów dziedzinowych w naszej firmie, a niemające odzwierciedlenia w rzeczywistości. Ktoś założył, że nasz produkt jest gotowy w pięćdziesięciu procentach, a faktycznie w ogóle nie istnieje. Ktoś rzekomo uzgodnił z klientem pewne uproszczenia w zakresie czy to funkcjonalności, czy migracji, czy integracji, ale okazuje się, że w kontrakcie nie ma po tych ustaleniach śladu.

Brak dobrej czy nawet poprawnej relacji biznesowej z klientem, projekt sprzedany wbrew woli części interesariuszy po stronie klienta. Mało kto o tym wspomina, ale zdarzają się projekty sprzedane wbrew pewnym ważnym osobom lub grupom osób po stronie klienta. To jedna z najgorszych sytuacji, w której może się znaleźć zespół i kierownik projektu. Skutkuje to niejako „wrogimi” działaniami czy nawet swego rodzaju strajkiem włoskim po stronie klienta. Rozbijanie dyskusji, podważanie ustaleń, przekładanie spotkań, ciągła krytyka, wyszukiwanie problemów. Bardzo często takie projekty kończą się niestety fiaskiem niezależnie od wybranej metodyki zarządczej.

Źle skonstruowana umowa, brak mechanizmów zabezpieczających przed wszelkiego rodzaju wymuszeniami ze strony klienta, a także przed naliczaniem kar. Prowadzenie projektu w oparciu o źle przygotowany kontrakt jest bardzo trudne — zwłaszcza kiedy zaniedbane zostały zapisy dotyczące kontroli zakresu, a także procedur postępowania w przypadku opóźnień oraz naliczania kar. W zależności od nastawienia, uczciwości (lub jej braku) po stronie klienta w sytuacjach wątpliwych, kiedy moglibyśmy „powalczyć o swoje”, okazuje się, że mamy związane ręce i musimy się podporządkować woli klienta, nawet jeśli czujemy, że racja leży po naszej stronie. Możemy się znaleźć w sytuacji, kiedy to klient opóźnia prace w projekcie, ale umowa została tak napisana, że to dostawcę można karać finansowo. Może być tak, że dostarczyliśmy do odbioru etap projektu, natomiast klient na bieżąco dodaje sobie nowe wymagania oraz zmienia kryteria odbioru, a my nie możemy w żaden sposób zareagować. Klienci potrafią nawet uzależniać odbiór poprawnie dostarczonego systemu od tego, czy dostawca zgodzi się na realizację dodatkowych wymagań, czy nawet wstrzymywać płatności za poprawnie wystawione faktury do momentu otrzymania „wymuszonych” dodatków. Źle skonstruowana umowa od początku ustawia dostawcę oraz kierownika projektu w defensywie. W skrajnych przypadkach dostawcy są zmuszani do realizacji nierentownych projektów, których nie są w stanie formalnie wypowiedzieć.

Niedopasowanie dostawcy i klienta — inna mentalność oraz kultura pracy. Różnice w organizacji pracy, mentalności, procesach zarządczych, sposobie podejmowania decyzji, podejściu do rozwiązywania problemów — wszystko to prowadzi do napięć, eskalacji, opóźnień w realizacji prac. Jeśli nasza firma wszystkie swoje projekty realizuje w metodykach zwinnych, to trudno nam będzie współpracować z klientem, który ma bardzo formalne podejście do podejmowania decyzji oraz przeprowadzania jakichkolwiek zmian, który wszystko musi planować z wyprzedzeniem, a znaczące decyzje procesuje hierarchicznie miesiącami. Podobnie, jeśli prowadzimy projekt w kraju o znacząco odmiennej kulturze narodowej, to stracimy zwykle miesiące, zanim zrozumiemy specyfikę pracy naszego klienta. Co więcej, możemy nawet kategorycznie nie zgadzać się z pewnymi praktykami, takimi jak: konieczność targowania się o płatności za poprawnie wystawione faktury, wstrzymywanie akceptacji dokumentów analitycznych do czasu odbioru działającego systemu itp.

Nieprzygotowanie klienta do realizacji projektu. Często to klient nie jest gotowy do prowadzenia projektu. Brakuje mu specjalistów dziedzinowych, liderów czy osób odpowiedzialnych za poszczególne obszary, więc nie ma wystarczającej wiedzy. Nie jest w stanie dostarczyć artefaktów, których wymaga dostawca. Nie ma wystarczającej wiedzy na temat swoich własnych systemów wewnętrznych, które trzeba zastąpić lub z którymi trzeba się integrować. Nie przewidział, jak jego struktura organizacyjna wpłynie na możliwość podejmowania koniecznych decyzji. Bardzo trudno prowadzić projekt w takim środowisku pracy.

Niestabilne środowisko biznesowe. Ryzykowny układ biznesowy — w który weszliśmy, podpisując umowę — a więc między innymi zbliżające się po stronie klienta procesy M&A (mergers and acquisitions, czyli zakupu innych graczy, konsolidacji czy sprzedaży części lub całej jego firmy), zmiany w zarządzie i kluczowym kierownictwie, nachodzące decyzje strategicznie w zakresie wyboru kluczowych dostawców. Prowadzenie projektu w takiej konstelacji ma zwykle niedeterministyczny przebieg, w dużej mierze niezależny od tego, czy realizujemy go poprawnie i wywiązujemy się dokładnie z zapisów umowy. Jeśli przykładowo klient dokona przejęcia firmy, która już posiada nowoczesny system informatyczny pokrywający się funkcjonalnie z wdrażanym przez nas produktem, to z dużym prawdopodobieństwem skutkiem będzie zatrzymanie naszego projektu. Jeśli natomiast klient będzie się przygotowywał do sprzedaży firmy, to może zatrzymać wszystkie inwestycje (w tym nasz projekt), jeśli uzna, że krótkoterminowo nie przyczyniają się one do wzrostu wyceny spółki.

Projekt nierealny może charakteryzować się jedynie podzbiorem wyżej wymienionych cech. Bardzo często już tylko jedna czy dwie wystarczają, aby skomplikować sytuację na tyle, że jego realizacja wydaje się niemożliwa. Weźmy dla przykładu najbardziej typowy wzorzec projektu nierealnego, a więc kontraktu na dostawę produktu, który w dużej części lub w ogóle nie istnieje. Brzmi znajomo? Mamy zatem dostarczyć system, którego nie posiadamy. Co więcej, musimy zakończyć prace na konkretny termin. Trudność zaś polega na tym, że nie mamy jeszcze doświadczenia dziedzinowego. Kiedy zaś dostawca nie rozumie dobrze dziedziny problemu i oczekiwań klienta, to przekłada się na źle lub bardzo ogólnie spisany zakres. Wtedy naturalną konsekwencją jest zbyt optymistyczne podejście do wyceny i oferowania cen, które w żadnym wypadku nie wystarczą na pokrycie prac. To wreszcie powoduje brak pieniędzy na finansowanie prac zespołu, opóźnienia, konflikty z klientem, eskalacje, naliczanie kar itd.

PODSUMOWANIE

Można podać wiele przykładów projektów, które znakomicie wpasowują się w ten wzorzec. Wymiana systemów IT klienta, kiedy opóźnienie sięgało 3 lat, a koszt projektu był kilka razy wyższy. Migracja do nowej platformy IT, gdy klient otrzymał jedynie jedną trzecią zakresu projektu przy opóźnieniu sięgającym 2–3 lat i następnie zatrzymał projekt. Budowa nowej platformy IT, kiedy również projekt był opóźniony o kilka lat, jego koszt zaś znacząco wyższy niż zakładano.

Praca przy projekcie nierealnym jest bardzo wymagająca, a często toksyczna dla obu stron — i klienta, i dostawcy. To ekstremalnie trudny układ, który generuje problemy nietrywialne, na które nie ma prostych odpowiedzi. Co więcej, klasyka teorii zarządzania projektami nie będzie tutaj również zbyt pomocna. Zaskakujące może być to, że w takich projektach kierownik często książkowo wypełnia wszystkie zalecenia wybranej metodyki zarządczej. Można by powiedzieć, że wzorowo realizuje prace, a pomimo tego projekt nadal pozostaje nierealny!

Skoro zatem projekty nierealne nie przynoszą korzyści nikomu, to warto zadać pytania: dlaczego one w ogóle powstają?; skąd siębiorą?; oraz czy takie projekty da się skutecznie realizować? Więcej o tym dowiemy się w następnych rozdziałach.

O Autorze – 10 zasad dowożenia projektów nierealnych

Marcin Dąbrowski ― prowadził i nadzorował duże projekty dla największych na świecie grup telekomunikacyjnych i banków w różnych częściach świata; pracował z klientami reprezentującymi skrajne kultury narodowe i organizacyjne. Współwłaściciel i CEO People More PSA. Wcześniej pełnił między innymi funkcję wiceprezesa zarządu Comarch SA, a także COO i wiceprezesa zarządu Ailleron SA. Autor książek Wieczne opóźnienie (Onepress), Managing IT Projects (Apress/Springer), wielu międzynarodowych publikacji naukowych (między innymi dla ACM CCS DIM 2008, IEEE ICCS 2008) i kontrybucji do ITU-T. Jest absolwentem AGH, ukończył studia na kierunkach elektronika i telekomunikacja oraz informatyka. Studiował w Stanford Graduate School of Business i IESE Business School.

Czytelniku, zapisz się na nasz Newsletter! ZAPISUJE SIĘ! Jeśli jesteś zainteresowany naszymi treściami, koniecznie się zapisz. Co miesiąc wysyłamy skrót wszystkich postów wraz z praktycznymi radami, których nigdzie indziej nie publikujemy! Nie możesz tego przegapić 😉