Spis treści5 sekcji
Projekt ma wysoką wartość kontraktu, faktury są wystawiane zgodnie z harmonogramem, a klient regularnie zleca kolejne zadania. Na poziomie sprzedaży wszystko wygląda dobrze.
Problem pojawia się dopiero wtedy, gdy firma sprawdza, ile osób byłną zaangażowanych w realizację, jak długo pracowały i jakie dodatkowe koszty trzeba było ponieść.
Okazuje się, że projekt wymagał udziału senior developera, architekta, testera, UX designera i Project Managera. Pojawiły się dodatkowe spotkania, nieplanowane poprawki, wsparcie powdrożeniowe oraz zadania, których nie uwzględniono w pierwszej wycenie.
Przychód wygląda dobrze, ale zysk jest niewielki.
Wiemy, jak to jest, gdy projekt generuje dużo faktur, a mimo to nie poprawi wyniku firmy. Zespół jest zajęty, klient zadowolony, a właściciel dopiero po kilku miesiącach odkrywa, że realizacja pochłonęła niemal całą planowaną marżę.
Nierentowny projekt IT rzadko wygląda na problematyczny od pierwszego dnia. Najczęściej stopniowo angażuje coraz więcej czasu i kosztownych zasobów, podczas gdy wartość kontraktu pozostaje bez zmian.
Projekt ma wysoką wartość kontraktu, faktury są wystawiane zgodnie z harmonogramem, a klient regularnie zleca kolejne zadania. Na poziomie sprzedaży wszystko wygląda dobrze.
Dlaczego projekt o wysokiej wartości może mieć niską marżę?
Wartość faktur nie pokazuje rentowności. Informuje jedynie, ile firma sprzedała klientowi.
Aby ocenić wynik projektu, trzeba uwzględnić wszystkie koszty związane z jego realizacją.
Projekt angażuje najdroższe osoby w zespole
Pierwotna wycena może zakładać, że większość zadań wykona mid developer przy okresowym wsparciu seniora. W praktyce projekt okazuje się bardziej złożony.
Senior developer zaczyna uczestniczyć w codziennych konsultacjach, architekt rozwiązuje problemy techniczne, a Project Manager spędza coraz więcej czasu na komunikacji z klientem.
Liczba godzin może nadal mieścić się w przyjętym budżecie, ale zmienia się ich struktura kosztowa.
Przykład:
- 100 godzin junior developera przy koszcie 80 zł za godzinę: 8 000 zł,
- 100 godzin senior developera przy koszcie 200 zł za godzinę: 20 000 zł.
Projekt wykorzystał tyle samo czasu, ale jego koszt wzrósł o 12 000 zł.
Nieplanowane działania nie są widoczne w budżecie
Część pracy nie trafia do pierwotnej estymacji, ponieważ pojawia się dopiero w trakcie realizacji.
Mogą to być:
- dodatkowe spotkania z klientem,
- kolejne rundy analizy,
- poprawki po zmianie decyzji biznesowej,
- wsparcie użytkowników,
- prygotowanie dodatkowej dokumentacji,
- prace związane z migracją danych,
- problemy z infrastrukturą klienta,
- konsultacje międzyzespołowe,
- naprawa błędów wynikających z niepełnych wymagań.
Każde takie działanie kosztuje firmę czas i pieniądze. Jeżeli nie zostanie przypisane do projektu, raport rentowności będzie zaniżał rzeczywisty koszt.
Scope creep zwiększa koszt bez zwiększenia przychodu
Klient zgłasza niewielkie zmiany, które zespół realizuje bez osobną wyceny. Jedna dodatkowa funkcja, kolejny wariant widoku albo rozszerzenie integracji nie wydają się dużym problemem.
Po kilku miesiącach okazuje się jednak, że zakres wzrósł o kilkadziesiąt lub kilkaset godzin.
Jeżeli projekt jest rozliczany w modelu Fixed Price, każda dodatkowa godzina obniża marżę. W modelu abonamentowym problem pojawia się wtedy, gdy klient wykorzystuje więcej czasu niż przewidziano w miesięcznej opłacie.
Koszty zewnętrzne nie są przypisane do projektu
Projekt może wymagać dodatkowych:
- licencji,
- usług chmurowych,
- narzędzi testowych,
- komponentów,
- podwykonawców,
- konsultantów,
- środowisk serwerowych,
- koszty podróży i spotkań.
Jeżeli wydatki pozostają w kosztach ogólnych firmy, projekt wygląda na bardziej rentowny, niż jest w rzeczywistości.
Wynik jest analizowany dopiero po zakończeniu prac
Największym błędem jest czekanie na końcowe rozliczenie.
Po zamknięciu projektu można już tylko stwierdzić, że marża była zbyt niska. Nie da się odzyskać przepracowanych godzin, ograniczyć dodatkowych działań ani zmienić składu zespołu.
Dlatego koszt i rentowność powinny być kontrolowane na bieżąco.
Jak wykryć nierentowny projekt IT przed jego zakończeniem?
Skuteczna analiza powinna łączyć dane o przychodach, czasie pracy, kosztach specjalistów, wydatkach zewnętrznych i pracy potrzebnej do zakończenia projektu.
1. Przeliczaj czas na koszt konkretnych specjalistów
Sama liczba godzin nie wystarczy.
Każda osoba powinna mieć określoną indywidualną stawkę kosztową uwzględniającą między innymi:
- wynagrodzenie lub fakturę B2B,
- obciążenia pracodawcy,
- urlopy i nieobecności,
- koszty stanowiska pracy,
- narzędzia,
- czas niekomercyjny,
- koszty zarządzania.
Następnie każda godzina zaraportowana do projektu powinna automatycznie zwiększać jego koszt.
Podstawowy wzór:
Koszt pracy projektu = suma przepracowanych godzin każdego specjalisty × jego stawka kosztowa
Dzięki temu widać nie tylko, ile czasu wykorzystano, ale również jaka była jego finansowa wartość.
2. Porównuj koszt z postępem realizacji
Wykorzystanie 70% budżetu nie musi oznaczać problemu, jeśli wykonano już 90% zakresu.
Jeżeli jednak projekt wykorzystał 70% budżetu, a ukończono dopiero połowę prac, ryzyko przekroczenia jest wysokie.
Project Manager powinien regularnie porównywać:
- procent wykorzystanych godzin,
- koszt poniesiony,
- procent ukończenia zakresu,
- liczbę otwartych zadań,
- koszt pozostałych prac,
- prognozowaną marżę końcową.
3. Oddzielaj koszt podstawowy od prac dodatkowych
Każda zmiana zakresu powinna być rejestrowana jako osobna pozycja.
Warto wskazać:
- kto zgłosił zmianę,
- czego dotyczy,
- czy mieści się w umowie,
- ile godzin wymaga,
- jakie osoby będą potrzebne,
- jaki jest jej koszt,
- czy została dodatkowo wyceniona,
- jak wpłynie na termin i marżę.
Dzięki temu firma widzi, jaka część kosztu wynika z pierwotnej realizacji, a jaka z dodatkowych oczekiwań klienta.
4. Prognozuj koszt końcowy, a nie tylko koszt poniesiony
Projekt może obecnie wyglądać rentownie, ponieważ znaczna część prac dopiero czeka na wykonanie.
Przykład:
- wartość kontraktu: 200 000 zł,
- koszt poniesiony: 90 000 zł,
- aktualna różnica: 110 000 zł,
- prognozowany koszt pozostałych prac: 80 000 zł,
- przewidywany koszt końcowy: 170 000 zł,
- prognozowana marża: 30 000 zł.
Aktualna różnica między przychodem a poniesionym kosztem nie jest marżą końcową.
Najważniejszym wskaźnik jest odpowiedź na pytanie:
Ile projekt będzie kosztował, jeśli utrzymamy obecne tempo i sposób realizacji?
Jak rozwiązaliśmy wykrywanie nierentownych projektów w Administy?
Prowadząc agencje, realizowaliśmy projekty, które na pierwszy rzut oka wyglądał bardzo dobrze.
Miały wysoką wartość kontraktu, regularnie wystawiane faktury i dużą liczbę przepracowanych godzin. Były istotne dla zespołu oraz portfela klientów.
Dopiero dokładniejsza analiza pokazywała, że część z nich angażowała najbardziej kosztowne osoby i wymagał wielu nieplanowanych działań.
Problem polegał na rozproszeniu danych:
- przychody znajdowały się w fakturach,
- czas pracy w systemie projektowym,
- stawki pracowników w osobnych zestawieniach,
- faktury podwykonawców w dokumentach kosztowych,
- dodatkowe wydatki w transakcjach bankowych,
- zakres i harmonogram w kolejnych narzędziach.
Widzieliśmy obrót, ale nie zawsze widzieliśmy pełny koszt projektu.
Dlatego w Administy stworzyliśmy raport rentowności, który łączy:
- wartość kontraktu,
- kwoty zafakturowane,
- środki rzeczywiście wpłacone,
- czas pracy zespołu,
- indywidualny koszt każdego specjalisty,
- faktury podwykonawców,
- koszty zewnętrzne,
- godziny pozostałe do wykorzystania,
- prognozowany koszt zakończenia,
- bieżąca i przewidywaną marżę.
Czas pracy importowany z systemu projektowego jest automatycznie przypisywany do projektu i przeliczany według kosztu konkretnej osoby.
Dzięki temu widzimy różnicę między projektem, który wykorzystał:
- 300 godzin tańszego zespołu,
- a projektem, który wykorzystał 300 godzin seniorów i kadry zarządzającej.
Liczba godzin może być identyczna, ale wynik finansowy zupełnie inny.
Raport pozwala także zauważyć, że projekt:
- generuje wysoki przychód, ale niski zysk,
- wymaga zbyt dużego udziału seniorów,
- przekracza założony koszt zarządzania,
- posiada dużo nieplanowanych prac,
- angażuje podwykonawców poza pierwotnym budżetem,
- potrzebuje więcej środków do zakończenia, niż zakładano,
- może zakończyć się niską lub ujemną marżę.
Dzięki temu możemy zareagować przed zamknięciu projektu.
W zależności od źródła problemu można:
- zmienić skład zespołu,
- ograniczyć udział najdroższych specjalistów,
- uporządkować komunikację z klientem,
- zatrzymać nieuzgodnione poprawki,
- wycenić prace dodatkowe,
- renegocjować zakres,
- zmienić harmonogram,
- poprawić estymację pozostałych etapów.
Najważniejsza zmiana polega na oddzieleniu wartości sprzedaży od realnej wartości finansowej projektu.
Projekt o wartości 300 000 zł nie zawsze jest lepszy od projektu wartego 100 000 zł. Jeżeli pierwszy angażuje większość zespołu i kończy się marżę 5%, a drugi ma prosty zakres i marżę 35%, mniejszy projekt może generować znacznie większą wartość dla firmy.
Duży projekt nie zawsze oznacza dobry projekt
Nierentowny projekt IT może długo pozostawać niewidoczny, jeżeli firma analizuje wyłącznie wartość kontraktu, faktury i liczbę godzin.
Prawdziwy wynik pojawia się dopiero po uwzględnieniu kosztu konkretnych specjalistów, wydatków zewnętrznych, dodatkowego zakresu i pracy potrzebnej do zakończenia.
Im wcześniej firma zobaczy prognozowaną marżę, tym większa szansa, że ograniczy stratę i poprawi sposób realizacji.
Sprawdź, które projekty naprawdę zarabiają
Administy pomaga łączyć przychody, czas pracy, koszt zespołu, wydatki zewnętrzne i prognozowaną marżę w jednym raporcie.
Umów prezentację Administy i sprawdź, które projekty generują realny zysk, a które jedynie wysoki obrót i duże obciążenie zespołu.
