Rentowność projektu IT: jak policzyć, czy naprawdę zarabiasz na zleceniu

Masz pięć projektów oddanych w tym kwartale. Zespół był obłożony, klienci zadowoleni, faktury wyszły. A gdy patrzysz na wynik firmy, czujesz, że coś się nie domyka — bo jest słabszy, niż „powinien” być przy takim obłożeniu. Najczęstsza przyczyna jest cicha i niewidoczna z poziomu salda: dwa z tych pięciu projektów dołożyły do biznesu, a Ty nawet nie wiesz które. Rentowność projektu IT rzadko bywa policzona uczciwie do końca — zwykle zatrzymuje się na „stawka minus pensja”, a tam, gdzie zaczyna się prawda, nikt nie dolicza ani pełnego kosztu zespołu, ani części kosztów stałych firmy. W tym tekście pokażę Ci, jak zbudować rachunek rentowności pojedynczego projektu krok po kroku: koszt bezpośredni zespołu, narzut kosztów stałych i realna marża po fakcie — tak, żebyś wiedział, które zlecenia naprawdę zarabiają, a które tylko zajmują kalendarz.

To tekst o tym, jak policzyć wynik projektu po jego zamknięciu — rachunek post factum, którym porównasz projekty między sobą. Jeśli zależy Ci na pilnowaniu marży w trakcie realizacji, gdy jeszcze można reagować, to osobny temat — rozkładam go w tekście o rentowności projektu w software house. Tutaj zajmujemy się konstrukcją samej liczby.

Dlaczego „stawka minus pensja” kłamie

Większość właścicieli liczy rentowność projektu intuicyjnie: przychód minus to, co zapłacili ludziom za czas na tym projekcie. Problem w tym, że obie strony tego równania bywają policzone za płytko — i to systematycznie w stronę, która każe projektowi wyglądać na rentowniejszy, niż jest.

• Koszt człowieka to nie jego pensja. Do projektu trzeba przypisać pełny koszt zatrudnienia: wynagrodzenie, składki po stronie pracodawcy, świadczenia, sprzęt i licencje przypisane do stanowiska. To zwykle o jedną trzecią do połowy więcej niż kwota na pasku.
• Liczy się czas rozliczalny, nie etat. Dzieląc koszt na wszystkie godziny w miesiącu, zaniżasz stawkę. Część czasu zawsze pochłaniają urlopy, rozwój, ławka i praca wewnętrzna — i to marża z projektów ma ją sfinansować.
• Nikt nie dolicza kosztów stałych firmy. Czynsz, zarząd, sprzedaż, administracja, księgowość — te koszty firma ponosi tak czy inaczej, a każdy projekt powinien ponieść swoją część. Bez tego mylisz marżę bezpośrednią z realnym wynikiem.

Te trzy uproszczenia razem sprawiają, że projekt z „marżą 40%” na serwetce potrafi być realnie pod kreską. Uczciwy rachunek rentowności projektu naprawia je po kolei — i właśnie po kolei je teraz przejdziemy.

Krok 1: koszt bezpośredni zespołu

Koszt bezpośredni to wszystko, co pochłonął ten projekt i czego by nie było, gdyby go nie przyjęto. Jego trzon to czas zespołu wyceniony pełnym kosztem godziny, a nie pensją.

pełny koszt godziny = pełny koszt zatrudnienia roczny / godziny realnie rozliczalne w roku
koszt bezpośredni = Σ (godziny na projekcie_i × pełny koszt godziny_i) + koszty zewnętrzne projektu

Pełny koszt zatrudnienia to pensja brutto powiększona o składki pracodawcy oraz przypisane do stanowiska świadczenia, sprzęt i licencje. Dzielisz go nie przez 2 016 godzin nominalnych w roku, lecz przez godziny realnie rozliczalne — czyli te, które da się przypisać do płatnej pracy klienta. Jeśli specjalista jest obłożony płatnymi projektami w 80% czasu, jego koszt rozkłada się na te 80% i stawka godzinowa rośnie. Sposób, w jaki obłożenie i koszt głowy łączą się w budżet całej firmy, rozkładam w tekście o budżecie kosztów w software house.

Do tego dolicz koszty zewnętrzne projektu: podwykonawców, chmurę i licencje użyte tylko tutaj, koszty podróży. W projekcie z dużym udziałem podwykonawcy to one często decydują o wyniku. Tak policzona różnica „przychód minus koszt bezpośredni” daje marżę bezpośrednią — pierwszy poziom prawdy, ale jeszcze nie ostatni.

Krok 2: narzut kosztów stałych — część, której wszyscy zapominają

Marża bezpośrednia mówi, ile projekt zostawił po opłaceniu ludzi, którzy przy nim pracowali. Nie mówi jeszcze, czy projekt dołożył do zysku firmy — bo firma ma też koszty, które istnieją niezależnie od konkretnego zlecenia: zarząd, sprzedaż, biuro, administracja. Każdy projekt powinien ponieść swoją część tych kosztów. To właśnie narzut kosztów stałych (po angielsku overhead allocation). Bez niego rentowność projektu jest połowiczna.

Cała rzecz w rozsądnym kluczu podziału. W firmie usługowej najuczciwszym miernikiem zaangażowania zasobów jest czas, więc koszty stałe rozkłada się zwykle proporcjonalnie do godzin rozliczalnych:

stawka narzutu (zł/godz.) = roczne koszty stałe firmy / roczne godziny rozliczalne zespołu
narzut na projekt = godziny na projekcie × stawka narzutu

Jeśli firma ma 1,2 mln zł rocznych kosztów stałych i 12 000 rozliczalnych godzin zespołu w roku, każda godzina musi pokryć 100 zł narzutu. Projekt, który zjadł 600 godzin, niesie więc 60 000 zł kosztów stałych — niezależnie od tego, czy ktokolwiek to nazwał. Można też rozkładać narzut proporcjonalnie do kosztu bezpośredniego albo do przychodu; ważne, by metoda była jedna i stosowana konsekwentnie do wszystkich projektów. Sam podział kosztów na stałe i zmienne — i to, dlaczego ich proporcja decyduje o odporności firmy — rozwijam w tekście o strukturze kosztów stałych i zmiennych.

Marża bezpośrednia mówi, czy projekt opłacił własny zespół. Dopiero marża po narzucie mówi, czy w ogóle warto było go robić.

Krok 3: realna marża projektu, czytana na dwóch poziomach

Złóż obie warstwy w jeden rachunek. Pokazuję go na liczbach, żeby było widać, jak ten sam projekt wygląda inaczej na każdym poziomie.

Pozycja	Kwota
Przychód z projektu	300 000 zł
− Koszt bezpośredni zespołu	165 000 zł
= Marża bezpośrednia	135 000 zł (45%)
− Narzut kosztów stałych	60 000 zł
= Marża po kosztach stałych	75 000 zł (25%)

Ten sam projekt to 45% marży bezpośredniej i 25% marży po kosztach stałych — i obie liczby są prawdziwe, tylko odpowiadają na inne pytania. Marża bezpośrednia służy do decyzji operacyjnych: czy warto domknąć dodatkowe zlecenie, gdy zespół ma wolne moce. Marża po kosztach stałych mówi, czy projekt realnie zasilił zysk firmy. Logikę pojedynczego zlecenia ocenianego marżą bezpośrednią rozkładam osobno w tekście o marży kontrybucyjnej.

Niebezpieczna strefa to projekty z dodatnią marżą bezpośrednią, ale ujemną po narzucie. Wyglądają na opłacalne — „przecież zarobiliśmy na zespole” — a po cichu dokładają do struktury firmy. Im więcej takich projektów, tym mocniej rośnie obrót przy stojącym w miejscu zysku. To najczęstszy obraz firmy, która „dużo robi, a nic z tego nie ma”.

Jak czytać wynik: porównanie, nie pojedyncza liczba

Marża jednego projektu nic nie mówi w próżni. Wartość pojawia się dopiero w porównaniu — gdy ustawisz wszystkie zamknięte projekty obok siebie i posortujesz od najwyższej marży po narzucie do najniższej. Niemal zawsze ujawnia się ten sam rozkład: garść projektów zarabia naprawdę dobrze, środek jest przyzwoity, a ogon balansuje wokół zera lub jest pod kreską.

Dla firmy usługowej kilka punktów odniesienia, które pomagają czytać te liczby:

• Marża bezpośrednia. W zdrowym software house i agencji zwykle rzędu 40–60%. Poniżej około 35% projekt z trudem pokrywa narzut i własną strukturę.
• Marża po kosztach stałych. To ona pokazuje realny wkład w zysk. Stale ujemna na wielu projektach oznacza, że ceny nie pokrywają kosztu prowadzenia firmy, a nie tylko kosztu zespołu.
• Wzorzec, nie wyjątek. Jeden słabszy projekt to życie. Powtarzalny wzorzec — np. wszystkie projekty fixed price dla jednego typu klienta są pod kreską — to sygnał do zmiany cen albo modelu współpracy.

Kiedy odkryjesz, które projekty dokładają, masz konkretny materiał do decyzji: podnieść ceny w danym segmencie, twardziej pilnować zakresu i aneksów, zmienić mix ról albo świadomie przestać przyjmować dany typ zleceń. Jak i kiedy przeprowadzić samą podwyżkę, rozkładam w tekście o tym, jak i kiedy podnieść ceny.

Jeden warunek, bez którego cała kalkulacja jest zgadywanką

Wszystkie powyższe liczby opierają się na jednej rzeczy: na rzetelnym raportowaniu czasu. Bez wiedzy, ile godzin i czyich poszło na konkretny projekt, nie policzysz ani kosztu bezpośredniego, ani narzutu — a marża projektu staje się fikcją opartą na pamięci. To nie biurokracja dla samej biurokracji; to jedyne źródło danych o tym, gdzie wycieka Twój wynik.

Druga pułapka jest finansowa, nie księgowa: projekt z dobrą marżą po narzucie wciąż może drenować konto, jeśli klient płaci po 60 dniach, a koszty ponosisz na bieżąco. Rentowność i gotówka to dwie różne sprawy — mechanizm, w którym rentowna firma traci płynność, rozkładam w tekście o różnicy między zyskiem a gotówką. Marża mówi, czy projekt był wart roboty; płynność mówi, czy przeżyjesz czekanie na zapłatę.

Rentowność projektu IT w praktyce: co z tym zrobić

Uczciwy rachunek rentowności projektu IT to nie wdrożenie systemu, tylko cztery nawyki: pełny koszt godziny zamiast pensji, rzetelny time tracking, jeden konsekwentny klucz narzutu kosztów stałych i czytanie wyniku na dwóch poziomach — bezpośrednim i po narzucie. Gdy to ustawisz raz, każdy zamknięty projekt sam wpada na właściwe miejsce w rankingu, a Ty przestajesz zgadywać, które zlecenia zarabiają.

Jeśli prowadzisz firmę projektową i masz wrażenie, że obłożenie jest pełne, a wynik Cię nie cieszy, przyczyna zwykle nie leży w cenach z cennika, lecz w tym, że nikt nie zestawia kosztu, czasu i narzutu na poziomie pojedynczego zlecenia. To dokładnie ten moment, w którym pomaga spojrzenie CFO. Jeśli chcesz zobaczyć, jak prosty układ rachunku rentowności per projekt — z czytelnym rankingiem, które dokładają, a które zarabiają — mógłby wyglądać u Ciebie, porozmawiajmy. Bez zobowiązań, od konkretnych liczb na stole.