Implementation Dip - Nicht reinfallen!

Mit jedem Veränderungsvorhaben sind in der Regel hohe Erwartungen an dadurch erzielbare Produktivitäts- oder Performance-Steigerungen verbunden. Oft ist es jedoch so, dass nach dem Rollout der Änderungen die Produktivität zunächst abfällt. 

Das liegt in erster Linie daran, dass jede Änderung erstmal verdaut werden muss. Neue Fähigkeiten müssen erworben und oft auch Ängste überwunden werden. Michael Fullan hat diesen Effekt 2001 als “Implementation Dip” beschrieben. 

Der Implementation Dip erfüllt damit zunächst nicht die eigentlich an die Veränderung geknüpften Hoffnungen. Im Gegenteil, die zunächst sinkende Produktivität erzeugt einen Verlust, der eigentlich auch als notwendige “Investition” bei der Planung der Veränderung berücksichtigt werden müsste. Dieser nur auf den ersten Blick überraschende Einbruch hat schon oft dafür gesorgt, dass Veränderungen wieder rückgängig gemacht wurden, da die Verantwortlichen plötzlich kalte Füße bekommen haben und nicht mehr an den Erfolg der Maßnahme glaubten.

Wenn man am Ball bleibt, besteht aber immer noch das Risiko, dass der Veränderung der Schwung genommen wird. Wenn der Einbruch besonders tief ist, wird unter Umständen auch auf lange Sicht nicht der Business Value erzielt, der ursprünglich geplant war. 

Vollständig vermeiden wird man diesen “Dip” nicht können. Die Frage ist also: Was können wir tun, um den Absturz so gering wie möglich zu machen und die Recovery Zeit, also die Zeit, die notwendig ist um wieder zur ursprünglichen Performance zurückzukommen, so kurz wie möglich zu machen. 

Der aus meiner Sicht wichtigste Lösungsansatz ist, nicht den gesamten Change sofort und in voller Breite durchzuführen, sondern ihn in kleine verdaubare Häppchen zu packen, die mit einem zeitlichen Versatz eingeführt werden. Das verkleinert das Risiko und hilft dabei die Änderungen besser adaptieren zu können. Erinnert euch das an was?

Neben der besseren Verdaubarkeit gibt es weitere Vorteile: Nehmen wir zum Beispiel eine DevOps Transformation. Wenn ich ein ganzes Bündel an technischen und organisatorischen Änderungen gleichzeitig einführe, dann kann ich nicht mehr unterscheiden, welche Maßnahme tatsächlich einen Effekt auf eines meiner Business Ziele, z.B. häufigere Releases, erzielt hat. Führe ich Änderungen gestaffelt ein, kann ich die Wirkung prüfen und ggf. für weitere Rollouts anpassen. 

Seid ihr schon dem Implementation Dip begegnet? Wie habt ihr euch wieder nach oben gekämpft?

Wenn euch das Thema interessiert hat, freue ich mich über Feedback in Form von Likes. Wenn ihr auch eine Meinung dazu habt, freue ich mich noch mehr über Kommentare und Austausch oder eine Kontaktaufnahme.