#26 How To: Dein 7-Schritte-Plan zum Meistern von Änderungen

Das Thema Änderungen ist wahrlich mächtig. Nach nun drei Folgen zu Grundlagen und Grundverständnis, gibt es jetzt das ganz konkrete How To. Nach all dem WAS und dem WARUM folgen nun das WIE GENAU und WAS WENN. Wir gießen all dein bis dato erlangtes Wissen zum Thema Änderungen von Anforderungen in einen 7-Schritte-Ablaufplan für dein Projekt. Und erarbeiten uns so ein Schema zum erfolgreichen, strukturierten und systematischen Umgang mit Änderungen im Projektverlauf. Das ist das WIE.

Das WAS WENN heißt dann, dass du und ich gemeinsam beleuchten, wie das passend zur jeweiligen Projektgröße aussehen kann. Denn was wir nicht wollen, da gibst du mir sicher recht, ist, dass du und dein Team nur noch Änderungen und keine Projekte mehr managen. Ich stehe auf Pragmatismus und habe selbst erlebt, wie zu strenge und starre Prozessvorgaben ein Team auch überfordern können.

In dieser und der nächsten Folge beantworten wir daher folgende Kernfragen:

1. Wie genau managst du jetzt Änderungen – also jetzt ganz in echt, Schritt für Schritt?
2. Was ist die Regel, der Standard? Und was sind die Ausnahmen zur Regel?
3. Wie lässt sich das je nach Projektgröße skalieren?
4. Und was genau ist deine Aufgabe als Projektleiter:in bzw. was genau trägt dein bei?

Der Inhalt erstreckt sich über zwei Folgen (diese und Nummer #27), damit jede Einzelfolge greifbar, kurz und prägnant auf den Punkt bleibt. Und damit schon genug der einleitenden Worte. Auf geht‘s zum konkreten Umgang mit Änderungen in deinem Projektalltag. Bist du dabei?

7-Schritte-Plan

Yes, springen wir direkt rein in dein Projekt. Egal ob dein aktuelles Projekt klein und kurz oder groß und komplizierter Natur ist, die sieben zugrundeliegenden Schritte der nachfolgenden Methode sind immer gleich. Die Herangehensweise, die ich dir mitgebracht habe ist also allgemeingültig und unterscheidet sich je nach Projekt lediglich dahingehend, wie umfangreich jeder einzelne der Schritt ist.

Sehen wir uns alle sieben der Reihe nach an:

1. Schritt 1: Zunächst nimmst du, nehmt ihr, einen Änderungswunsch oder Änderungsantrag oder im Englischen Change Request entgegen. Das kann sehr formalisiert erfolgen, wie das Wort Antrag schon sagt (und das ist auch gut in komplexen Umgebungen – warum? Darauf schauen wir im Verlauf der Doppelfolge noch im Detail). Das kann aber auch ein simples Telefonat, eine E-Mail oder das Hast-du-mal-ne-Minute-Gespräch zwischen Tür und Angel sein. So ein Änderungswunsch kann den Weg also auch reichlich informell zu dir finden. Das ist Schritt eins. Zu beachten ist, dass dieser Änderungswunsch prinzipiell von jedem Stakeholder kommen kann. Also von deinem Kunden, deinem Auftraggeber, Lieferanten, genau wie auch mitten aus deinem Team oder sogar von dir selbst. Häufig entstehen Änderungswünsche nämlich auch aus Projektstatusmeetings heraus, weil der Status deines Projekts eben nicht okay ist und nachgesteuert werden muss. Dem Thema Projektstatusmeeting widmen wir uns übrigens in Folge #28.
   
2. Es folgt Schritt 2. Da geht es darum, den Änderungswunsch sauber zu erfassen bzw. zu dokumentieren und zu verstehen. Der ist extrem wichtig, um Transparenz zu schaffen. Erinnerst du dich daran, was wir in der vorangegangenen Folge #25 als WEG VON / HIN ZU / UM ZU beschrieben haben? Alle relevanten Personen sollten diesen Änderungswunsch transparent einsehen können und es sollte auch von allen verstanden werden können, was da gewünscht wird und warum. Das Warum wird gerne mal weggelassen oder unklar ausgedrückt. Mein Tipp: Besteht darauf! Denn erinnerst du dich an die vierte Facette einer jeden Änderung? Jep, ganz richtig, jede Änderung kostet Energie. In deinem Projekt bedeutet das: es braucht einen Invest. Entweder von Zeit oder Budget. Mindestens, um die Änderung zu dokumentieren und zu kommunizieren. Und diesen extra Aufwand, für den musst du wahrscheinlich jemanden motivieren. Wie soll das gehen, wenn der Sinn und Zweck der Änderung im Verborgenen bleibt? Lässt man das „Warum“ weg, folgt ein stumpfes Ausführen von Anweisungen. Und so sollte es nur unter enormen Zeitdruck laufen oder dann, wenn Menschenleben auf dem Spiel stehen und Schaden abgewendet werden muss. Was in Krisenprojekten oft der Fall ist. In allen anderen Projekten sollte es statt um Law & Order (was reinem Befehle empfangen und umsetzen entspricht), lieber um echte Zusammenarbeit gehen.
   
3. Ist der Änderungswunsch soweit im Kasten, dann folgt jetzt die darauf aufbauende Analyse. Das ist Schritt 3. Hier findet auch die Beurteilung statt, welche Auswirkungen die Änderung voraussichtlich hat. Auch diese Analyse kostet Aufwand, obwohl noch nichts beschlossen wurde. Diesen Aufwand unterschätzen die Bittsteller:innen eines Änderungswunsches gerne mal. Dann wird nach x Szenarien gefragt und überdies vergessen, dass währenddessen all diejenigen, die in die Analyse eingebunden sind, nicht an ihren ursprünglichen Arbeitspaketen weiterarbeiten können. Es ist also fast wie ein temporäres Abziehen der jeweiligen Ressourcen vom Projekt. Also Achtung, wenn du das Gefühl hast, dass aktuell zu viele und zu sinn-befreite Änderungswünsche das Team und den Fortschritt im Projekt blockieren! Dann stehst du als Leiter:in des Projekts in der Bütt, das Team hier zu schützen und Filter einzubauen. Wie das genau aussehen kann, schauen wir uns noch im Detail an.
   Für die ersten 3 der 7 Schritte gilt: Ein essentieller Bestandteil ist es auch, zu verhandeln. Um dich gedanklich auf solche Änderungs-Verhandlungen vorzubereiten, kannst du dich grob an den folgenden Fragen orientieren:
   Muss die Änderung JETZT sein? Ist der Wunsch schon durchdacht genug? Lässt sich damit das Ziel besser erreichen oder der Wert des Ergebnisses erhöhen. Wird für diesen Mehrwert auch vom Kunden bezahlt?
   
4. Denn in Schritt 4 wird dann entschieden, ob die Änderung berücksichtig wird oder nicht. Hier schaut ihr euch die Analyse an, wägt ab und fällt eine Entscheidung: go/no go? Wenn „go“, in welchem Umfang? Teilweise Umsetzung oder komplett wie gewünscht? Bis wann? Mit welchen Mitteln?
   
5. In Schritt 5 erfolgt dann nämlich schon die tatsächliche Implementierung. Ihr arbeitet die Änderung ein bzw. setzt um, was beschlossen wurde und berücksichtigt das in den neuen Projektplänen. Dein Projekt wird so an den neuen Anforderungen entsprechend ausgerichtet. Das ist dann eure neue Baseline, eure neue Absprungbasis gegen die ihr künftige Änderungswünsche vergleicht. Und – ganz wichtig zum Abschluss von Schritt 5 – die neue Baseline kommunizierst du an alle Stakeholder.
   
   Klingt ganz intuitiv oder? Intuitiv ist sicher auch, dass es in diesen ersten 5 Schritten dazu kommen kann, dass alle Beteiligten durchaus ein paar Schleifen drehen. Bspw. um genauer zu verstehen, worum es bei dem Änderungswunsch geht, was das Interesse dahinter ist. Oder es kommen während der Analyse zusätzliche (vorher nicht absehbare) Detailfragen auf, die noch beantwortet werden müssen um abschließend zu beurteilen und zu bewerten, ob und wie der Änderungswunsch umgesetzt wird. Im Laufe des Prozesses kann auch klar werden, dass ihr Teile des Änderungsantrags sehr wohl umsetzen könnt, andere jedoch definitiv nicht. Du siehst: hier kann es sich plötzlich richtig in die Länge ziehen. Und so können mehr und mehr Ressourcen verschlungen werden. Ohne dass direkter Mehrwert für dein Projekt entsteht.
   
   Daher meine Kernbotschaft an dich für diese Folge: Mach deine Hausaufgaben als Projektleiter:in, indem du bei Schritt 1 und 2 zum Wadlbeißer wirst. Hinterfrage jeden Änderungswunsch kritisch. Geh ihm zusammen mit dem/der Antragsteller:in auf den Grund und lass nicht locker, bis klar ist, worum es geht und warum die Änderung wichtig ist. Gehst du hier zu Larifari mit den Änderungswünschen um und winkst blind alles durch, belastet und belästigt das dein Team mitunter sehr. Und vor allem hindert es euch daran, das Projekt voranzutreiben. Im SCRUM, einem agilen Projektmanagement Framework, wird deshalb bspw. während eines Sprints keine Änderung zugelassen. Das Team wird nicht behelligt. Sondern erst in einer Review am Ende des Sprints werden Änderungswünsche hervorgebracht. Hauptsächlich, um die Performance des Teams während der Umsetzung nicht zu gefährden und die Störungen zu minimieren. Und glaub mir, Änderungen verursachen viele Störungen. Und Störungen haben immer Vorrang. Also: Sei ein Wadlbeißer und schütze dein Team vor sinnlosen Störungen.
   
6. Ganz wichtig ist nun der Schritt Nummer 6. Das ist der Qualitätscheck, ob die Änderung wie vereinbart implementiert wurde. Wenn nicht war das ja vorher alles, all der Aufwand bis hier her, für die Katz. Wie du das recht easy sicherstellen kannst, quasi on-the-fly, im Vorbeigehen ohne Extraufwand, das erläutere ich gleich in dem Beispiel für einfache Projekte.
   
7. Vorher noch zu Schritt 7, in dem du den Änderungsantrag schließt. Also zu den Akten legst. Das kann theoretisch auch schon gleich nach Schritt 4, also nach der Entscheidung go/no go geschehen, oder auch nach der Implementierung in Schritt 5 und damit vor einer etwaigen Überprüfung. Wichtig ist aber, dass ein sauberer Abschluss der Änderung überhaupt erfolgt, damit du als Projektleiter:in und ihr als Team noch den Überblick behaltet. Denn die Änderungen können sich im Laufe des Projektes sehr leicht stapeln. Dann willst du da Ordnung haben, um den Überblick zu bewahren. Und nicht etwa veraltete, längst nicht mehr aktuelle und bereits implementierte Änderungswünsche verwalten.

Das sind die universellen 7 Schritte, dein How to , wie du und dein Team Änderungen managt. Dieser Ablauf wird dir helfen, den Überblick zu behalten. Denn sehr leicht enden verschiedene Änderungswünsche von verschiedenen Stakeholdern nämlich in einem riesen Durcheinander. Insbesondere, wenn sie recht ähnlich sind. Oder wenn sie sich teilweise widersprechen. Oder wenn überhaupt nicht mehr klar ist, wogegen die Änderungen verglichen werden, gegen welchen Stand der Pläne. Wenn du keine transparente Baseline hast und den Stand zur Umsetzung von Änderungen nicht kennst, dann merkst im ersten Moment womöglich nicht einmal, dass der Überblick längst verloren ist. Erst Stück für Stück wird dann anhand von sinnloser Doppelarbeit und driftendem Scope klar, dass euch da als Projektteam etwas durch die Lappen gegangen ist oder schleichend sogar gegenläufige Ziele verfolgt werden. Wenn die rechte Hand nicht mehr weiß, was die Linke tut und auch keine Chance hat, das rauszufinden weil deine Dokumentation zu den Änderungswünschen der Stakeholder fürn A-Punkt ist, dann wird es kunterbunt. Dann ist eine Punktlandung des Projekts nur noch aus einem Zufall heraus möglich. DOCH: Mit dem 7-Schritte-Plan weißt du jetzt, wie du von Beginn an alle Änderungswünsche in geregelte Bahnen lenkst, sodass du und alle im Team wissen, was abgeht und was zu tun ist.

Anwendung für einfache Projekte

1. Schritt 1: Änderungswunsch entgegennehmen. Der kann auf allen möglichen Wegen in dein Projekt getragen werden und das sollten du und dein Team auch nicht unterbinden. Euer Kunde will blauen Sand. Im O-Ton und oft zwischen den Zeilen lauert häufig wertvolles Feedback. Es soll also kein Sandkasten wie jeder andere werden. Es gibt also einen guten Grund für den Änderungswunsch. Vielleicht verstehst du jetzt zum 1. Mal was genau mit dem Sandkasten EIGENTLICH gebaut werden soll. Etwas, dass die Kids fasziniert. Und so eine Info, das bringt euch im Projekt weiter. Also bloß nicht abwürgen, den scheinbar komischen Wunsch. Nicht du, und auch niemand anders. Wichtig ist hier in Schritt 1 nur, dass wenn Änderungen schon über alle möglichen Kanäle eingehen können, dass alle im Team wissen wohin damit. Also wo diese bspw. abgelegt werden. Stellst du jedoch fest, dass dieser offene Umgang mit Änderungswünschen eine enorme Ablenkung für dein Team ist, schick die Leute mit ihren Änderungswünschen zu mir, äh zu dir natürlich als Projeklteiter:in. Da kannst du dein Team und deren Fokus aus deiner Rolle heraus schützen. Du bist dann die 1. Hürde, die jeder nehmen muss.
   
2. Damit zu Schritt 2: Wie könnt ihr das pragmatisch dokumentieren? Dafür hast du eine dedizierte Spalte in der Excel-Vorlage aus Folge #11. Ich habe festgestellt, dass die meisten Änderungen immer auch etwas mit dem zu tun haben, woran ihr ohnehin schon arbeitet – also was dort im Zeitplan als Arbeitspaket „3t Sand bestellen“ aufgeführt ist. Und so finden du und dein Team auch leicht die passende Zeile für die Zuordnung des Änderungswunsches. Spalte und Zeile bekannt, wunderbar, dann dokumentiert ihr in diese Box den Änderungswunsch. Trag hier am besten auch gleich mit ein, wann die Änderung einging und von wem sie kam. So stellst du von Anfang an Transparenz her.
   
3. Schritt 3 ist nun die Analyse. In einfachen Projekten habe ich es so gemacht, dass ich diese Änderungen mit ins wöchentliche Projektteammeeting genommen habe. Bzw. dort auf die Agenda gesetzt habe und sie damit zur Sprache kamen. Spätestens hier wird also das gesamte Team davon erfahren, dass der Sand im Sandkasten blau sein soll. Und gemeinsam bewertet ihr dann die Änderung. Meist habe ich mir zuvor bereits selber dazu eine Meinung gebildet und mit den betroffenen Personen gesprochen. Selten gab es dort im Meeting also echte Überraschungen. Wenn der blaue Sand 3mal so viel kostet wie der normale, dann wussten wir das da schon. Wenn das Meeting für die Bewertung nicht ausreichend Zeit bot, um bspw. herauszufinden ob wir das irgendwie im bestehenden Budget unter bekommen, haben wir vereinbart, wer sich um die Bewertung kümmert und bis wann das Team zu den prognostizierten Auswirkungen der Änderungen Informationen bereitstellt. Denk nur an Dinge wie Lieferzeit oder ob der blaue Sand gesundheitlich unbedenklich ist. Der/die jeweilige Fachexperte:in hat sich dann um alles Weitere bzgl. der Beurteilung gekümmert. Die Analysen selbst können ganz verschiedener Natur sein, je nach Thema. Wichtig ist allerdings, dass du und das Team stets einen Blick auf Zeit, Kosten und die Qualität des Produktes habt und ob ihr im Projekt dafür überhaupt die Ressourcen, also die Leute, das KnowHow und die finanziellen Mittel habt. Denn was nützt die beste Änderung, wenn ihr nicht die Mittel habt, sie in die Realität umzusetzen.
   
4. Im 4ten Schritt haben wir dann gemeinsam im Teammeeting entschieden, ob wir die Änderungen akzeptieren – und wenn ja: ob im vollen Umfang oder eben nur teilweise. Das macht mit dem blauen Sand jetzt nicht viel Sinn sonst würde der sich ja vermischen und dann ist er eben nicht mehr blau. Wenn wir als Team diese Entscheidung nicht treffen konnten oder durften, je nach Spielraum, wurde das Thema an die Personen bzw. Kreise eskaliert, die darüber entscheiden dürfen. Sagen wir es braucht dafür extra Budget. Die Entscheidung selbst – und das ist mein Tipp für Schritt 4 – haben wir dann in der gleichnamigen Spalte weiter links in der gleichen Zeile der Excel-Vorlage aus Folge #11 dokumentiert.
   
   Tipp und Anmerkung zugleich: Bei ganz einfachen Änderungen a la „Hey, ich brauche hier nen Tag länger, um die Ecken von den Brettern noch schön rund zu schleifen“ und du siehst, das der eine Tag an Puffer vorhanden ist, weil der Sand eh erst in 2 Tagen angeliefert wird und das Arbeitspaket somit nicht auf dem Kritischen Pfad liegt: dann überspringe gerne Schritt 2 bis 4. Halte dich damit nicht auf und geh direkt zu Schritt 5.
   
5. Schritt 5 ist dann das Einarbeiten bzw. die Umsetzung. Die Umsetzung erfolgt ja dann wohl mit der Lieferung des blauen Sands. D.h. ihr aktualisiert zunächst die Beschreibung des Arbeitspakets zu „3t blauen Sand bestellen“. Und du hast dann noch ein Auge drauf, dass alle Projektpläne überarbeitet werden oder übernimmst es grad selbst. Konkret: Du aktualisierst, wenn nötig, den Zeitplan und kontrollierst insbesondere nochmal die Abhängigkeiten zwischen den Arbeitspaketen, sagen wir wenn die Lieferung des blauen Sands an eine anderen Tag als ursprünglich geplant stattfindet. Sind von der Änderung weitere Arbeitsschritte betroffen, dann gehört auch deren Aktualisierung zu Schritt 5. Achtung: Bei allem Drive und bei aller Vereinfachung: Nicht die Kommunikation in Richtung der relevanten Stakeholder aus den Augen verlieren.
   
6. Schritt 6, also die Kontrolle der Umsetzung, ist nun praktischerweise in deinen Ablauf im Projekt eingebaut, denn ihr habt ja eure Pläne entsprechend aktualisiert. Ihr arbeitet dann das Projekt gemäß der neuen Planung ab, werdet sicher nicht übersehen ob der Sand blau ist oder nicht & habt die Kontrolle dadurch automatisch in der Tasche, yes!
   
7. Schritt 7, das Schließen der Änderung würde hier im einfachen Beispiel ganz simpel aussehen. Denn deine Pläne sind aktualisiert, die Entscheidung dokumentiert und die Umsetzung erfolgt mit der regulären Anlieferung vom Sand. Den in Schritt 2 dokumentierten Änderungswunsch kannst du also einfach löschen. So bleiben in der Spalte der Änderungsanträge nur die, die noch offen zur Bewertung sind, nicht entschieden und auch noch nicht umgesetzt sind.

Manche Branchen sehen aus Compliance-Gründen eine Archivierung vor und würden dir das Löschen verbieten. Arbeitest du in einer solchen Umgebung, gelten natürlich diese Regeln. So oder so: Gib Acht, dass deine Änderungsspalte aufgeräumt ist und sich darin nix Veraltetes findet. Eine Idee, auch das pragmatisch zu lösen, wäre die Datei zu speichern, eine neue Version der Datei anzulegen und den Eintrag dort zu löschen. Dann sind alle älteren Versionen dein Archiv. Nicht super elegant, nicht immer praktisch, aber sehr simpel und zeitsparend. Wäg da einfach selber ab, was für dich und dein Umfeld passend ist.

Soweit der einfache Prozess. Kannst du noch? Dann rein in Folge #27 und den universellen 7 Schritten zum erfolgreichen Managen von Änderungen in einem komplexeren, größeren Projekt. Dort geht es nahtlos  weiter. Viel Spaß und auf zur Brillanz!

---