9. März 2026
Änderungslogiken in IT-Projekten: Warum Vorgehensmodell und Vergaberecht zusammen gedacht werden müssen
Veränderungen gehören zu IT-Projekten. Auch wenn sie in der Praxis oft als Störung empfunden werden, sind sie in komplexen Systementwicklungen unvermeidlich. Projekte entwickeln sich weiter, Anforderungen werden präzisiert, Prioritäten verschieben sich.
Flexibilität ist daher kein optionaler Zusatz, sondern eine grundlegende Voraussetzung dafür, dass IT-Projekte überhaupt erfolgreich umgesetzt werden können.
1. Vorgehensmodell und Vergaberecht: zwei Ebenen der Änderungssteuerung
Wie Änderungen in einem Projekt entstehen und verarbeitet werden, hängt zunächst vom gewählten Vorgehensmodell ab. Das Vergaberecht setzt dagegen den rechtlichen Rahmen dafür, wie weit Änderungen während der Vertragslaufzeit gehen dürfen.
Bei klassischen Vorgehensmodellen wie Wasserfall oder V-Modell XT sollen Anforderungen möglichst vollständig zu Beginn definiert werden. Änderungen werden daher über strukturierte Change-Request-Verfahren geprüft und formal freigegeben.
Agile Vorgehensmodelle verfolgen einen anderen Ansatz. Anforderungen sind hier bewusst nicht vollständig ausformuliert, sondern werden iterativ entwickelt und sprintweise konkretisiert. Ein klassisches Change-Request-Verfahren würde in diesem Kontext dem methodischen Ansatz widersprechen.
Der zentrale Zusammenhang lässt sich daher so zusammenfassen:
Das Vorgehensmodell erzeugt die Änderungslogik – das Vergaberecht setzt ihr den rechtlichen Rahmen.
2. Klassische Modelle: Change Requests als systemimmanenter Bestandteil
Klassische Vorgehensmodelle beruhen auf klar abgegrenzten Projektphasen und einer vorab definierten Soll-Beschaffenheit der Leistung. Ein genehmigtes Pflichtenheft bildet dabei regelmäßig die Grundlage für die spätere Realisierung.
Änderungen an Anforderungen oder Zwischenergebnissen erfolgen ausschließlich über formale Change Requests. Ohne ein entsprechendes Verfahren existiert kein strukturierter und rechtskonformer Weg, Leistungsänderungen im Projekt zu verarbeiten.
3. Verankerung in den EVB-IT-Verträgen
Diese Logik spiegelt sich auch in den EVB-IT-Vertragsmustern wider. Regelungen zu Auftragsänderungen finden sich beispielsweise in:
- Ziffer 17 der EVB-IT System-AGB
- Ziffer 16 der EVB-IT Erstellungs-AGB
- Ziffer 17 der EVB-IT Dienstleistungs-AGB
Die EVB-IT System-AGB regeln unter anderem:
- das Initiativrecht des Auftraggebers für Änderungen
- die Prüfpflicht des Auftragnehmers
- Zumutbarkeitsgrenzen
- Anpassungen von Vergütung und Terminen
- sowie ein formalisiertes Änderungsverfahren (Muster 3).
Der Hintergrund ist klar: Wenn ein Projekt auf einer definierten Soll-Beschaffenheit basiert, bedeutet jede Änderung zugleich eine Änderung des Vertrags. Dafür wird ein Verfahren benötigt, das nachvollziehbar, fair und rechtssicher ausgestaltet ist.
4. Warum klassische Change Requests in agilen Modellen nicht passen
Agile Vorgehensmodelle wie Scrum beruhen dagegen auf der Annahme, dass Anforderungen zu Beginn gerade nicht vollständig vorliegen. Sie werden iterativ entwickelt und fortlaufend präzisiert.
Das Product Backlog bildet dabei den zentralen Steuerungsmechanismus. Anforderungen werden kontinuierlich priorisiert, angepasst und weiterentwickelt.
In diesem Kontext wäre ein klassisches Change-Request-Verfahren häufig eine Überformalisation. Viele Änderungen sind bereits integraler Bestandteil des Prozesses.
Typische Beispiele hierfür sind:
- Änderungen in der Priorisierung einzelner Backlog-Einträge
- Anpassungen von User Stories
- Präzisierungen von Akzeptanzkriterien
- Verschiebungen von Backlog-Elementen in spätere Sprints.
Solche Anpassungen sind Teil des vereinbarten Entwicklungsprozesses und stellen regelmäßig keine Vertragsänderung dar.
Ein formaler Change Request wird dagegen erforderlich, wenn Änderungen den vertraglichen Rahmen überschreiten, etwa wenn:
- das Budget angepasst wird,
- sich der Gesamtumfang wesentlich verändert,
- Liefergegenstände oder Leistungskennzahlen angepasst werden,
- oder das grundlegende Vertragsziel verändert wird.
Agile Zusatzmodule greifen diese Logik auf und stellen klar, dass Change Requests nur dann erforderlich sind, wenn Änderungen Auswirkungen auf Budget, Vertragsumfang oder Liefergegenstände haben.
Damit wird eine funktionale Aufgabenteilung sichtbar:
Das Product Backlog ist das operative Änderungsinstrument.
Der Change Request bleibt der Mechanismus für strukturelle Vertragsänderungen.
5. Verbindung zu § 132 GWB
Diese Differenzierung ist auch vergaberechtlich relevant. § 132 GWB erlaubt Änderungen während der Vertragslaufzeit nur innerhalb bestimmter Grenzen.
Wie restriktiv diese Grenzen wirken, hängt maßgeblich davon ab, welches Vorgehensmodell dem Vertrag zugrunde liegt.
Change-Request-Verfahren können vergaberechtlich als Überprüfungsklauseln im Sinne von § 132 Abs. 2 Nr. 1 GWB eingeordnet werden, sofern sie in den Vergabeunterlagen klar, präzise und transparent geregelt sind. In diesem Fall bilden sie eine zulässige Grundlage für nachträgliche, nicht wesentliche Vertragsänderungen.
Fazit
Agile IT-Projekte sind aus vergaberechtlicher Sicht häufig robuster gegenüber Änderungen, weil ihre Methodik darauf ausgelegt ist, Anpassungen innerhalb des vereinbarten Projektprozesses zu verarbeiten.
Klassische Projekte benötigen dagegen zwingend formalisierte Change-Request-Verfahren, da jede Änderung der Anforderungen unmittelbar die vertraglich vereinbarte Soll-Beschaffenheit berührt und damit schnell in den Anwendungsbereich des § 132 GWB führen kann.