20 Entwickler, ein Stundensatz – und keine Ahnung, was das Projekt wirklich einbrachte
"Ich kannte den Stundensatz jedes Entwicklers. Ich kannte den Vertragssatz des Kunden. Ich habe den einen vom anderen abgezogen und dachte, ich kenne die Marge. Dann habe ich eine Projekt-GuV erstellt und gemerkt, dass ich vier Jahre lang ein Unternehmen auf Basis einer Fiktion geführt hatte."
Die Gründerin eines IT-Dienstleistungs- und Outstaffing-Unternehmens — 20 Entwickler, ₴36 Mio. Jahresumsatz, sieben aktive Kunden — beschrieb die Übung, die ihre Preisgestaltung und Einstellungspraxis veränderte.
Vier Jahre lang hatte sie das Geschäft nach dem geführt, was in der Branche üblich ist: Stundensatz-Rechnung. Jeder Entwickler hatte einen Kostensatz (im Schnitt ₴550/Stunde). Jeder Kunde hatte einen Vertragssatz (im Schnitt ₴950/Stunde über alle Kunden hinweg). Einfache Subtraktion ergab ₴400/Stunde Bruttomarge pro Entwickler, ~42% Marge. Hochgerechnet auf das ganze Team: komfortabel, profitabel, wachsend.
Dann machte sie die Übung. Ein Projekt herausgreifen. Nicht die Zahl "wir haben dem Kunden ₴X pro Stunde in Rechnung gestellt". Die tatsächliche Projekt-GuV. Kundenumsatz für den Monat. Alle Kosten, die diesem Projekt direkt zurechenbar sind. Alle Kosten, die indirekt zurechenbar sind. Was übrig bleibt.
Projektmarge bei ihrem wichtigsten Kunden, über die vergangenen 12 Monate: 14%. Nicht 42%.
Achtundzwanzig Margenpunkte waren in einer Reihe von Kosten verschwunden, die die Stundensatz-Rechnung gar nicht erfasste.
Was die Stundensatz-Rechnung wirklich verschleiert
Der Stundensatz setzt voraus, dass ein Entwickler zu 100% auf das Projekt ausgelastet ist, während dieser Zeit zu 100% produktiv ist und das Projekt nur seine Arbeitszeit verbraucht. Für kein reales Dienstleistungsunternehmen trifft das zu.
Bench und Ramp-down (−5 Punkte). Wenn ein Projekt endet oder ein Kunde pausiert, ist der Entwickler untätig, wird aber weiterhin bezahlt. Im Schnitt zwei Wochen pro Jahr und Entwickler. Nicht abrechenbar. Geht von der Marge ab.
Urlaub und Krankheitstage (−4 Punkte). Fest angestellte Entwickler erhalten bezahlten Urlaub und Krankheitstage. Der Vertragssatz wird nur für tatsächlich geleistete Arbeit abgerechnet. Die Lücke bleibt unsichtbar, bis man sie zählt.
Interne Meetings, Prozesse, Einstellungsgespräche (−6 Punkte). Standups, Retros, Planung, Interviews mit Kandidaten, interne Abstimmungen. Alles bezahlt, nichts abrechenbar. Im Schnitt 4–6 Stunden pro Entwickler und Woche.
Tools und Lizenzen (−2 Punkte). IDE-Lizenzen, Cloud-Infrastruktur für interne Umgebungen, Projektmanagement-Tools, Monitoring, Kommunikationsplattformen. Pro Einheit klein; summiert sich aber.
Recruiting- und Management-Overhead (−7 Punkte). HR, Delivery Manager, Projektmanager, die eigene Zeit der Gründerin. Alle werden bezahlt. Fast nie abrechenbar. Das war das größte Einzelleck.
Rabatte und nicht abgerechnete Überstunden (−4 Punkte). Der Kunde hat bei der Vertragsverlängerung auf den Preis gedrückt, 8% Rabatt gewährt. Notfallarbeit am Wochenende wurde nicht immer erfasst. Überschreitungen bei Fixpreis-Anteilen wurden absorbiert.
Achtundzwanzig Punkte, sechs Kategorien, keine davon in der Stundensatz-Rechnung.
Der Neuaufbau — Projekt-GuV-Framework
Die Gründerin baute ihre Projekt-GuV an einem Wochenende auf. Sie wurde zum wichtigsten Dokument ihres Unternehmens. Das Framework lässt sich auf jedes Dienstleistungsunternehmen anwenden.
Eins — Projektumsatz. Monatlich abgerechnete Stunden × Kundenvertragssatz. Nicht Sales-Zusagen; tatsächlich abgerechnet.
Zwei — Direkte Entwicklerkosten, voll beladen. Gehalt + Steuern + Zusatzleistungen + Abschreibung der Ausrüstung + bezahlte Freizeit, geteilt durch Auslastungsstunden (nicht Kalenderstunden). Wenn ein Entwickler zu 65% der Zeit abrechenbar ist, betragen seine voll beladenen Stundenkosten Gehalt/(Stunden × 0,65).
Drei — Allokierte Projektmanagement-, Delivery-Management- und Recruiting-Kosten. Grober Anteil nach Projektgröße oder Umsatz. Muss nicht perfekt sein. Muss konsistent sein.
Vier — Tools und Lizenzen, die dem Projekt zurechenbar sind.
Fünf — Bench-Allokation. Gesamte Bench-Kosten für das Jahr, aufgeteilt auf aktive Projekte.
Sechs — Allokation interne Meetings und Prozesse. Prozentsatz der bezahlten Stunden, die in projektfremde Arbeit fließen, × allokierte Kosten.
Ergebnis — Echte Projektmarge. Für ihren wichtigsten Kunden: 14%. Für zwei kleinere Kunden: 21% und 8%. Für einen Kunden, den sie für ihren besten hielt: 3%.
Was sie mit der Wahrheit machte
Mit dem 3%-Kunden gab es ein Gespräch über eine Preiserhöhung. Es verlief gut; die Marge stieg auf 12%. Der 8%-Kunde hatte Probleme mit Scope-Disziplin (Over-Servicing), die behebbar waren; die Marge stieg auf 15%. Die Recruiting-Overhead-Kosten wurden neu verhandelt — statt Gebühren pro Neueinstellung gab es nun einen festen monatlichen Retainer. Interne Meetings wurden geprüft — drei wöchentlich wiederkehrende Meetings wurden gestrichen. Die Auslastung von zwei ihrer Senior-Entwickler stieg von 58% auf 72%, indem sie von Bench-lastiger interner Arbeit auf Kundenarbeit umgeschichtet wurden.
Die Gesamtmarge des Unternehmens stieg von scheinbaren 42% (fiktiv) auf reale 19% (vor dem Neuaufbau) auf reale 27% (sechs Monate später). Wichtiger als die Zahl: Sie wusste jetzt, welcher Kunde tatsächlich profitabel war, welcher die Bench-Zeit subventionierte und welcher sie im Stillen Geld kostete.
Das Framework — was zu erfassen ist
Sechs Zahlen, monatlich, pro Projekt:
- Echte abrechenbare Stunden (nicht zugesagte Stunden; tatsächliche)
- Voll beladene Entwicklerkosten pro Projekt
- Allokierter Management-Overhead (PM/DM/Recruiter/Gründerzeit als % des Monats)
- Bench-Allokation (Bench-Kosten dieses Monats × Umsatzanteil des Projekts)
- Echte Projektmarge (Umsatz − alles Obige)
- Auslastung pro Entwickler, separat von der Marge erfasst
Sechs Zahlen, ein Dashboard, monatliches Review mit dem Delivery Lead. Zwei Stunden im Monat, die verhindern, dass die Fiktion zurückkehrt.
📌 Möchten Sie sehen, ob Ihre Projekte wirklich so profitabel sind, wie es Ihre Stundensatz-Rechnung nahelegt? Schicken Sie uns drei Monate Abrechnungsdaten und die Kostenaufstellung Ihres Teams — wir erstellen die echte Projektmarge-Wasserfallgrafik und erklären sie Ihnen in 15 Minuten. [Fordern Sie Ihre kostenlose Finmap-Diagnose an →]
Häufig gestellte Fragen
Beides. Höhere Auslastung erhöht die voll beladene Marge direkt, weil sich die Entwicklerkosten auf mehr abrechenbare Stunden verteilen. Niedrigere Auslastung tötet die Marge lautlos.
Seine Zeit nach den tatsächlich für jedes Projekt geleisteten Stunden allokieren. Seine voll beladenen Kosten teilen sich im gleichen Verhältnis auf. Deshalb ist Zeiterfassung — auch leichtgewichtig — wichtig.
Gepoolt ist für kleinere Firmen (unter 30 Entwicklern) in Ordnung. Darüber ist pro Entwickler sauberer, weil Senior-Bench deutlich teurer ist als Junior-Bench.
Gleiche Rechnung, aber der Umsatz ist der monatlich verdiente Anteil (Vertragswert × % Fertigstellung). Verlustprojekte werden so viel früher sichtbar als in der Kassenbuchführung.
Die Alternative testen — ist das Projekt zu den aktuellen Sätzen profitabel genug, um es zu behalten? Ist die Marge negativ oder unter 10%, Scope-Reduzierung, Delivery-Effizienz oder einen geordneten Übergang prüfen.
Ihr Buchhalter erstellt eine GuV auf Unternehmensebene. Dies ist eine GuV auf Projektebene, die Allokationen erfordert, für die der Buchhalter normalerweise nicht die operativen Daten hat.
