#25 Anforderungen im Wandel inkl. Zeitmanagement Hack

In den letzten beiden Folgen haben wir uns ganz der Psychologie hinter dem Thema Veränderungen gewidmet. Und ich habe beschrieben, wie eine unterschiedliche persönliche Prägung im Umgang mit Veränderungen und deine individuelle Haltung bspw. gegenüber Änderungen in Projekten, eine unterschiedliche Arbeitsweise nach sich zieht. Solltest du die beiden Folgen verpasst haben, pack die auf deine Bucket List. Denn das sind zwei echte Schmankerl. Viel zu schade für ne schnöde ToDo Liste. Das ist feinste Kost und ich bin richtig stolz, dass dort was ganz Einmaliges entstanden ist – denn Psychologische Töne sind in der Projektmanagement-Umgebung selten. Neugierig geworden? Na ich hoffe doch sehr.

Wenn du sie schon gehört hat: Sweeeeet, high 5! Dann weißt du schon ganz genau wovon ich spreche. Und dass ich nicht übertreibe. It’s freakin mindblowing. Also an alle anderen: nicht verpassen, unbedingt reinhören in die Folgen #23 und #24.

So, nach diesen paar einleitenden Worten starte wir weiter durch mit dem Thema Änderungen erfolgreich managen im Projekt! Dazu habe ich dir in dieser Folge einen kongenialen Zeitmanagement Hack mitgebracht. Doch um den zu verstehen braucht es etwas Vorarbeit. Zuletzt habe ich ja folgende drei Fragen aufgeworfen:

1. Wie gelingt es dir, ein Grundverständnis für die Unausweichlichkeit von Veränderungen bei deinem Team zu erzeugen?
2. Welches Handwerkszeug und welche Modelle gibt es, um Änderungen zu managen?
3. Welche Arten von Änderungen gibt es überhaupt?

Änderungen managen? Und wie jetzt?

Gehen wir vom Allgemeinen ins Spezifische und fangen mit Frage 1 an, dem Grundverständnis für das Thema Änderungen. Zum einen hast du ja jetzt in vorherigen zwei Folge eine Art Crashkurs in Psychologie bekommen. Trage deine Erkenntnisse und Aha-Moment daraus ruhig ins Team oder lass sie gleich selbst in die Folge rein hören und tauscht euch dann untereinander dazu aus.

Wenn dir das beispielsweise noch nicht anschaulich genug war und du dir denkst:
„Hey Chris, gibt es den Input auch knackig auf einer Seite?“ Dann sag ich: „Klaro, zück Zettel und Stift – ich hab da was für dich. Etwas, das Frage 2 nach dem Modell und Frage 3 nach den Arten von Änderungen gleich mit beantwortet!“.
Zettel und Stift sind wichtig, denn du weißt ja: der Text hier gehört zu meinem Tutorial Podcast. Mein Anspruch ist es also, dass du immer etwas von mir mit an die Hand bekommst – für dich und dein Projekt. In dem Fall will ich dir ein Diagramm mitgeben.

Diagramm: Anforderungen im Wandel

Dieses Diagramm, dass wir jetzt gemeinsam auf deinem Zettel entstehen lassen, lege ich selbst seit Jahren stets zu Beginn eines jeden Projekts im KickOff auf oder bringe es in eines der ersten Projekt-Team-Meetings mit. Es verdeutlicht in meinen Augen sehr anschaulich, was Änderungen im Projekt bedeuten, warum sie unabwendbar sind und welche Arten von Änderungen ganz grundlegend auf dich und dein Team zukommen können.

Du kennst das Diagramm vielleicht aus Folge #4. Dort habe ich lediglich darauf hingewiesen und es in die Shownotes gepackt. Nun ist die Zeit reif, um näher darauf einzugehen. Das Diagramm trägt den Titel „Anforderungen im Wandel“. Nichts anderes sind ja Änderungen im Projekt – Anforderungen an das Projektergebnis, Erwartungen an dich und dein Team, die sich im Laufe des Projekts verändern. Ein „weg von“ dem, was ursprünglich vereinbart wurde und gleichzeitig ein „hin zu“ etwas anderem oder Neuem – jeweils mit der Intention, damit den Kurs hin zum Projektziel und hin zu den Ergebnissen nachzujustieren. Die Änderung ist also notwendig, weil dein Auftraggeber, du oder auch dein Team und andere Stakeholder glauben, mit dem initialen Setup von Anforderungen (so wie zu Beginn des Projekts festgezurrt wurde) das Ziel nicht mehr erreichen zu können. Oder ihr realisiert, dass es schneller, kostengünstiger oder mit einer höheren Qualität erreichbar wäre.

Kernbotschaft dieser Folge:
Dein Projektleben wird unglaublich erleichtert, wenn du dir vor Augen führst, dass auch die komplizierteste Änderungen, der komplexeste Kurswechsel, im Kern immer als WEG VON / HIN ZU / UM ZU beschrieben werden können bzw. kann. Egal woher der Änderungswunsch kommt, egal von wem, egal warum: lenke die Diskussion auf diese 3 Facetten und erfasse, worum es geht. So machst du nicht nur einen souveränen Eindruck, dir wird es auch leichter fallen die Interessen dahinter zu erschließen und die Auswirkungen der Änderung auf dein Projekt besser zu überblicken.
Doch Achtung, und das ist die 4te Facette, die du dir, bzw. ihr euch, unbedingt bewusst machen müsst: Jede Veränderung kostet Energie. Das heißt also: Um den Wandel auch tatsächlich zu realisieren, ist notgedrungen immer ein gewisser Aufwand bzw. Invest notwendig. Diese also in Summe 4 Facetten, das WEG von der Ausgangssituation, HIN zu dem neuen Zustand, UM etwas bestimmtes zu bezwecken von dem das Unternehmen dann profitiert und das das stets etwas KOSTET: Diese 4 Facetten willst du bei jedem Wandel, bei jedem Änderungswunsch stets beleuchten.

Und damit zu Zettel und Stift und dem Diagramm. Mit Hilfe dieses Diagramms und geeigneten Beispielen kannst du die Kernbotschaft später schön verdeutlichen und überprüfen. Wir brauchen dazu deinen Zettel im Querformat sowie eine x- und eine y-Achse. Bist du bereit?
Auf der waagerechten x-Achse hast du die Projektlaufzeit t. Ganz links auf der x-Achse finden wir also den Projektstartzeitpunkt. Ganz rechts das zeitliche Projektende. Hinzu kommt die senkrechten y-Achse: Diese trifft die x-Achse im Nullpunkt, also der linken unteren Ecke. Du beschriftest sie mit „Anzahl der Anforderungen“. Füg bitte noch eine Skala von 0 (ganz unten) bis 15 (ganz oben) hinzu.

Ein Beispiel

Sagen wir mal der Einfachheit halber, dein Projekt hat zum Projektstart genau 10 Anforderungen, die im Projektverlauf in dein Projektergebnis einfließen sollen. Dann startest du also auf der x-Achse ganz links zum Projektzeitpunkt 0 und trägst 10 Anforderungen auf der y-Achse ab. Eine Anforderung kann z. B. sein, dass ihr ein neues Produkt auf drei Märkten launchen sollt: in Deutschland, in Österreich und in der Schweiz. Diese und die anderen 9 Anforderungen stehen für dein initiales Anforderungsset. So wie du es in einem Pflichtenheft oder Projektauftrag wiederfinden würdest.

Nun startet dein Projekt und die Umsetzung schreitet voran, die Zeit vergeht. Und du wanderst hier auf deinem Zettel entlang der x-Achse nach rechts. Ich sage gerne „die Welt dreht sich weiter“. Häufig hören wir dieser Tage, diese Welt sei eine VUCA Welt, also volatil, unsicher, komplex und vieldeutig. ,VUCA‘ gibt dir dann eine Aussage darüber, wie schnell und wie verrückt sich diese Welt dreht. Fakt ist, sie ist im Wandel. Konkret für dein Projekt heißt das: Ansprechpartner:innen kommen und gehen, der Wettbewerb bringt neue Produkte auf den Markt, die Forschung sammelt neue Erkenntnisse und publiziert diese, eine neue Regierung wird gewählt, Gesetzestexte werden überarbeitet, der FC Bayern holt tatsächlich mal nicht das Tripple … okay, ich schweife ab: Also die Welt ist im Wandel und dein Kunde ändert seine Meinung, euch als Team liegen neue, genauere Informationen vor, ihr bringt eigene Ideen ein und so weiter. Du siehst: ,Änderungen‘, das kann ein wildes Ensemble, ein bunter Mix von Dingen sein. Und du weißt, worauf ich hinaus will: Da draußen bleibt auf lange Sicht nix so, wie es ist. Und genau deshalb verändern sich auch die initialen 10 Anforderungen in deinem Diagramm, um auf dem Stück Papier vor dir zu bleiben. Und das führt uns direkt zu den drei Arten von Veränderungen.

Drei Arten von Veränderungen

1) Zum einen werden sich die Anforderungen in der Form ändern, dass bereits vorher geplante Ergebnisse nun nachjustiert werden müssen. Ich bemühe ein konkretes Beispiel für dich: Statt das neue Produkt gleichzeitig in Deutschland, Österreich und der Schweiz zu launchen, soll es nun schrittweise und zeitversetzt erst in Österreich, dann in Deutschland, dann in der Schweiz auf den Markt gebracht werden. Damit verändern sich sehr wahrscheinlich sowohl die Zeitplanung, auch wenn es nicht notwendigerweise länger dauern muss, als auch die Verteilung der Ressourcen. Letztere muss wohl mindestens angepasst werden.

Das ist ein simples Beispiel für bestehende Anforderungen, die sich ändern. Der Scope deines Projekts bleibt im Prinzip gleich, allerdings verändert sich seine Zusammensetzung.
Das visualisieren wir jetzt in deinem Diagramm: Die Anzahl der Anforderungen in deinem Diagramm, die gleich bleiben, also genau so bleiben wie sie anfangs formuliert waren, verringert sich jetzt im Vergleich zum Projektende. Wir springen also nach rechts an das Ende der x-Achse. Dort, am Ende deines Zeitstrahls, trägst du als Orientierungshilfe wieder die 10 Punkte auf der Skala ab, also die 10 Anforderungen. Und verbindest diese 10 mit der 10 ganz links zu Projektbeginn mit einer waagerechten Linie. Das war wie gesagt nur zur Orientierung. Jetzt haben sich ja Änderungen innerhalb des Scopes ergeben. Sagen wir zu Projektende wurden 3 der 10 Anforderungen so verändert wie in unserem Beispiel, in dem die Reihenfolge der Launches je Markt verändert wurde. Ganz recht auf der x-Achse, also zu Projektende, trägst du deshalb bitte noch einen Punkt bei 7 ab. Dieser repräsentiert die 7 Anforderungen, die noch ganz genau identisch zu denen zu Beginn sind. Auch diesen Punkt bei 7 ganz rechts verbindest du mit der 10 ganz links auf der y-Achse zu Projektbeginn. Was ergibt sich? Genau, es ergibt sich eine von links nach rechts abschüssig verlaufende Rampe. Die bei 10 startet und bei 7 endet. 7 Anforderungen sind identisch der, die du am Anfang auch kanntest. 3 wurden geändert. Zwischen der waagerechten Linie, die links wie rechts die 10 verbindet, und der abschüssigen Linie, die bei 7 endet, ergibt sich ein Dreieck. Dieses Dreieck repräsentiert das Delta, also den Umfang der Änderungen. Dort hinein schreibst du „aktualisierte Anforderungen“ hinein. 10 Anforderungen gab es vorher, 10 sind es am Ende, aber 3 sind anders, wurden aktualisiert. Und schon hast du „aktualisierte Anforderungen“, die erste von 3 Arten von Änderungen, klar vor Augen.

2) Was gibt es noch? Klar, darüber hinaus können auch gänzlich neue Anforderungen hinzukommen. Das ist die 2te Form der Veränderung. Ich gebe dir wieder ein Beispiel: Sagen wir, es hat sich eine gute Möglichkeit ergeben, das neue Produkt parallel zur Schweiz auch noch in Frankreich zu launchen. Der Scope wird also ausgedehnt. Und in deinem Projekt ändert sich wahrscheinlich schon mehr als noch zuvor. Deutsch als Sprache zur Deklaration der Ware, als Benutzerhandbuch, als Sprache der Software, je nachdem um welches Produkt es sich handelt, genügt nun plötzlich nicht mehr. Und wenn es einmal vom Deutschen ins Französische übersetzt wird, macht im selben Aufwasch ggf. auch noch eine Übersetzung ins Englische Sinn. Noch eine neue Anforderung, wie aus dem Nichts. Passt das noch in den Zeitplan? Brauchen du und dein Team jetzt mehr Ressourcen? Wahrscheinlich lautet die Antwort auf mindestens eine der beiden Fragen „ja“. Und wieder ändert sich eine Anforderung, die bzgl. des zeitlichen Ziels oder des zur Verfügung stehenden Budgets, um für das Mehr an Ressourcen aufzukommen. Hier siehst du sehr schön, wie wir beim Abwägen der Änderungen stets auf das Magische Dreieck im Projektmanagement aus Kosten, Zeit und Scope schauen. Das sehen wir uns genauer an, wenn es ums Reporting geht, also in Folge Nummer #28.

Schauen wir jetzt auf deine Skizze, dann hast du ganz am Ende der Projektlaufzeit ganz rechts auf der x-Achse wahrscheinlich wenigsten 3 Anforderungen mehr: Zusätzlicher Launch in Frankreich, Französisch und Englisch als weitere Sprachen neben Deutsch und außerdem mehr Budget. Zu den 10 ursprünglichen Anforderungen tragen wir am Projektende also 3 weitere Anforderungen ab und sind so schon bei 13. Verbinde auch diesen Punkt mit der 10 zu Beginn des Projekts ganz links auf der y-Achse. Nun ergibt sich eine Rampe von links nach rechts ansteigend. Und das ist auch recht realistisch, denn die neuen Anforderungen kommen ja oft im Projektverlauf sukzessive hinzu – es wird also Stück für Stück mehr, oft schleichend. In das nun neu entstandene Dreieck oberhalb der aktualisierten Anforderungen, schreibst du „neue Anforderungen“ hinein.

3) Fehlt noch die dritte Grundform von Änderungen. Eine Idee? Das sind die Anforderungen, die entfallen. Ziehen wir auch hier wieder unser Beispiel des Produkt-Launches heran: Jetzt soll doch nicht mehr in Deutschland gelauncht werden. Man hat seitens der Geschäftsführung entschieden, sich als Unternehmen sukzessive aus dem deutschen Markt zurückzuziehen, weil die Margen dort kein Engagement mehr rechtfertigen und die Wettbewerber uneinholbar voraus sind. Solche strategischen Unternehmens-Entscheidungen können also durchaus Änderungen in deinem Projekt triggern. Gleiches gilt für sich änderndes Nutzer- oder Konsumverhalten. Im gleichen Atemzug sind auch Änderungen in Bezug auf rechtliche Auflagen und regulatorische Bedingungen zu nennen. Auf der anderen Seite kann es genauso gut sein, dass zu Beginn des Projekts schlichtweg falsche Annahmen getroffen wurden, bestimmte Anforderungen einfach falsch formuliert waren und jetzt fallen gelassen werden. Warum das? Ganz einfach: Wenn ihr euch zum jetzigen Zeitpunkt als Team mit dem Projekt beschäftigt und an den Ergebnissen arbeitet, entstehen neue Einsichten. Das kann auch technologischer Natur sein, bspw. im Kontext von Fertigung und Waren-Handling. Kommen hier neue Technologien auf den Markt und ihr wollt sie für das Projekt nutzbar machen, ergeben sich mitunter signifikante Änderungen. Um das im Diagramm zu veranschaulichen, zeichnest du bitte einen fetten Pfeil von links nach rechts unter deine x-Achse und beschriftest den mit „Zunahme an Informationen und Klarheit bzgl. der Anforderungen“.

Zurück im Diagramm selbst bedeutet das, dass wir die wegfallenden Anforderungen noch abtragen wollen. Sagen wir, es sind wieder 3 Stück, die über die Projektlaufzeit entfallen. Dann trägst du jetzt am Projektende ganz rechts auf deiner x-Achse, noch die 3 ab und verbindest die mit dem Nullpunkt in deinem Diagramm. Genau, mit dem Nullpunkt, dieses mal nicht mit der 10. Was ergibt sich? Genau, beginnend im Nullpunkt ganz links steigt jetzt eine Rampe bis ganz nach rechts auf Höhe der 3 an. Das so entstehende Dreieck zwischen x-Achse und der Rampe beschriftest du mit „nichtige Anforderungen“. Das ist also die dritte Form von Änderungen. Super! Das Diagramm ist fertig. Lass uns gemeinsam reflektieren!

Reflexion

Schauen wir mal gemeinsam von oben auf dein Diagramm vor dir drauf. Was wir sehen ist, dass wir links mit 10 gestartet sind, und auch rechts wieder 10 Anforderungen haben. Jedoch sind 3 weggefallen, 3 haben sich geändert und 3 sind neu hinzugekommen. In Summe sind nur 4 Anforderungen genau identisch mit denen zu Beginn. Krass oder? Wir haben eigentlich gar nicht soooo viel verändert, doch das Projekt an sich ist zu Projektende kaum wiederzuerkennen.

Das was am Ende des Projekts geliefert wird, entspricht nur noch zu 40% dem, was anfangs vereinbart bzw. angenommen wurde. Klar, die Zahlen im Beispiel habe ich mir jetzt alle ausgedacht. Vielleicht sind sie aber gar nicht so weit weg vom Schnitt. Du kannst es ja mal selbst in deinem Projekt überprüfen. So oder so ist das Schaubild, das du nun erstellt hast, ideal dafür geeignet, um deinem Team zu Projektbeginn zu verdeutlichen, worauf es sich einzustellen gilt.

Wie gesagt lege ich diese Folie, die ich dir auch nochmal in den ShowNotes verlinkt habe, stets zu Beginn meiner Projekte auf. Das stößt häufig tolle Diskussionen rund um das Grundverständnis an und führt nicht selten zu Aha-Effekten. Insbesondere, dass etwas so Abstraktes wie Änderungen im Projekt, sich soeinfach grafisch veranschaulichen lassen.

Was sagst du? Vermitteln dir dein Diagramm und dieser Form der Darstellung auch ein Gefühl von Leichtigkeit und Souveränität? Glaubst du, dass du und dein Team damit Änderungen fortan gemeinsam meistern könnt?

Tipp

Damit du dabei so richtig brillierst, hab ich dir noch einen unbezahlbaren Tipp mitgebracht. Das ist ganz sicher nach deinem Geschmack, oder? Lass uns zusammen noch einen genaueren Blick auf dein Diagramm werfen.

Eine wichtige Sache gibt es nämlich noch, die ich dir basierend auf meinen eigenen Erfahrungen unbedingt mit auf den Weg geben möchte. Die Anforderungen, die nichtig und obsolet sind – also diejenigen, die wegfallen und dein Dreieck ganz unten rechts bilden – die entpuppen sind ganz häufig als Stolpersteine im Projekt. Und gleichzeitig sind sie deine größte Chance, um Zeit, Nerven und Ressourcen zu sparen, Konflikte zu vermeiden und bares Geld zu sparen.
Wie kann das sein? Der Grund ist recht banaler Natur und besteht darin, dass dein Team ganz häufig trotzdem weiter an diesen Dingen arbeiten wird und so wertvolle Zeit und Ressourcen verschwendet werden, obwohl unlängst beschlossen wurde, diese Anforderungen aus dem Projektplan zu streichen.

Wie kommt es dazu? Nun: Wird diese Art der Änderung, also das Wegfallen, nicht mit dem Team geteilt und nicht sauber kommuniziert, dann werden trotzdem Ergebnisse produziert, die hinterher niemand benötigt. Einfach weil niemand weiß, dass es dies und jenes nicht mehr braucht. Das Problem der schlechten oder Nicht-Kommunikation potenziert sich sogar häufig noch. Arbeitet das Team weiter daran, sieht es sich früher oder später mit Vorwürfen konfrontiert, warum hier für die Tonne gearbeitet wurde. Ich sage das so drastisch und deutlich, weil es sich dann genau so anfühlt. Frust auf beiden Seiten, auf Seiten des Auftraggebers, der etwas bekommt, was er oder sie doch bereits abbestellt hatte … und das Team ist ebenfalls frustriert, weil es etwas geliefert hat, das nun niemand haben möchte. Total waste of time. Die reinste Verschwendung – und das nur, weil aneinander vorbeigeredet wurde. Beide Seiten fühlen sich dann missverstanden und dein Team vor allem auch nicht wertgeschätzt – immerhin wurde durch die schlechte Kommunikation auch deren Zeit gestohlen. Nicht selten mündet das in Anschuldigungen der Art: „Du hast ja nix gesagt!“ oder „Wie deutlich hätte ich es denn noch sagen sollen, damit ihr es kapiert?“. Und stell dir vor, wie das eskaliert, wenn egal aus welchem Grund, nicht mal die eigentlichen Ziele im Projekt erreicht wurden. Dann kann es richtig hitzig und unangenehm werden. Im schlimmsten Fall ist der Kunde weg oder du und dein Team, ja … eure Reputation ist versaut. Daher Achtung: Hier sind Transparenz und gute, gezielte Kommunikation unglaublich wichtig.

Jetzt drehen wir das Ganze um: Sagen wir du und dein Team ihr ertrinkt förmlich in Arbeit. Wo fängst du an zu suchen, wenn du Zeit finden willst? Bingo, bei den Anforderungen, die im Projektverlauf obsolet geworden sind. Mitunter musst du dich dazu nochmal beim Auftraggeber rückversichern, weil ihr es nie explizit gemacht habt. Doch stell dir vor, du findest in deinem Projekt zwei oder drei Dinge, die ihr schlichtweg weglassen könnt, weil du ein gezielte Gespräch mit deinem Kunden oder Auftraggeber geführt hast. So machst du dich ziemlich beliebt bei deinem Team, wollen wir wetten?

Gold Plating

Der dazu passende Begriff heißt übrigens Gold Plating. Zu Deutsch ist damit der berühmte goldene Henkel gemeint, nach dem niemand gefragt hat, der aber geliefert wird. Sieht gut aus, macht was her, braucht aber keiner und es hat auch niemand darum gebeten. Dafür wird also auch niemand Geld bezahlen. Ihr im Projekt habt also im schlimmsten Fall viel Mühe und Kapazitäten in die Arbeit gesteckt, die dann nicht mal honoriert wird. Womöglich hat das Projektteam sogar am eigentliche Bedarf vorbei gearbeitet und damit den Kunden verärgert.
Ich plädiere dafür, dass das „Gold“ lieber in deinen Taschen landet, nämlich in Form von mehr Fokus, weniger Zeitaufwand und einer gesunden Balance im Leben. Daher hier für dich die drei Fälle, wie es zu Gold Plating kommt, und wie du es von Anfang an verhindern kannst:

1. Zum einen, der Klassiker, wenn das Projektteam von Anfang an das Ergebnis over-engineert. Also statt aufzuhören, wenn alle Anforderungen erfüllt sind, weiter daran tüftelt oder eine eigene Note als i-Tüpfelchen fungieren soll. Motivation für diese Art von Gold Plating ist, dass sich das Ergebnis für das Team oder einzelne vermeintlich besser oder richtiger anfühlt – dem liegen aber keine ,Hard Facts‘ oder Ziele zugrunde, die mit dem Kunden oder Auftraggeber abgestimmt wären. Das lässt sich am besten durch SMARTen Kriterien bei der Formulierung der Anforderungen vermeiden. Du erinnerst dich an Podcast Folge #4? Anforderungen sollten, wann immer möglich, spezifisch und messbar und damit auch testbar sein. Auf diese Weise lässt sich für alle Beteiligten nachvollziehbar bestimmen und erkennbar, wann wirklich genug ist und ab wann ihr dem over-engineering und Gold Plating verfallt.
   
2. Dann kann es auch zu Gold Plating kommen, wenn ihr als Team den Auftrag von Anfang an falsch interpretiert habt und an Dingen arbeitet, die der Kunde nicht benötigt bzw. sich ganz anders vorgestellt hat. Die Ursache ist dann in der Auftragsklärung zu suchen. Fertigt also am besten Skizzen, Prototypen, Briefings, Entwürfe oder Mockups an, um eine möglichst konkrete Vorstellung davon zu vermitteln, wie das Endergebnis auszusehen hat. So verwandelt ihr implizite Projektanstöße in explizite, plastische Konkretisierungen. Das mindeste ist es, dem Kunden Fragen zu stellen, bis du das Endergebnis klar vor deinem geistigen Auge sehen kannst, um es mit den Erwartungen des Kunden abzugleichen. Gut gebrieft ist die halbe Miete. Du erinnerst dich mitunter an Podcast Folge #3 und das Kano-Modell zurück. Hol gerne deine Skizze aus der Folge nochmal hervor, um dich für den Ernstfall zu wappnen.
   
3. Und dann sind es zum dritten eben die Anforderungen, die im Projektverlauf wegfallen und an denen DENNOCH weiter gearbeitet wird. Das ist der dritte Weg, der zu Gold Plating führen kann. Darüber haben wir in dieser Folge bereits ausführlich gesprochen.

In allen drei Fällen wird an etwas gearbeitet, das nie, nicht oder nicht mehr benötigt wird. Gerade weil im Projektverlauf oft neue Anforderungen hinzukommen, sich Bestehende ändern (du hast deine Skizze vor dir) und dadurch viel los ist, wird häufig vergessen, das, was wegfällt, überhaupt als Änderung kenntlich zu machen. Hier ist aber tatsächlich großes Einsparpotential oder zumindest Effizienzpotential, das gerne mal verpasst wird zu heben und, wie wir gehört haben, zu unschönen Begleiterscheinungen führen kann. Spar dir das lieber!

Tipp: Not-To-Do-Liste

Mein konkreter Tipp an der Stelle: Mach dir gerne eine Not-To-Do-Liste und schreibt dort alles rein, woran ganz explizit von Anfang an nicht, nicht mehr, oder im Projektverlauf nicht weiter gearbeitet wird. Im Fachjargon des Projektmanagements heißt diese Not-To-Do Liste übrigens Out-of-Scope Liste. Mach an der Stelle gern kurz Pause und schreib runter, woran dein Team definitiv nicht weiterarbeiten sollte oder mit wem du sprechen wirst, um herauszufinden, was ihr getrost weglassen könnt. Da liegt mitunter ein Schatz begraben, um die eigene Kapa wieder frei zu spielen bzw. auch mal Überstunden ab- und nicht nur aufzubauen. Bonus: Teile dieses Wissen mit deinem Team – wenn du alle ins Boot holst, sind gleich mehrere Leute aufs Vermeiden von goldenen Henkeln aus. Es lohnt sich.

Ausblick

Soweit die dritte Folge zum Thema Änderungen von Anforderungen und deinem Umgang damit. In der nächsten Folge starten wir mit einer konkreten Schritt-für-Schritt Anleitung durch. 7 Schritte, die du dann mit in dein Projekt nehmen kannst und die dir zeigen, wie du bzw. ihr als Team nun konkret mit Änderungen umgehen könnt, wie ihr sie schlussendlich im laufenden Projekt strukturiert und transparent managt. Es wird eine Doppelfolge, denn ich will dir mit auf den Weg geben, wie das in kleineren Projekten ganz einfach aussehen kann, also so pragmatisch wie möglich. Und ich will dir zeigen, wie das in ganz großen Projekten laufen kann, damit du die Komplexität leichter beherrschen kannst. Die gute Nachricht ist also: das 7 Schritte-Modell kannst du je nach Projektgröße skalieren. Du siehst: es bleibt mega spannend, yeah! Ich sag an der Stelle wie gewohnt meinen Dank und freue mich, dass du reingehört hast.
Und damit auf zur Brillanz!

---