Menu Schließen

Agile Transformation

Die Zeit verging im Flug und schon schreibe ich meinen letzten Blog. Diesmal zum Thema Agile Transformation von Pit Zurkirchen.

Das Fazit vorgezogen kann ich sagen, dass ich dieses Modul am Spannendsten erlebt habe. Lean Change, dachte ich mir. Die Aspekte von Change ändern sich kaum, nur weil ein Projekt agil umgesetzt wird. Doch Pit Zurkirchen holte früher aus, d.h. was Menschen zu Veränderungen bewegt, was es auslöst bzw. was es mit ihnen macht. Erst dann brachte er die mir bekannten Aspekte aus Change. Und ich lernte über das SCARF Modell, Veränderungsmodelle wie das 3-Phasen Modell (Lewin), die emotionale Veränderungskurve (Kübler-Ross) oder das psychologische Satir-Modell (Satir). Diese zahlreichen Inhalte und Themen aus der Kommunikations-, Psychologie-, Qualitätsmanagement-Toolbox wurden nun kombiniert. Die Kombination machte es letztlich lehrreich für mich und ich freue mich, in einem meiner nächsten Projekte das Erlernte anzuwenden.

 

Um meine nachstehenden Überlegungen und Interpretationen zum in diesem Modul neu Erlernten zu begründen, möchte ich die Arbeitswelt umschreiben, denen ich in Changeprojekten nach wie vor begegne. Dies gilt selbstverständlich nicht als Pauschalisierung, doch weitestgehend so oder ähnlich verlaufende Gegebenheiten. Mit Pit Zurkirchen vermittelten Inhalte jedoch lernte ich, dass meine Erwartung nach mehr Sinnhaftig-, Handhabbar- und Verstehbarkeit in einem Changeprojekt offenbar doch mit Systematik existiert, einen Namen hat und der Aspekt «Lean» nicht nur ein Märchen von morgen ist. Doch nun zu meinem Arbeitsalltag als Unternehmungsberaterin:

 

Wie oft in meinem Arbeitsalltag bezüglich Change-Projekten denke ich mir «schon wieder wird eine Organisation nach dem «budgetierten» oder «politisch verträglichen» Fahrplan umgesetzt. So werden nicht selten – und abhängig von den Erfahrungen des Projektleiters – die 8 Stufen (Kotter) des Changes mehr oder weniger gleichmässig und linear in den Projektplan eingebettet. D.h. wieviel Zeit, welche Phase in der Organisation benötigen «darf» wird im Voraus phasenweise verteilt. Zwar spricht man von Wirksamkeit der Massnahmen, erfolgskritische Faktoren wie die Beteiligung der Mitarbeitenden. Doch blicke ich auf meine Statussitzungen mit Auftraggebenden, bzw. sog. Steering Committee Meetings, so wird wenig Zeit für die Überprüfung und Anpassung der Insights oder Changezustand besprochen. Meist geht es um schnelle Meilensteinerreichung – um möglichst schlank «durch zu kommen». Die Projektnamen besiegeln förmlich die Projektpriorität mit Bezeichnungen wie «Fast Track», «Speed-Up» oder «RC», das für «Reduce Complexity» stand und statt Komplexität als Rahmenbedingung zu nehmen und damit zu arbeiten, versucht wurde, in der Organisation zu glätten bis hin aufzuheben. Die Besiegelung all dieser weniger optimalen Vorgehensweisen erfolgt dann noch mit Erfolgsboni sowie Halteprämien. Damit wird den Entscheidungsträgern und Projektleiter der Anreiz für die Einhaltung des Projektplanes und quantitative Projektziele geschaffen oder für sog. Key-Player-Mitarbeitende Prämien angeboten, damit sie das Unternehmen währendes Changes «trotzdem» nicht verlassen.

 

 

Der Lean Change Management Cycle (LCM)

Summary

Betrachte ich den obigen Zyklus von LCM, so sind sie mir nicht ganz fremd. Ob RADAR aus EFQM, DMAIC aus SixSigma oder PDCA (Deming/QM), es geht hauptsächlich um die konsequente Einhaltung der Systematik. Hier sehe ich auch den wesentlichen Unterschied zwischen LCM und meinen (plangetriebenen/klassischen) Vorgehensweisen. Die hohe Gewichtung von Zusammenarbeit, Qualität, Werte, die Erlaubnis von einer «fail fast and better»-Kultur sind bei LCM handlungsleitender und verankern viel stärker die Changemassnahmen. Auf einzelne möchte ich nachstehend vertiefter eingehen.

 

Der Hauptunterschied besteht also in der Fähigkeit, das Projekt einerseits voranzutreiben, das Spektrum jedoch auf die Entwicklungen, Feedback, Bedarf und Ideen zu erweitern. Erst auf dieser Grundlage können Changeprojekte das volle Potenzial entfalten. Die Erkenntnisse pro Iteration dienen demnach als Wegbeschreibung, von der aus stimmig und erfolgreicher gehandelt werden kann.

Aus meiner Sicht ein deutlich anspruchsvolleres Vorgehen. Raum, Zeit und Individualität zuzulassen und trotzdem das Projektziel zu «beherrschen», erfordert sehr viel mehr Empathie und Kompetenzen von allen Beteiligten. Sicherlich ist dieses agile Vorgehen kein Garant für das Gelingen eines Changes, doch die typischen Widerstände werden sicherlich gemindert, gemildert und Akzeptanz durch Beteiligung über alle acht Phasen des Changes, gekürzt.

 

 

Iteratives Vorgehen

Anders als beim oben beschriebenen Fall, wird in LCM schrittweise und teilweise iterativ vorgegangen. Ziel ist pro Schritt möglichst viel richtungsweisende Erkenntnisse und Feedback aus der Organisation zu erhalten, um den Change bedarfsgerechter weiter zu steuern und entwickeln. Der Change-Verlauf wird demnach kontinuierlich geprüft und darauf basierend die Planung der nächsten Massnahmen angepasst.

 

Insights

Zu Beginn ist es erforderlich, das zu lösende Problem zu verstehen, um daraus die richtigen Massnahmen und Hypothesen aufzustellen. Eine Aufgabe, mit der sich meine Auftraggebenden kaum aufhalten (möchten). Viel eher liegt ihr Fokus auf dem Ziel und dem Massnahmenplan dahin. Doch zurück zum Erlernten. Eine systematische Ursachenanalyse mit beispielsweise Ishikawa oder 5W hilft nicht nur die Vielschichtigkeit der zu verändernden Thematik zu erkennen und verstehen. Darauf basierend werden Hypothesen gebildet, was zur Folge hat, dass in einer so frühen Phase schon entscheidende Weichen richtig oder falsch gestellt werden können.

 

Options

Anders als in meiner Praxis, wo der Weg vorgängig weitestgehend statisch geplant und höchstens Pufferzeiten für Unvorhergesehenes eingebaut werden, werden hier basierend auf die identifizierten Ursachen mehrere Hypothesen beziehungsweise Lösungsoptionen gebildet. Das bedeutet, mehrere Massnahmen und Szenarien werden so formuliert, dass dabei die Frage beantwortet werden kann, wie eine zu verändernde Situation oder das Problem möglicherweise (auch) gelöst werden kann. Diese Optionen können verschiedenen Rahmenbedingungen Rechnung tragen und sich deshalb auch voneinander unterscheiden.

 

Experiments

Hier werden zu den Hypothesen Experimente gefahren, die nun die Hypothese bestätigen oder widerlegen. Der Unterschied zur eingangs erwähnter Vorgehensweise ist, dass durch das Ziel, möglichst viele Erkenntnisse zu sammeln, diejenigen, die sich als falsche Hypothese ergeben, mindestens so wichtig sind, wie diejenigen, die sich bestätigen lassen. Und selbstverständlich experimentiert man nicht ins Blaue hinaus. Diese Optionen werden wie in allen Investitionsthemen und das Aufwand-/Nutzenverhältnis gegenseitig erwogen. Je nach Firmenkultur sehe ich hier dieselben Hürden, wie in jedem anderen Projekt mit Investitionen. Die Wozu-Frage leidet nicht selten unter der Wieviel- oder Wie-Lange-Frage.

Umso wichtiger ist die Wozu-Frage gegenwärtig zu halten, welches Problem lösen wir damit und was benötigt es nun dafür? Die vorgängige Festlegung von Kennzahlen und Indikatoren, die eine Hypothese Zahlen-Daten-Fakten basiert bestätigen oder widerlegen sind eine weitere Massnahme zur Zielorientierung und Qualitätssicherung. Und auch hier sehe ich eine weitere Herausforderung. In der Praxis stelle ich fest, dass das Verständnis für Kennzahlen und Indikatoren sehr unterschiedlich ist und je nach Ergebnis (u/o Politik) sie einfach weggelassen werden.

Diese Experimente werden so lange durchgeführt bis alle Hypothesen bzw. Massnahmen abgearbeitet sind – vergleichbar mit dem PDCA-Regelkreis (Deming) nur mit einer zusätzlichen Iteration in der Iteration. Vergleichbar mit der Scrum-Iteration, bestehen die Experimente aus einer eigenen Sub-Iteration mit folgenden Teilleistungen:

  • Prepare– Vorbereitung der Option zur Umsetzung inkl. Bestimmung Messgrössen, KPIs, Indikatoren.
  • Introduce– Umsetzung der Optionen und Gewinnung der Erkenntnisse und Feedbacks.
  • Review– Validierung der Ergebnisse, Erkenntnisse auf das zu lösende Problem bezogen und diesbezüglich vorgängig geplanten KPIs/Indikatoren. Insbesondere dieser Punkt wird in meiner Praxis zu wenig konsequent bis gar nicht durchgeführt, zumindest was die Erfahrungen betrifft, wie auch die Qualität der Zusammenarbeit ist.

 

Der LCM-Cycle ist eingebettet in einen Kontext und Rahmenbedingungen und prägen massgeblich die oben beschriebenen Hypothesen in ihrer diesbezüglichen Ursache. Teile davon werden nachstehend mit Vergleichen zu meinen Projekt-Rahmenbedingungen in Changeprojekten zusammengefasst. Ausserdem werde auf den ebenfalls in der Grafik abgebildete Canvas eingehen.

 

People

Auch Beteiligte werden stark eingebunden und in ihrem Standpunkt sozusagen typisiert. Diese Typisierung nach Movers, Movables, Immovables klingt zunächst missverständlich. Doch basiert die Kategorisierung auf Aspekte, wie sie einleitend mit SCARF etc. beschrieben, bzw. systematisch identifiziert wurden. Ausserdem wird nicht nur anfänglich, sondern kontinuierlich der Entwicklungsstand der Beteiligten und ihrem Mind-Set erwogen und ermöglicht auch bedürfnis- und bedarfsgerechtere Massnahmen. Zumal die Betroffenen sich auch selbst einschätzen können. Dies verschafft die Möglichkeit, dass der Stand der Veränderung realistischer eingeschätzt werden kann.

Auch die Dauer der Change-Phasen relativiert und individualisiert sich bezüglich Handlungsbedarfes und auf Basis der gewonnen Einschätzung. Zwar besagt Kotters Modell, dass Beteiligte in unterschiedlichen Phasen des Changes abzuholen sind. Von LCM erfuhr ich nun jedoch, wie weiter damit umgegangen werden soll.

 

Selbstverständlich sehe ich auch die Gefahren dieser Typisierung. Zu schnell können voreilige Schlüsse darüber gezogen werden, wie sich jemand verhält und wie mit ihm umgegangen oder gar ignoriert wird. Doch diese Gefahr besteht in jeder Form der Vorgehensweise. Diese Gefahr mache ich auch vom Reifegrad und Kultur der Organisation abhängig, wobei ich mir gut vorstellen kann, dass auch hier agilere Vorgehensweisen diese Gefahr weniger bieten, weil der Mindset schon eine ganz andere ist.

 

Lean Change Canvas

Der Canvas ist eine einfachste Form der Planung, Umsetzung und Transparenz und stellt die Aufgaben und ihren aktuellen Stand dar. Der Fortschritt kann dann durch Heftnotizen-Umplatzierungen verwaltet werden und visualisiert den Projektstatus at a Glace. Auf dieser Grundlage können Diskussionen einfacher geführt werden, wenn die Konversion nicht im gewünschten Masse vorangeht oder Anpassungen im Vorgehen erforderlich werden.

 

Unter den zahlreichen Canvas arbeitete ich bisher mit dem Business Canvas Modell von Osterwalder/Pigneur. Je nach Detaillierungsstufe des Abzubildenden, können die Inhalte von strategischer bis Einzeltätigkeitsstufe kaskadiert werden und unterscheiden sich dementsprechend in den Feldbezeichnungen. Beim Lean Canvas geht es um die Umsetzung des Projektes, weswegen folgende Inhalte grundsätzlich thematisiert werden sollten:

  • Wozu: Ziel-/Sinnfrage
  • Was: Experimente
  • Wie: Umsetzung
  • Wer: Beteiligte/Bereich
  • Wann: Friste, Termine

 

Die Sichtbarmachung der Aufgaben und ihre Stati ist in agilen Projekten deutlich wichtiger, als in meinen bisherigen Changeprojekten. Die Visualisierung ist allerdings sehr einfach und kreativ gehalten. D.h. während für meine bisherigen Status-Meetings zeitintensive Folien für die Führung erstellt werden, die den Stand des Fortschrittes in Management-Folien wiedergeben, wird hier wahrscheinlich ein Foto des Canvas-Boards gemacht und diese in einer Managementpräsentation abgebildet. Ich würde – nach all dem Gelernten- sogar einen Schritt weitergehen und bei einfacheren Fällen die oberste Führung dazu einladen, den Projektstatus direkt vor dem Board durchzuführen. Zum einen, weil es Teamergebnisse zum Projekt nichts Vertrauliches sind, und zum anderen, um den Bezug und Committment hoch zu halten.

 

Zu Praxistipp LCM: «Are failed experiments really failing, or is the organization not ready for change?»

Nebst den oben aufgeführten Insights nehme ich diese Aussage mit.

 

Sie erinnerte mich unweigerlich an einen vor langen Jahren gelernten Ansatz: «Können – Wollen – Dürfen». Dieser besagt, dass eine gute Leistung – im vorliegenden Fall ist die Leistung der Change – nur möglich ist, wenn die drei Komponenten im Gleichgewicht sind. Ist dem nicht so, werden Ziele nicht oder nur teilweise erreicht, die Motivation sinkt und das fach- und firmenspezifische Wissen geht verloren. Die Konsequenz in Changeprojekten daraus sind schlechte Ergebnisse, Frustration der Beteiligten bis hin zu Abbruch u/o Neustart von Change-Rollouts.

 

Beispiel:

  • Nur weil eine Organisation den Change will
    (weil z.B. Markt Anpassung und damit Change erfordert) und
  • die Führung den Change als Massnahme erkennt und genehmigt (Dürfen),
  • ist die Organisation für die Transformation und Change nicht zwingend bereit und fähig (Können);

 

Denn oft dachte ich mir, dass der Kern mancher meiner Projekte der ist, dass die Organisation für den Change gar nicht bereit ist. Ein Dilemma für jede Unternehmungsberaterin. Da einerseits eine Optimierung und Wertschöpfung durch mich angestrebt wird, und andererseits diesbezüglich bei der Führung (Auftraggeber) diesbezüglich auf taube Ohren stosse wird.

 

Hilfreich wäre hier ein Tipp gewesen, wie mit solchen Organisationen umgegangen werden kann. Selber versuche ich diese Herausforderung mit der Wozu-Frage in Erinnerung zu rufen und lasse die Führung ausarbeiten, welche Voraussetzungen für das Projekt wichtig bis hin zu kritische Erfolgsfaktoren sind.

 

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert