Podcast-Folge #27
Wie du Änderungen in komplexen Projekten managest und Scope Creep vermeidest

#27 Änderungen auch in komplexen Projekten meistern

Die gleichen sieben Schritte, die wir in Folge #26 für einfache Projekte kennengelernt haben, sind auch die Grundlage für den Prozessablauf, um Änderungen in komplexen Projektumgebungen zu managen.

Änderungen in komplexen Projekten ... wie du sie erfolgreich managest

Was ist ein komplexes Projekt?

Komplex meint, dass nicht alle Anforderungen zu Beginn vorliegen oder zumindest nicht in allen Punkten Einigkeit im Projektteam herrscht. Auch könnte es sein, dass es unter den beteiligten Stakeholdern noch verschiedene Auffassungen gibt, mit welcher Herangehensweise die Ergebnisse erreicht werden sollen. Demnach müssen unterschiedliche Lösungswege noch diskutiert und ausprobiert werden, um das Projekt zum Erfolg zu führen.

Komplex könnte dein Projekt auch sein, wenn aus regulatorischen bzw. aus Compliance-Gründen sehr viele Stakeholder in den gesamten Ablauf von Änderungen involviert werden müssen. Dann muss der Ablauf sehr häufig detailliert belegt, bestimmte Zwischenschritte schriftliche dokumentiert, Freigaben erteilt und Unterschriften geleistet werden. Im Bereich Pharma, in der Medizintechnik oder auch in der Lebensmittelindustrie, wo strenge Nachverfolgungsvorschriften gelten, ist das gängige Praxis.

Gleiches gilt für ähnliche Branchen, in denen fixe Zulassungsrichtlinien gelten. Dort kann eine Änderung z. B. nach sich ziehen, dass eine Firma die Zulassung für das Vermarkten eines Produkts verliert oder Personen zu Schaden kommen. Nur zu gut verständlich, dass dann mehrere Entscheider:innen stufenweise involviert sind.

Die Kernfrage dieser Folge lautet: Wie läuft das dort also genau ab?

Folge #27 anhören:

Das Skript zur Folger hier herunterladen

Schaubild: 7-Schritte-Ablauf-Plan zum Managen von Änderungen in komplexen Projekten

Schaubild herunterladen: 7-Schritte-Ablauf-Plan zum Managen von Änderungen in komplexen Projekten

Prinzipiell folgen du und ich nun wieder den universellen sieben Schritten.

Diesmal gehen wir aber auf jeden einzelnen davon sehr viel umfangreicher ein. Denn teilweise braucht es bewusst Iterationen (Schleifen) als eine Art Qualitätskontrolle für eingereichte Änderungen. Schnapp du dir gerne Zettel und Stift und skizziere dir den Ablauf mit.

In den Shownotes verlinke ich dir ein Schaubild zum Abgleich. Für dich ist das Skribbeln auf deinem eigenen Zettel allerdings die Chance, dir gleich zu notieren, wie euer Anforderungs-Änderungs-Management-Prozess künftig aussehen soll – ganz unabhängig vom Schaubild.

Legen wir los mit Schritt 1, dem Entgegennehmen des Änderungsantrags.

Das kann in komplizierten und auch in hoch regulatorischen Projekten nicht einfach irgendwie erfolgen. Jede:r der/die eine Änderung wünscht, hat hier einen tatsächlichen Antrag zu stellen. Schriftlich oder digital, das spielt keine Rolle. In jedem Fall sind ganz bestimmte Angaben erforderlich. Darin werden dann alle essentiellen Punkte dokumentiert – wie bspw. die Dringlichkeit, der Anlass und Grund des Änderungswunsches, die Begründung der Notwendigkeit. Idealerweise wird auch der Bezug zur ursprünglichen Anforderung hergestellt bzw. darauf verwiesen, was im Projektauftrag vereinbart wurde. Auf diesem Weg kann auch abgefragt und damit gleich kategorisiert werden, ob es sich um eine Änderung, eine neue Anforderung oder das Streichen von Anforderungen handelt. Viele andere Prozedere zum Entgegennehmen sind denkbar. Hier sieht der Antrag je nach Firma und Projektkontext ganz unterschiedlich aus.

Du denkst dir womöglich gerade, dass das ja schon ganz schön aufwendig ist. Doch der erhöhte Aufwand hat auch seine Vorteile, gerade in einem komplexen Umfeld. Dort ist der Aufwand häufig sogar Absicht. Denn so wird der Änderungswunsch natürlich schon mit dem Einreichen auf den Prüfstand gestellt. Der Antragsteller oder die Antragstellerin werden sich schon hier von ganz alleine überlegen „ist das jetzt nice-to-have oder ganz essentiell?“ Und wenn der Änderungsantrag gleichzeitig so viele Informationen abverlangt, wird sich meist hier schon genau überlegt, wie die Änderungen oder neuen Anforderungen so präzise wie möglich beschrieben und begründet werden können. Damit es die Zeit auch wert ist. Ein „mal-eben-über-den-Zaun-werfen“ ist nicht.

Und das Projekt über Änderungen zu steuern wird dann auch echt mühsam. Es mag zwar witzig klingen, doch dass ein Projekt über Änderungen gesteuert wird, habe ich sogar schon öfter erlebt. Manchmal absichtlich, gerade in agilen Projekten, dort ist es gewollt. Doch viel häufiger geschieht es ungewollt – vor allem in klassisch gemanagten Projekten. Wenn die Beteiligten schlicht am Anfang verpasst haben, für Klarheit in der Beauftragung und Abgestimmtheit in der geplanten Umsetzung zu sorgen.

Dann gesellen sich in regelmäßigen Abständen neue Umfänge, neue Anforderungen und Änderungswünsche hinzu und das Projektteam ist ungewollt gezwungen in Iterationen zu arbeiten. Was sehr frustrierend sein kann, gerade weil man sich denkt: „Hätte nicht mal einer/jemand oder zur Not auch man zu Beginn des Projektes die Hausaufgaben machen können, dann würde es nicht einmal Hü und einmal Hott heißen?! Denn jetzt müssen wir das jeden Tag aufs Neue ausbaden und wissen nicht, was alles noch kommt.“
Wie Axel Hacke mal erklärte, sind Einer, Jemand und Man echt tolle Mitbewohner(innen) – ihnen kann man herrlich die Schuld zuschieben. Nur kümmern sie sich nie um irgendwas. Über Rollen und Verantwortlichkeiten haben wir uns deshalb in den Folgen #15 und #16 unterhalten.

Doch zurück zum Änderungsantrag hier in Schritt 1 – jep, wird sind immer noch im Prozessschritt eins. Diese Änderungsanträge sind auch noch für etwas anderes gut. Spätestens bei der Beurteilung der Änderungen lässt sich durch eine einheitliche Vorlage zur Beschreibung von Änderungen auch viel leichter eine Kategorisierung realisieren, die das schnelle Vergleichen und Priorisieren von Änderungswünschen erleichtert. Das trifft dann natürlich auch auf eine erste grobe Beurteilung der Auswirkungen, also des tatsächlichen Änderungsumfangs, zu. Du siehst: In Schritt 1 steckt schon eine Mange Zündstoff für Pulverfässer, die in deinem Projekt hochgehen können.
Schritt 2: Dokumentation.

Da die ja mit dem Antrag schon sehr ausführlich vorliegt, geht es nun nur noch darum, den Antrag so abzulegen, dass dieser von allen relevanten Personen eingesehen werden kann. Häufig kommen dafür spezielle IT-Programme zum Einsatz. Dort wird dann auch der Eingang bestätigt, ihr hinterlegt einen Status und fügt weitere Metadaten hinzu, die für eine hinreichende Dokumentation erforderlich sind. Da können die Auflagen dahingehend, was Transparenz bei dir im Projekt bedeutet, ganz unterschiedlich aussehen. Auf jeden Fall erreicht ihr so, dass nichts verloren geht und auch nur Änderungen bearbeitet werden, die so erfasst und abgelegt wurden. In gewisser Weise ist das also neben dem Antrag selbst ein zweiter, automatischer Filter, um das Projektteam vor unnötigen Störungen zu schützen.

An der Stelle will ich es dennoch nicht missen, auf eine Gefahr hinzuweisen. Die ist psychologischer Natur. Bei aller Prozessliebe und dem Wunsch nach geregelten Bahnen gebe ich dir ein großes OBACHT mit: Wenn es sehr aufwendig ist, eine Änderung zu beantragen, kann es dazu kommen, dass Änderungswünsche (obwohl sie notwendig und sinnvoll wären) nicht hervorgebracht werden. Einfach weil es an Zeit oder Nerven dafür fehlt. Oder der Ablauf nicht bekannt ist. Dann läuft das Projektteam Gefahr, wider besseren Wissens an den falschen Dingen zu arbeiten, weil sich die Beteiligten vor allzu viel Bürokratie scheuen.

Für dich heißt das: Wäge stets ab, wie hoch ihr die Hürden zur Beantragung von Änderungen hängen wollt. Macht ihr es zu einfach, werdet ihr im schlimmsten Fall regelrecht vollgespamt, und zwar mit jedem Quatsch, teilweise völlig unqualifiziert. Sind die Hürden zu hoch, nimmt es niemand mehr auf sich, Änderungen und Verbesserungswünsche vorzubringen. Formalien bremsen dann den gesunden Menschenverstand aus und ihr haltet euch selbst davon ab, bessere Ergebnisse zu liefern.

Wer kennt noch den berüchtigten Passierschein A38 aus dem Asterix und Obelix Film? Ja, du weißt schon, was ich damit sagen will: Ich empfehle dir stets mit Augenmaß und zielgerichtet vorzugehen. Ihr wollt ja Projekte managen und nicht den Beamtenstatus erwerben.
Schritt 3: Analyse und Bewertung.

Zurück zum Prozess: Antrag gestellt, Antrag dokumentiert, also ab zu Schritt 3. Das ist die Analyse und Bewertung. Wobei das im komplexen Projekt meist gestaffelt abläuft. Wir beide unterteilen mal in 3a und 3b.

In 3a) findet nun zunächst eine erste grobe Bewertung statt. Die zentralen Fragen sind: Ist die Änderung im Scope des Projekts oder nicht? Handelt es sich um eine neue Anforderung oder kann sie einer bestehenden zugeordnet werden? Auch wird hier „von oben drauf schauend“ geprüft, ob die Änderung wirklich nötig und zielführend ist – also einen Mehrwert verspricht. Dabei wird gerne mal festgestellt, dass der Antrag unzureichend ausgefüllt wurde oder ohne Rückfragen nicht zu behandeln ist. Gar nicht zu selten werden hier also Fragen gesammelt und an den/die Antragsteller:in zurückgesandt. Und zack kommt beim Schritt 2, der Dokumentation, das Thema Versionierung hinzu. Diesen ersten Schritt 3a erledigt häufig ein Change Board, das dem Projektteam extra für diesen Zweck vorgeschaltet ist. Das kann auch Teil der Portfoliosteuerung sein. Ziel ist es, auf jeden Fall hier noch nicht das Projektteam zu behelligen. Dafür sitzt hier also ein Kreis von Expert:innen bzw. Fachleuten, die regelmäßig zusammenkommen, um alle Änderungsanträge aller Projekte zu prüfen und grob zu begutachten. Nur wenn der Antrag dort durch ist, also nicht abgewiesen wurde, geht es zu Schritt 3b.

3b) ist die detaillierte Begutachtung. Wenn der Antrag also korrekt vorliegt und nach grober Prüfung prinzipiell gerechtfertigt ist, erfolgt jetzt die nähere Analyse und Beurteilung in Bezug auf die Auswirkungen und Implikationen auf das Projekt. Das erfolgt dann von den Experten aus dem Projektteam. Zusammen mit dir als Projektleiter:in wird dann auch geprüft, welche Planänderungen der jeweilige Änderungsantrag nach sich ziehen würde. Diese detaillierte Analyse wird dann wieder dem Change Board zur Revision vorgelegt. Erst dann wird über den Antrag final entschieden. Vorher werden allerdings oft nochmal weitere Informationen von den Antragsteller:innen abgefragt und sogar regelrecht verhandelt.
Die Entscheidung über den Antrag ist dann schon Schritt 4.

Auf Basis der erfolgten Analyse und Bewertung kann immer noch herauskommen, dass die Änderung nicht genehmigt wird. Wenn es allerdings grünes Licht gibt, dann stellst du sicher, dass alle Unterschriften eingesammelt werden, der Antrag als genehmigt im System dokumentiert ist und es geht weiter mit Schritt 5.
Schritt 5: die Implementierung.

Das Projektteam bekommt also die Anweisung, die Umsetzung einzuplanen und alles notwendige an Korrekturleistungen in die Wege zu leiten. Nun kann es wieder extrem hilfreich sein, alles bis hier her präzise dokumentiert zu haben. Seien es die Änderungen in Bezug auf Lösungswege, Projektziele, Testprozeduren, Teilergebnisse oder auch Zeitpläne und Budget. Die Kommunikation an alle relevanten Stakeholder wird so bedeutend einfacher, denn es ist ja bereits alles beschrieben. Auch der/die Antragsteller:in weiß nun genau, was beschlossen wurde und ab hier läuft die Erwartungshaltung der Stakeholder in Bezug auf die Projektergebnisse hoffentlich wieder synchron. Und der Änderungsantrag kann zu den Akten gelegt werden. Fast. Du weißt natürlich, dass noch zwei weitere Schritte fehlen.
Schritt 6 ist die Kontrolle, ob die Änderungen eingearbeitet wurden.

Ist das erfolgt, bekommt der Änderungsantrag meist noch einen zweiten Stempel. Nummer 1 war der „genehmigt und zur Umsetzung freigeben“. Nummer 2 ist nun der Stempel „Umsetzung erfolgt, Antrag kann geschlossen werden.“
Und in Schritt 7 wird der Status des Änderungsantrags auf erledigt gesetzt und der Antrag selbst final archiviert.

Das inkludiert das Aktualisieren des Status im Programm, in dem ihr die Anträge verwaltet. So liefert dann das System zuverlässige Reports, wie viele Änderungen in welchem Status der Umsetzung sind, sofern sie genehmigt wurden. Solche Reports, also Berichte, sind dann meist Teil des Berichtswesens in deinem Projekt und du wirst darüber in gewisser Weise auch dein Projekt steuern. Hoffentlich nicht ausschließlich.

Im Unterschied zu einfacheren Projekten …

Alles in allem können diese 7 Schritte, wie du siehst, in einen echt aufwendigen, sehr formalisierten Prozess mitsamt Reports münden! Obwohl im Kern dasselbe passiert wie im einfacheren Projekt aus Folge #26. Das hoch regulierte, gerade durchexerzierte Projekt geht nur deutlich weiter in die Tiefe und erlaubt es, dass mehrere Stakeholder parallel und systematisch an Änderungen arbeiten. Wie schnell der Prozess damit von statten geht, steht auf einem anderen Blatt.

„Den Ablauf richtig zu dokumentieren sorgt für Nachvollziehbarkeit und Klarheit.“

Das hängt sicher u.a. davon ab, wie oft das Change Board tagt und wie viele Anträge eingehen. Da das in komplizierten Projekten jedoch meist sehr viele sind und sichergestellt werden muss, dass diese auch untereinander in Bezug gesetzt werden, dauert dieser Ablauf i.d.R. deutlich länger. Er bietet jedoch, richtig dokumentiert, extrem hohe Nachvollziehbarkeit und Klarheit, also Transparenz. Im Idealfall schützt der Ablauf das Projektteam vor ungewollten Störungen, gibt euch also Fokus und erlaubt es allen Involvierten, nicht nur die Dinge richtig zu machen, sondern auch an den richtigen Dingen zu arbeiten.

Und das führt uns zur Kernbotschaft dieser Folge:

Ja, Änderungen können lästig sein, doch, und das ist die Botschaft, sie stellen sicher, dass ihr die Dinge nicht nur richtig macht, sondern dass ihr auch die richtigen Dinge macht. Und dein Projekt damit zum Erfolg und zu einem zufriedenen Kunden führt. Ganz sicher nicht zu deinem Nachteil. Und darum geht es dir und mir ja.

Reflexion

Was uns zur Reflexion führt. Wie du erkannt hast, ist die größten Herausforderung im Kontext des Änderungsmanagement, eine einheitliche Struktur zu kreieren. Ein systematisches Vorgehen, sodass die Änderungen den relevanten Stakeholdern bekannt sind. Du willst also über Transparenz brillieren. Und das wirst du dadurch.

„In der Projektrealität landen Änderungswünsche häufig irgendwo irgendwie.“

Denn wie sieht denn der Projektalltag im echten Leben oft aus?

Häufig landen die Änderungswünsche doch eher irgendwo irgendwie. Am liebsten in Emails – soweit will man es noch schriftlich. Dann werden alle weiteren Infos zwischen den Beteiligten irgendwie ausgetauscht, es wird verhandelt und beliebige Details besprochen. Das gerne am Telefon – schriftlich ist das schließlich zu zeitraubend. Wenn schriftlich, dann ohne jedwede Struktur. Nur damit es dann genauso unstrukturiert geteilt, weitergeleitet, abgearbeitet und kommuniziert wird. Wozu gerne prosaische Meisterwerke von Emails über größtmögliche Verteilern geschrieben werden. Immer in der Hoffnung, damit zufällig alle relevanten Stakeholder zu erreichen. Gerne mit dem Zusatz „Wenn ich wen vergessen habe, bitte einfach weiterleiten“. Auch toll: Flammenreden vor wichtigen Projektmeetings – dann also gar nix schriftlich, und wer nicht da war, erfährt es hoffentlich über den Flurfunk.

Und natürlich dauert die Bearbeitung von Änderungswünschen ganz unterschiedlich lang. Und deren Priorität ist entweder vom Rang des Stakeholders oder der Tageslaune der Person abhängig, die den Änderungswunsch in Empfang nimmt. Immer scheint alles dringend und wichtig zugleich zu sein – und nicht selten stehen Standpunkte statt Interessen und Mehrwert des Änderungsvorschlags im Mittelpunkt der Diskussion. Ganz schlimm finde ich persönlich Ansagen wie: „Los, macht! Das haben wir so beschlossen!“
Aus Prinzip löst der Satz bei mir schon Aversionen aus.

Scope Creep – was ist das und wie lässt er sich vermeiden?

Willkür statt System führen dann dazu, dass schon nach wenigen Wochen im Projekt längst alle den Überblick verloren haben. Von der Qualität der Ergebnisse und der Stimmung im Team sprechen wir gar nicht erst. Und müssen wir auch nicht. Immerhin wissen du und ich, dass es nur 7 Schritte sind, die dem Einhalt gebieten können. Welch Erleichterung!

Du wirst dann auch nicht so leicht von einer Sache geplagt, die als Scope Creep bekannt ist. Das ist immer dann der Fall, wenn sich der Scope des Projektes verschiebt, ohne dass den Beteiligten dies bewusst ist. Es wird an Dingen gearbeitet, die ihren Weg unkontrolliert in die ToDo-Listen der Mitarbeitenden gefunden haben. Das kann zwar gut vom Kunden gewünscht worden sein ggf. denkt der aber, alle Aufwände sind eh im Projektpreis inbegriffen.

Die Arbeit für dich und dein Team ufert im Fall von Scope Creep aus – mit dem Budget kommen du und dein Team vorne und hinten nicht hin. Und weil es nirgends dokumentiert wurde, stellt ihr es dem Kunden auch nicht in Rechnung. Viel eher kompensiert ihr es durch eigene, unbezahlte Überstunden. Und das dann niemand mehr Lust auf Änderungen hat, sondern lieber stur Plänen folgt, wem können wir das jetzt noch übelnehmen? Dann heißt es „Adé Agilität“. Pläne zu verwalten wird so zum reinen Selbstschutz, auch wenn es alle Beteiligten besser wüssten. Nur um sich vor Änderungen, Scope Creep und Mehrarbeit zu schützen. Also: ran an den 7-Schritte-Plan und Scope Creep ist Geschichte!

„Ist allen klar, was ihr mit dem Projekt erreichen wollt?“

Was abschließend zu sagen bleibt und unheimlich wichtig ist, das sehen wir beide: Es ist entscheidend, zu wissen, was du/ihr überhaupt mit dem Projekt erreichen willst/wollt. Nur so lässt sich beurteilen, ob ein Änderung Sinn macht, in den Scope des Projekts passt oder ganz woanders hingehört. Hinterfrag also stets, ob du und dein Projektteam überhaupt die richtigen Adressat:innen sind und mit der Änderung auch tatsächlich Mehrwert kreiert wird.

Mission Statement oder Scope Statement sind da die richtigen Begrifflichkeiten. Sie sollten Teil deines Projektauftrags sein und stehen häufig als der eine Satz oder als ein Absatz in Textform über dem Projekt. Wenn dein Projekt so etwas als Teil des Projektauftrags hat, dann fällt es dir leicht zu entscheiden, ob etwas „in Scope“ oder „out of Scope“ ist. Entsprechend landet es auf eurer ToDo-Liste oder auf der Not-to-do-Liste. Die Frage ist also, ob es Wert zum Ergebnis beiträgt oder nicht. Und ob der Mehrwert vom Kunden geschätzt und bezahlt wird.

Auf zur Brillanz

Ganz wichtig sind auch die zugrundeliegenden Hypothesen bzw. Annahmen – deshalb gehören sie auch unbedingt in jedes Mission oder Scope Statement.

„Bedenke: ändern sich grundlegende Annahmen, ändert sich ggf. auch der Scope.“

Ändern sich die Annahmen, kann es gut sein, dass sich auch der Scope ändert. Eine Annahme wäre z.B. dass man ein bestehendes Produkt aus den USA, sagen wir einen Corona-Impfstoff der dort hergestellt und vertrieben wird, jetzt auch in Europa zulassen und verkaufen kann. Dann bedeutet das, dass keine komplette Produktneuentwicklung stattfinden muss. Außer es stellt sich dann zu einem späteren Zeitpunkt heraus, dass der Impfstoff hier doch keine Zulassung erhält. Dann ändert sich die Situation für das Projekt dramatisch – immerhin jedoch ganz bewusst und somit planbar. Du siehst, mal wieder wird am Anfang der Grundstein für dein Projekt gelegt. Und dieser Grundstein gibt dir dann auch beim Thema Änderungen eine super Orientierung.

Damit bin ich, bist du, am Ende der fünfteiligen Reihe zum Thema erfolgreiches Managen von Änderungen angelangt. Ich hoffe, der Kopf schwirrt dir nur ein wenig und du bist motiviert, das Gehörte ganz professionell in deinem Projekt umzusetzen. In dem Thema stecken viele Facetten, Tipps, Tricks, Achtung-Vorsichts und Stolperfallen. Auch ist es leicht, das Thema Änderungsmanagement zu übertreiben, zu bürokratisieren, somit kostbare Zeit zu verlieren und das Team zu nerven. Wäge also mit all dem gesammelten Wissen ab, wie du (bzw. wie ihr) das Ganze als Projektteam in eurem Projekt angehen wollt.

Und wenn du Fragen hast, wende dich sehr gerne an mich.
Du findest hier auch alle Skripte zu den „Projektmanagement on demand“ Podcast-Folgen. Online und in voller Länge veröffentlicht – so kannst du alles noch mal nachlesen. Stell also sicher, dass du auf dem Laufenden bleibst und vernetze dich mit mir auf LinkedIn oder schreib mir eine E-Mail an chris@pm-botschaft.com.

Bis dahin: viel Erfolg beim weiterhin Durchstarten in deinem Projekt, berichte gerne mal, wie es dir ergeht und ob du mit dem Input von mir hier gut voran kommst. Über Feedback und Erfolgsgeschichten freue ich mich natürlich total.

Dir von Herzen nur das Beste und auf zur Brillanz!

Chris

Folge #26

Folge #28