Änderungsmanagement

Änderungsmanagement: Basis

Einleitung Änderungsmanagement

Änderungen in Projekten sind normal. Schwierig wird es nur, wenn die Änderungen in großer Zahl und unkontrolliert in das Projekt fließen. Das führt in aller Regel zu einer Verlängerung der Projektlaufzeit, mehr Kosten und zu technischen Risiken, wenn die inoffiziellen Änderungen nicht korrekt getestet und dokumentiert werden. Insofern sollte sich die Projektleitung auch mit dem Thema auseinandersetzen, welchen Änderungsprozess man im vorliegenden Projekt verwendet, welche Change Request-Formulare verwendet werden und wie man gleichzeitig überflüssigen Formalismus bei Änderungen vermeiden kann.

Mit klaren Prozessen Änderungen kontrolliert in den Projektumfang integrieren

Änderungsmanagement ist die Einführung und Durchführung des Änderungsverfahrens im Projekt. Es sorgt dafür, dass die verabredeten Genehmigungsprozesse durchlaufen und alle Änderungen rückverfolgbar und nachvollziehbar sind.

⚠️ Änderungsmanagement (Change Request Management) von Veränderungsmanagement abgrenzen. Mit Veränderungsmanagement ist in der Regel “Management of Change” oder auch - etwas missverständlicher Changemanagement. Missverständlicher deshalb, weil in der ITIL-Zertifizierung der Begriff “Changemanagement” für das Änderungsmanagement verwendet wird.

Änderungen in Projekten sind normal, sie sollten nur kontrolliert werden.

⚠️ Wenn Änderungen nicht kontrolliert dem Projektumfang zugeführt werden, ist die Gefahr von Scope-Creep (der “schleichenden Umfangsausweitung”) besonders groß.

Ein klarer Änderungsprozess reduziert diese Gefahr deutlich und kann durch deeskalierende Kommunikation unterstützt werden. Also zum Beispiel: “Den Wunsch kann ich nachvollziehen. Lassen Sie uns einen Change Request machen” statt “Das war nicht vereinbart”.

Mit einem gut strukturierten Change Request Formular den Änderungsprozess effizienter machen

Ein gut strukturiertes Change-Request-Formular ist ein starker Effizienzhebel – aber nur dann, wenn es richtig dimensioniert ist und in einen klaren Prozess eingebettet wird.

⚠️ Ein Formular allein macht den Prozess nicht effizient, wenn es überladen ist und unnötige Detailtiefe verlangt, für jede Kleinigkeit ausgefüllt werden muss und es keine Instanz gibt, die die Qualität der vielen Einträge noch überprüfen kann.

💡 Das Change Request Formular sollte proportional zur Projektgröße gestaltet werden und zum Beispiel bei Unterschreitung von Schwellenwerten in vereinfachter Form auszufüllen sein. Eine weitere Vereinfachung des Change Request Prozesses wird im Hintergrund-Abschnitt beschrieben.

Vorteile einer Standardisierung: Wenn alle Anträge nach demselben Schema aufgebaut sind, können sie:

• schneller bewertet werden durch eine gewohnte Struktur
• objektiver priorisiert werden durch eine bessere Vergleichbarkeit

Zwang zur strukturierten Voranalyse entlastet die Change Board Sitzung: Ein Entscheidungsgremium (z. B. Change Board) kann nur so gut entscheiden, wie die Informationslage ist. Ein gutes Formular zwingt zur strukturierten Voranalyse – das spart Zeit in der Sitzung.

Neben der Effizienz liefert ein gutes Change Request Formular auch einen wesentlichen Beitrag zur “Konfigurationsbuchführung”, die im nächsten Kapitel beschrieben wird.

Mit der Einbettung des Änderungsmanagements in ein professionelles Konfigurationsmanagement den Änderungsprozess effizienter machen

Konfigurationsmanagement umfasst alle koordinierten Tätigkeiten zur Leitung und Lenkung der Konfiguration.

Konfigurationsmanagement ist ein “Teilgebiet des Projektmanagements, das die Planung, Überwachung und Steuerung der Konfiguration(en) der im Projekt zu liefernden Produkte umfasst, um zu jedem Projektzeitpunkt die Rückverfolgbarkeit von Änderungen auf die Bezugskonfigurationen und letztlich die vollständige Erfüllung der festgelegten Anforderungen zu gewährleisten”* (Erhard Motzel und Thor Möller, 2017, Projektmanagement Lexikon).*

Der Konfigurationsprozess besteht aus der Konfigurationsidentifizierung, der Konfigurationsüberwachung (dem eigentlichen Änderungsmanagement) und der Konfigurationsbuchführung (der Dokumentation).

Eine wichtige Voraussetzung für ein effizientes Änderungsmanagement ist die Verfügbarkeit eines Ausgangspunktes für die Änderung. Das ist eine jeweils freigegebene Bezugskonfiguration.

Eine Bezugskonfiguration ist die “zu einem bestimmten Zeitpunkt (formal) festgelegte Konfiguration eines Produkts (oder eines Teils davon), die als Grundlage für die weiteren Tätigkeiten liegt. Sie repräsentiert die Gesamtheit der freigegebenen technischen und anderen Unterlagen, die ein Produkt (oder Teile davon) definieren”* (Erhard Motzel und Thor Möller, 2017, Projektmanagement Lexikon).*

Als Bezugskonfiguration kann auch vereinfacht die miteinander verbundenen funktionellen und physischen Merkmale eines Produkts bezeichnet werden.

Der Prozess, zu einem bestimmten Zeitpunkt mit einer Bezugskonfiguration eine Momentaufnahme des Produkts zu machen, also eine “Baseline” zu ziehen, nennt man auch Baselining.

Änderungen sind immer Abweichungen von einem definierten Zustand. Insofern kann ein Änderungsantrag nur sinnvoll bewertet werden, wenn man eine klare Referenz hat. Ohne die klare Referenz der Bezugskonfiguration fehlt eine klare Bewertungsgrundlage für die Auswirkung auf Aufwand und Kosten, Zeit und Qualität. Genehmigungen werden unsauber, wenn nicht klar ist: Was genau wird eigentlich geändert und was sind die Konsequenzen? Das wiederum setzt eine projektbegleitende Dokumentation voraus: Ohne die Dokumentation und Versionierung der verschiedenen Produktkonfigurationen ist die Beurteilung und Genehmigung von Änderungen schwierig. Zum anderen können ohne klare Dokumentation - je nach Projektart und Branche - verschiedene Versionen gleichzeitig kursieren. Ein Durcheinander von Versionen und die versehentliche Arbeit an alten Versionen oder das Versehentlich einspielen alter Softwareversionen kann durch einen professionelles Konfigurationsmanagement verhindert werden. In bestimmten regulierten Bereichen (Medizintechnik, Luftfahrt, IT-Sicherheit) ist eine nachvollziehbare Versionskennzeichnung und Rückverfolgbarkeit von Änderungen (Traceability) sogar ein Compliance-Thema. Insofern kann Konfigurationsmanagement auch als “Enabler des Änderungsmanagements” bezeichnet werden. Änderungsmanagement (Schwerpunkt Steuerung von Änderungen) ohne Konfigurationsmanagement (Schwerpunkt = Kontrolle des Produktzustands) kann überspitzt formuliert auch als organisatorischer Blindflug bezeichnet werden.

💡 Man sollte beim Änderungsmanagement prüfen, ob das oft bereits schon organisationsweit verwendete Änderungsverfahren für das eigene Projekt geeignet ist. Dann kann man sich unter Umständen viel Zeit und politische Diskussion sparen. Auf der anderen Seite sollte man sich auch nicht davor scheuen, mit dem Auftraggeber ein projektspezifisches und ggf. schnelleres Verfahren einzuführen. Das könnte zum Beispiel der Fall sein, wenn zum Beispiel der Zeitdruck im Projekt sehr groß ist und man bei Änderungen nicht immer warten kann, wann das nächste organisations- oder bereichtsweite Change Request Board tagt.

💡 Für wenig riskante, kleinere Änderungen ein Sonderbudget für das Projektteam verabreden (ohne diesen Prozess)

Zunächst sollte man prüfen, ob das organisationsweite Verfahren auf das eigene Projekt anwendbar ist. Ein bereits etabliertes organisationsweites Änderungsverfahren hat klare Vorteile:

• Akzeptanz und Legitimität: Es ist bekannt und politisch „abgesichert“.
• Klare Rollen und Entscheidungswege: Keine langen politischen Grundsatzdiskussion über Zuständigkeiten.
• Transparenz und Nachvollziehbarkeit: Audit- und Compliance-Sicherheit. Gerade in größeren Organisationen oder regulierten Umfeldern (z. B. Banken, Automotive, öffentliche Verwaltung) spart das enorm viel Abstimmungsaufwand.

Aber: Projektkontext geht aus meiner Sicht vor Organisationstandard: Ein Standardverfahren ist nicht automatisch für jedes Projekt geeignet. Typische Fälle, in denen ein projektspezifisches Change-Verfahren sinnvoll sein kann:

• Hoher Zeitdruck
• Viele kleine, operative Änderungen
• Innovations- oder Pilotprojekte
• International verteilte Teams mit unterschiedlichen Governance-Strukturen

Wenn ein Change Request Board nur einmal im Monat tagt, kann das in einem dynamischen Projekt ein echter Flaschenhals sein.

Wie schon oben beschrieben ist der eigentliche Erfolgsfaktor “Proportionalität”, also eine gewisse Angemessenheit bezüglich “Projektkritikalität und Dynamik”. Kleinere Änderungen könnten über ein spezielles Budget dem Projektteam oder einem “Mini-Board” für eigenständige Entscheidungen bereitgestellt werden. Erst aber einem definierten Umfang und Auswirkungsgrad könnte dann das größere offizielle Board einbezogen werden.

Natürlich muss das immer in Abstimmung mit dem Auftraggeber und ggf. relevanten Compliance-Stellen der Organisation erfolgen.