Projektmarge sichern: Stille Verlustbringer früh erkennen

Projekte verlieren Geld, bevor es jemand bemerkt. In Projektdienstleistungsunternehmen ohne durchgängige Datenbasis sind strukturelle Verlustbringer in der Regel erst nach dem Monatsabschluss sichtbar. Bis dahin sind Budget, Zeit und Handlungsspielraum bereits verbraucht.

Das Tückische ist, dass diese Projekte im laufenden Betrieb oft unauffällig wirken. Aufwand wird erfasst, das Projekt ist aktiv, der Kundenvertrag läuft. Erst die Gesamtbetrachtung am Monatsende zeigt, dass Stunden und Kosten die abrechenbare Leistung übersteigen.

Was auf Projektebene passiert:

• Stunden akkumulieren ohne Abgleich mit dem Budgetstatus
• Change Requests verändern den Scope, aber nicht die Kalkulation
• Nicht abrechenbare Mehrarbeit wird intern abgefedert
• Projektleiter sehen Aufwand, aber keine Margenperspektive
• Finance, Projektleitung und Geschäftsführung arbeiten mit unterschiedlichen Zahlenständen

Die wirtschaftliche Konsequenz ist konkret messbar: Ein Festpreisprojekt mit 150.000 Euro Volumen und 15 % unerkannter Überschreitung kostet 22.500 Euro Marge. Bei mehreren parallelen Projekten summiert sich das schnell zu einem Ergebnis, das die Geschäftsführung erst im Jahresabschluss überrascht.

Warum Projekte Geld verlieren, bevor jemand es sieht

Die strukturelle Ursache liegt in der Abfolge kleiner Entscheidungen, die jede für sich vertretbar wirken: eine zusätzliche Abstimmungsrunde mit dem Kunden, ein Bugfix, der nicht als Change Request erfasst wird, eine Ressource, die zwei Tage länger eingesetzt wird als geplant.

Jeder dieser Punkte ist für sich genommen marginal. Über ein Projekt mit 20 Wochen Laufzeit summiert sich das zu einer Budgetüberschreitung von 15 bis 25 %, die zum Zeitpunkt der Abrechnung bereits feststeht. Ohne laufende Steuerungsdaten wird diese Entwicklung erst erkannt, wenn keine reaktionsfähige Handlungsoption mehr besteht.

Die fünf häufigsten stillen Margenkiller

1. Scope Creep ohne Eskalation: Kundenwünsche außerhalb des vertraglich vereinbarten Scope werden pragmatisch umgesetzt, aber nicht als Nachtragsleistung abgegrenzt. Das ist die häufigste Ursache für Budgetüberschreitungen in IT- und Consulting-Projekten. Laut einer Analyse des Project Management Institute überziehen Projekte mit ungesteuertem Scope Creep ihr Budget im Schnitt um über 20 %.
2. Fehlkalkulation in der Angebotsphase: Wenn historische Projektdaten nicht strukturiert vorliegen, basiert jede neue Kalkulation auf Erfahrungswerten und Schätzungen. Wer nicht weiß, dass Hypercare-Phasen in vergleichbaren Projekten regelmäßig 30 % mehr Aufwand erzeugen als geplant, baut diesen Puffer nicht ein.
3. Unbezahlte Mehrarbeit ohne Abgrenzung: Überstunden, die nicht auf den richtigen Buchungstyp gebucht werden, verschwinden in der internen Leistungserbringung. Das Projekt sieht profitabel aus, weil Mehrstunden nicht als Projektkosten sichtbar werden.
4. Falsche Ressourcenzuweisung: Ein Senior-Consultant, der Aufgaben übernimmt, die ein Junior-Consultant leisten könnte, erzeugt strukturell höhere interne Kosten. Wenn Stundensätze nicht differenziert gepflegt werden, bleibt dieser Effekt unsichtbar.
5. Zu späte Nachsteuerung bei Budgetabweichungen: Ohne wöchentliche Budget-Burn-Analyse werden Abweichungen erst im letzten Projektdrittel sichtbar. Zu diesem Zeitpunkt sind Spielräume für Scope-Anpassungen, Ressourcen-Umplanung oder Kundenverhandlungen minimal.

Frühwarnsignale: Woran erkennt man ein kippendes Projekt?

Drei Datenpunkte in Kombination zeigen, dass ein Projekt in die falsche Richtung läuft:

• Budget-Burn vs. Fertigstellungsgrad: Wenn 60 % des Budgets verbraucht sind, aber nur 40 % des definierten Scope abgeschlossen wurden, ist das eine klare Warnung. Diese Diskrepanz ist mit manueller Excel-Auswertung selten zeitnah erkennbar.
• Stundenmix-Veränderung: Wenn der Anteil nicht abrechenbarer Stunden über mehrere Wochen zunimmt, deutet das auf interne Nacharbeiten, Scope-Diskussionen oder Qualitätsprobleme hin.
• Abweichende Ressourcenstruktur: Wenn erfahrenere und damit teurere Ressourcen eingesetzt werden als in der Kalkulation vorgesehen, steigen die internen Kosten, ohne dass dies automatisch auffällt.

Warum diese Signale in der Praxis zu spät ankommen

Projektleiter kennen den Zusammenhang zwischen Budget-Burn und Fertigstellungsgrad in der Regel gut. Das Problem ist die Datenlage: Stunden liegen in einem Tool, Budgets in Excel, Rechnungen in einem dritten System. Bis diese drei Quellen manuell zusammengeführt sind, ist die Information veraltet.

Hinzu kommt ein zweites, oft übersehenes Problem: Selbst wenn die Konsolidierung gelingt, fehlt häufig der Vergleichswert. Ohne historische Projektdaten aus vergleichbaren Mandaten lässt sich schwer beurteilen, ob 60 % Budgetverbrauch bei 40 % Fertigstellungsgrad in dieser Projektphase ungewöhnlich ist oder im normalen Rahmen liegt. Genau diese Referenzwerte entstehen erst, wenn Projektdaten über mehrere Projekte hinweg strukturiert und vergleichbar vorliegen.

Genau an dieser Stelle entsteht der Unterschied zwischen einem Unternehmen, das reagiert, und einem, das steuert.

Umsetzung im Unternehmensalltag: Warum Excel-Controlling an seine Grenzen stößt

In der Theorie ist die Lösung einfach: Budget-Burn wöchentlich prüfen, Scope-Änderungen sofort dokumentieren, Ressourceneinsatz laufend abgleichen. In der Praxis scheitert das an drei Realitäten des Arbeitsalltags.

Realität 1: Projektleiter haben keine Zeit für manuelle Konsolidierung

Ein Projektleiter mit vier bis sechs parallelen Mandaten kann nicht wöchentlich Stunden aus der Zeiterfassung exportieren, mit dem Budget in einer separaten Tabelle abgleichen und daraus eine Prognose ableiten. Diese Aufgabe wird de facto bestenfalls monatlich erledigt, oft erst, wenn die Geschäftsführung nach Zahlen fragt.

Das Ergebnis: Projektleiter sehen zwar Aufwand, aber keine Margenperspektive. Sie verwalten Stunden, ohne die wirtschaftliche Auswirkung dieser Stunden in Echtzeit zu kennen.

Realität 2: Change Requests werden pragmatisch statt systematisch behandelt

Wenn ein Kunde während eines laufenden Projekts eine zusätzliche Anforderung stellt, ist die pragmatische Reaktion, sie einfach umzusetzen. Ein separates Change-Request-Formular auszufüllen, eine neue Kalkulation zu erstellen und den Kunden formal zu informieren, kostet Zeit und wirkt im Tagesgeschäft wie unnötige Bürokratie.

Genau diese Pragmatik ist der Grund, warum Scope Creep so schwer zu bekämpfen ist. Die wirksame Lösung besteht darin, Change Requests direkt im Arbeitsablauf der Zeiterfassung abzubilden, sodass Mehraufwand automatisch sichtbar wird, ohne zusätzlichen Verwaltungsschritt und ohne Projektleiter zu mehr Formalismus zu verpflichten.

Realität 3: Finance, Projektleitung und Geschäftsführung sehen unterschiedliche Zahlen

Das größte strukturelle Problem ist die Datenfragmentierung. Die Projektleitung sieht Stunden. Finance sieht Rechnungen. Die Geschäftsführung sieht das Monatsergebnis. Niemand sieht die Projektmarge in Echtzeit, weil die Verbindung zwischen geleisteten Stunden, entstehenden Kosten und abrechenbarer Leistung nicht systemisch abgebildet ist.

Ein typisches Beispiel aus dem IT-Consulting

Ein IT-Dienstleister mit 80 Mitarbeitenden betreut ein Transformationsprojekt mit fünf parallelen Work Packages. In Woche zwölf von zwanzig zeigt die Zeiterfassung 65 % Budgetverbrauch, das Projektmanagement-Tool zeigt 45 % Fertigstellungsgrad. Beide Zahlen liegen in getrennten Systemen und werden nicht automatisch miteinander abgeglichen.

Der Projektleiter bemerkt die Diskrepanz erst, als die kaufmännische Leitung im Rahmen der Monatsauswertung nachfragt, warum das Projekt so viel Budget verbraucht. Zu diesem Zeitpunkt sind acht Wochen Laufzeit verstrichen, in denen eine frühzeitige Eskalation zum Kunden, eine Anpassung des Ressourceneinsatzes oder eine Nachverhandlung des Scopes möglich gewesen wäre. Stattdessen bleibt nur noch die Möglichkeit, den Verlust am Projektende zu dokumentieren.

Dieses Muster wiederholt sich in Management-Beratungen mit hoher Auslastung über mehrere Mandate ebenso wie in Ingenieurbüros mit langlaufenden, meilensteinbasierten Projekten. Die Branchen unterscheiden sich, das strukturelle Problem nicht: Steuerungsrelevante Daten liegen vor, aber nicht zusammengeführt.

{{blog-cta}}

Wie ZEP Professional diese drei Realitäten auflöst

Genau hier setzt ZEP Professional als Betriebssystem für Projektdienstleister an. Statt Projektzeit, Budget, Abrechnung und Forecast in getrennten Systemen zu pflegen, führt ZEP Professional diese Ebenen auf einer durchgängigen Datenbasis zusammen, von der ersten Zeitbuchung bis zur Rechnung.

Für die Projektleitung bedeutet das: Budget-Burn-Rate, Billability und Soll-Ist-Abweichung stehen tagesaktuell zur Verfügung, ohne dass jemand Stunden manuell exportiert oder Tabellen abgleicht. Die Steuerungsdaten entstehen automatisch aus der laufenden Projektzeiterfassung.

Für Change Requests bedeutet das: Zusätzlicher Aufwand wird direkt im Projekt erfasst und einem eigenen Buchungstyp zugeordnet. Scope-Erweiterungen werden dadurch sichtbar, bevor sie sich unbemerkt in der Gesamtstundenzahl verlieren, ohne dass die Projektleitung einen separaten Verwaltungsprozess durchlaufen muss.

Für Finance und Geschäftsführung bedeutet das: Projektmarge, Forecast und Rechnungsstellung basieren auf denselben Daten wie die Zeiterfassung der Projektteams. Der klassische Bruch zwischen operativer Leistung und kaufmännischer Auswertung, der sogenannte Medienbruch, entfällt. Das ist der Kern des Project-to-Bill-Ansatzes, den ZEP Professional als durchgängigen Prozess abbildet: vom Angebot über die Leistungserbringung bis zur Rechnung, ohne dass Daten zwischen Systemen manuell übertragen werden müssen.

Damit wird ZEP Professional zur zentralen Steuerungsebene, die Compact-Funktionen wie Ressourcenplanung und Projektcontrolling um Angebotswesen, Rechnungswesen und Forecasting erweitert. Für Unternehmen, die bereits mit Festpreisprojekten, Change Requests und mehreren Auftraggebern gleichzeitig arbeiten, ist das der Unterschied zwischen einer Software, die Daten sammelt, und einer Plattform, die das Projektgeschäft tatsächlich steuerbar macht.

Vom Frühwarnsignal zur wirtschaftlichen Entscheidung

Ein Frühwarnsignal allein sichert noch keine Marge. Entscheidend ist, was daraus folgt: Kann die Projektleitung sofort erkennen, welches Arbeitspaket die Abweichung verursacht? Lässt sich der zusätzliche Aufwand direkt einem Change Request zuordnen und dem Kunden nachvollziehbar in Rechnung stellen? Und lässt sich aus dieser Erkenntnis eine belastbare Prognose für die verbleibende Projektlaufzeit ableiten?

In ZEP Professional hängen diese drei Schritte zusammen, weil sie auf denselben Projektdaten basieren. Die Budgetabweichung eines Arbeitspakets führt direkt zur betroffenen Ressource und zum betroffenen Zeitraum. Die Zuordnung zu einem Change Request macht den Mehraufwand abrechenbar, statt ihn stillschweigend intern zu absorbieren. Und die aktualisierte Prognose fließt automatisch in das laufende Forecasting ein, sodass Finance und Geschäftsführung nicht auf den nächsten Monatsabschluss warten müssen, um die wirtschaftliche Entwicklung eines Projekts einzuschätzen.

Für Projektleiter bedeutet das weniger manuelle Auswertung. Für Finance bedeutet das eine Rechnungsstellung, die auf denselben Daten basiert wie die operative Leistung. Für die Geschäftsführung bedeutet das eine Forecast-Qualität, die strukturell aus dem System entsteht, statt von der Disziplin einzelner Projektleiter bei der Excel-Pflege abzuhängen.

Gesundheitscheck für Ihr Projekt

Ein strukturiertes Verfahren, das wöchentlich für jedes aktive Kundenprojekt durchgeführt werden sollte:

Wirtschaftliche Gesundheit:

• Budget-Burn vs. Fertigstellungsgrad: Verhältnis im grünen Bereich?
• Abrechenbare Stunden vs. Gesamtstunden: Billability im Zielkorridor?
• Prognostiziertes Abschlussdatum: Liegt das innerhalb des Budgets?

Scope-Gesundheit:

• Gibt es offene Change Requests, die noch nicht abgegrenzt sind?
• Wurden in der letzten Woche Leistungen erbracht, die außerhalb des vereinbarten Scope liegen?
• Ist der Kunde über den aktuellen Scope-Status informiert?

Ressourcengesundheit:

• Stimmt der aktuelle Ressourceneinsatz mit der ursprünglichen Planung überein?
• Gibt es Überauslastungen, die zu Qualitätsproblemen führen könnten?
• Sind Engpässe für die nächsten vier Wochen erkennbar?

Wer diese neun Fragen für jedes Projekt beantworten kann, hat Steuerungsfähigkeit. Wer sie nicht beantworten kann, steuert reaktiv. In ZEP Professional lassen sich diese neun Punkte direkt aus den vorhandenen Projekt- und Zeitdaten ableiten, ohne separaten Auswertungsaufwand.

Wann sich systematische Margensteuerung wirtschaftlich rechnet

Die Entscheidung für ein System wie ZEP Professional fällt selten, weil jemand die Zusammenhänge zwischen Scope Creep, Billability und Marge nicht versteht. Sie fällt, weil die tägliche Umsetzung dieser Steuerungslogik ohne System zu aufwendig, zu fehleranfällig oder zu teuer ist.

Typische Auslöser, an denen Projektdienstleister diesen Punkt erreichen:

• Wachsende Projektanzahl: Ab einer bestimmten Anzahl paralleler Projekte wird manuelle Konsolidierung schlicht nicht mehr leistbar. Die Steuerungsaufgabe wächst schneller als die verfügbare Zeit der Projektleitung.
• Margendruck bei wachsendem Umsatz: Wenn der Umsatz steigt, die Marge aber stagniert oder sinkt, ist das ein direktes Signal dafür, dass Projekte unwirtschaftlich laufen, ohne dass es jemand rechtzeitig bemerkt.
• Kundenforderung nach belastbaren Nachweisen: Wenn Auftraggeber detaillierte Leistungsnachweise oder transparente Abrechnung verlangen, reicht eine Excel-Tabelle als Grundlage nicht mehr aus.
• Tool-Wildwuchs als Managementthema: Wenn Zeiterfassung, Projektmanagement, Angebotswesen und Rechnungsstellung in getrennten Systemen liegen, wird die Konsolidierung dieser Systeme irgendwann zur strategischen Entscheidung der Geschäftsführung.
• Bedarf an belastbarem Forecast: Sobald Finance oder Geschäftsführung zusätzlich zur Frage, wie ein Projekt gelaufen ist, wissen wollen, wie es voraussichtlich laufen wird, reicht rückblickendes Reporting nicht mehr aus.

In all diesen Situationen ist ZEP Professional keine zusätzliche Software neben der bestehenden Toolwelt, sondern der Ersatz für die verstreuten Einzellösungen: eine Datenbasis statt fünf Toolbrüche, Steuern statt nur Dokumentieren. Wer heute mit ZEP Compact bereits Projektzeit, Ressourcenplanung und Controlling zusammengeführt hat, findet in Professional die konsequente Erweiterung um Angebotswesen, Rechnungswesen und Forecasting, also die Schritte, die aus Projektcontrolling einen vollständigen Project-to-Bill-Prozess machen.

Fazit

Projektmarge zu sichern erfordert keine zusätzliche Controller-Stelle. Es erfordert drei Dinge:

1. Zeiterfassung mit wirtschaftlicher Buchungslogik: Abrechenbar, nicht abrechenbar, intern, Change Request. Ohne diese Differenzierung gibt es keine Margenperspektive.
2. Wöchentliche Budget-Burn-Analyse: Nicht monatlich. Wöchentlich. Nur so bleiben Handlungsspielräume erhalten.
3. Eine durchgängige Datenbasis statt getrennter Systeme: Solange Stunden, Budget und Rechnung in unterschiedlichen Tools liegen, bleibt jede Analyse eine nachträgliche Rekonstruktion statt einer laufenden Steuerung.

ZEP Professional bildet genau diese drei Punkte als Betriebssystem für Projektdienstleister ab: von der Zeitbuchung über die Budgetkontrolle bis zur Rechnung, durchgängig verbunden, ohne Medienbruch. Für IT-Consultings, Beratungen und Ingenieurbüros, die ihre Marge sichern wollen, bevor Projekte eskalieren, ist das der Unterschied zwischen Nachkalkulation und echter Steuerung.