Kein IT-Projekt läuft exakt so ab, wie es geplant wurde. Das ist kein Qualitätsproblem, sondern Realität im Projektgeschäft. Work Packages werden neu bewertet, Anforderungen ändern sich während der Implementierung, der Kunde erweitert den Scope. Was dabei entsteht, ist ein Change Request.
Das Wichtigste in Kürze:
- Mehraufwand wird nicht dem richtigen Projektbudget zugeordnet
- Change Requests bleiben abrechnungsrelevant, werden aber nicht nachgewiesen
- Festpreisprojekte geraten strukturell unter Margendruck
- Projektleiter können keine belastbare Change-Request-Abrechnung gegenüber dem Kunden erstellen
- Folgeprojekte werden auf Basis falscher Aufwandsdaten kalkuliert
Was ein Change Request kaufmännisch bedeutet
Ein Change Request (CR) ist eine formelle Anforderungsänderung innerhalb eines laufenden Projekts. Er entsteht, wenn der vereinbarte Scope nicht mehr mit dem tatsächlichen Lieferumfang übereinstimmt. Im IT-Projektgeschäft ist der CR der zentrale Mechanismus, um ungeplante Mehrleistung zu dokumentieren, zu bewerten und abzurechnen.
Rechtlich und kaufmännisch ist ein CR eine eigenständige Vereinbarung zwischen Auftragnehmer und Auftraggeber. Er muss schriftlich festgehalten, inhaltlich bewertet und bei Festpreisverträgen explizit genehmigt werden, bevor die Leistung erbracht wird. Ohne diesen Nachweis hat der Dienstleister im Streitfall keine Grundlage, Mehraufwand in Rechnung zu stellen.
Change Requests im T&M-Modell
Bei Time-and-Material-Verträgen (T&M) sind Change Requests kaufmännisch unkritischer, weil jede Stunde ohnehin erfasst und abgerechnet wird. Trotzdem ist die Zuordnung zu einer CR-Kategorie sinnvoll: für das interne Projektcontrolling, für Kundenberichte und für die spätere Projektnachkalkulation.
Change Requests im Festpreismodell
Hier liegt das eigentliche wirtschaftliche Risiko. Bei Festpreisverträgen ist der Scope vertraglich fixiert. Jede Leistung außerhalb dieses Scopes muss als CR dokumentiert, genehmigt und separat abgerechnet werden. Fehlt dieser Prozess, trägt der Dienstleister die Kosten. Laut einer Studie des PMI ist unkontrollierter Scope Creep einer der häufigsten Gründe für Budgetüberschreitungen in IT-Projekten.
Wo die Projektzeiterfassung bei Change Requests versagt
Viele IT-Dienstleister erfassen ihre Projektzeiten. Aber die Erfassung allein reicht nicht. Entscheidend ist, wie granular und wie strukturiert diese Erfassung erfolgt.
Das Stunden-Pool-Problem
In der Praxis werden Zeiten häufig auf übergeordnete Projektnummern gebucht. Change Requests tauchen in dieser Logik nicht als separate Einträge auf. Sie fließen in den allgemeinen Stunden-Pool, werden mit dem ursprünglichen Projektbudget verrechnet und verschwinden rechnerisch in einer Abweichung, die der Projektleiter erst beim nächsten Statusgespräch bemerkt. Bis dahin hat das Team vielleicht 30 bis 50 Stunden Mehraufwand erbracht, für die keine separate Abrechnungsgrundlage besteht.
Das Excel-Dokumentationsproblem
Viele Projektleiter dokumentieren Change Requests in separaten Excel-Tabellen oder Mailverläufen. Diese Informationen sind strukturell getrennt von den tatsächlichen Zeitdaten. Das Ergebnis: Es gibt eine CR-Liste irgendwo, und es gibt Stundenbuchungen irgendwo anders. Wenn dann die Rechnung gestellt werden soll, fehlt der saubere Nachweis: Wer hat wann wie viele Stunden auf welchen Change Request gebucht?
Das Cutover-Problem
In IT-Implementierungsprojekten entstehen rund um Cutover und Hypercare besonders viele unkontrollierte Mehraufwände. Der Zeitdruck ist hoch, die Kommunikation läuft über viele Kanäle, und strukturierte Erfassung fällt weg. Stunden, die in dieser Phase entstehen, sind häufig die wirtschaftlich kritischsten, weil sie außerhalb des ursprünglichen Scopes liegen und selten vollständig nachgewiesen werden können.
Projektzeiterfassung mit Change-Request-Logik: So sieht Steuerung aus
Der Unterschied zwischen Dokumentation und Steuerung liegt in der Struktur der Zeiterfassung. Eine belastbare Projektzeiterfassung im CR-Kontext braucht vier Ebenen:
1. CR-spezifische Buchungsstruktur
Jeder genehmigte Change Request erhält eine eigene Erfassungskategorie. Stunden werden dem Projekt und explizit dem CR zugeordnet. Das schafft eine saubere Trennung zwischen vertraglich vereinbartem Scope und Mehrleistung.
2. Soll-Ist-Abgleich auf CR-Ebene
Sobald ein CR einen definierten Stundenrahmen hat, kann dieser gegen tatsächlich gebuchte Stunden gestellt werden. Projektleiter erkennen frühzeitig, wenn ein CR über Budget läuft, und können gegensteuern oder eskalieren, bevor das Gesamtprojektbudget betroffen ist.
3. Abrechnungsreife Nachweise
Zeiteinträge mit CR-Zuordnung sind direkt exportierbar als Nachweis gegenüber dem Kunden. Kein manuelles Zusammenführen aus Excel und Mailverläufen. Die Rechnung entsteht aus einer einzigen Datenquelle.
4. Historische Kalkulationsgrundlage
Change Requests aus abgeschlossenen Projekten zeigen, welche Scopeänderungen wie viel Aufwand erzeugt haben. Diese Daten sind die Grundlage für realistischere Kalkulationen in Folgeprojekten.
Praxisbeispiel: IT-Consulting mit parallelen Festpreisprojekten
Ein IT-Dienstleister mit 80 Mitarbeitenden betreibt sieben parallele ERP-Implementierungsprojekte. Jedes Projekt hat einen Festpreis und läuft über sechs bis zwölf Monate. Im Durchschnitt entstehen pro Projekt drei bis fünf Change Requests, die nachverhandelt werden müssen.
Ohne strukturierte Projektzeiterfassung auf CR-Ebene sammelt der Projektleiter am Monatsende manuell Stundenzettel, gleicht diese mit seiner CR-Liste ab und erstellt den Nachweis für den Kunden in Excel. Dieser Prozess dauert pro Projekt und Monat zwei bis drei Stunden. Fehler entstehen, Stunden fehlen, Kunden zweifeln an den Nachweisen.
Mit CR-spezifischer Buchungsstruktur in ZEP Compact buchen Teammitglieder Zeiten direkt auf den genehmigten CR. Der Projektleiter sieht in Echtzeit, wie viele Stunden welchem CR zugeordnet sind, ob der Rahmen überschritten wird, und kann den Abrechnungsnachweis mit wenigen Klicks exportieren.
{{blog-cta}}
Mehraufwand dokumentieren: Von der Stunde zur Rechnung
Die wirtschaftliche Wirkung strukturierter Projektzeiterfassung bei Change Requests zeigt sich im systematischen Effekt über alle Projekte hinweg. Wenn ein IT-Consulting mit 50 Beratern im Durchschnitt fünf Stunden pro Projekt und Monat an Mehraufwand nicht nachweisen kann, verliert es bei einem Stundensatz von 120 Euro und zehn aktiven Projekten pro Monat 6.000 Euro an nicht abrechenbaren Leistungen. Im Jahr macht das 72.000 Euro, ohne einen einzigen Berater mehr einzustellen.
Warum Projektcontrolling im IT-Projekt früher ansetzen muss
Viele Unternehmen betreiben Projektcontrolling rückwirkend: nach Projektabschluss oder nach Rechnungsstellung. Zu diesem Zeitpunkt lässt sich nichts mehr korrigieren. Margen, die in CR-Stunden ohne Zuordnung verschwunden sind, kommen nicht zurück.
Projektcontrolling auf CR-Ebene bedeutet: Abweichungen sichtbar machen, bevor sie wirtschaftlich kritisch werden. ZEP Compact bietet genau diesen Controlling-Layer: Aufgaben, Zeitbuchungen, Ressourcenplanung und Projektcontrolling auf einer Datenbasis. Change Requests können als separate Work Packages abgebildet werden, Soll-Ist-Vergleiche laufen automatisch, und Projektleiter sehen in Echtzeit, wo Budget läuft.
Wenn Change Requests zum Symptom werden
Ein Change Request ist kein Qualitätsmangel. Er zeigt, dass ein Projekt lebt. Die Frage ist, ob das Unternehmen strukturell in der Lage ist, mit dieser Dynamik wirtschaftlich umzugehen. Projektdienstleister, bei denen Change Requests systematisch zu Margenverlusten führen, haben meistens ein tiefergehendes Steuerungsproblem.
ZEP Professional schließt den Kreis von der CR-Buchung bis zur Abrechnung: Rechnungsstellung und Controlling liegen auf einer Datenbasis. Project-to-Bill ohne Medienbruch ist kein Ziel, sondern der Standardprozess.
Fazit
Wer Change Requests wirtschaftlich absichern will, braucht drei Dinge: eine CR-spezifische Buchungsstruktur in der Projektzeiterfassung, einen Soll-Ist-Abgleich in Echtzeit auf CR-Ebene und abrechnungsreife Nachweise ohne manuelle Rekonstruktion.
- Prüfen Sie, ob jeder Change Request eine eigene Buchungskategorie in Ihrer Projektzeiterfassung hat.
- Stellen Sie sicher, dass Ihr Projektleiter täglich sehen kann, wie viele Stunden welchem CR zugeordnet sind.
- Testen Sie, ob ein Abrechnungsnachweis für einen CR heute ohne manuelle Rekonstruktion möglich ist.
FAQ
Wie dokumentiere ich einen Change Request rechtssicher?
Ein Change Request muss schriftlich festgehalten werden, bevor die Leistung erbracht wird. Er sollte den geänderten Scope, den kalkulierten Mehraufwand in Stunden, den vereinbarten Preis und die Genehmigung des Kunden enthalten. Im Streitfall ist dieser Nachweis die einzige Grundlage, Mehrleistung in Rechnung zu stellen.
Was ist der Unterschied zwischen T&M-Abrechnung und Festpreisabrechnung bei Change Requests?
Bei T&M-Verträgen werden alle geleisteten Stunden abgerechnet, Change Requests sind daher abrechnungsrelevant, aber weniger kritisch für die Marge. Bei Festpreisverträgen ist jeder Mehraufwand außerhalb des ursprünglichen Scopes nicht automatisch abrechnungsfähig. Ohne schriftlich genehmigten CR trägt der Dienstleister die Kosten selbst.
Wie erkenne ich, ob ein Change Request meinen Festpreis gefährdet?
Der Frühwarnindikator ist der Soll-Ist-Vergleich auf Projektebene: Wenn tatsächlich gebuchte Stunden schneller steigen als der Projektfortschritt, entstehen entweder interne Ineffizienzen oder nicht abgegrenzte Mehrleistungen. Projektcontrolling auf CR-Ebene zeigt, welcher Anteil auf genehmigte CRs entfällt und welcher Teil ungeplant ist.
Warum reicht Excel für die Change-Request-Dokumentation nicht aus?
Excel trennt CR-Listen strukturell von den tatsächlichen Stundenbuchungen. Wenn beide Systeme nicht verbunden sind, entsteht bei jeder Abrechnung manueller Aufwand, Fehleranfälligkeit und Datenverlust. Kundenbestreitungen sind schwerer zu entkräften, weil der Nachweis rekonstruiert werden muss und keine sauber protokollierte Zeitreihe existiert.
Wie bilde ich Change Requests in der Projektzeiterfassung strukturell ab?
Change Requests sollten als separate Work Packages oder Buchungskategorien innerhalb des Projekts abgebildet werden. Jede gebuchte Stunde wird einem spezifischen CR zugeordnet. Das ermöglicht Soll-Ist-Vergleiche auf CR-Ebene, automatische Abrechnungsnachweise und historische Auswertungen für die Projektkalkulationshistorie.
Ab wann sollte ein IT-Dienstleister eine spezialisierte Software für Projektzeiterfassung einsetzen?
Sobald mehr als drei aktive Kundenprojekte parallel laufen, regelmäßig Change Requests entstehen und Projektleiter mehr als zwei Stunden pro Monat damit verbringen, Zeitdaten für Kundenberichte manuell zusammenzuführen, übersteigt der operative Aufwand den Nutzen von Excel-Lösungen. Der wirtschaftliche Kipppunkt liegt typischerweise früher als erwartet, weil nicht abrechnungsfähige Stunden kaum sichtbar sind.
