Änderungsmanagement im Projekt: der strukturierte Ablauf in 6 Schritten

Kategorie: Methodik & Frameworks

Infografik: Strukturierter Änderungsablauf

Was ist Änderungsmanagement im Projekt?

Änderungsmanagement ist die "Erfassung, Bewertung, Entscheidung, Dokumentation und Steuerung der Umsetzung von Änderungen im Projekt gegenüber der bisher gültigen Planung" . Gegenstand ist der Änderungsantrag gegen eine freigegebene Baseline, nicht die Stimmung im Team.

Diese Abgrenzung entscheidet über den Prozess. Änderungsmanagement im Projekt läuft auf Anfrage des Auftraggebers oder des Kunden ab und betrifft Leistungsumfang, Termine und Kosten eines konkreten Vorhabens. Organisationales Change Management zielt dagegen auf Strategien, Strukturen, Prozesse und Verhalten in der Aufbau- und Ablauforganisation (Quelle). Beide werden im Deutschen gleich abgekürzt und regelmäßig verwechselt. Wer den Change Request eines Kunden mit Kommunikationsmaßnahmen beantwortet, verliert Geld.

Der internationale Referenzprozess heißt im PMBOK Guide Perform Integrated Change Control: alle Änderungsanträge prüfen, Änderungen an Lieferobjekten, Projektdokumenten und Projektmanagementplan genehmigen und steuern, Entscheidungen kommunizieren (Quelle). Das Wort "integriert" trägt die Substanz: keine Genehmigung im Vakuum, jede Änderung wird gegen alle Randbedingungen des Projekts gleichzeitig bewertet.

Auf der Produktseite liefert DIN ISO 10007 den passenden Rahmen. Konfigurationsmanagement besteht dort aus Konfigurationsidentifikation, Konfigurationsüberwachung, Konfigurationsbuchführung und Konfigurationsaudit. Die Konfigurationsüberwachung ist das Änderungsmanagement an Konfigurationseinheiten und den zugehörigen Dokumenten (Quelle). Im Engineering trägt derselbe Ablauf die Kürzel ECR und ECN: Der Engineering Change Request ist der formale Antrag auf Änderung von Konstruktion, Zeichnung, Spezifikation oder Stückliste, die Engineering Change Notice ist die nach Genehmigung ausgegebene Umsetzungsanweisung (Quelle).

Wann brauchen Sie einen formalen Änderungsablauf, und wann nicht?

Ein formaler Ablauf lohnt sich, sobald eine Baseline existiert, gegen die abgerechnet oder terminiert wird: freigegebenes Pflichtenheft, bestätigter Meilensteinplan, vertraglich fixierter Lieferumfang. Ab diesem Punkt ist jede Abweichung eine Vertragsänderung mit Preis und Termin, kein technisches Detail.

Der Ablauf ist ebenfalls Pflicht, wenn die Änderung Konfigurationseinheiten berührt, die in die Zulassung, die CE-Dokumentation oder die Rückverfolgbarkeit eingehen. Ohne dokumentierte Konfigurationsüberwachung lässt sich später nicht belegen, welcher Stand ausgeliefert wurde.

Verzichten Sie auf den vollen Ablauf, solange die Baseline nicht freigegeben ist. In der Konzeptphase sind Änderungen Bestandteil der Arbeit, nicht Ausnahme. Ein Change-Board über jede Skizze erzeugt nur Durchlaufzeit. Ebenfalls ungeeignet ist der formale Ablauf für Fehlerbehebung: Ein Mangel an der vereinbarten Leistung ist keine Änderung, sondern Nacherfüllung. Wer Mängel als Change Request führt, stellt dem Kunden die eigene Gewährleistung in Rechnung und verliert die Diskussion spätestens bei der Abnahme.

Definieren Sie deshalb Genehmigungsschwellen statt Einheitsprozess. PRINCE2 arbeitet mit einer Change Authority, der das Project Board Entscheidungsbefugnis bis zu einem Change Budget delegiert; Änderungen darüber hinaus oder außerhalb der vereinbarten Toleranzen für Kosten, Zeit, Umfang und Risiko werden an das Project Board eskaliert (Quelle). Übertragen auf ein Industrieprojekt: Der Projektleiter entscheidet bis 5.000 Euro, der Änderungsausschuss bis 50.000 Euro, darüber entscheidet die Geschäftsführung gemeinsam mit dem Vertrieb.

Wie läuft der Änderungsablauf in 6 Schritten ab?

1. Änderung erfassen und formalisieren

Ziel: Jede Änderungsidee wird zu einem eindeutig identifizierten Antrag mit Antragsteller, Datum, betroffener Konfigurationseinheit und Begründung.

Vorgehen: Ein Eingangskanal, ein Formular, eine laufende Nummer. Pflichtfelder sind der betroffene Baseline-Stand, der gewünschte Zielzustand und der fachliche Grund. Anträge ohne diese Angaben gehen zurück, sie werden nicht "nebenbei geklärt".

Typischer Fehler: Die Änderung kommt per E-Mail an den Konstrukteur, der sie sofort einarbeitet. Damit existiert sie technisch, aber weder kaufmännisch noch vertraglich.

2. Vorprüfen und klassifizieren

Ziel: Aussortieren, was kein Änderungsantrag ist, und den Rest in Kategorien mit definiertem Entscheidungsweg einsortieren.

Vorgehen: Drei Prüffragen. Ist es ein Mangel gegen die vereinbarte Leistung? Dann Nacherfüllung. Ist es bereits im Leistungsumfang enthalten? Dann Klarstellung. Ist es eine echte Erweiterung oder Abweichung? Dann Änderungsantrag. Anschließend Klassifizierung nach betroffener Konfigurationseinheit und nach Genehmigungsschwelle.

Typischer Fehler: Alles landet im Änderungsausschuss. Der Ausschuss wird zur Warteschlange, und dringende Anträge stehen hinter Trivialitäten.

3. Auswirkungen analysieren

Ziel: Eine belastbare Aussage zu Technik, Termin, Kosten, Vertrag und Risiko, bevor jemand entscheidet.

Vorgehen: Die Analyse macht der Fachbereich, nicht das Gremium. Es ist ausdrücklich nicht die Aufgabe eines Change Control Board, die Auswirkungen selbst zu ermitteln (Quelle). Bewerten Sie fünf Dimensionen getrennt: technische Machbarkeit und Folgeänderungen an angrenzenden Baugruppen, Aufwand in Stunden je Gewerk, Materialkosten, Verschiebung auf dem kritischen Pfad, vertragliche Folgen wie Pönale, Zahlungsplan und Gewährleistungsumfang.

Typischer Fehler: Nur der direkte Aufwand wird geschätzt. Wiederholungstests, Dokumentationsnachträge und Abnahmeumfänge fehlen und tauchen später als ungeplante Arbeit auf.

4. Entscheiden und freigeben

Ziel: Eine dokumentierte Entscheidung mit Datum, Gremium und Begründung: genehmigt, abgelehnt, zurückgestellt.

Vorgehen: Der Änderungsausschuss ist ein temporäres Gremium, das über alle Änderungsanträge an Projektdokumente entscheidet; seine Aufgaben sind Bewertung von Aufwand und Nutzen, Entscheidung und Kommunikation über Annahme oder Ablehnung sowie Priorisierung der angenommenen Anträge (Quelle). Besetzen Sie es mit Projektleitung, Technik, Kalkulation und Vertrieb. Genehmigte Anträge oberhalb der Bagatellgrenze gehen als Nachtragsangebot an den Kunden, bevor gearbeitet wird.

Typischer Fehler: Technische Freigabe ohne kaufmännische Gegenzeichnung. Die Arbeit läuft, das Nachtragsangebot folgt Wochen später und wird bestritten.

5. Umsetzen und Baseline nachziehen

Ziel: Die genehmigte Änderung wird ausgeführt, und alle Planstände bilden anschließend denselben Zustand ab.

Vorgehen: Die Freigabe wird als Umsetzungsanweisung an alle betroffenen Stellen ausgegeben, im Engineering als ECN (Quelle). Nachziehen müssen Sie: Terminplan, Budget, Stückliste, Zeichnungsstand, Pflichtenheft, Abnahmekriterien und Prüfplan. Jede Änderung erhält einen neuen Baseline-Index.

Typischer Fehler: Zeichnung und Stückliste werden aktualisiert, die Abnahmekriterien nicht. Der alte Prüfplan produziert bei der Abnahme einen Mangel, der keiner ist.

6. Nachverfolgen und abschließen

Ziel: Nachweis, dass die Änderung wirksam umgesetzt und wirtschaftlich erfasst ist.

Vorgehen: Status je Antrag bis zum Abschluss führen, Ist-Aufwand gegen den geschätzten Aufwand stellen, Nachtragsrechnung auslösen, Änderungsdokumentation archivieren. Das entspricht der Konfigurationsbuchführung nach DIN ISO 10007: rückverfolgbare Dokumentation von Konfigurationen und Konfigurationseinheiten (Quelle).

Typischer Fehler: Der Antrag gilt mit der Genehmigung als erledigt. Die Schätzabweichung wird nie gemessen, und die nächste Schätzung ist genauso schlecht wie die letzte.

Wie sieht eine Auswirkungsanalyse konkret aus?

Ausgangslage: Sondermaschine zur Montage von Getriebekomponenten, Auftragswert 1,8 Mio. Euro, Liefertermin in 22 Wochen, Pönale 0,3 Prozent des Auftragswerts je angefangener Verzugswoche. Acht Wochen vor der geplanten Werksabnahme meldet der Kunde eine Änderung: Die Anlagenschnittstelle soll von PROFINET auf EtherCAT umgestellt und zusätzlich per OPC UA an das MES angebunden werden. Die Baseline ist das am Projekttag 40 freigegebene Pflichtenheft, Index C. Interner Verrechnungssatz: 95 Euro je Stunde.

Die vertragliche Dimension entscheidet den Fall. Ohne vereinbarte Terminverschiebung kostet der Verzug 0,3 Prozent von 1,8 Mio. Euro je Woche, also 5.400 Euro pro Woche und 16.200 Euro für drei Wochen. Diese Summe ist größer als der Risikozuschlag und übersteigt den Deckungsbeitrag des Nachtrags deutlich.

Entscheidung des Änderungsausschusses am Projekttag 98: Antrag CR-014 genehmigt unter zwei Bedingungen. Erstens Nachtragsauftrag über 37.750 Euro vor Arbeitsbeginn. Zweitens schriftliche Verschiebung des vertraglichen Liefertermins um drei Wochen und Freistellung von der Pönale für diesen Zeitraum. Die Schwelle von 50.000 Euro ist nicht überschritten, die Geschäftsführung wird informiert, entscheidet aber nicht. Pflichtenheft geht auf Index D, Abnahmekriterium A-17 wird um den OPC-UA-Verbindungstest erweitert, der FAT-Prüfplan entsprechend nachgezogen.

Hätte der Ausschuss nur die 34.320 Euro betrachtet, wäre die Änderung als kleiner Nachtrag durchgelaufen und hätte netto Geld gekostet. Genau das ist der Grund, warum die Auswirkungsanalyse Termin und Vertrag mitführt und nicht nur Stunden zählt.

Fazit

Änderungsmanagement scheitert selten an der Technik. Es scheitert daran, dass Änderungen den Prozess umgehen: informell vereinbart, technisch umgesetzt, kaufmännisch nie erfasst. Die sechs Schritte kosten pro Antrag wenige Stunden Bewertungsaufwand und schützen einen Nachtrag, der im Beispiel 37.750 Euro wert ist.

Entscheidend sind zwei Punkte. Der Änderungsantrag braucht eine freigegebene Baseline, sonst gibt es nichts, wogegen geändert wird. Und die Auswirkungsanalyse braucht alle fünf Dimensionen, weil der Termineffekt über die Pönale regelmäßig teurer ist als der Aufwand.

Quellen

1. projektmagazin: Was ist Änderungsmanagement? (Definition nach DIN 69901-5) – https://www.projektmagazin.de/glossarterm/aenderungsmanagement (abgerufen 2026-09)
2. Peterjohann Consulting: Änderungsmanagement, Abgrenzung zum organisationalen Change Management – https://www.peterjohann-consulting.de/aenderungsmanagement/ (abgerufen 2026-09)
3. Rework Resources: Integrierte Änderungssteuerung (PMBOK Perform Integrated Change Control) – https://resources.rework.com/de/libraries/project-management/integrated-change-control (abgerufen 2026-09)
4. quality.de: DIN EN ISO 10007 – Konfigurationsmanagement, vier Teilprozesse – https://www.quality.de/lexikon/din-en-iso-10007/ (abgerufen 2026-09)
5. PTC: What Is an Engineering Change Request (ECR)? – https://www.ptc.com/en/blogs/plm/what-is-an-engineering-change-request (abgerufen 2026-09)
6. PTC: What Is an Engineering Change Notice (ECN)? – https://www.ptc.com/en/blogs/plm/what-is-an-engineering-change-notification (abgerufen 2026-09)
7. projektmagazin: Was ist ein Änderungsausschuss? – https://www.projektmagazin.de/glossarterm/aenderungsausschuss (abgerufen 2026-09)
8. t2informatik Smartpedia: What is a Change Control Board? – https://t2informatik.de/en/smartpedia/change-control-board/ (abgerufen 2026-09)
9. PRINCE2 Wiki: Change Authority und Change Budget – https://prince2.wiki/people/change-authority/ (abgerufen 2026-09)
10. DIN Media: DIN ISO 10007:2020-10, Qualitätsmanagement – Leitfaden für Konfigurationsmanagement – https://www.dinmedia.de/en/standard/din-iso-10007/325347639 (abgerufen 2026-09)

Weiterführend: Integriertes Risikomanagement im Projekt: Portfolio, Eskalation und Kommunikation · Projektabnahme: der vollständige Ablauf von Planung bis Freigabe

Mehr zu Projektmanagement für technisch komplexe Projekte: Aligia