Haben Sie schon einmal einen großen Veränderungsplan entworfen, der in der Realisierungsphase sukzessive vom Tagesgeschäft überrollt wurde? Ein ambitioniertes Changeprojekt gestartet, das niemals zum Abschluss kam? Oder versucht, die laufenden Dinge im Auge zu behalten und dabei jeden Überblick verloren? Falls dem so ist, dann könnte sich für Sie das Weiterlesen lohnen.

Worum geht es?

Viele unternehmerische Veränderungsprojekte sind Fixstarter in der Hitparade des Scheiterns. Empirische Untersuchungen belegen seit Jahren, dass durchschnittlich rund 70% dieser Projekte nicht ins Ziel kommen. Die Dunkelziffer liegt wahrscheinlich noch höher. Die Zufriedenheit mit dem klassischen, projekt- und plangetriebenen Change Management halt sich dementsprechend in Grenzen — und das wohl nicht nur bei mir, der ich als Führungscoach und Organisationsberater seit vielen Jahren durch die Lande ziehe. Auch wenn ich es mir nicht gerne eingestehe: die Einsätze in Sachen Change, die ich als voller Erfolg bezeichnen würde, muss ich selbst mit der Lupe suchen.

Der chronische Misserfolg hat bekanntermaßen viele Gründe: fehlende Informationen, schlechte Einbindung von Betroffenen oder mangelndes Engagement des Linienmanagements gehören diesbezüglich ebenso zu den üblichen Verdächtigen wie unaufgelöste Widerstände oder kulturelle Immunreaktionen, Es fällt auf, dass die meisten Erklärungen für das Scheitern von Veränderungsvorhaben stark auf soziale und emotionale Aspekte fokussieren. Selbstverständlich bleibt diese vermeintlich weiche Seite das Um und Auf: Erfolgreicher Change ist nicht ohne die Menschen zu haben.

Zugleich hege ich seit längerem den Verdacht, dass es noch ganz andere Probleme gibt: dass die bekannten Reaktionen auf Veränderungen nur Symptome viel grundlegenderer Ursachen sind; dass, salopp formuliert, der Wurm im System steckt, in der Art, wie wir unternehmerische Veränderung denken, konzipieren und umzusetzen versuchen. Doch welche anderen Rahmenbedingungen können wir für unsere Veränderungsvorhaben schaffen? Welches Design bräuchte es für ein Veränderungsmanagement, das auf der Höhe der Zeit ist? Und last but not least: welche Hilfsmittel stehen dafür zur Verfügung?

Meiner Erfahrung nach gibt Kanban darauf wegweisende Antworten. Mit Hilfe des evolutionären Ansatzes können jedenfalls einige Systemfehler des traditionellen Change Managements adressiert werden. Aus praktischer Sicht zählen dazu insbesondere:

  • die Vielzahl paralleler Veränderungsinitiativen
  • die Intransparenz des Change Managements
  • ein Mangel an Veränderungsflüssen
  • fehlende Feedbackschleifen

Das verdient Erläuterung.

Zu viele parallelle Veränderungsinitiativen

In größeren Unternehmen laufen üblicherweise viele Projekte nebeneinander her. Manche dieser Projekte laufen einander sogar zuwider, wie ich mehrfach beobachten konnte:

  • in einem Infrastrukturunternehmen soll Teamarbeit unternehmensweit gestärkt werden, während das erneuerte Performance Management System ganz auf die individuelle Leistung abstellt;
  • die Entwicklungsabteilung eines Auomobilzulieferers ruft dezentrale Selbstorganisation als neuern Leitwert aus, halt aber an einer zentralen Ressourcenverteilung fest;
  • der Customer Service einer großen Telekommunikationsfirma will Innovation fördern und forciert gleichzeitig ein rigoroses Kostenkontrollprogramm;
  • ein mittelständischer IT-Spezialist führt agile Softwareentwicklung ein, die zentralen Rollen werden aber ausschließlich mit Linienführungskräften besetzt.

Diese Widersprüche haben mit der von Ed Schein “Grundannahmen” zu tun, wie sie für viele Unternehmenskulturen typisch ist. Gerade Führungskräfte übersehen gerne, dass die Ziele, die wir offiziell anstreben nicht immer dem entspricht, was unser Handeln tatsächlich leitet. Die Unsichtbarkeit dieser kulturellen Leitlinien, wie wir sie zuletzt auch in “Culture eats Agile for breakfast” analysiert haben, ist ein zusätzliches Hindernis für viele Veränderungsvorhaben. Darauf wird leider zumeist inadäquat mit verstärkten Anstrengungen und noch mehr Projekten reagiert.

Die Vielzahl von Veränderungsprojekten führt jedoch dazu, dass sich die bekannte J-Curve weiter abflacht. Abbildung 1 stellt dieses Phänomen in vereinfachter Form dar: Je mehr gleichzeitige oder überlappende Veränderung stattfindet, desto länger braucht die Organisation, um die Veränderung zu verdauen und nach dem anfänglichen Abfall der Performance wie gewünscht zu neuen Höhen aufzusteigen. Schließlich dauert es seine Zeit, bis alte Routinen verlernt und neue Praktiken gelernt sind. Und es dauert umso länger, je mehr auf einmal ver- bzw. gelernt werden muss.

Abbildung 1: “Sinkende J-Curve”

Abbildung 1: “Sinkende J-Curve”

Intransparentes Veränderungsmanagement

Viele Veränderungsinitiativen sind kaum sichtbar. Sie sind im Tagesgeschäft selten präsent und verlaufen großteils im unternehmerischen Untergrund. Nimmt es angesichts dieses Schattendaseins wunder:

  • dass vielen Mitarbeitern weder die Ziele noch die einzelnen Schritte des angestrebten Veränderungsprozesses klar sind?;
  • dass sie nicht wissen, wie diese Veränderung zum unternehmerischen Erfolg beiträgt?;
  • geschweige denn, was sie selbst von der Veränderung haben?

Der Mangel an Transparenz schafft Raum für Spekulationen. Wo wenig Kommunikation ist, blühen bekanntlich die Phantasien. Persönliche Befürchtungen entstehen, Verunsicherung wächst, entsprechende Abwehrmechanismen werden auf den Plan gerufen. Währenddessen sind die mit dem Change Management betrauten Spezialisten mit ausgeklügelte Projektplänen beschäftigt, die eine bessere Zukunft antizipieren und Unsicherheit verbannen wollen. Dass diese Pläne im Wesentlichen hinter verschlossenen Türen ausgearbeitet und verwaltet werden, macht Organisationen gleich in zweifacher Hinsicht blind: zum einen blind für den tatsächlichen Wert von Veränderung, zum anderen blind für die Kosten von verzögerten, blockierten oder abgebrochenen Change Initiativen. Einer Untersuchung der Standish Group zufolge verursachen allein die fehlgeschlagenen IT-Entwicklungen in Europa jährlich einen Schaden von 140 Milliarden Euro.

Das Problem wird durch die Intrasparenz des hinter der gewaltigen Verschwendung stehenden Change Management Systems verschärft. Das Scheitern vieler Projekte wird zwar rituell beklagt, eine Ursachenanalyse findet jedoch selten statt. Geschweige denn, dass die Art, wie Veränderung ein- und durchgeführt wird, selbst in den Brennpunkt notwendiger Veränderung rückte und ein angemessenes Problemverständnis entstünde.

Mangelnde Veränderungsflüsse

Nach wie vor werden die meisten Veränderungsvorhaben nach den Vorgaben des traditionellen Projektmanagements und damit nach dem Push-Prinzip gesteuert. Als Change Agent will der verantwortliche Projektmanager mit einem initial erstellten Masterplan von vordefinierten Maßnahmen einen geordneten Übergang vom Ist zum Soll sicher stellen. Dabei kommt den eigentlichen Protagonisten dieses Übergangs zumeist nur eine Statistenrolle zu. Betroffene werden weder frühzeitig informiert noch am Design des Veränderungsprozesses beteiligt. Die im Zuge dieses Prozesses auftretenden Blockaden, seien es nun offene inhaltliche Fragen oder emotionale Widerstände werden zumeist ebenso ignoriert wie neue Veränderungsimpulse aus der Umwelt. Das macht es schwer, die notwendige Energie für eine nachhaltige Veränderung zu gewinnen – ganz zu schweigen von der agilen Kultivierung eines kontinuierlichen Veränderungsflusses.

Stattdessen werden in vielen Change-Projekten vorgedachte Programme in großen batch sizes abgewickelt:

  • zuerst müssen alle die Einführungsveranstaltunen besuchen, in denen die jeweils verantwortlichen Manager über die Veränderung aufklären (gerne auch “Informationsveranstaltung” genannt);
  • danach müssen alle nacheinander für die neuen Praktiken, Prozesse und Tools geschult werden (womit man meistens externe Experten beauftragt);
  • im Anschluss gibt es funktionsspezifische Umsetzungsworkshops (wobei gerne das managementspezifische oder gar hierarchieübergreifende Lernen übersehen wird);
  • schließlich wird flächendeckend Coaching verabreicht (deto mit Fokus auf operative Umsetzung und also Mitarbeiter);
  • bis das Vorhaben organisationsweit wie geplant auf “fertig” gestellt wird (wo auch immer es tatsächlich steht).

Es überrascht kaum, dass die Vorherrschaft des Wasserfall-Modells auch im Change Management eine Vielzahl von Konflikten verursacht. Und es überrascht wohl ebenso wenig, dass die Ergebnisse derartiger Veränderungsprojekte sehr oft niemanden zufrieden stellt.

Fehlende Feedbackschleifen

Ganz im Sinne von John Lennons berühmter Songzeile “life is what happens to you while you´re busy making other plans” haben Pläne auch im Geschäftsleben nur eine untergeordnete Bedeutung. Notwendige Veränderungen werden jedenfalls nicht durch Pläne, sondern durch das Feedback der wichtigsten Stakeholder vorangetrieben. Allerdings werden Mitarbeiter, Business Partner und vor allem Kunden in die wenigsten Veränderungsinitiativen konsequent eingebunden. Deren Interessen bleiben zuweilen ebenso auf der Strecke wie das emotionale Ab- und ins vielzitierte Boot holen. Das führt wiederum dazu, dass zumeist nur wenige Leute kraftvoll rudern. Ein solches Change Management geht einmal mehr an den Leuten vorbei. Es trägt zur vielerorts grassierenden Veränderungsmüdigkeit, wenn nicht sogar zu einem ausgeprägten Zynismus bei. “War er wieder einmal auf einer Führungskräfteschulung?”, “voilà, die neueste Managementmode” und “duckt euch, damit diese Welle gut über uns hinwegrollen kann” sind einige der Klassiker, die mir in zahlreichen Unternehmen zu Ohren gekommen sind.

Diese Haltung Diese wird durch fehelnde Change Management Skills prächtig gefördert. Halbwissen verbindet sich kongenial mit mangelnder Erfahrung und fehlendem Training. Diesen Defiziten wird vorzugsweise mit einer Kombination von Selbstüberschätzung und Komplexitätsunterschätzung begegnet. “Change können wir doch ohnehin alle! Und zum Management hatten wir auch schon viele Schulungen” lautet der sinngemäße Tenor. Im Dunklen verbleibt dabei jener weitverbreitete knowing-doing gap , den Jeffrey Pfeffer und Robert J. Sutton bereits vor über 10 Jahren treffend analysiert haben. Wie das nahezu konstante gebliebene Scheitern zeigt, hat sich seitdem jedoch wenig geändert. Das Wissen (knowing) mag vielleicht sogar vorhanden sein. Die Praxis (doing) läßt aber nach wie vor zu wünschen übrigen. Es fehlt vielerorts an deni notwendigen Fähigkeiten, die eben nur durch konstantes Training on the job, durch kontinuierliche Einsätze im Unternehmensfeld und durch ein differenziertes System von Feedbackschleifen zu diesen Einsätzen zu erwerben sind.

Wie Kanban helfen kann

Selbstverständlich ist das weder ein gänzlich neues noch ein vollständiges Problem Statement. Nichtsdestoweniger spüre ich ein starkes Bedürfnis nach neuen Lösungen. Und bilde mir ein, damit nicht ganz allein zu sein. Es geht, wie das zuletzt auch David Anderson gefordert hat, um den Aufbau einer Change Management Capability, die den Anforderungen des 21. Jahrhunderts gewachsen ist. Doch wie sieht diese neue Veränderungskompetenz aus? Welche Fähigkeiten bräuchte es, um die skizzierten Probleme effektiv zu adressieren? Und wie kann Kanban helfen, ein besseres Veränderungsmodell zu entwickeln?

Im Folgenden möchte ich einige Praktiken vorstellen, mit denen ich in den letzten 1,5 Jahren in den verschiedensten Unternehmen gute Efahrungen gemacht habe.

Apropos Intransparenz: Visualisiere den Veränderungsprozess!

Um es einmal vollmundig auszudrücken: Die gemeinsame Visualisierung des aktuellen Veränderungsprozesses kann Wunder bewirken! Und das gleich in mehrfacher Hinsicht:

1.)    ebnet die offensichtliche Darstellung den Weg zu einem gemeinsamen Verständnis des spezifischen Change Flow;

2.)    bietet die Visualisierung einen Überblick über die laufenden Maßnahmen und deren aktuellem Status – insbesondere hinsichtlich evidenter Probleme und Engpässe;

3.)    hilft die Visualisierung dabei, die jeweiligen Aufgaben und Verantwortlichkeiten zu klären.

Abbilung 2 zeigt am Beispiel einer Kanban-Einführung, wie eine solche Visualisierung des Veränderungsprozesses aussehen kann.

 

Abbildung 2: “Kanban Change Team Board”

Abbildung 2: “Kanban Change Team Board”

Zu sehen ist das sogenannte “Kanban Change Team Board” eines deutschen Software-Unternehmens, das Kanban für die gesamte Produktentwicklung nutzen möchte. Nach der Einführungsveranstaltung, die als Großgruppen-Event für alle Mitarbeiter und weitere wichtige Stakeholder stattfand, übernimmt eine ebenso bereichs- wie hierarchieübergreifende Gruppe die Verantwortung für die professionelle Gestaltung des Einführungsprozesses. Im Laufe eines intensiven Tages wird aus dieser Gruppe ein Change Team geformt. Ein zentraler Baustein dieses Teambuildings ist die Aufarbeitung der bisherigen Change-Erfahrungen:

  • Welche Initiativen gab es bereits?
  • Was lief dabei gut? Und was hat dazu beigetragen?
  • Was lief nicht gut? Und woran lag das?
  • Welche Schlüsse können wir auf den bisherigen Erfahrungen ziehen?
  • Und was wollen wir bei der aktuellen Initiative besonders beachten?

Auf Basis dieser lessons learned wird der aktuelle Veränderungsprozess visualisiert. Dabei sollen alle Schritte und Aufgaben erfasst werden, die bis zum erfolgreichen Betrieb des Kanban-Systems notwendig sind. Entlang einer Schrittfolge von “To do”, “Next”, “Vorbereitung”, “Durchführung” und “Done” werden alle Tätigkeiten (blassgelbe Post-its), verantwortliche Personen (orange Post-its) und organisatorische Details (neongelbe Post-its) festgehalten.

Apropos Feedbackschleifen: Prüfe und verbessere dich laufend!

Ziel dieses Vorgehens war es, alle formellen und inhaltlichen Voraussetzungen für ein maßgeschneidertes System-Design zu erfüllen. Diese Voraussetzungen wurden durch eine Serie von intensive Kommunikationsloops erarbeitet. Dabei ging es zum einen um ein vertieftes Verständnis der aktuellen Stärken und Verbesserungsfelder, die mittels Einzel- und Gruppengesprächen mit allen Stakeholdern erhoben und zu einem Gesamtbild konsolidiert wurden. In einer Art Kanban-Probebetrieb aktualisierte das Kanban Change Team das Board im Rahmen von “Daily Standups”, visualisierte auftretende Blockaden (z.B. Terminabsagen), bearbeitete diese in Anschlussmeetings und traf sich einmal wöchentlich zu einer Retrospektive.

Zum anderen steckte das Kanban Change Team auch die strukturellen Rahmenbedingungen für einen erfolgreichen Kanban-Vollbetrieb ab:

  • Wer arbeitet mit dem System?
  • Wer ist in das konkrete Design eingebunden?
  • Wo soll das Board für den operative Betrieb platziert werden?
  • Welche Materialien werden dafür benötigt? Und Ähnliches mehr.

Da das Kanban Change Board vor einem der Gemeinschaftsräume angebracht wurde, war der gesamte Prozess die ganze Zeit über für alle transparent. Das lud zu einer Vielzahl informeller Gespräche ein, die im Sinne kleiner Feedbackschleifen eine Menge an zusätzlichen Verbesserungsimpulsen lieferte.

Doch Feedback wurde auch im formellen Rahmen gefördert: sowohl die Ergebnisse der inhaltlichen als auch der organisatorischen Arbeit wurden den Stakeholdern präsentiert, bevor eine Auswahl an Mitarbeitern sich an die Gestaltung eines maßgeschneiderten Systems machte. Konsequenter Weise stellate man dieses System ebenfalls zur Diskussion – bis es von allen zumindest soweit pragmatisch abgesegnet wurde, dass einer Inbetriebnahme nichts mehr im Wege stand.

Präsentation von Ergebnissen, gemeinsame Prüfung und Verbesserung auf Basis des erhaltenen Feedbacks steht im übrigen auch im operativen Betrieb im Zentrum. Auf spezifischen Messungen aufbauend wird Feedback zum Motor der Systemverbesserung.

 

Abbildung 3: “Feedbackschleifen in Kanban”

Abbildung 3: “Feedbackschleifen in Kanban”

 

In Anlehnung an Klaus Leopold zeigt Abbildung 3 wie die kleine Verbesserungsschleife (grüne Pfeile) im Kanban-Betrieb kongenial durch eine große Schleife (rote Pfeile) ergänzt wird, in die sowohl die Betreiber des Systems, als auch deren wichtigste Stakeholder periodisch eingebunden werden. Denn so wie für das initiale Systemdesign der Input der Stakeholder unerläßlich ist, muss neben der laufenden Prüfung und Adaption innerhalb des Systems immer wieder auch das System selbst geprüft werden:

  • Haben wir alle Probleme am Radar?
  • Verstehen wir die Probleme richtig?
  • Liefern wir die richtigen Lösungen?
  • Müssen wir etwas am Gesamtdesign ändern?

Kontinuierliche Verbesserung wird durch die Kombination formeller und informeller Meetings sicher gestellt: zum Feedback innerhalb der bekannten Formate von Daily Standup, Queue Replenishment Meeting, Retrospektive oder Operations Review  kommt das Feedback, das in spontanen Anschlussmeetings, kollegiale Beratungen oder Einzelgespräche erfolgt.

Apropos Mangel an Veränderungsflüssen: Koordiniere deine systemischen Verbesserungen!

Abbildung 4: “Change Ban”

Abbildung 4: “Change Ban”

Abbildung 4 zeigt ein weiteres Beispiel für die Visualisierung eines Veränderungsprozesses, Wir sehen das sogenannte “Change Ban”-Board einer IT-Abteilung in einem Schweizer Infrastrukturunternehmen. Über dieses Board wird jedoch nicht der Einführungsprozess, sondern die Verbesserungsmaßnahmen der vier Kernteams koordiniert. Dafür wurden im Führungskreis, dem der Abteilungsleiter, alle Teamleiter sowie ausgewählte Spezialisten angehören:

  • spezifische Prozessschritte definiert: “Backlog” (im Sinne von “Veränderungsideen”), “Retrospektive” (im Sinne von “Prüfen”), “Machen” (im Sinne von “Ausgewählt”), “in Arbeit” (im Sinne von “Durchführen”), “Kommunizieren” (im Sinne von “Feedback einholen”), “Fertig”;
  • alle Verbesserungsaktivitäten, die über die einzelnen Teams und deren spezifische Boards hinausgehen, werden auf einzelnen Tickets festgehalten (siehe gelbe und blaue Karten);
  • Verantwortlichkeiten zugeordnet (orange Stickies)
  • Regeln definiert (siehe A4-Blatt auf der rechten Bildseite), zu denen unter anderem auch ein wöchentliches Monitoring zählt, das im Rahmen des Führungs-Jour fixe durchgeführt wird.

Obowohl das Board dafür angelegt ist, Veränderungsflüsse zu fördern, führt es auch ein gängiges Problem vor Augen. Denn dadurch, dass nach dem Prinzip “Starte mit dem, was du jetzt tust” erst einmal die Ist-Situation erfasst wurde, befinden sich sehr viele Maßnahmen in den Stadien “Machen”, “in Arbeit” oder “Kommunizieren”. Es gibt einige neue Vorhaben, die auf Realisierung drängen, während zahleiche Verbesserungsaktivitäten noch unabgeschlossen sind, viel parallel läuft und einiges still steht, da noch nicht einmal klare Verantwortlichkeiten zugewiesen sind. Kurz und bündig: es gibt zu viel laufende Veränderungen (change in progress).

Apropos zu viele parallelle Initiativen: Limitiere den Change-in-Progress (CIP)!

Ein weiteres Change-Board (Abbildung 5) unterstreicht, dass auch in punkto Veränderung die Nachfrage für gewöhnlich das Leistungsvermögen des Systems bei weitem übersteigt  Das gilt für den operativen Betrieb ebenso wie für die laufende Verbesserungsarbeit. Dass viele Veränderungsprozesse kaum sichtbar sind, fördert die Tendenz zur Überlastung.

Dieser Tendenz kann nur mit einer Strategie wirksam begegnet werden: mit einer konsequenten Limitierung des Change-in-Progress (CIP). Ohne CIP-Limits ist Stau vorprogrammiert – und dazu all die oft beklagten Symptome zwischen passiver Veränderungsmüdigkeit und aktiver Ablehnung.

 

Abbildung 5 “Improvement Board Business-IT”

Abbildung 5 “Improvement Board Business-IT”

Das in Abbildung 5 gezeigte Board stellt eine sehr radikale Form der Selbst-Beschränkung vor— und dazu einen kreativen Weg, den Prozess der laufenden Verbesserung zu visualisieren. Es handelt sich um das sogenannte “Improvement Board” eines österreichischen Telekommunikations-Unternehmens, mit Hilfe dessen der Business- und der IT-Bereich gemeinsam an Verbesserungen arbeiten. Das Ziel des Boards ist die Pflege eines kontinuierlichen Change Flow. Dieser wird nicht nur durch einen PDCA-artigen Zyklus, sondern auch durch die bewußte Limitierung des Inputs gefördert. Zum Zeitpunkt, an dem dieses Foto entstand, war der Input (siehe “Next”) sogar auf 0 gestellt, da sich bereits sechs Initiativen im Loop von “prepare”, “do”, “feedback” und “adapt” befanden. Um den Zug von diesem “Doing”-Loop zum “Done” nicht zu gefährden, wurde vereinbart, auf absehbare Zeit keine neuen Aktivitäten mehr zu starten.

Zusammenfassung

Leopold / Kaltenecker, Kanban in der IT, 2.A.

Leopold / Kaltenecker, Kanban in der IT, 2.A.

Obwohl es natürlich kein allgemeines Rezept gibt, dass Sie einfach kopieren und nahtlos in Ihr eigenes Umfeld einfügen können, will ich zum Abschluss einige konkrete Empfehlungen wagen.

Die folgenden Praktiken haben sich in den verschiedensten Zusammenhängen bewährt und sind großteils in unserem, mittlerweile in 2. Auflage erschienenen Buch “Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen” beschrieben:

  • das Eatblieren eines gemeinsamen Problemverständnisses: Warum sollten wir unseren Veränderungsansatz überdenken? Wozu brauchen wir ein anderes Vorgehen, wenn wir uns kontinuierlich verbessern wollen?;
  • das Überprüfen von Kanban als Lösungsansatz: Wie helfen uns die Prinzipien und Praktiken des evolutionären Managements bei der Adressierung unserer Probleme?;
  • das Einsetzen einer bunt gemischten Gruppe von Leuten, idealerweise einer fach- wie hierarchieübergreifenden Führungskoalition, die gemeinsam Verantwortung für das gesamte Veränderungsmanagement übernimmt;
  • die Identfikation aller wichtigen Stakeholder einer Veränderungsmaßnahme: Wen müssen wir informieren? Wen möglichst frühzeitig einbinden? Welche Abstimmung suchen? Und wie am Laufenden halten?;
  • das aktive Involvieren dieser Stakeholder durch ein angemessenes System von Feedbackschleifen, das direkte, persönliche Kommunikation ermöglicht;
  • das Erheben von Input für ein maßgeschneidertes Design eines Change Management Boards, am besten über Einzel- und Gruppengespräche mit den wichtigsten Stakeholdern: Was läuft derzeit gut und worauf können wir bauen? Was läuft nicht gut? Warum nicht? Und was sollte vordringlich geändert werden?;
  • die Präsentation und Diskussion eines konsolidierten Gesamtbildes aus den Gesprächen: wie stellt sich der Status Quo aus den unterschiedlichsten Perspekiven dar? Und wie kann uns Kanban helfen, die Anforderungen besser zu erfüllen?;
  • die Ausarbeitung eines maßgeschneiderten Boards für das laufende Verbesserungsmanagement und dessen neuerliche Diskussion mit allen wichtigen Stakeholdern;
  • die offizielle Inbetriebnahme und der laufende Betrieb resp. die kontinuierliche Verbesserung des Change Management-Systems mit Hilfe von Messungen und persönlichem Feedback.