1. Anforderungen (Requirements) und Änderungen (Changes) – Zwei Perspektiven auf denselben Zielzustand

In Projekten werden „Requirements“ und „Changes“ häufig vermischt, obwohl sie zwei unterschiedliche Perspektiven auf denselben Zielzustand darstellen. Requirements definieren den Soll‑Zustand eines Systems oder Prozesses. Sie beschreiben, was im Zielbild vorhanden sein muss, unabhängig davon, wie der aktuelle Ist‑Zustand aussieht. Changes hingegen definieren die Abweichung vom Ist‑Zustand, also die konkrete Anpassung, die notwendig wird, um den Soll‑Zustand zu erreichen oder anzupassen. Diese Unterscheidung ist zentral, weil sie die fachliche Zieldefinition von der technischen oder organisatorischen Veränderung trennt.

1.1. Requirements als Definition des Soll‑Zustands

Ein Requirement beschreibt, was ein System im Zielbild leisten muss. Es entsteht typischerweise in frühen Projektphasen und ist lösungsneutral. Requirements definieren den Umfang, die fachliche Erwartung und die Kriterien, die später im UAT abgenommen werden. Sie sind nicht reaktiv, sondern planend. Ein Requirement wie „Das System muss vier Sprachen unterstützen“ beschreibt ausschließlich den Soll‑Zustand, nicht die Arbeit, die notwendig ist, um diesen Zustand zu erreichen.

1.2. Changes als Anpassung des Ist‑Zustands

Eine Änderung ergibt sich stets aus der Differenz zwischen dem Ist-Zustand und dem Zielzustand. Wenn ein System bereits Russisch und Spanisch unterstützt, die Ziel-Lösung jedoch vier Sprachen erfordert, besteht die Änderung darin, Englisch und Französisch hinzuzufügen. Die Änderung ist somit die konkrete Anpassung des Ist-Zustands und nicht die abstrakte Definition des Zielzustands. Änderungen ergeben sich aus neuen Erkenntnissen, technischen Einschränkungen, regulatorischen Anforderungen oder Mängeln und haben direkte Auswirkungen auf Zeitplan, Budget, Tests und die Umstellung.

2. Warum im UAT Requirements getestet werden – und nicht Changes

Der User Acceptance Test (UAT) ist die Abnahme des Soll‑Zustands. Er prüft nicht die Änderung, sondern das Ergebnis der Änderung. Auch wenn das System Russisch und Spanisch bereits konnte, müssen diese beiden Sprachen im UAT erneut getestet werden, weil der UAT den vollständigen Soll‑Zustand abnimmt. Der UAT prüft also nicht nur die neuen Sprachen Englisch und Französisch, sondern alle vier Sprachen, da das Requirement vier Sprachen umfasst. Der UAT ist damit kein Change‑Test, sondern ein Requirement‑Test. Er bestätigt, dass der Soll‑Zustand vollständig erreicht wurde — unabhängig davon, wie viele Changes dafür notwendig waren.

2.1. Regressionstests als integraler Bestandteil der UAT

Dass bestehende Funktionen erneut getestet werden müssen, ist eine logische Konsequenz der Soll‑Zustands‑Abnahme. Jeder Change kann Auswirkungen auf bestehende Funktionen haben, sei es durch neue Konfigurationen, neue Datenmodelle, neue UI‑Elemente oder neue Übersetzungslogiken. Der UAT prüft nicht die Historie, sondern den Zielzustand — und dieser Zielzustand umfasst alle Funktionen, nicht nur die geänderten.

3. Projektplanung bezieht sich auf Changes – nicht auf Requirements

Requirements definieren den Soll‑Zustand, aber sie erzeugen noch keine Arbeit. Erst die Abweichung vom Ist‑Zustand — also der Change — erzeugt Aufwand, Ressourcenbedarf, Timeline‑Impact und Budget. Deshalb planen Projekte nicht „Requirements“, sondern „Changes“. Die Projektplanung beantwortet die Frage: „Was müssen wir tun, um den Soll‑Zustand zu erreichen?“ Und diese Frage lässt sich nur auf Basis der Changes beantworten, nicht auf Basis der Requirements.

4. Warum PMI hier nicht differenziert

Im klassischen PMI‑Verständnis ist ein Change Request eine Änderung des genehmigten Scope. PMI betrachtet Changes ausschließlich als Scope‑Changes und unterscheidet nicht zwischen Requirement‑Änderungen und Solution‑Änderungen. Für PMI ist jeder Change eine Veränderung des Projektumfangs, unabhängig davon, ob er durch neue fachliche Anforderungen, technische Constraints, regulatorische Vorgaben oder Defects ausgelöst wird. Diese Sichtweise ist für klassisches Projektmanagement ausreichend, bildet aber die Komplexität moderner Lösungen nicht ab.

5. Requirement‑to‑Change‑Mapping – das Bindeglied zwischen Soll und Ist

In realen Projekten existiert keine lineare Beziehung zwischen Requirements und Changes. Es ist immer eine n:n‑Beziehung: Ein Requirement kann mehrere Changes erzeugen, und ein Change kann mehrere Requirements betreffen. Ein Requirement kann ohne Change umgesetzt werden, wenn der Ist‑Zustand bereits dem Soll‑Zustand entspricht. Ein Change kann ohne Requirement entstehen, etwa durch regulatorische Vorgaben oder Defects. Das Requirement‑to‑Change‑Mapping macht diese Beziehungen sichtbar und schafft die Grundlage dafür, dass Changes nachvollziehbar, testbar und steuerbar werden.

Das Mapping zeigt, welche konkreten Changes notwendig sind, um ein Requirement umzusetzen, und welche Requirements durch einen Change beeinflusst werden. Es bildet die Grundlage für die Impact‑Analyse, die Testplanung und die Cutover‑Bewertung. Ohne Mapping bleibt die Verbindung zwischen Soll‑Zustand und Ist‑Zustands‑Anpassungen unsichtbar — und damit auch die Risiken, Abhängigkeiten und Regressionen.

6. Warum das CAB in der Praxis oft Requirements statt Changes bewertet

In ITIL ist das Change Advisory Board (CAB) dafür vorgesehen, Changes zu bewerten — also die Abweichungen vom Ist‑Zustand, die notwendig sind, um den Soll‑Zustand zu erreichen oder anzupassen. In der Praxis werden im CAB jedoch häufig Requirements präsentiert. Das CAB diskutiert dann fachliche Zielbilder, obwohl es eigentlich die Auswirkungen der konkreten Changes bewerten sollte. Der Grund dafür ist einfach: Das Requirement‑to‑Change‑Mapping wird selten durchgeführt. Wenn nicht klar dokumentiert ist, welche Changes aus einem Requirement entstehen, bleibt dem CAB nichts anderes übrig, als das Requirement selbst zu bewerten.

Dadurch verliert das CAB seine eigentliche Funktion als Kontrollinstanz für Solution‑Changes und wird zu einem Scope‑Gremium — ähnlich wie im klassischen PMI‑Verständnis. Risiken, Abhängigkeiten, Regressionen und Cutover‑Auswirkungen bleiben unsichtbar, weil die Changes nicht explizit gemacht wurden.

7. Die Change Governance Matrix (ChGM) als Lösung

Die Change Governance Matrix (ChGM) trennt die Ebenen sauber. Sie betrachtet Requirements als Definition des Soll‑Zustands und Changes als Abweichung vom Ist‑Zustand. Erst durch das Requirement‑to‑Change‑Mapping wird sichtbar, welche konkreten Changes notwendig sind, um ein Requirement umzusetzen, und welche Auswirkungen diese Changes haben. Das CAB bewertet dann nicht mehr das Requirement, sondern die Changes, die aus dem Requirement entstehen. Die ChGM liefert die Struktur, die PMI und viele klassische Projektmethoden nicht bieten. Sie operationalisiert die Verbindung zwischen Soll‑Zustand und Ist‑Zustands‑Anpassungen und macht die n:n‑Beziehung zwischen Requirements und Changes sichtbar.

8. Fazit

Requirements definieren den Soll‑Zustand. Changes definieren die Abweichung vom Ist‑Zustand. Die Projektplanung bezieht sich auf die Changes, weil sie die konkrete Arbeit darstellen. Der UAT testet die Requirements, weil er den Soll‑Zustand abnimmt. PMI betrachtet Changes als Scope‑Changes und unterscheidet nicht zwischen Requirement‑Änderungen und Solution‑Änderungen. Die Change Governance Matrix (ChGM) geht weiter: Sie steuert Changes auf Solution‑Ebene und nutzt das Requirement‑to‑Change‑Mapping, um die n:n‑Beziehung zwischen Soll‑Zustand und Ist‑Zustands‑Anpassungen transparent und steuerbar zu machen. Dadurch kann das CAB seine eigentliche Aufgabe erfüllen: die Bewertung und Steuerung von Changes auf Solution‑Ebene.

Die Change Governance Matrix (ChGM) ist (i) als digitales Produkt (Download) verfügbar and (ii) im Buch über “SAP Cutover Management“, von Guido Nageldinger, beschrieben.

Aktualisierung

Dieser Artikel bietet eine vereinfachte Einführung in die behandelten Konzepte. Eine erweiterte Fassung mit formalen Definitionen, der Outcome Delivery Structure (ODS), den Transitional Deliverables (TD), dem Cutover Deliverable Flow und dem Change-Illusion-Modell ist verfügbar im Change Illusion Journal

List of terms