Wady modelu Fixed Price. Dlaczego ten popularny sposób rozliczeń prowadzi do problemów?

Często rozmawiamy z klientami, którzy nie są zadowoleni ze swoich poprzednich wykonawców. Zawsze poświęcamy im sporo uwagi, bo zależy nam, aby jak najlepiej zrozumieć, gdzie tak naprawdę tkwił problem. Okazuje się, że najczęstszym czynnikiem decydującym o porażce projektu wcale nie są niskie kompetencje wykonawcy.

Popularny, ale czy uniwersalny?

Najpopularniejszym sposobem rozliczeń z firmami IT jest model Fixed Price.
Wykonawca tworzy listę funkcjonalności, przelicza to na czas pracy i z góry ustala odpowiednią kwotę za wykonanie całości. Z perspektywy klienta jest to bardzo wygodna metoda - jeszcze przed rozpoczęciem pracy zna dokładny koszt i termin wykonania. Projekt rozliczany w ten sposób ma łatwiejszą drogę do przejścia przez odpowiednie działy w firmie:

  • dział budżetowy zorganizuje wymaganą kwotę,
  • dział IT nie poniesie bezpośredniej odpowiedzialności za ewentualne problemy,
  • dział zakupów może łatwo porównać kilka ofert i obniżyć koszt,
  • dział prawny bez większych problemów zminimalizuje ryzyko, stosując kary umowne.

No dobrze - wydaje się, że zalety są mocne. Jednak czemu to właśnie model Fixed Price sprawia, iż wiele projektów kończy się fiaskiem?

Początkowo wszystko jest pod kontrolą...

Załóżmy, że zgłaszasz się do wykonawcy. Opowiadasz o swoich potrzebach i przedstawiasz wymagania: potrzebujesz software na zamówienie, taki który będzie idealnie dopasowany do działalności, jaką prowadzi Twoja firma. Wykonawca zapoznaje się z tematem, szacuje czas oraz koszt i prezentuje Ci ofertę.
Zadowolony, że masz pełną kontrolę nad zleceniem, podpisujesz umowę i wiesz, że znowu wykonałeś dobrą robotę. Wszystko idzie dobrze, do czasu aż pojawią się pierwsze...

Problemy

A te pojawiają się już na etapie projektowania. Skoro projekt ma ograniczony budżet, wykonawca będzie trzymał się minimalnego planu, zgodnego ze specyfikacją. W tym samym czasie Tobie zależy na tym, aby Twój system miał jak największą funkcjonalność i był wygodny w obsłudze - mamy pierwszy zgrzyt. Kolejny jest już w drodze.

Konflikt interesów

Wykonawcy zależy na zysku, więc będzie zabezpieczał swój interes powiększając kwotę o odpowiedni "margines bezpieczeństwa". Jeśli wszystko pójdzie po jego myśli, wtedy prawdopodobnie przepłacisz - wartość na umowie znacząco przekroczy realny koszt projektu.

Drugi i zdecydowanie częstszy scenariusz jest taki, że w trakcie kodowania wystąpią nieprzewidziane problemy; będziesz chciał coś zmienić, albo system okaże się bardziej rozbudowany, niż zakładano na początku.
Co to oznacza dla wykonawcy? Potężny wzrost nakładów pracy, ryzyko niedotrzymania terminu, a w efekcie stratę pieniędzy. Tutaj nie ma górnej granicy, koszty mogą wzrastać lawinowo, a przewidzieć to na etapie projektowania jest praktycznie niemożliwym.
No dobrze, ale przecież jesteś klientem i to nie Twój problem, bo i tak dostaniesz to, co zamówiłeś… ale czy na pewno?

Kłopoty wykonawcy = Twoje kłopoty

Wykonawca w tarapatach będzie minimalizował straty. Pominie wszystkie dodatkowe elementy, które w trakcie prac okazały się zbędne do poprawnego funkcjonowania systemu. Pominie także Twoje sugestie zmian, bo de facto nie jest zobowiązany do ich wykonania. Będzie dążył do wdrożenia głównej specyfikacji, pomijając optymalizację, jakość oraz testy. Co więcej - skupi się na tym, aby jak najszybciej zakończyć Waszą współpracę i nie będzie skory do pomocy przy implementacji i rozwoju systemu w przyszłości.

Owszem, można renegocjować umowę i dopisywać aneksy, ale to zaowocuje wzajemną niechęcią i dużą stratą czasu oraz pieniędzy.

Ktoś musi stracić

Konsekwencją zawsze będzie nieudana współpraca. Raz poszkodowany może być dostawca, który w obawie przed negatywną reputacją stworzy bardziej rozbudowany system, niż zakładała specyfikacja i straci pieniądze.
Innym razem będzie to klient - otrzyma oprogramowanie, które nie spełni jego potrzeb i mimo iż dostawca będzie chciał kontynuować współpracę, to zamawiający już niekoniecznie.

Model rozliczeń ma znaczenie

Fixed Price doskonale sprawdza się przy rozliczaniu małych, powtarzalnych projektów, jednak w przypadku systemów pisanych na zamówienie (nawet tych stosunkowo niewielkich) tworzy barierę pomiędzy klientem a wykonawcą i jest źródłem sporów. W tej sytuacji, zamiast skupić się na rozwiązaniach, obie strony starają się wywalczyć jak najwięcej korzyści lub ograniczyć straty. Dlatego tak ważne jest, aby przed podpisaniem umowy dokładnie przemyśleć, czy wybrany model rozliczeń wpłynie pozytywnie na realizację projektu.