# Change Request im Projekt: Ablauf, Vorlage, Bewertung

> Ein Change Request ist ein formaler Antrag, den vereinbarten Projektumfang zu ändern. Er wird schriftlich gestellt, vom Auftragnehmer nach Aufwand, Kosten, Termin und Risiko bewertet und von einer benannten Person freigegeben oder abgelehnt. Erst nach Freigabe wird umgesetzt. So bleibt sichtbar, warum Budget und Termin sich verschieben.

- URL: https://go-projects.de/projektsteuerung/change-request-projekt/
- Sprache: de
- Aktualisiert: 2026-10-19
- Herausgeber: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

„Können wir da noch schnell ein Feld für die Steuernummer ergänzen?“ Solche Sätze fallen in jedem Projekt, oft im Flur oder am Ende eines Termins. Einzeln sind sie harmlos. Ein Feld, eine Stunde, kein Problem. Zwanzig solcher Wünsche später ist das Budget um 15 Prozent überzogen, und niemand kann sagen, wann genau das passiert ist.

Ein Change Request ist kein bürokratisches Hindernis. Er ist die einzige Möglichkeit, nachträglich zu erklären, warum ein Projekt teurer wurde.

## Warum § 650b BGB bei Software nicht hilft

Viele Auftraggeber gehen davon aus, dass sie Änderungen einfach anordnen können. Im Baurecht stimmt das teilweise: [§ 650b BGB](https://www.gesetze-im-internet.de/bgb/__650b.html) gibt dem Besteller beim Bauvertrag ein Anordnungsrecht, wenn sich die Parteien nicht einigen. Diese Regel steht aber im Kapitel zum Bauvertrag. Für einen gewöhnlichen Werkvertrag über Software gilt sie nicht.

Das heißt: Ohne vertragliche Regelung braucht jede Änderung des vereinbarten Umfangs eine Einigung beider Seiten. Der Auftragnehmer kann ablehnen oder einen Preis verlangen, den du nicht zahlen willst. Deshalb gehört ein Änderungsverfahren in den Vertrag, bevor die erste Änderung auftaucht. Wie die Vertragsmodelle sich dabei unterscheiden, steht im Vergleich [Festpreis oder Time and Material](https://go-projects.de/schaetzung-und-budget/festpreis-oder-aufwand/).

## Musterformulierung für den Vertrag

Eine Änderungsklausel muss nicht kompliziert sein. Diese Formulierung deckt die wichtigsten Punkte ab und lässt sich an das eigene Projekt anpassen:

> Änderungen des vereinbarten Leistungsumfangs beantragen die Parteien schriftlich über das Change-Request-Formular. Der Auftragnehmer legt innerhalb von fünf Arbeitstagen eine Bewertung mit Aufwand, Vergütung, Auswirkungen auf Termine und Risiken vor. Die Bewertung selbst ist bis zu einem Aufwand von einem halben Personentag kostenfrei. Umgesetzt wird erst nach schriftlicher Freigabe durch die benannte Ansprechperson des Auftraggebers. Bis zur Entscheidung arbeitet der Auftragnehmer am vereinbarten Umfang weiter.

Der letzte Satz ist wichtiger, als er klingt. Ohne ihn kann ein offener Änderungsantrag das ganze Projekt blockieren, weil unklar ist, ob am alten oder neuen Stand gearbeitet werden soll. Auch die Frage, ob die Bewertung selbst kostet, sorgt erstaunlich oft für Streit. Bei Projekten mit größerem Volumen lohnt es sich, die Klausel von einer Anwältin prüfen zu lassen.

## Der Ablauf in sechs Schritten

**Ein Change Request vom Wunsch bis zur Umsetzung**

1. **Erfassen** Antragsteller beschreibt Änderung und Grund schriftlich im Formular.
2. **Einordnen** Projektleitung prüft: Präzisierung im Umfang oder echte Änderung?
3. **Bewerten** Auftragnehmer schätzt Aufwand, Kosten, Terminwirkung und Risiko, in der Regel innerhalb von fünf Arbeitstagen.
4. **Entscheiden** Benannte Person oder Gremium gibt frei, lehnt ab oder vertagt.
5. **Dokumentieren** Entscheidung im Änderungsprotokoll, Plan und Budget werden angepasst.
6. **Umsetzen** Erst jetzt beginnt die Arbeit, mit eigenen Akzeptanzkriterien.

Schritt zwei wird oft übersprungen, dabei entscheidet er über den Ton im Projekt. Nicht jede Rückfrage ist eine Änderung. Wenn im [Lastenheft](https://go-projects.de/projektplanung/lastenheft-software-vorlage/) „Export als CSV“ steht und offen ist, welches Trennzeichen, dann ist die Klärung Teil des Auftrags. Wenn plötzlich zusätzlich ein Excel-Export mit Formatierung gewünscht wird, ist es ein Change Request.

## Vorlage: das Formular

Ein Change-Request-Formular muss nicht lang sein. Diese Felder reichen für die meisten Projekte:

| Feld | Inhalt |
|---|---|
| Nummer und Datum | CR-014, 12.03. |
| Antragsteller | Name, Rolle |
| Beschreibung | Was soll sich ändern, in zwei bis vier Sätzen |
| Begründung | Warum, und was passiert, wenn wir es nicht tun |
| Betroffene Anforderungen | Verweis auf Nummern im Lastenheft oder Backlog |
| Priorität | Muss, Soll, Kann |
| Aufwand (vom Auftragnehmer) | Spanne in Personentagen |
| Kosten | Spanne in Euro |
| Terminwirkung | verschiebt Meilenstein X um Y Tage, oder keine |
| Risiken und Abhängigkeiten | zum Beispiel Tests, Datenmigration, Schulung |
| Alternative | günstigere Variante, falls vorhanden |
| Entscheidung | freigegeben, abgelehnt, vertagt, mit Datum und Unterschrift |

Das Feld „Alternative“ ist das wertvollste. Oft lässt sich ein Wunsch mit einem Bruchteil des Aufwands erfüllen, wenn jemand danach fragt.

## Bewertung mit Rechenbeispiel

Angenommen, der Vertrieb möchte im Kundenportal zusätzlich zur Lastschrift eine Zahlung per Kreditkarte. Der Auftragnehmer bewertet:

**Bewertung CR-014: Kreditkartenzahlung im Kundenportal (Beispiel)**

- Anbindung Zahlungsanbieter: 4 bis 7 PT
- Anpassung Rechnungslogik: 2 bis 3 PT
- Tests inkl. Fehlerfälle: 2 bis 3 PT
- Summe Aufwand: 8 bis 13 PT
- **Kosten: 5.760 bis 9.360 €**

Tagessatz 720 € angenommen. Die Spanne stammt aus einer Dreipunktschätzung des Auftragnehmers.

Dazu kommt die Terminwirkung: Ohne zusätzliches Personal verschiebt sich der Pilot um etwa zwei Wochen. Mit dieser Information kann die Fachseite entscheiden. Vielleicht ist die Kreditkarte wichtig genug. Vielleicht reicht sie im zweiten Release. Vielleicht fliegt dafür eine andere Funktion aus dem Umfang, die nach [MoSCoW](https://go-projects.de/projektplanung/moscow-priorisierung/) nur ein Kann war.

Ohne Bewertung wäre die Entscheidung im Flur gefallen: „Klar, machen wir.“

## Kleine Änderungen ohne Bürokratie

Wenn jede Kleinigkeit einen formalen Antrag braucht, wird der Prozess umgangen. Bewährt hat sich eine Bagatellgrenze. Zum Beispiel: Änderungen unter einem Personentag darf der Product Owner direkt freigeben, solange die Summe aller Bagatelländerungen ein vereinbartes Kontingent nicht überschreitet, etwa fünf Prozent des Budgets. Alles darüber läuft über das volle Verfahren.

Das Kontingent wird sichtbar geführt. Ist es aufgebraucht, braucht auch die kleinste Änderung einen regulären Antrag.

## Das Änderungsprotokoll als Frühwarnsystem

Jeder Change Request, auch der abgelehnte, wird in einer einfachen Liste festgehalten: Nummer, Titel, Aufwand, Entscheidung, Datum. Diese Liste ist mehr als Dokumentation. Sie zeigt Muster.

Kommen auffällig viele Änderungen aus einer Abteilung, war deren Bedarf im Lastenheft unterrepräsentiert. Häufen sich Änderungen nach jeder Präsentation, sehen die Nutzer die Software zu spät. Und wenn die Summe freigegebener Änderungen 20 Prozent des Ursprungsbudgets erreicht, ist es eigentlich ein anderes Projekt, und die Planung sollte neu aufgesetzt werden. Schleichend wachsender Umfang gehört zu den häufigsten Gründen, [warum IT-Projekte scheitern](https://go-projects.de/projektsteuerung/warum-it-projekte-scheitern/).

## Agil und Change Request: kein Widerspruch

Agile Projekte begrüßen Änderungen ausdrücklich. Das ändert aber nichts an der Rechnung. Bei festem Budget verdrängt jede neue Story eine andere. Der formale Antrag wird dann zur Tauschentscheidung im Backlog: Was kommt rein, was fällt raus, wer hat entschieden?

Teams, die das sauber dokumentieren, haben bei der Abnahme ein klares Bild davon, was geliefert werden sollte. Teams, die das nicht tun, streiten am Ende über einen Umfang, den niemand mehr rekonstruieren kann.

Wer ein Projekt mit externem Partner aufsetzt, sollte das Änderungsverfahren schon im ersten Gespräch ansprechen. Bei Studios wie [OnlineBuilders](https://onlinebuilders.biz/how-we-work) gehört die Frage, wie mit neuen Anforderungen umgegangen wird, zur Projektvorbereitung.

Nächster Schritt: Leg heute eine Tabelle mit den Spalten Nummer, Titel, Aufwand, Entscheidung und Datum an und trag rückwirkend alle Änderungen der letzten vier Wochen ein. Die Summe wird dich vermutlich überraschen.

## Häufige Fragen

### Ist jede Änderung ein Change Request?

Nein. Präzisierungen innerhalb des vereinbarten Umfangs sind normale Projektarbeit. Ein Change Request liegt vor, wenn sich Umfang, Qualität, Termin oder Budget gegenüber dem Vertrag ändern sollen.

### Muss der Auftragnehmer jede Änderung umsetzen?

Im Werkvertrag über Software grundsätzlich nicht ohne Einigung. Ein einseitiges Anordnungsrecht wie beim Bauvertrag nach § 650b BGB gibt es dort nicht. Deshalb sollte der Vertrag ein Verfahren für Änderungen regeln.

### Wer darf einen Change Request freigeben?

Eine im Vertrag oder Projekthandbuch benannte Person mit Budgetvollmacht. Bei größeren Projekten entscheidet ein Gremium, oft Change Control Board genannt. Wichtig ist, dass niemand aus dem Entwicklungsteam auf Zuruf Änderungen zusagt.

### Wie gehen agile Teams mit Änderungen um?

Änderungen sind dort normal und landen im Backlog. Bei festem Budget gilt aber dieselbe Logik: Was neu hineinkommt, verdrängt etwas anderes. Der formale Change Request wird dann zur Tauschentscheidung des Product Owners.

Foto: Nicolas Bouliane, CC BY-SA 4.0 (https://commons.wikimedia.org/wiki/File:Pen_revisions_on_a_paper_document.jpg)