Rentowność projektu w software house i agencji: jak nie tracić na realizacji

Projekt wyglądał świetnie w ofercie. Wycena domknęła się z przyzwoitą marżą, klient podpisał, zespół ruszył. Trzy miesiące później projekt jest oddany, klient zadowolony — a kiedy w końcu zsumujesz, ile czasu naprawdę na niego poszło, okazuje się, że zarobiłeś na nim grosze albo dołożyłeś. Nikt nie zrobił nic złego. Po prostu rentowność projektu w software house rozegrała się tam, gdzie jej nie pilnowałeś: w trakcie realizacji, godzina po godzinie. W tym tekście pokażę Ci, jak liczyć marżę na pojedynczym projekcie tak, żeby uwzględniała realny koszt czasu zespołu, scope creep i nadgodziny — i jakie sygnały śledzić na bieżąco, zanim wynik zniknie.

To tekst o rentowności pojedynczego projektu, a nie całej firmy. Jeśli najpierw chcesz uporządkować koszty na poziomie spółki — kto jest rozliczalny, ile kosztuje pełna głowa — zacznij od budżetu kosztów w software house, a tu zejdziemy o piętro niżej, do konkretnej realizacji.

Dlaczego projekt rentowny w ofercie traci na realizacji

Wycena to obietnica. Marża, którą widzisz w ofercie, jest marżą planowaną — opartą na założeniu, ile godzin zajmie praca i kto ją wykona. Rzeczywista rentowność powstaje dopiero w trakcie, gdy te założenia zderzają się z życiem. Między jednym a drugim wciska się kilka cichych kosztów, których wycena zwykle nie widzi.

• Niedoszacowanie pracochłonności. Estymata bywa optymistyczna, bo robi ją się pod presją sprzedaży. Realne godziny niemal zawsze przekraczają plan.
• Scope creep — pełzający zakres. Klient prosi o „drobne” zmiany, zespół je robi, bo relacja jest dobra, a żadna z nich nie trafia do aneksu. Każda dokłada koszt bez dokładania przychodu.
• Praca nierozliczalna w projekcie. Koordynacja, doprecyzowywanie wymagań, poprawki, spotkania statusowe — godziny realne, których nikt nie zafakturuje.
• Droższe ręce, niż założono. Zadanie wycenione na juniora robi senior, bo junior był zajęty. Koszt godziny rośnie, stawka dla klienta zostaje.

Każdy z tych czynników z osobna wygląda niewinnie. Razem potrafią zamienić projekt z marżą 40% w wynik bliski zera — a ponieważ rozkładają się na tygodnie, nikt nie zauważa momentu, w którym marża wyparowała.

Policz rentowność projektu uczciwie: przychód minus pełny koszt czasu

Wzór jest prosty. Trudność leży w jednej liczbie — w koszcie.

marża projektu (kwota) = przychód z projektu − koszt realizacji
marża projektu (%)     = (przychód − koszt realizacji) / przychód × 100%

Przychód jest zwykle oczywisty: to, co zafakturujesz. Koszt realizacji bywa liczony błędnie, bo właściciele biorą do niego samą wypłatę netto albo stawkę z umowy B2B. Tymczasem do projektu trzeba przypisać pełny koszt godziny każdej osoby — to, co nazywa się blended cost rate, czyli pełną stawkę kosztową roli.

koszt realizacji = Σ (godziny przepracowane_i × pełny koszt godziny_i) + koszty zewnętrzne projektu

Pełny koszt godziny to nie pensja podzielona przez 168. To pełny koszt zatrudnienia (wynagrodzenie, składki po stronie pracodawcy, świadczenia, sprzęt, licencje przypisane do stanowiska) podzielony przez godziny realnie rozliczalne, nie przez wszystkie godziny w miesiącu. Jeśli specjalista jest obłożony płatną pracą w 80% czasu, jego koszt rozkłada się na te 80% — pozostałe 20% (ławka, urlopy, rozwój) musi sfinansować właśnie marża z projektów. Dlatego stawka kosztowa policzona „na pełen etat” jest zawsze zaniżona i każe projektom wyglądać na rentowniejsze, niż są. Ten sam mechanizm — koszt czasu kontra obłożenie — rozkładam szerzej w tekście o płynności w software house.

Do tego dolicz koszty zewnętrzne projektu: podwykonawców, licencje i chmurę użyte tylko na tym projekcie, koszty podróży. Często to one robią różnicę między marżą na papierze a marżą realną — projekt z dużym udziałem podwykonawcy potrafi mieć zupełnie inną rentowność niż projekt robiony własnym zespołem.

Estymata kontra rzeczywistość: wskaźnik, który mówi prawdę

Pojedyncza liczba marży na koniec projektu jest jak sekcja zwłok — dowiadujesz się, co poszło nie tak, gdy nic już nie zmienisz. Dlatego CFO patrzy nie tylko na to, ile zarobiłeś, ale na to, jak godziny realne miały się do estymaty. Służy do tego wskaźnik realizacji (realization rate):

wskaźnik realizacji = godziny zafakturowane / godziny przepracowane

Jeśli na projekcie przepracowaliście 1 000 godzin, a klientowi możesz zafakturować 800, wskaźnik wynosi 80% — pozostałe 20% pracy firma sfinansowała z własnej marży. W projektach rozliczanych w modelu fixed price ten wskaźnik jest jeszcze ważniejszy, bo cena jest sztywna: każda godzina ponad estymatę to czysta erozja marży, której klient nie pokryje.

Przyjmowany w branży usług IT punkt odniesienia dla godzin rozliczalnych to mniej więcej 75–85% czasu osób „przy produkcji”. Spadek realizacji wyraźnie poniżej tego poziomu to najwcześniejszy sygnał, że projekt zaczyna się rozjeżdżać — i widać go na długo przed tym, zanim odchylenie pojawi się w wyniku. Jak czytać samo odchylenie planu od wykonania, rozkładam w tekście o analizie odchyleń.

Projekt nie traci marży w jednym dniu — traci ją po pół godziny dziennie przez trzy miesiące. Dlatego rentowności pilnuje się w trakcie, nie po fakcie.

Sygnały ostrzegawcze, które warto śledzić w trakcie

Żeby pilnować rentowności na bieżąco, nie potrzebujesz skomplikowanego systemu — potrzebujesz kilku liczb, na które patrzysz co tydzień przy każdym większym projekcie. Te cztery wychwytują problem, zanim zje budżet.

1. Procent zużytego budżetu godzin kontra procent ukończenia. Jeśli projekt jest w 60% gotowy, a zużył 85% zaplanowanych godzin, marża już się pali. To najprostszy i najwcześniejszy sygnał przekroczenia.
2. Godziny nieobjęte aneksem. Licz osobno czas poświęcony na prośby spoza pierwotnego zakresu. Gdy ta pula rośnie, masz scope creep — i twardy argument, by uruchomić change order zamiast pracować za darmo.
3. Realny mix ról kontra wycena. Jeśli pracę juniorską wykonują seniorzy, koszt rośnie po cichu. Porównuj, kto faktycznie pracuje, z tym, kogo założyłeś w wycenie.
4. Trend marży projektu z tygodnia na tydzień. Nie sama wartość, lecz kierunek. Spadająca marża przy rosnącym zaawansowaniu mówi, że końcówka projektu będzie najdroższa — bo poprawki i domykanie zawsze kosztują najwięcej.

Najważniejsza zasada: te liczby mają sens tylko wtedy, gdy zespół realnie raportuje czas. Bez rzetelnego time trackingu rentowność projektu jest zgadywanką, a wszystkie wskaźniki powyżej są puste. To nie biurokracja — to jedyne źródło danych o tym, gdzie wycieka Twoja marża.

Co dobra marża projektu naprawdę oznacza

Liczba marży na projekcie ma sens dopiero w porównaniu — i w świadomości, na którym poziomie ją liczysz. To rozróżnienie, które najczęściej myli właścicieli: marża, o której zaraz mowa, to marża bezpośrednia, jeszcze przed kosztami stałymi firmy.

• Marża bezpośrednia projektu to przychód minus pełny koszt zaangażowanych ludzi i kosztów zewnętrznych. W zdrowym software house i agencji bywa to zwykle rząd 40–60% — to jednak musi wystarczyć na pokrycie całej struktury nierozliczalnej (zarząd, sprzedaż, administracja).
• Marża po kosztach stałych zostaje dopiero wtedy, gdy od marży bezpośredniej odejmiesz przypadającą na projekt część kosztów firmy. To ona mówi, czy projekt realnie dołożył do zysku.

Dlatego projekt z marżą bezpośrednią 30% może być pod kreską na poziomie całej firmy, jeśli koszty stałe pochłaniają więcej. Różnicę między tym, ile dokładasz do ceny, a ile realnie zostaje, rozkładam osobno w tekście o tym, jak liczyć marżę i narzut. A jeśli mimo dobrej marży na papierze i tak brakuje gotówki, przyczyna leży zwykle gdzie indziej — w tym, że zysk to nie to samo co pieniądze na koncie.

Najprostszy test, czy panujesz nad rentownością projektów: czy potrafisz dziś, bez tygodniowej rekonstrukcji w arkuszu, powiedzieć, który z bieżących projektów zarabia, a który dokłada. Jeśli odpowiedź brzmi „muszę policzyć”, to właśnie tam wycieka marża, której nie widzisz.

Co z tym zrobić w praktyce

Kontrola rentowności projektu nie jest osobnym projektem ani drogim narzędziem. To pięć nawyków: pełny koszt godziny zamiast pensji, rzetelne raportowanie czasu, cotygodniowy rzut oka na zużycie budżetu kontra zaawansowanie, twarda dyscyplina aneksów przy zmianach zakresu i czytanie marży na dwóch poziomach — bezpośrednim i po kosztach stałych. Tyle wystarczy, żeby zamiast dowiadywać się o stracie po oddaniu projektu, widzieć ją w czwartym tygodniu, gdy jeszcze można zareagować.

Jeśli prowadzisz firmę projektową i masz wrażenie, że obłożenie jest pełne, a wynik i tak Cię nie cieszy, problem zwykle nie leży w cenach, lecz w tym, że koszt, czas i zakres żyją w trzech różnych miejscach i nikt nie zestawia ich na poziomie pojedynczego projektu. To dokładnie ten moment, w którym pomaga spojrzenie CFO. Jeśli chcesz zobaczyć, jak prosty układ kalkulacji per projekt — z sygnałami ostrzegawczymi do śledzenia w trakcie — mógłby wyglądać u Ciebie, porozmawiajmy. Bez zobowiązań, po to, żeby zobaczyć, gdzie naprawdę wycieka Twoja marża.