Dlaczego określenie stałego budżetu projektu jest tak trudne?

Aż 27% projektów IT ma przekroczony budżet. Część z projektów jest również opóźniona w czasie nawet o 70%! Postarajmy się zatem odpowiedzieć na to, co powoduje taki stan rzeczy i jak mu przeciwdziałać.

W roku 1979 opublikowana została praca Daniela Kahnemana i Amosa Tvesky’ego, w której pojawiło się pojęcie “planning fallacy” (,,złudzenie planowania”), które oznacza naszą wrodzoną nieumiejętność poprawnego oszacowania czasu, który jest potrzebny do zrealizowania przykładowego zadania.

Jeden z najsłynniejszych eksperymentów, który to potwierdza został przeprowadzony w 1994 roku. Roger Buehler przebadał swoich studentów i poprosił ich o oszacowanie, ile czasu zajmie im napisanie pracy magisterskiej. Średni czas został przez nich wyliczony na 33,9 dni. W badaniu sprawdzono również ile czasu zajmie to samo zadanie, jeżeli wszystko pójdzie bez problemów oraz ile zajmie w najgorszym przypadku. Okazało się, że prawidłowa wartość wynosiła 55,5 dnia, co stanowiło 62% więcej, niż pierwotnie zakładano. Było to także aż 14,2% więcej, niż studenci zakładali nawet w najgorszym przypadku. Tylko 30% z nich skończyło pracę w pierwotnie założonym terminie.

Dlaczego każdy z nas określa inaczej czas potrzebny na wykonanie tego samego zadania?

To proste. Z reguły opieramy się tylko na własnym doświadczeniu i nie bierzemy pod uwagę czynników zewnętrznych, które nie dotyczą zadania, ale które mogą na nie wpływać w wymierny sposób. Mamy także dużą tendencję do ignorowania ryzyk, ponieważ każde z nich ma niewielką szansę wystąpienia. W rzeczywistości jednak najczęściej jakieś pojawiają się w trakcie realizacji zadania.

W projektach IT sprawa jest równie skomplikowana, ponieważ mamy mnogość czynników i procesów, które mogą znacząco wpłynąć zarówno na budżet jak i termin realizacji projektu, między innymi:

• Problem z brakiem wystarczająco szczegółowych informacji na temat projektu – gdy Klient opisuje cele, funkcjonalności, czy zadania w sposób zbyt uproszczony, który na dalszym etapie może prowadzić do nieporozumień ze względu na brak szczegółowości założeń do której mogłyby odnieść się obie strony;
• Problem ze zmieniającym się zakresem zadań i celów do zrealizowania – często zmieniających się już w trakcie trwania projektu, gdy Klient nagle wymaga realizacji nowych celów, lub modyfikacji tych wyznaczonych wcześniej;
• Problem z połączeniem funkcjonowania różnych elementów systemu lub stron – w projektach IT zazwyczaj występuje połączenie kilku lub więcej różnych technologii przez co dodawanie kolejnych elementów i modułów wiąże się z powstaniem nowych problemów np. z integracją z istniejącymi już funkcjonalnościami
• Problemy z komunikacją i interpretacją – brak wypracowania szczegółowej dokumentacji projektowej często prowadzi do nieporozumień lub nawet konfliktów, ponieważ częstym przypadkiem jest postrzeganie przez ludzi tych samych rzeczy w zupełnie odmienny sposób i tak w przypadku projektów IT prostym przykładem byłoby np. zlecenie dodania baneru informacyjnego na stronę internetową Klienta, co możemy rozumieć po prostu przez jego wstawianie, ale Klient może myśleć również że baner ten będzie mógł sam w łatwy sposób edytować, co nie jest takie oczywiste i wymaga większego nakładu pracy programisty do wdrożenia takiej opcji w panelu zarządzania stroną, a zarazem wymaga większego nakładu budżetowego po stronie Klienta;
• Problem ze zbyt dużą liczbą osób decyzyjnych, mających wpływ na realizację projektu, a jednocześnie chcących nadać mu zupełnie odmienny od siebie kształt;
• Zmiany technologiczne – niejednokrotnie spotykaliśmy się z przypadkiem, gdzie już w trakcie realizacji projektu Klient chciałby zmienić wstępne założenia względem samej technologii w jakiej realizowany jest cały projekt.

Określenie budżetu projektowego

Bardzo często spotykamy się z sytuacją w której Klient nie chce udzielić nam informacji jakim budżetem dysponuje na realizację projektu, gdyż często boimy się po prostu zaufać danej firmie czy innym osobom grając niejako w otwarte karty i posługując się następującym tokiem myślowym “mam 50 tysięcy, ale lepiej napiszę, że nie wiem lub że mam 20, bo na 100% od razu wyślą mi ofertę na cały dostępny budżet, żeby tylko jak najwięcej zarobić”.

W ten sposób sami skazujemy się na możliwość powstania problemów przy realizacji projektu, a nawet redukujemy możliwości firmy, której projekt chcemy zlecić, ponieważ musi ona wtedy w ciemno przedstawić nam potencjalne warianty rozwiązań w różnych budżetach, zapewniających “lepszy” lub “gorszy” poziom realizacji, zależny od tego ile czasu pracy zespołu projektowego będzie potrzebne żeby wypracować finalny efekt.

Pytamy naszych Klientów o ich budżet na realizację projektu, aby jak najlepiej dopasować propozycje wariantów jego realizacji. Aby lepiej zobrazować dlaczego określenie budżetu jest tak ważne, posłużmy się przykładem z innej branży i zastanówmy się, czy kiedy idziemy do firmy deweloperskiej z założeniem wybudowania pięknej willi z ogrodem to z góry zakładamy ograniczenie się do np. 300 000 zł, nawet jeśli tak naprawdę nasz budżet wynosi 1 000 000 zł? Nie podając wykonawcy realnego budżetu sami zamykamy sobie różne możliwości realizacji projektu w formie w jakiej potrzebujemy.

Rdzeniem każdego projektu powinna być dokumentacja projektowa. Niestety jest kilka powodów, przez które najczęściej Klientom proces ten wydaje się zbędny i chcieliby pomijając go jak najszybciej rozpocząć prace nad realizacją projektu. Wielokrotnie obserwowaliśmy smutne konsekwencje takiego podejścia na bazie Klientów, którzy przeszli przez nieudany proces realizacji projektu z innym wykonawcą i chcieli zlecić nam jego finalizację lub wprowadzenie zmian/poprawek. Obie strony powinny mieć świadomość, że dokumentacja projektowa jest kluczowym stadium projektu. Jeśli przemyśleniu projektu i przygotowaniu dokumentacji poświęcimy odpowiednią ilość czasu, to możemy zredukować lub całkowicie wyeliminować późniejsze niepotrzebne koszty i czas realizacji, a co za tym idzie, zaoszczędzić sobie sporo nerwów. Dokumentacja projektowa powinna zawsze być punktem wyjściowym, a gdy jej brakuje najlepszym wyjściem dla obu stron jest praca nad projektem w oparciu o rozliczenie godzinowe.

Co składa się na budżet projektu?

Na budżet projektu mają wpływ czynniki takie jak:

• wybrana technologia – np. React, WordPress, Jamstack, Gatsby, NextJs
• poziom skomplikowania – prosta strona informacyjna vs portal z panelem klienta, systemem subskrypcyjnym, integracjami itp.
• termin realizacji – im krótszy czas na realizację tym wyższe stawki godzinowe
• koordynacja projektu – czynnik często pomijany, a przecież po stronie wykonawcy ktoś odpowiedzialny i doświadczony musi poświęcić czas na zrealizowanie projektu i utrzymanie go w ryzach
• RWD – optymalizacja projektu do wyświetlania na urządzeniach mobilnych, które stanowią już większość wytwarzanego ruchu w sieci
• poziom doświadczenia specjalistów – możemy oczywiście nasz projekt zlecić freelancerowi lub specjalistom na stanowisku juniora i może jeśli trafimy na wybitną osobę to wszystko fortunnie potoczy się dalej, ale w większości przypadków raczej na pewno każdy chciałby pracować z doświadczonymi specjalistami zarówno z zakresu UX/UI, designu, czy programowania, a wyższa jakość to zawsze wyższe stawki, które dyktuje w IT po prostu zapotrzebowanie rynkowe

Ryczałt czy rozliczenie godzinowe?

Głównymi modelami rozliczeniowymi projektów IT jest rozliczenie ryczałtowe (fixed price) oraz rozliczenie godzinowe (time & materials). Bez jasnego określenia wszystkich funkcjonalności, struktury, oraz logiki serwisu lub aplikacji jedynym rozsądnym wyjściem jest rozliczenie godzinowe. W innym przypadku najczęściej wykonawcy zamiast zrobić coś z należytą starannością koncentrują się zamiast tego na tym, aby jak najszybciej zrealizować projekt i nie zamknąć go ze stratą, tak aby wyjść na zero, a w gorszym przypadku nawet tylko po to, aby zredukować potencjalne straty.

Wiele razy przejmowaliśmy takie projekty po innych wykonawcach, gdzie współpraca Klienta i poprzedniego wykonawcy kończyła się konfliktem. Powodem takiego stanu rzeczy jest z reguły niedoszacowanie budżetów lub rozbieżna wizja tego co powstało jako końcowy rezultat prac, a co nie było spisane w formie zamkniętej dokumentacji projektowej do której mogłyby odnieść się obie strony. Bardzo często takie projekty mają dług technologiczny, który powoduje że praca nad nimi jest trudna i powoduje sporo dodatkowych kosztów, a w niektórych przypadkach tak naprawdę projekt wypadałoby napisać całkiem od nowa, zamiast go łatać tylko po to aby zaoszczędzić budżet (czasem bywa tak, że łatanie wychodzi drożej niż jego ponowna realizacja).To właśnie dlatego tak ważne jest aby już na samym początku stworzyć dokumentację projektową, która pozwoli na zamknięcie projektu w sztywnych ramach możliwych również do wyceny ryczałtowej do której ewentualnie dokładne będą prace godzinowe przy dalszej rozbudowie projektu już w trakcie jego realizacji, zależnie od potrzeb Klienta.

Jak zatem odpowiednio podejść do budżetu i wyceny projektu?

Najlepiej zacząć od wstępnego briefu z wykonawcą oraz przemyślenia i spisania oczekiwanego przez nas rezultatu. Następnie należy wspólnie szczegółowo omówić całość. Przy większych projektach warto rozważyć rozpoczęcie prac od warsztatów na których uda się wypracować wspólnie wszystkie ustalenia do stworzenia dokumentacji projektowej. Jest to szczególnie ważne, ponieważ najczęściej bywa tak, że Klient i Wykonawca zupełnie inaczej wyobrażają sobie rezultat podejmowanych działań co jest prostą drogą do konfliktu. Brak szczegółowej dokumentacji nie pozwala jednoznacznie określić czy założenia projektu zostały spełnione czy też nie.

Jeżeli chciałbyś omówić z nami potencjalną realizację projektu to serdecznie zapraszamy do wypełnienia briefu.