Alle sind sich einig: Digitalisierung ist ein Change, braucht ein modernes Change-Konzept – warum scheitern trotzdem so viele Projekte?

Anscheinend ist es banal: Digitalisierung bedeutet Veränderung. Ob es um die Anpassung oder Neudefinition von Abläufen (als Stichwort „Papierfreies Büro“) oder um die Auslagerung von Daten in die Cloud und deren Nutzung von überall her, ob als Neu-Definition von Kommunikation bzw. Austausch über elektronische Plattformen und von Kooperation („Co-Creation“) oder ob auf der Ebene von Geschäftsfeldern bzw. -strategien (mit Hilfe einer app wird eine neue Dienstleistung kreiiert und verkauft)  – es leuchtet jedem ein, dass das eine irgendwie geartete Veränderung ist. Aber wodurch ist sie gekennzeichnet, wie grenzt sie sich ab und welche Konzepte helfen wirklich weiter?

Auf Nachfrage bei IT-Dienstleistern wird aber schnell klar, dass diese Differenzierung vielen fremd ist; vielmehr stellt man folgendes fest:

1. IT- oder Digitalisierungs-Projekte werden häufig – so wie schon seit 30 Jahren – technik-zentriert, einem klassischen Planungs-Paradigma folgend – angegangen (obwohl schon seit mindestens 15 Jahren die Vorteile des „agilen Ansatzes“ – grade in so einem beweglichen Veränderungsbereich wie der Digitalisierung – im Projektmanagement bekannt sind) – das ist mit einem modernen Change-Verständnis nicht vereinbar.
2. die Verbindung von IT-/ Digitalisierungs-Projekten mit einem explizit-formulierten und passenden Change-Konzept ist eher selten und wenn, dann auf die Schaffung von Akzeptanz bei den MitarbeiterInnen gerichtet, weil man erkannt hat, dass man sie braucht und weil man sie „ruhig halten“ will.

Wenn man sich über den Erfolg von IT- und Change-Projekten informieren will, fällt auf, dass in einschlägigen Untersuchungen (McKinsey, PWC u.a.) von einer Scheiter-Quote von 60-70% die Rede ist – und das schon viele Jahre immer wieder:  

• Das Ziel ist nicht klar – nicht gut kommuniziert…
• Der Projektauftrag ist unklar -nicht gut geklärt – dazu immer wieder Debatten
• Die Probleme des Projekts werden nicht wahrgenommen bzw. verleugnet (die Ampel steht schon lange auf gelb, weil sich keiner traut, sie auf Rot springen zu lassen, was eine Kulturfrage ist)
• Pläne sind unrealistisch  – Termine werden nicht gehalten – sind „von oben“ vorgegeben und haben mit dem Projektverlauf wenig zu tun (sind oft anders begründet), Kapazitäten werden nicht realistisch eingeschätzt, Aufwände sind real unerwartet gestiegen, viele Aufgaben werden als „fast fertig“ gemeldet…
• Projektrisiken werden allenfalls zu Beginn formuliert – spielen im weiteren Pro-jektablauf aber keine Rolle; VUCA wird unterschätzt (Umgang mit Komplexität, Unsicherheiten usw. – obwohl Handlungsanleitungen bekannt, klappts nicht)
• Die Zuordnung der Linien-Mitarbeiter ist formal klar -informell wird aber multitasking – selbst im agilen Projekt – praktiziert;
• Fluktuation: Ausscheiden von Projekt-Personal (kein schneller Ersatz möglich)
• Die Stakeholder sind zwar bekannt, aber es wurde versäumt, eine passende Kommunikationsorganisation aufzusetzen und grade in schwierigen Zeiten zu nutzen

Dies deutet für uns – mit unserem systemischen Verständnis von Projekten und Organisationen – eindeutig auf das Wirken von ungünstigen Mustern hin: was passiert also, dass immer wieder dieselben Verhaltensweisen, Sachverhalte, Dynamiken negativ auf den Fortgang von Projekten wirken?

Um einen Unterschied zu machen, definieren wir hier unser Change-Verständnis: wir verstehen Change als Wandelprozess, der die Elemente einer Organisation wie Prozesse/Strukturen, Kultur, Führung und Personalentwicklung, technische u.a. Hilfsmittel und sich auf die Vision, Mission und ggf strategischen Ziele eines Unternehmens bezieht. Dieser Prozess kann Phasen von KVP (kleine, überschaubare Veränderungen) enthalten, aber eben auch radikalen Umbau von Mission/ Strategie und in der Folge von Prozessen usw. bedeuten. Dabei ist die Digitalisierung für uns eine aus der ggf nötigen Anpassung oder Neu-Ausrichtung der Prozesse/ Strukturen usw. an die Kundenbedürfnisse/ Marktanforderungen oder an die Anforderungen des legalsystems oder der Kultur abzuleitendes Element, das natürlich auch eigenständig strategisch ausgerichtet sein kann.

Empfehlung: als Unternehmen, das die nächsten Digitalisierungs-Schritte gehen will oder als Unternehmen, das für diese Klientel entsprechende Dienstleistungen anbietet, sollte ich mich zusammen mit meinen Kunden bzw. meinen Consultants in die Klärung von Begriffen und Zusammenhängen begeben, um so das Feld gemeinsam auszuloten und entsprechende Schlüsse bzgl. Vorgehensweise, zu verwendende Tools, einzunehmende Rollen usw. ziehen zu können.

Insbesondere sollten sich die Dienstleistungs-Anbieter – bezogen auf den oben zitierten 2.Spiegelpunkt – eine professionellere Auftragsklärung angewöhnen: dazu gehört, sich in die Welt des Kunden hineinzuversetzen und dessen Lösungswünsche oder Problembeseitigungs- oder Veränderungwünsche ernst zu nehmen, sie aber auch kritisch zu hinterfragen aus verschiedenen Perspektiven unter realer Einbeziehung interessanter Stakeholder-Gruppen (z.B. auch den BR, wenn es einen gibt).

Wir verfolgen die Leitidee, dass Organisationen – auch die KMU – nicht blind sind oder schlafen (wie in der Presse oft kolportiert wird), sondern häufig bereits Ideen haben, woran sie als nächstes arbeiten sollten/ wollen, dass es aber Bedingungen gibt, die ggf den nächsten Schritt behindern  – z.B. die mangelnde Liquidität oder Kapazitäten oder die fehlende Priorisierung, welchen Schritt man zuerst tun soll… Wir haben die Erfahrung gemacht, dass der Mittelstand eher einfühlsame, erfahrene Berater braucht, die nicht nur verstehen, wo man steht und was als nächstes zu tun ist, sondern die auch eine Idee haben, wie man diese Schritte kostengünstig,mit den vorhandenen Ressourcen bzw vorhandenen Kapaztitäten stemmen kann. Und das hat auch was mit entsprechenden Konzepten und der Vernetzung zu tun.

Weiterhin haben wir die Überzeugung gewonnen – gefestigt über viele Jahre positiver Erfahrung – dass es zielführend ist, nicht den erfolgreichen Technologieeinsatz in den Mittelpunkt zu stellen, sondern eher das, was den Kunden befriedigen könnte und das, was für die MitarbeiterInnen ein Benefit sein könnte.

Damit sind wir bei der beteiligungs-orientierten Vorgehensweise: für den Erfolg von Digitalisierung und Change ist aus unserer Erfahrung entscheidend, von wo ab und wie tief die betroffenen Mitarbeitenden einbezogen waren und sind. Je früher und je besser sie mitgestalten durften, desto weniger entstehen im Zuge des Veränderungs-Prozesses Motivations-probleme oder Ziel-Unklarheiten. Dies ist eine gute Möglichkeit das Scheitern von Projekten zu verhindern.

Die Vermeidung des „Scheiterns“

Neben den oben bereits erwähnten Zusammenhängen und deren Folgen für das Thema „Vermeidung von Scheitern“, zeigt sich auch die Bedeutung von „open-mind“: ist meine Grundüberzeugung, dass die Berücksichtigung der im PM üblichen Standards bei der Durchführung von IT-/Change-Projekten quasi automatisch zum Projekt-Erfolg führen, dann kommen mir die Scheiter-Punkte zumindest auf der Oberfläche entgegen, wenn sie PM-Grundlagen ansprechen – weil ich dann nicht umdenken muß, sondern direkt aus meiner Grundüberzeugung auch die „Problemlösung“ ableiten: Appell: berücksichtigt bzw. befolgt doch die im Kanon der IPMA oder des PMI formulierten Theorien/ Konzepte , Methoden – dann habt Ihr keine Probleme.

Bei einem derartigen Vorgehen wird ignoriert, – wenn man mal voraussetzt, dass die „Gescheiterten“ keine Dummköpfe oder schlampigen Arbeiter sind – dass es Gründe geben wird, warum nicht alle Punkte dieses Kanons wie vorgeschrieben angewendet worden sind.

Wenn – wie wir oft gelesen und gehört haben – häufig davon die Rede ist, dass man keine Zeit für das und jenes habe oder dass einem im Projekt dafür keine Zeit gelassen wird, dann wäre das nach unserer Kategorisierung kein Grund für das Scheitern, sondern eher eine Rahmenbedingung unter der geklärt werden müsste, ob man z.B. eine Stakeholder- oder Risiko-Analyse „ungestraft“ weglassen kann und ob es zur Klärung dieser Frage nicht eine entsprechende Gestaltung der Auftrags- und Rollen- sowie Konzeptklärung braucht. Und dann ginge es möglicherweise dort um Klarheit, um Mut, derartige Punkte anzusprechen und um die Fähigkeit, die Konsequenzen aus einem derartigen Handeln aufzuzeigen.

Wenn es – wie wir ebenfalls schon gehört haben – um die „Umständlichkeit“ einer Methode oder um deren „Wirkungslosigkeit“ geht, dann wäre das nach unserer Kategorisierung ein Methoden-Problem und ggf  ein „Denkmodell-Problem“. Wenn z.B. die Stakeholder-Analyse weggelassen wird, weil Ihr Nutzen nicht klar ist oder weil man das Vorgehen zu „umständlich“ findet, dann sollte man sich darüber informieren, welche modernen Methoden es mittlerweile – grade auch im agilen Umfeld – gibt, um einen „mitlaufenden Prozess des Check von wichtigen Personen und deren Beziehungen im Projekt sowie in seinem Umfeld“ anzustossen und für die Projektarbeit zu nutzen.

Ein weiterer „Scheiterpunkt“, der in vielen Untersuchungen immer wieder genannt wird: „unrealistische Planung“, „unrealistische Erwartungen“ u.ä. Das zeigt uns, dass die schon viele Jahre geführte Debatte über das im klassischen PM vermittelte Prinzip einer logischen Ablaufplanung  inkl. einer umständlichen Vorgehensweise anhand von Aufgaben und Zeitschätzungen nicht in der aktuellen Projektpraxis angekommen ist: ein Projekt – grade wenn es sich um Digitalisierungs- und damit um Change-Projekte handelt – ist ja dadurch gekennzeichnet, dass es unerwartete Ereignisse oder neue Wege bis hin zu einer sich erst im Prozess konkretisierenden Zielstellung geben kann. Das bedeutet, dass hier eher eine iterative Vorgehensweise mit dann zu diskutierenden Zwischenergebnissen und einer immer wieder neu zu treffenden Entscheidung über die nächsten Schritte angesagt ist. Insofern würde es darum gehen, ein an den Projektgegenstande, das Umfeld, das Team, die Kultur usw. angepasste, agile Vorgehensweise zu wählen – zusammen mit wichtigen Stakeholder-Gruppen. In den Reviews, Retrospektiven u.a. Feedback-Runden wird man feststellen, ob die gewünschten Verbesserungen/ Veränderungen eintreten oder nicht und was es dann braucht an weiteren Maßnahmen/ Interventionen, um den nächsten Step erfolgreich zu erreichen. Das klappt nach unserer Erfahrung allerdings nur, wenn es eine gemeinsam getragene Vision/ allgemeine Zielbeschreibung gibt, und die Aufgaben/ Rollen gemäß den Kompetenz-profilen gut verteilt sind.  

Die Bedeutung des „Reloads“

So wie oben hergeleitet anhand von ein paar Beispielen, schlagen wir vor, zur Vermeidung von Scheitern/ von Krisen usw. folgendermaßen vorzugehen:

Es muss in einem ersten Schritt darum gehen, die Change- oder Scheiter-Erfahrungen so zu reflektieren, dass die gefundenen Lösungen für Probleme bei der Durchführung von Digitalisierungs-/Change-Projekten nicht nur als sog. „best practices“ abgehakt werden, sondern dass man sich bewusst macht, welche Theorien/ Modelle/ Konzepte und Methoden zum Erfolg beigetragen haben – oder, wenn man das Scheitern analysieren und daraus lernen will, müsste man nach denjenigen Theorien/ Modellen usw. fahnden, die ggf nicht oder nicht mehr angemessen sind für das Handeln in heutigen Kontexten/ mit heutigen Rahmenbedingungen.

Dabei scheint es uns ganz grundsätzlich darum zu gehen, schon bei dieser Analyse ein systemisches Denkmodell anzuwenden und so wichtige Dimensionen, deren Zusammenhänge und Dynamiken zu erfassen und in ihrer Wirkung auf das Projekt im Blick zu haben. Wenn in vielen Studien immer wieder die steigende Komplexität beklagt wird, dann zeigt dies die Notwendigkeit, sich genau darum zu kümmern, wie man im Projekt einen besseren, zielführenden Umgang mit der Komplexität etabliert. Dazu gehört auch das sog. „schnelle – langsame Denken“ von Kahnemann (..)

Sollte man weiterhin feststellen, dass die gelernten Konzepte, Modelle und Methoden nicht mehr richtig passen, dann sollte es in einem nächsten Schritt um die praktische Erprobung neuer, moderner Konzepte/ Modelle bzw. um das agile Anpassen von Vorgehensweisen gehen. Dabei sollten alle Disziplinen, die etwas substantielles zum Erfolg von IT-/Change-Projekten beitragen können, berücksichtigt werden. Insbesondere wollen wir – falls es noch nicht klargeworden ist – darauf hinweisen, für wie wesentlich wir die Einbeziehung der Beschäftigten in diesen Prozess halten: deren spezifisches Know-How und deren Erfahrung hilft nicht nur, Realitäten und Zukünfte mit in den Change zu integrieren, sondern auch, die Motivation hochzuhalten und den Change als „unsere Sache“ zu verankern. Unsere Erfahrung sagt, dass sich die meisten Beschäftigten gerne engagieren, wenn sie etwas davon haben – man an ihren Bedürfnissen und Kompetenzen anknüpft und Möglichkeiten schafft, dass sie diese auch einbringen dürfen – und wenn man mit ihnen „auf Augenhöhe“ umgeht und sie die Umsetzung ihrer Ideen mitverfolgen können. Leider mussten wir oft beobachten, wie „von oben herab“ durchgeplant wurde und das von Beschäftigten vorhergesagte Scheitern auch wirklich eintraf (was dann beim nächsten Change-Projekt nicht unbedingt zu freudiger Erwartung geführt hat).

Viele BeraterInnen halten sich bei der Erklärung,  wieso es zu Widerständen kommt und wie sich Beschäftigte durch diese Phase des Projekts „quälen“ mit vielfältigen Spekulationen zur Abfolge von Verhaltensweisen und für ganz andere Zwecke entwickelten Modellen auf (wie z.B. das von Kübler-Ross entwickelte Konzept zum Umgang mit dem Tod – zur Kritik s. …ZfOE). Für sinnvoller halten wir, ein board im Zuge des Projekts zu führen, auf dem sich die Probleme, Ärgernisse usw. sammeln und nach Bearbeitung sichtbar für alle wieder verschwinden.

Nochmal zusammenfassend:

IT-, Digitalisierungs- und Change-Projekte scheitern dann weniger, wenn

• ein agiles Change-Konzept genutzt wird mit dessen Hilfe die Digitalisierung in das Organisations-Ganze eingeordnet und auf die Vision/Mission/ Geschäfts-Strategie bezogen wird und mit dessen Hilfe „Planungs-Illusionen“ vermieden werden;
• mit systemischem Verständnis einer Organisation ihre Veränderungs-Notwendigkeiten /Bedarfe sowie ihre IST-Zustände (verschiedene Perspektiven) während der Beauftragungs-Phase geklärt werden, um sich dann über die Stellhebel zur Weiterentwicklung dynamischer Organisationen zu unterhalten und zu besprechen, wohin sie – je nach zu verfolgenden Zielen, nach vorhandenen und z.V. gestellten Ressourcen und Kompetenzen – bewegt werden sollen (in Abhängigkeit voneinander mit entsprechender Folgenabschätzung) – Ergebnis sollte eine zwischen Veränderungs-willigen Unternehmen und ihren Consultants vereinbarte, erste grobe roadmap sein
• man sich nicht nur die Zeit für nützliche Analysen und Reflexionen/ Lernphasen (Feedback-Schleifen) nimmt, sondern auch überall da, wo man merkt, dass Gelerntes PM- und Change-Wissen sowie die eigene oder die Team-Erfahrung nicht reichen, um Probleme zu lösen/ Fortschritte zu ermöglichen o.ä. Möglichkeiten gesucht werden, Neues zu lernen, mutig zu sein, um Neues auszuprobieren, für bessere Rahmenbedingungen zu streiten.

Zur Anregung für die eigene Change-Praxis geben wir unsere Frageliste frei.