Es kann viele Gründe dafür geben, dass man in einem Projekt von der ursprünglichen Planung abweichen will oder sogar muss: Eine Spezifikation kann sich als technisch nicht machbar erweisen, ein Meilensteintermin als nicht realistisch oder eine Kostenstruktur als ungünstig aufgesetzt. Aber auch das Projektmanagement selbst kann sich als veränderungsbedürftig erweisen, z.B. wenn man mit einer Reorganisation des Projektteams die Effizienz der Arbeit steigern möchte.

Ein häufig zu beobachtender Fehler ist, dass solche Änderungen zentraler Planungsinhalte kommentarlos vollzogen werden, ohne dass sie entsprechend dokumentiert und auf weitere Auswirkungen hin untersucht werden. Zu einem professionellen Projektmanagement gehört deshalb auch ein Verfahren zur Behandlung von Änderungsanträgen. Teile eines solchen Verfahrens (das Bestandteil des Konfigurationsmanagements ist) sind z.B. ein Änderungsausschuss, der über Änderungsanträge entscheidet oder ein Änderungsbudget, das die durch genehmigte Änderungen entstehenden Mehrkosten finanziert.

Zentrales Steuerungsinstrument für das Änderungsverfahren ist der Änderungsantrag, der einerseits eine Entscheidungsvorlage liefert und andererseits das Verfahren selbst dokumentiert.

In der folgenden Darstellung orientiere ich mich stark am Projektmanagementsystem PRINCE2® (TSO, 2009; AXELOS, 2017), das in seinem Verfahren zur Änderungssteuerung explizit die Behandlung von Änderungsanträgen beschreibt. In einzelnen Punkten ergänze ich Anforderungen, die in anderen Richtlinien aufgeführt werden oder die ich selbst als sinnvoll erfahren habe.

Wenn Sie – egal in welcher Rolle und in welchem Projektumfeld – die Notwendigkeit sehen, dass im Projekt etwas geändert werden soll, dann unterstützt Sie dieser Beitrag bei der Umsetzung. Er liefert:

• klare Kriterien, in welchen Fällen Sie einen Änderungsantrag schreiben müssen und wann Sie die Änderung einfach umsetzen dürfen, sofern Sie die Befugnis dafür haben.
• eine Beschreibung, welche Elemente ein Änderungsantrag enthalten sollte, damit er von den Verantwortlichen effizient behandelt werden kann.
• Darüber hinaus zeigt der Beitrag, dass ein professionelles Konfigurationsmanagement unverzichtbar ist, um Änderungen zu steuern. Es dient zur Verwaltung und Überwachung der zu erbringenden Leistungen und sollte in keinem Projekt vernachlässigt werden.

Beispiel: Ungeplante Artenschutzmaßnahme bei einem großen Infrastrukturprojekt

Zur Illustration soll ein typisches Beispiel aus dem Alltag deutscher Großprojekte dienen: Beim Ausbau einer Bahnstrecke wird eine Population unter Naturschutz stehender Zauneidechsen entdeckt. Diese müssen umgesiedelt werden, was erhebliche Auswirkungen auf den Bauablauf hat. (Ähnlichkeiten mit realen Großprojekten sind weder beabsichtigt noch zufällig, sondern ganz einfach unvermeidlich.)

Wann ist ein Änderungsantrag erforderlich?

Wer in Projekten arbeitet, ändert beständig etwas: z.B. möchte der Entwickler bei einer Hardware-Entwicklung ein anderes Material verwenden, da sich das vorgesehene als ungeeignet erweist. Oder der Kunde möchte bei einer Software-Entwicklung die User Storys neu priorisieren. Muss der Entwickler oder der Kunde nun dafür einen Änderungsantrag stellen?

Das Produkt oder Dokument ist als "Baseline" festgelegt

Als Grundregel gilt: Nur für Änderungen von "eingefrorenen" Produkten oder Dokumenten ist ein Änderungsantrag erforderlich. "Eingefroren" bedeutet, dass das Produkt oder Dokument als "Baseline" ( Bezugskonfiguration) festgelegt wurde, z.B. indem es für die weitere Bearbeitung im Projekt freigegeben wurde. Wenn also ein Material im Lastenheft vorgegeben ist oder die Priorisierung der User Storys für den weiteren Projektverlauf verbindlich vereinbart wurde, z.B. um Engpassressourcen optimal einzuteilen, dann ist ein Änderungsantrag notwendig.

Grundsätzlich darf jeder Stakeholder eines Projekts – vom Team-Mitglied bis zum Auftraggeber – einen Änderungsantrag stellen. Verpflichtender Adressat aller Änderungsanträge ist der Projektmanager. Dieser muss dann das Verfahren zur Änderungssteuerung in Gang setzen.

Weitere typische Beispiele für Baselines sind: Eine vom Auftraggeber abgenommene Spezifikation, ein vom Lenkungsausschuss freigegebener Phasenplan oder ein geprüftes Zwischenprodukt eines abgeschlossenen Arbeitspakets. Alles andere, was nicht durch eine Baseline festgelegt ist, darf das Projektteam völlig frei gestalten und immer wieder beliebig verändern – vorausgesetzt, dass dies andere festgelegte Grenzen wie Budget, Zeit oder Projektumfang nicht gefährdet. So bedürfen z.B. das eigenverantwortliche Zusammenstellen des Sprint Backlogs oder das Verschieben von User Storys in den nächsten Sprint keines Änderungsantrags, da dies dem beschlossenen, agilen Vorgehen entspricht. Wenn jedoch die Produkterstellung nicht mehr nach Scrum, sondern z.B. nach V-Modell XT erfolgen soll, dann ist ein Änderungsantrag obligatorisch.

Richtlinien des Änderungsmanagements dienen als Informationsquelle