Powrót do strony głównej

Business case projektu: dwa business case’y dla zamawiającego i wykonawcy

Artykuł wyjaśnia, dlaczego w każdym projekcie istnieją dwa business case’y: zamawiającego i wykonawcy. Pokazano, jak ich niezgodność prowadzi do porażek i jakie kroki są niezbędne do harmonizacji. Przedstawiono zalecenia dla specjalistów IT.

Sekret sukcesu projektu: jak pogodzić dwa business case’y
Advertisement 728x90

# Dwa uzasadnienia biznesowe w jednym projekcie: jak pogodzić interesy zamawiającego i wykonawcy

W projekcie z udziałem zamawiającego i wykonawcy zawsze istnieją dwa niezależne uzasadnienia biznesowe. Ich niezgodność to główna przyczyna niepowodzeń. Omawiamy, jak zbudować wzajemnie korzystną współpracę i uniknąć typowych błędów.

Dlaczego w projekcie zawsze istnieją dwa uzasadnienia biznesowe?

Projekt zaczyna się od zlecenia: jedna strona (Zamawiający) formułuje zadanie, druga (Wykonawca) je realizuje. Nawet jeśli to ta sama firma, w ramach projektu powstają dwa podmioty ekonomiczne z własnymi celami. Zamawiający dąży do minimalizacji kosztów przy osiągnięciu rezultatu. Wykonawca do maksymalizacji zysku przy spełnieniu warunków umowy. Te cele są z natury przeciwstawne, ale projekt jest możliwy tylko wtedy, gdy obie strony mają pozytywne uzasadnienie biznesowe.

Kluczowa kwestia: uzasadnienie biznesowe to nie tylko obliczenie rentowności. To techniczno-ekonomiczne uzasadnienie, obejmujące:

Google AdInline article slot
  • Oczekiwane rezultaty i korzyści
  • Parametry finansowe (przychody, koszty, marżowość)
  • Ocenę ryzyk i ich wpływu
  • Alternatywne scenariusze (PRINCE2 wymaga co najmniej trzech: «nic nie robić», «minimum», «optimum»)

Jeśli uzasadnienia biznesowe nie są sformalizowane lub nie są przeliczane w trakcie projektu, powstaje dysproporcja. Na przykład Wykonawca może kontynuować pracę mimo strat, licząc na przyszłe bonusy, co prowadzi do spadku jakości lub opóźnień.

Perspektywa akademicka: struktura uzasadnienia biznesowego

Standard PRINCE2 definiuje uzasadnienie biznesowe jako obowiązkowy artefakt projektu. Musi zawierać obiektywną ocenę celowości projektu i być przeliczane przy każdej istotnej zmianie. W praktyce jednak często występuje rozbieżność między teorią a rzeczywistością.

Typowe problemy:

Google AdInline article slot
  • Brak formalizacji: 70% projektów rusza bez szczegółowego uzasadnienia biznesowego. Decyzja opiera się na ofercie komercyjnej, gdzie obliczenia są uproszczone.
  • Izolacja od ryzyk: Rentowność oceniana bez uwzględnienia dynamiki ryzyk. Na przykład przy zmianie terminów lub zakresu prac nie następuje przeliczenie.
  • Niezgodność z umową: Umowa fiksiuje tylko parametry końcowe, ale nie mechanizm adaptacji do zmian.

Aby uzasadnienie biznesowe działało, trzeba je zintegrować z kartą projektu. Tam powinny być jasno określone:

  • Wyzwalacze do przeliczenia (zmiana zakresu, terminów, warunków rynkowych)
  • Progi dla kluczowych wskaźników (minimalna marżowość, maksymalne nakłady pracy)
  • Procedura uzgadniania korekt

Różnice kulturowe: jak przygotowanie uzasadnienia biznesowego wpływa na sukces

Kultura firmy bezpośrednio wpływa na podejście do uzasadnienia biznesowego. W organizacjach reaktywnych (gdzie gasi się pożary) sprowadza się ono do paru liczb w ofercie komercyjnej. W proaktywnych to żywy dokument, regularnie aktualizowany.

Przykład z praktyki: w jednym projekcie IT Wykonawca otrzymał zaliczkę i zaczął pracę, ale nie przeliczył uzasadnienia biznesowego po zmianie składu zespołu. Rezultat:

Google AdInline article slot
  • Terminy przekroczone z powodu braku ekspertów
  • Koszt własny wzrósł o 30% przez zatrudnienie zewnętrznych zasobów
  • Marżowość spadła do zera, ale projekt kontynuowano «dla reputacji»

Rozwiązanie: wprowadzenie regularnych «audytów biznesowych» co 2-3 miesiące. Na nich:

  • Porównuje się rzeczywiste wskaźniki z prognozami
  • Analizuje odchylenia w nakładach pracy i budżecie
  • Podejmuje się decyzję o kontynuacji/korekcie/zakończeniu projektu

Taki sposób zmniejsza ryzyka o 40% (dane PMI), ale wymaga kultury przejrzystości — gdy zespół gotów jest przyznać się do błędu w szacunkach bez obawy kary.

Praktyczny przykład: jak uzasadnienie biznesowe uratowało projekt

Rozważmy rzeczywisty przypadek development platformy SaaS. Zamawiający żądał ścisłych terminów, Wykonawca podał agresywne szacunki w ofercie komercyjnej. Po starcie wyszło:

  • Zespół przeciążony równoległymi projektami
  • Kluczowy deweloper odszedł
  • Problemy techniczne zwiększyły nakłady pracy o 25%

Wykonawca zignorował przeliczenie uzasadnienia biznesowego, licząc, że «nadrobi» na końcu. Wynik:

  • Opóźnienie o 3 miesiące
  • Dodatkowe koszty 15% budżetu
  • Konflikt z Zamawiającym z powodu jakości

Co zmieniło sytuację? W kryzysie zespół przeprowadził sesję przeliczenia:

  • Określono «punkt bez powrotu»: maksymalne nakłady pracy, przy których projekt pozostaje rentowny
  • Uzgadniano skrócenie scope (zakresu prac) bez szkody dla MVP
  • Wprowadzono cotygodniowy monitoring marżowości

Rezultat: projekt zakończony z zyskiem 8% (zamiast prognozowanych 20%), ale bez strat. Zamawiający dostał działający produkt, a Wykonawca zachował reputację.

Czynnik ludzki: osobiste motywy w projekcie

Nawet idealne uzasadnienie biznesowe zawiedzie, jeśli nie uwzględni aspektu ludzkiego. Każdy uczestnik ma swój «osobisty bizneskes»:

  • Kierownik sprzedaży chce zamknąć KPI przychodów
  • Lider techniczny dąży do rozwoju zawodowego
  • Deweloper kieruje się pensją i stabilnością

Gdy cele osobiste nie są uzgodnione z projektowymi, rodzą się konflikty. Na przykład:

  • Sprzedawca obiecuje krótkie terminy, by wygrać przetarg
  • Techlead milczy o ryzykach, by nie zepsuć umowy
  • Deweloper oszczędza na dokumentacji, by zmieścić się w planie

Rozwiązanie — harmonizacja wszystkich poziomów:

  • Poziom projektowy: jasne KPI dla terminów, budżetu, jakości
  • Poziom organizacyjny: premie za udane zakończenie projektu (nie tylko za start)
  • Poziom osobisty: indywidualne cele zgodne z projektowymi (np. nauka nowych technologii w ramach projektu)

Co jest ważne

  • Dwa kasy — dwa projekty: Zamawiający i Wykonawca zawsze realizują różne projekty. Łączy ich tylko umowa.
  • Przeliczaj regularnie: Uzasadnienie biznesowe starzeje się co 3-6 miesięcy. Ignorowanie zmian prowadzi do strat.
  • Szukaj punktów wspólnych: Umowa powinna określać warunki korekty projektu przy zmianie uzasadnienia biznesowego.
  • Uwzględniaj czynnik ludzki: Osobiste motywy uczestników są silniejsze niż formalne KPI. Harmonizacja interesów to klucz do sukcesu.

— Editorial Team

Advertisement 728x90

Czytaj dalej