Kein einziges Projekt läuft exakt so ab, wie es ursprünglich geplant wurde. Inhalte, Ziele, Rahmenbedingungen und Kundenanforderungen können sich verändern – das ist ganz normal. Trotzdem sorgen diese Veränderungen in der Praxis immer wieder für Verwirrung, zwischenmenschliche Konflikte und sogar Rechtsstreitigkeiten. Ein systematisches Änderungsmanagement ist deshalb ein wesentlicher Baustein eines professionellen Projektmanagements.
Es gibt sehr viel Literatur zum Thema Änderungsmanagement, insbesondere in den Bereichen IT-Projektmanagement und Product Lifecycle Management (PLM). Mir persönlich sind diese Vorgehensweisen oft zu bürokratisch und theoretisch.
Deshalb hier einige pragmatische Tipps, wie Sie mit Änderungen in Projekten umgehen können:
- Das Änderungsmanagement beginnt bereits mit der exakten und messbaren Ziel- und Inhaltsformulierung eines Projekts (Project Scope Management). Wenn Ziele und Inhalte unklar oder gar nicht dokumentiert sind, sind Konflikte in den Durchführungsphasen eines Projekts oft schon vorprogrammiert.
- Mein Tipp zum Project Scope Management: Versuchen Sie, die verschiedenen Lieferobjekte (= Deliverables) des Projekts möglichst klar und messbar zu beschreiben. Diese Lieferobjekte haben oft den Charakter von Meilensteinen, die auch entsprechend freigegeben werden müssen (z.B. durch den internen Auftraggeber oder den Projektkunden).
- In vielen Projekten fällt es zu Beginn schwer, die Lieferobjekte der späteren Projektphasen schon exakt zu spezifizieren. Hier besteht die Möglichkeit, zum Beginn einen Rahmenvertrag zu vereinbaren und dann jede einzelne Projektphase inkl. der jeweiligen Lieferobjekte und Inhalte im Detail festzulegen und zu beschließen.
- Wenn Änderungen eintreten, sollten Sie in 7 Schritten abgehandelt werden (siehe Change Control Beitrag bei Wikipedia):
- Die (gewünschte) Änderung wird dokumentiert. –> Record
- Die möglichen Auswirkungen der Änderung werden analysiert und bewertet. –> Impact Assessment
- Die Implementierung der Änderung in den laufenden Projektprozess wird geplant. –> Plan
- Die Änderungen werden erarbeitet. –> Build
- Die Änderungen werden getestet. –> Test
- Die Änderungen werden implementiert. –> Implement
- Die Änderungen werden abgeschlossen und freigegeben. –> Close
- Ich stelle oft fest, dass Menschen mentale Barrieren aufbauen, wenn sich Änderungen ankündigen. Im ersten Schritt ist es einfacher, Änderungen einfach zu ignorieren, zu akzeptieren oder zu bagatellisieren. Dies rächt sich aber fast zwangsläufig in einer späteren Projektphase. Deshalb mein Tipp: Stellen Sie sich den notwendigen Änderungen im Projekt. Sprechen Sie notwendige Änderungen an, auch wenn es weh tut. Schaffen Sie Transparenz und dokumentieren Sie ausreichend. Das heißt nicht, dass Sie einen Bürokratismus aufbauen sollen, doch meiner Einschätzung nach wird in 80-90 % der Projekte zu wenig dokumentiert. Und dies führt zu Konflikten, hohen Änderungskosten oder – wie bereits erwähnt – Rechtsstreitigkeiten. Häufig enden Projekte dann in einer Sackgasse.
- Und noch ein letzter Hinweis: Die Änderungen in einem Projekt gehen meist von den inhaltlichen Zielen aus – dem Project Scope. Diese Änderungen wirken sich dann meist auf die Kosten (Project Budget) sowie auf die Termine (Project Schedule) aus. Als Gedankenstütze und vor allem auch als Argumentationshilfe sollten Sie deshalb immer das Dreieck der Projektziele im Hinterkopf behalten.
Und noch ein allerletzter Hinweis: Oftmals wird Änderungsmanagement als „Change Management“ in die englische Sprache übersetzt. Dies sorgt aus meiner Sicht oft für Missverständnisse, da Change Management im generellen Sprachgebrauch für Organisationsentwicklung und betriebliche Veränderungsprozesse steht. Ich empfehle deshalb den Begriff „Change Control“ (übrigens auch der offizielle Terminus nach dem PMBOK).