Monatsarchiv 11. August 2017

Warum viele Veränderungsprozesse scheitern?

 

Projekt

Die Entwicklung von Projekten, Geschäftsprozessen, Businessplänen ist häufig aufwändig, zeitraubend, ressourcenintensiv und unproduktiv. Irgendwann ist das Ergebnis zusammengetragen und auf hunderten Folien dokumentiert. Viel Zeit ist ins Land gegangen und nach so viel Aufwand müssen jetzt schnell Entscheidungen her. Auch dann, wenn sich viele ursprüngliche Randbedingungen schon wieder verschoben haben.

Irgendwann ist es an der Zeit den inhaltlichen Wandel zu verkünden. Abteilungsleiter oder Projektteam werden instruiert, was sich nun alles ändern wird. Unruhe und Unsicherheit macht sich im Betrieb breit. „Wer da oben hat denn dies entschieden? Als ob wir keine anderen Probleme hätten“, lässt der Flurfunk wissen. „Was sollen wir denn noch alles zusätzlich leisten?“, werden andere ergänzen und Dritte sehen dies gar nicht in Ihrer Zuständigkeit.

So verbringt das Vorhaben seine Entwicklung zuerst im Verschiebebahnhof bis es dann am Abstellgleis endet. „Eigentlich hatten wir uns mehr davon versprochen“ lautet das enttäuschte Fazit aus der Führungsetage. Und so wandern Projekte, Geschäftsprozessinnovationen, Businesspläne allmählich in die Schubläden und Aktendeckeln.

Laut Standish Group wird die Erfolgsrate bei Projekten in den USA werden auf 34% geschätzt. Nur knapp die Hälfte aller Projekt-Vorhaben in Deutschland waren in den drei vergangenen Jahren erfolgreich, fand die TU München heraus.  Das beschriebene Szenario ist also eher Standard als Fiktion.

Die häufigsten Ursachen warum Veränderungsprozesse scheitern!

In den letzten 20 Jahren wurde viel zu dem Scheitern erforscht und in diversen Bereichen alternative Methoden erfolgreich eingeführt. Die Innovationsdynamik kam hier vor allem aus den rasant wachsenden Internetunternehmen, die sehr schnell erkannten und erlebten, dass die gängigen Modelle nicht ausreichten, um dem massiven Entwicklungs- und Veränderungsdruck in dieser Branche Stand zu halten.

Die Vorhaben werden zu umfangreich und zu komplex definiert!

Das Konzept des Prototyping ist ein bewährtes Verfahren aus der Software-, Produkt- wie auch Dienstleistungsentwicklung. Die reduzierte Basisversion konzentriert sich auf die Kernaspekte der Anforderungen und verhindert so, dass sich Projekte frühzeitig verzetteln.  Prototyping darf nicht verwechselt werden mit einem Proof of Concept, improvisierten Lösungen oder mit Workaround-Lösungen. Der Proof of Concept ist eine Machtbarkeitsprüfung bezogen auf einen isolierten Aspekt. Der Workaround eine improvisierte Schnelllösung als Zwischenschritt einer endgültigen Lösung.

Die Planbarkeit wird überschätzt und auf Unerwartetes wird nicht methodisch reagiert!

Effectuation ist ein jüngerer strategisch-methodischer Ansatz unternehmerischer Entscheidungsmethodiken. Prinzip ist, stark von den vorhandenen Ressourcen und Gestaltungsmöglichkeiten aus zu planen. Risiken werden durch die Definition des leistabren Verlustes begrenzt. Die Wirksamkeit dieses Konzepts beweist sich insbesondere in Projekten mit hoher Unsicherheit und Komplexität.

Die Anforderungen und Features werden zu ungenau definiert!

Der Teufel steckt bekanntlich im Detail. Unklare Aufträge sind die zweithäufigste Ursache für ein Projektscheitern. Meist werden vertiefte Fragestellungen erst während der nach dem Start deutlich. Die Optimization ist eine weitere Methodik in der das Prototyping unter Abwägung der Ressourcen nachgeschärft wird, ohne das Projekt insgesamt zu gefährden. Zwangsläufig kommen an dieser Stelle sämtliche Hinweise aller Beteiligten und Betroffenen ins Spiel. Wohlgemerkt: Um den Entwicklungsprozess schnell und schlank zu halten, erfolgt in dieser Phase keine Ausweitung Ausweitung des Vorhabens auf Nebenschauplätze. Optimiert werden die Anforderungen an den Prototyp.

Das Vorhaben bleibt in Kommunikationsschwierigkeiten, unausgesprochenen Konflikten und fehlenden Entscheidungen stecken!

Bis zu diesem Grade sind Projekte, Businessmodelle oder Prozessinnovationen überwiegend  noch Angelegenheiten auf dem Reißbrett. Aber die Beteiligten und Betroffenen müssen ins Boot geholt werden. Der nachfolgende Zwischenschritt entfällt in der Mehrzahl der Vorhaben und ist regelmäßig der häufigste Grund des Scheiterns.

Ein ganz zentraler Faktor für das Gelingen von neuen Verfahren, Businessmodellen oder Innovationen ist, dass die Beteiligten das Projekt zu einem Thema für sich machen. Hier ist mehr gemeint als nur ein Kick-Off-Termin. Ich habe dieses methodischen Abschnitt Decisions genannt. Decision deshalb, da eine Kenntnisnahme der Betroffenen meist nicht ausreicht. Vielmehr müssen Projekte bei diesen Personen dort hingebracht werden, dass diese das Projekt zu Ihrer Entscheidung machen. Traditionell ist dieser Prozess als Change Management definiert. Es gibt aber weit darüber hinausgehende Entwürfe, wie z.B. Holacracy. Dieser Ansatz geht davon aus, dass Mitarbeiter selbst alle notwendigen Entscheidungen im Unternehmen kompetent fällen können, folglich also auch Neueinführungen eine Folge ihrer Entscheidungen sind und diese Entscheidungskompetenz hierfür haben. Voraussetzung ist, dass klare Regeln und Rollensysteme vorhanden sind und das Management dem die volle Aufmerksamkeit widmet. Eine positive Folge dieses Konzept ist, dass der Flaschenhals des Entscheidungsstaus in Projekten wegfällt.

Die Tests und Einführungen sind ungenügend vorbereitet!

Die operative Einführung ist häufig ein Stiefkind bei den Vorhaben. Da Projekte regelmäßig die Terminplanungen überziehen, geht dies häufig zu Lasten des Zeitkontos einer methodisch strukturierten Einführung, damit Projektleiter die Timelines einhalten können. Die Folgen sind fatal, denn dadurch werden Testphasen schlichtweg in die Produktivphasen verschoben. Ein immer wieder beobachtbarer Grundfehler ist, dass die Testpersonen überhaupt nicht instruiert sind, was diese eigentlich testen sollen. Die Folge ist ein rein oberflächliches Testen. Die Konfrontation der Anwender mit der operativen Form des Projekts beginnt mit dem Rollout. Der Begriff stammt aus der Softwareentwicklung und wird dort eher eng gefasst. Allgemein verstehe ich diesen methodischen Schritt umfassender in Verbindung mit Testing in allen Ausprägungen. Also auch in Form eines Labortests, Feldtests, A/B-Test oder Usability-Test. Rollout und Testing ist die vollständige Dokumentation und Beobachtung der produktiven Einführung inkl. Instruktion, Rollbackplanung, Aktivierung der Messsysteme und Festlegung systematischer Auswertungen.

Das Controlling des Vorhabens ist ungenügend und die Reflexionen über den Projektverlauf werden vermieden!

Gerade bei rein technisch definierten Projekten musste ich häufig die Erfahrung machen, dass zwar die technischen Spezifikation erfüllt waren, aber in der täglichen Praxis die Anwendung inkompatibel zu den Prozessen und Arbeitsweisen waren. Das 6. Verfahrenselement ist der Review. Aus dem Projektverlauf werden strukturiert die Learnings gewonnen die laufenden Ergebnisse bewertet, dahingehend, ob die definierten KPIs (Key Performance Indicators)  erreicht werden. Eine notwendige Begleiterscheinung des Prototypings ist das systematische Ausblenden der Nebenbaustellen. Der Review hält diese noch offenen Themen fest. In der Regel lässt ein sorgfältiger Review auch die Seiteneffekte, Unerwartetes, Erwartetes und weniger Erwartetes erkennen.

Es werden nur die sichtbaren, offensichtlichen Probleme gelöst!

Das Redesign ist der zwangsläufige methodische Folgeprozess des Reviews. Redesign meint keinen grundlegenden Relaunch. Redesign ist der Projektschritt der Optimierung in dem das Projekt weiter an die Kundenbedürfnisse angepasst wird. Es ist eine Form der Anpassung und Erweiterung von Details. Wichtig ist das Prinzip, dass auch hier Verbesserungen schnell und sichtbar umgesetzt werden. Redesign schließt auch Konzepte der Vereinfachung (Simplify), der Ressourcenschonung, Komplexitätsreduzierung (Lean Management), der Missverständlichkeitsreduzierung und der Gefährdungsreduzierung ein.

Projektoptimierungen

Ich vermittle mit seecob Ihnen ein praxisbewährtes Verfahren für Ihre eigenen Optimierungen!

Aus der Kenntnis dieser Entwicklungen und in Erprobung eigener Berufspraxis habe ich die Methodik der Strukturierten Entwicklung eCommerce Business „seecob“ entwickelt. Es ist eine Verbindung dieser Methodenansätze. Neu daran ist der strukturierte Einsatz in den jeweiligen Entwicklungsphasen eines Projekts, eines Businessmodell oder Prozessinnovation.

Wollen Sie mehr zu seecob erfahren? Kontaktieren Sie mich jetzt. Ich informiere Sie gerne.