Podcast-Folge #27
Änderungen auch in komplexen
Projekten meistern

-> Zur Übersicht aller Folgen

Folge #27 lesen:

Die gleichen 7 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. 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, respektive noch unterschiedliche Lösungswege diskutiert werden und ausprobiert werden müssen, 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 und eine Änderung z.B. nach sich ziehen kann, 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 also:

Wie läuft das dort
also genau ab?

Prinzipiell folgen du und ich nun wieder den universellen 7 Schritten, jedoch ist jeder Einzelne davon sehr viel umfangreicher. Und teilweise mit bewussten Iterationen, also Schleifen als eine Art Qualitätskontrolle für eingereichte Änderungen verbunden. 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.

Folge #27 anhören:

Shownotes  Folge #27

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


  1. 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 wird dann alles Essentielle dokumentiert, wie bspw. die Dringlichkeit, der Anlass und Grund des Änderungswunsches, die Begründung der Notwendigkeit. Idealerweise wird auch Bezug genommen auf die ursprüngliche Anforderungen bzw. 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. Vieles mehr ist 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 aufwändig 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 und ungewollt vor allem in klassisch gemanagten Projekten, weil die Beteiligten schlicht weg 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 – 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 – 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 Änderungsumfang, zu. Du siehst, in Schritt 1 steckt schon ne Mange Zündstoff für Pulverfässer, die in deinem Projekt hochgehen können.
  2. Schritt 2 ist dann die 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 aufwändig 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 Projekt-Team 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 wollte. 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.

3. Zurück zum Prozess: Antrag gestellt, Antrag dokumentiert, also ab zu Schritt 3. Das ist die Analyse und Bewertung. Wobei diese im komplexen Projekt meist gestaffelt ablaufen. 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 Projektes 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, dass extra für diesen Zweck dem Projektteam vorgeschalten 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 Experten 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 Änderungsanstrag 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 Antragstellern abgefragt und sogar regelrecht verhandelt.

4. Die Entscheidung über den Antrag ist nämlich 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 geht über zu Schritt 5.

5. Das ist 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 so 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 laufen Erwartungshaltung der Stakeholder und Projektergebnisse hoffentlich wieder synchron. Und der Änderungsantrag kann zu den Akten gelegt werden. Fast. Du weißt natürlich, dass noch 2 Schritte fehlen.

6. Schritt 6 ist auch hier die Kontrolle, ob die Änderungen eingearbeitet wurden. Ist das erfolgt bekommt der Änderungsantrag meist noch einen 2ten Stempel. Nummer 1 war der „genehmigt und zur Umsetzung freigeben“. Nummer 2 ist nun der Stempel „Umsetzung erfolgt, Antrag kann geschlossen werden.“

7. 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.

Alles in allem können dieselben 7 Schritte, wie du siehst, in einen echt aufwändigen, 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 und hängt sicher 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. 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, 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. Toll auch 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: „Macht! Das haben wir so beschlossen!“. Aus Prinzip löst der Satz bei mir schon Aversionen aus.

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!

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 To-Do-Liste oder auf der Not-to-do-Liste. Ob es also Wert zum Ergebnis beiträgt oder nicht. Und ob der Mehrwert vom Kunden geschätzt und bezahlt wird.

Ganz wichtig sind auch die zugrundeliegenden Hypothesen bzw. Annahmen – deshalb gehören sie auch unbedingt in jedes Mission oder Scope Statement. Ä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 Ganze 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, wie ihr das Ganze als Projektteam in eurem Projekt angehen wollt. Und wenn du Fragen hast, wende dich sehr gerne an mich. Künftig will ich auch die Skripte komplett veröffentlichen – dann 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!

Zur Übersicht aller Folgen

Hier kannst du mich überall hören:

Fragen, Wünsche, große Ziele?
Auf der Suche nach Abkürzungen, Tipps und Schlüsselerkenntnissen?

>