Änderungsantrag im Projekt: Flussdiagramm für Umfang, Kosten, Termine

Was ist änderungsantrag im projekt: flussdiagramm für umfang, kosten, termine?

Ein Änderungsantrag im Projekt verlangt, etwas zu ändern, das bereits vereinbart ist: den Umfang, die Kosten oder die Termine im freigegebenen Basisplan. Genau das trennt ihn von gewöhnlicher Umplanung. Aufgaben neu zu sortieren, eine Person zwischen Arbeitspaketen zu verschieben oder eine Verzögerung von zwei Tagen im Puffer aufzufangen, ist Aufgabe der Projektleitung und braucht keinen Antrag. Dieser Prozess beginnt, wenn jemand etwas verlangt, das der Basisplan derzeit nicht zusagt, und er endet entweder mit einem Basisplan, der etwas anderes sagt, oder mit einem geschlossenen Antrag samt dokumentierter Begründung.

Das hier ist Änderungssteuerung im Projekt, nicht IT-Service-Change-Management. Wenn Ihre Entscheidung lautet, ob eine Änderung in einen laufenden Service ausgerollt wird (mit CAB, Änderungskalender, Wartungsfenster und Rollback-Plan), decken das Flussdiagramm zum Change-Management-Prozess unter /de/templates/change-management-prozess-itil und der allgemeine Change-Control-Prozess unter /de/templates/change-control-prozess dieses Feld ab. Die Fragen hier sind anderer Art: Was kostet die Änderung, was verschiebt sie, wer finanziert sie, und trägt der Business Case noch? Es geht hier auch nicht um organisatorisches Veränderungsmanagement, die menschliche Seite hinter Modellen wie ADKAR, und es ist kein Phasen-Gate. Wenn Sie am Ende einer Phase entscheiden, ob es weitergeht, statt ob der Basisplan geändert wird, nehmen Sie die Go/No-Go-Entscheidung unter /de/templates/go-no-go-entscheidung.

Zwei Entscheidungen tragen das Diagramm. Die erste ist die Toleranz: ob die Änderung klein genug ist, dass die Projektleitung sie in delegierter Befugnis genehmigen darf, oder groß genug, dass der Lenkungsausschuss gebraucht wird. Ohne schriftliche Grenzen erreicht entweder alles das Gremium, was es in eine Warteschlange verwandelt, oder nichts, und dann werden Änderungen informell gemacht. Die zweite ist, was die Änderungsinstanz überhaupt antworten darf. Genehmigen und ablehnen sind eindeutig; zurückstellen ist die Antwort, die die meisten Register schlecht behandeln, denn eine Änderung ohne Wiedervorlagetermin ist nicht von einer unterscheidbar, die ignoriert wurde. Hier hat die Zurückstellung einen eigenen Rückweg in eine spätere Sitzung, und die Ablehnung hat einen ausdrücklichen Endzustand statt Stille.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Bahnen (Antragsteller, Projektleitung, Projektteam, Finanzen sowie Änderungsinstanz / Lenkungsausschuss) über fünf Phasen: Antrag, Auswirkungsanalyse, Genehmigung, Basisplan-Anpassung sowie Umsetzung und Abschluss.
• Die Annahme über die Bahnen Antragsteller und Projektleitung: Änderungsantrag mit Beschreibung und Begründung stellen, Änderung im Register erfassen, dann das Tor „Antrag klar genug zur Bewertung?“, das dünne Anträge zum Antragsteller zurückschickt, um Details und Begründung zu ergänzen, bevor sie dieselbe Prüfung erneut durchlaufen.
• Die Auswirkungsanalyse in den Bahnen Projektteam und Finanzen: Umfang, Termine und Qualität bewerten, Kosten schätzen und Risiko bewerten, Kosten und Finanzierungsquelle prüfen und danach eine einzige dokumentierte Auswirkungsanalyse erstellen (mit Optionen, Empfehlung und der Nulloption) statt eines Kommentarverlaufs.
• Die Toleranzentscheidung „Innerhalb der Toleranz der Projektleitung?“, die Innerhalb zur Genehmigung in delegierter Befugnis und Überschritten zur Eskalation an den Lenkungsausschuss führt.
• Die Entscheidung der Änderungsinstanz „Genehmigen, ablehnen oder zurückstellen?“ mit drei beschrifteten Zweigen: Genehmigen in die Basisplan-Anpassung, Ablehnen zu einem Endpunkt in der Bahn des Antragstellers und Zurückstellen zu einem Halteschritt, der die Änderung in einer späteren Sitzung des Lenkungsausschusses erneut vorlegt.
• Von der Basisplan-Anpassung bis zum Abschluss: Basisplan des Projekts aktualisieren, Finanzen aktualisieren Budget und Kostenprognose, Änderung an Stakeholder kommunizieren, das Projektteam setzt die Änderung im Plan um, und die Lieferung wird bestätigt, bevor der Vorgang geschlossen wird.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben den Abschnitt zur Änderungssteuerung in einem Projektmanagementplan oder PMO-Handbuch und wollen den Weg vom Antrag bis zum neuen Basisplan auf einer Seite.
• Änderungen werden in Besprechungen und Chatverläufen vereinbart, sodass später niemand sagen kann, was genehmigt wurde, von wem, und was es an Kosten und Endtermin hinzugefügt hat.
• Sie wollen die delegierte Befugnis klären, bevor das nächste Projekt startet: Was darf die Projektleitung selbst auffangen, und was muss an den Lenkungsausschuss?
• Sie übergeben ein Projekt an eine neue Leitung oder briefen einen neuen Lenkungsausschuss und müssen zeigen, wie Änderungen an Umfang, Kosten und Terminen genehmigt werden.
• Ein PMO oder Programm vereinheitlicht die Änderungssteuerung über Projekte hinweg, die sie bisher jeweils anders handhaben, bevor ein Änderungsregister im Delivery-Tool konfiguriert wird.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihren echten Rollen

   Ersetzen Sie Antragsteller, Projektleitung, Projektteam, Finanzen und Änderungsinstanz / Lenkungsausschuss durch die Rollen, die es bei Ihnen wirklich gibt. In einem kleinen Projekt kann die Änderungsinstanz ein einzelner Auftraggeber sein und Finanzen ein Business Partner, der die Zahlen per E-Mail prüft. Führen Sie Bahnen zusammen, statt Gremien zu zeichnen, die nicht existieren, und halten Sie die Bahnenzahl bei fünf oder weniger, damit das Diagramm lesbar bleibt.

2. Schreiben Sie Ihre Toleranzen neben die Entscheidung

   „Innerhalb der Toleranz der Projektleitung?“ ist nur mit Zahlen dahinter nützlich. Halten Sie die Kosten- und Terminabweichung fest, die die Projektleitung genehmigen darf, dazu eine Umfangsregel wie: keine Änderung an vereinbarten Ergebnissen, am Nutzen oder an vertraglichen Zusagen. Wenn Sie nach PRINCE2 arbeiten, ist das die Toleranz, die der Lenkungsausschuss delegiert, gegebenenfalls mit einem Änderungsbudget, damit Routineänderungen das Gremium nie erreichen. Vereinbaren Sie die Grenzen beim Projektstart, nicht beim ersten Mal, wenn sie geprüft werden.

3. Definieren Sie, was die Auswirkungsanalyse enthalten muss

   Machen Sie aus „Auswirkungsanalyse dokumentieren“ eine echte Vorlage: Wirkung auf Umfang, Termine, Kosten, Qualität und Risiko, die Finanzierungsquelle, die geprüften Optionen, eine Empfehlung und die Nulloption. Benennen Sie, wer welche Dimension bewertet und wie viel Zeit dafür zur Verfügung steht, denn eine Analyse, die drei Wochen dauert, wird zu einer Entscheidung ohne Analyse.

4. Benennen Sie die Änderungsinstanz und ihren Turnus

   Halten Sie zur Sitzung des Lenkungsausschusses fest, wer genehmigt, ob ein Quorum nötig ist, wie oft getagt wird und wann der Annahmeschluss für die Tagesordnung liegt. Entscheiden Sie ausdrücklich, was zwischen den Sitzungen gilt: Entweder darf eine benannte Person dringend genehmigen und berichtet es in der nächsten Sitzung, oder die Änderung wartet. Das offenzulassen ist genau das, was zu Genehmigungen auf dem Flur führt.

5. Machen Sie die Zurückstellung befristet

   Eine zurückgestellte Änderung braucht einen Wiedervorlagetermin, einen Verantwortlichen und einen aktiven Status im Register: Deshalb führt der Zweig Zurückstellen hier zu einer späteren Sitzung des Lenkungsausschusses und nicht zu einem Endpunkt. Prüfen Sie zurückgestellte Punkte in jeder Sitzung und schließen Sie die überholten mit dokumentierter Begründung, damit das Register Entscheidungen abbildet, statt sie anzuhäufen.

6. Legen Sie die Regel für den neuen Basisplan fest, veröffentlichen und versionieren Sie das Diagramm

   Bestimmen Sie, welche genehmigten Änderungen einen förmlich neuen Basisplan auslösen und welche in die Prognose aufgenommen werden, und verlangen Sie, dass die Änderungsnummer an der neuen Basisplanversion vermerkt wird. Bewahren Sie frühere Basispläne auf, damit sich eine Abweichung auch Monate später noch erklären lässt. Teilen Sie das Diagramm dann dort, wo gearbeitet wird (neben dem Änderungsantragsformular und im Projekthandbuch) und führen Sie seine eigene Versionshistorie, damit erkennbar bleibt, wann sich das Verfahren geändert hat und warum.

Häufig gestellte Fragen

Worin unterscheidet sich ein Änderungsantrag im Projekt vom IT-Change-Management?

Sie beantworten unterschiedliche Fragen. Ein Änderungsantrag im Projekt fragt, ob ein vereinbarter Basisplan (Umfang, Kosten, Termine und oft der Nutzen) geändert werden soll, und die Entscheidung ist kaufmännisch: Was kostet es, was verzögert es, wer finanziert es, und trägt der Business Case noch? IT-Change-Management fragt, ob eine Änderung an einem laufenden Service ausgerollt werden soll, und die Entscheidung ist betrieblich: Risiko für Nutzer, Tests, Wartungsfenster und Rollback. Geht es um CAB, Änderungskalender und Rollback-Plan, nehmen Sie das Flussdiagramm zum Change-Management-Prozess. Geht es um einen Lenkungsausschuss, einen neuen Endtermin und eine Budgetposition, ist dieses Diagramm das richtige.

Was sollte ein Änderungsantrag im Projekt enthalten?

Genug, damit eine andere Person ihn ohne Besprechung bewerten kann: was sich ändern soll und warum, wer ihn wann gestellt hat, den Auslöser (eine neue Anforderung, ein Fehler, eine externe Abhängigkeit, eine revidierte Entscheidung), die Dringlichkeit, wer betroffen ist und was passiert, wenn sich nichts ändert. Die Bewertung ergänzt den Rest: Wirkung auf Umfang, Termine, Kosten, Qualität und Risiko, die Finanzierungsquelle, die geprüften Optionen und eine Empfehlung. Führen Sie beides als getrennte Dokumente. Der Antrag sind die Worte des Antragstellers, die Analyse ist die Antwort des Projekts: Beides zu vermischen macht es unmöglich, später zu erkennen, was ursprünglich verlangt wurde.

Wer genehmigt einen Änderungsantrag im Projekt?

Das hängt von der Größe ab, und genau dafür ist die Toleranzentscheidung in diesem Diagramm da. Änderungen, die in die beim Projektstart delegierte Abweichung passen, werden in der Bahn Projektleitung genehmigt und dokumentiert. Alles darüber hinaus geht an die Änderungsinstanz, üblicherweise den Lenkungsausschuss oder den Auftraggeber. PRINCE2 benennt die Änderungsinstanz als Rolle, die der Lenkungsausschuss delegieren kann, mitunter mit einem Änderungsbudget, damit Routineänderungen keine Gremienentscheidung brauchen; die integrierte Änderungssteuerung nach PMI nutzt für denselben Zweck ein Change Control Board. Wie Sie es auch nennen: Schreiben Sie die Grenzen auf. Eine undefinierte Toleranz bedeutet, dass entweder alles eskaliert wird oder nichts.

Was bedeutet es, eine Änderung zurückzustellen?

Dass die Entscheidung vertagt und nicht abgelehnt wird: meist, weil die Auswirkung noch unklar ist, die Änderung von einer anderen Entscheidung abhängt oder in eine spätere Phase oder ein späteres Release gehört. Das funktioniert nur, wenn die Zurückstellung befristet ist. In diesem Diagramm führt der Zweig Zurückstellen zu einem Halteschritt, der die Änderung in einer späteren Sitzung des Lenkungsausschusses erneut vorlegt, und nicht zu einem Endpunkt, denn eine zurückgestellte Änderung ohne Rückweg ist eine Ablehnung, die niemand begründen musste. Geben Sie jedem zurückgestellten Punkt einen Wiedervorlagetermin, einen Verantwortlichen und einen sichtbaren Status im Register.

Muss nach jeder genehmigten Änderung ein neuer Basisplan erstellt werden?

Erstellen Sie einen neuen Basisplan für alles, was ändert, was das Projekt liefert, bis wann und zu welchen Kosten. Sonst misst die Abweichungsberichterstattung gegen einen Plan, den Sie bereits aufgegeben haben, und jeder Statusbericht braucht eine mündliche Erläuterung. Bewahren Sie die vorherigen Basispläne auf, statt sie zu überschreiben, vermerken Sie die Änderungsnummer an der neuen Version und halten Sie das Genehmigungsdatum fest. Kleine, innerhalb der Toleranz genehmigte Änderungen werden üblicherweise in die Prognose aufgenommen, statt einen förmlich neuen Basisplan auszulösen: Legen Sie in Ihrem Plan fest, was wofür gilt, damit zwei Personen denselben Bericht auf dieselbe Zahl bringen.

Wie bremst dieser Prozess Scope Creep?

Indem er die Kosten einer Änderung sichtbar macht, bevor sie vereinbart wird, statt nachdem sie geliefert ist. Scope Creep, die schleichende Ausweitung des Umfangs, ist selten eine einzige große Entscheidung; er ist eine Reihe kleiner Ergänzungen, die ein Team auffängt, ohne sie je zur Bewertung zu geben. Entscheidend sind hier drei Kontrollen: das Register, damit jeder Antrag einen Nachweis hat; die Auswirkungsanalyse, damit niemand eine Ergänzung genehmigt, ohne ihre Wirkung auf Termine und Budget zu sehen; und die Toleranzgrenzen, damit die Projektleitung genau weiß, wo die eigene Befugnis endet. Der Prozess kann Änderungen nicht verhindern und soll es auch nicht: Er macht sie bewusst und zurechenbar.