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 kreiert 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:
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 ebenso erfasst, wie die Vision, Mission und ggf. die strategischen Ziele eines Unternehmens. Bezieht er sich auf kleine, überschaubare Veränderungen insbesondere im Bereich Prozesse/Strukturen zusammen mit den technischen Hilfsmitteln, dann spricht man eher von KVP; bezieht er sich auf einen radikalen Umbau insbesondere im Bereich Mission und Strategie und ggf. Nachhaltigkeit und hat dann den Umbau von Prozessen, des Personals usw. zur Folge, dann reden wir von Transformation.
Empfehlung: als Unternehmen, das die nächsten Digitalisierungs-Schritte gehen will oder als Unternehmen, das für diese Klientel entsprechende Dienstleistungen anbietet, sollten Sie sich zusammen mit Ihren Kunden bzw. Ihren Consultants in die Klärung von Begriffen und Zusammenhängen begeben, um so das Feld gemeinsam auszuloten und zu begreifen, um was es genau gehen soll und um entsprechende Schlüsse ziehen zu können 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änderungswü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 ihre Systeme verkaufen wollen und 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 Kapazitä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 die Technologie 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 Motivationsprobleme oder Ziel-Unklarheiten. Darin liegt bereits eine gute Möglichkeit das Scheitern von Projekten zu verhindern.
Mögliche Aktivitäten zur 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 eines „open-mind“, eines bestimmten Denkansatzes: 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 muss, sondern direkt aus meiner Grundüberzeugung auch die „Problemlösung“ ableiten kann. Daraus folgt dann der von uns oft beobachtbare Reflex in Appellform: „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“ anzustoßen 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 Projektgegenstand, 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 mit Erfolgs-Wahrscheinlichkeit durchführen zu können. Das klappt nach unserer Erfahrung allerdings nur, wenn es eine gemeinsam getragene Vision/ allgemeine Zielbeschreibung gibt, und die Aufgaben/ Rollen gemäß den Kompetenzprofilen gut verteilt sind.
Die Bedeutung des „Reloads“ für das Vermeiden von „Scheitern“
Wir haben oben also anhand von ein paar Beispielen herausgearbeitet, wie wichtig in der heutigen Welt der Digitalisierungs- u.a. Change-Projekte der „Turnaround“ vom reflexartigen Herunterbeten von PM-Standards zum flexiblen, iterativen Vorgehen und Zusammenhänge und Bedürfnis-Erfassung mit einem systemischen Organisations-Verständnis ist.
Über verschiedene Recherchen haben wir ein paar dieses Vorgehen stützende Konzepte zur Nutzung für PM in Krisenzeiten und bei Gefahr von Scheitern gecheckt. Eines dieser Konzepte stammt von Otto Scharmer („theory U“,2014) und zeigt die Notwendigkeit des „Reload“ von bisher bekannten und angewendeten Konzepten/ Modellen/ Vorgehensweisen („man kann nicht mit denselben Konzepten, die die Probleme erzeugt haben, nach der Lösung suchen wollen“). Wir zeigen ein paar dieser Konzepte in folgendem Bild und geben über die Fragen – dem U von Scharmer folgend – Anregungen zur Veränderung der Herangehensweise bei der Gefahr des Scheiterns oder bei der Ankündigung einer Krise im Projekt.
Wir haben aus diesen Konzepten einen sog. „ChangeReload“-WS konzipiert, mit dessen Hilfe nicht nur die Change- oder Scheiter-Erfahrungen ausgetauscht werden, sondern sie reflektiert und mit neuen Konzepten konfrontier werden (andere „Brillen“ aufsetzen = Perspektiven einnehmen und etwas lernen über die Bedeutung von Emotionen und deren Berücksichtigung (Stichwort: Spüren lernen), dass daraus neue Anregungen für die Vermeidung von Scheitern und Lösungen/ Handlungsanleitungen deutlich werden, mit deren Hilfe erfolgreicher gearbeitet werden kann.
Dabei ist ergänzend ein systemisches Denkmodell (dazu gibt es ja auch im PM eine lange Debatte und viele Versuche das in den Projektalltag zu integrieren) sinnvoll. Interessanterweise wird ja in vielen Studien immer wieder die steigende Komplexität beklagt – das lässt darauf schließen, dass ein guter Umgang damit immer noch nicht selbstverständlich ist und dass man sich darum dringend kümmern sollte, wie diese Praxis in den Projekten besser etabliert werden könnte (vgl. z.B. Borgert, 2018 und Kahnemann (2012).
Und außerdem die Umsetzung der Erkenntnis aus dem Change Management, dass die Einbeziehung der Beschäftigten grade bei Digitalisierungs- oder Transformations-Projekten ein wesentlicher Faktor zur Vermeidung des Scheiterns ist: ohne deren spezifisches Know-How und Erfahrung, deren Engagement, deren Kenntnis der informellen Wege, der Spezialitäten der „wirklichen“ Prozesse usw. kann es kaum gelingen, eine funktionierende Zukunft im Unternehmen zu bauen. Dazu braucht es ein anderes Menschenbild und das Vertrauen, dass das gelingt und Wege, dieses herzustellen bzw. immer wieder neu zu gestalten..
Auf Nachfrage bei IT-Dienstleistern wird aber schnell klar, dass diese Differenzierung vielen fremd ist; vielmehr stellt man folgendes fest:
- 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.
- 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.
- 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 Projektablauf 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
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 ebenso erfasst, wie die Vision, Mission und ggf. die strategischen Ziele eines Unternehmens. Bezieht er sich auf kleine, überschaubare Veränderungen insbesondere im Bereich Prozesse/Strukturen zusammen mit den technischen Hilfsmitteln, dann spricht man eher von KVP; bezieht er sich auf einen radikalen Umbau insbesondere im Bereich Mission und Strategie und ggf. Nachhaltigkeit und hat dann den Umbau von Prozessen, des Personals usw. zur Folge, dann reden wir von Transformation.
Empfehlung: als Unternehmen, das die nächsten Digitalisierungs-Schritte gehen will oder als Unternehmen, das für diese Klientel entsprechende Dienstleistungen anbietet, sollten Sie sich zusammen mit Ihren Kunden bzw. Ihren Consultants in die Klärung von Begriffen und Zusammenhängen begeben, um so das Feld gemeinsam auszuloten und zu begreifen, um was es genau gehen soll und um entsprechende Schlüsse ziehen zu können 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änderungswü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 ihre Systeme verkaufen wollen und 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 Kapazitä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 die Technologie 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 Motivationsprobleme oder Ziel-Unklarheiten. Darin liegt bereits eine gute Möglichkeit das Scheitern von Projekten zu verhindern.
Mögliche Aktivitäten zur 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 eines „open-mind“, eines bestimmten Denkansatzes: 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 muss, sondern direkt aus meiner Grundüberzeugung auch die „Problemlösung“ ableiten kann. Daraus folgt dann der von uns oft beobachtbare Reflex in Appellform: „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“ anzustoßen 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 Projektgegenstand, 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 mit Erfolgs-Wahrscheinlichkeit durchführen zu können. Das klappt nach unserer Erfahrung allerdings nur, wenn es eine gemeinsam getragene Vision/ allgemeine Zielbeschreibung gibt, und die Aufgaben/ Rollen gemäß den Kompetenzprofilen gut verteilt sind.
Die Bedeutung des „Reloads“ für das Vermeiden von „Scheitern“
Wir haben oben also anhand von ein paar Beispielen herausgearbeitet, wie wichtig in der heutigen Welt der Digitalisierungs- u.a. Change-Projekte der „Turnaround“ vom reflexartigen Herunterbeten von PM-Standards zum flexiblen, iterativen Vorgehen und Zusammenhänge und Bedürfnis-Erfassung mit einem systemischen Organisations-Verständnis ist.
Über verschiedene Recherchen haben wir ein paar dieses Vorgehen stützende Konzepte zur Nutzung für PM in Krisenzeiten und bei Gefahr von Scheitern gecheckt. Eines dieser Konzepte stammt von Otto Scharmer („theory U“,2014) und zeigt die Notwendigkeit des „Reload“ von bisher bekannten und angewendeten Konzepten/ Modellen/ Vorgehensweisen („man kann nicht mit denselben Konzepten, die die Probleme erzeugt haben, nach der Lösung suchen wollen“). Wir zeigen ein paar dieser Konzepte in folgendem Bild und geben über die Fragen – dem U von Scharmer folgend – Anregungen zur Veränderung der Herangehensweise bei der Gefahr des Scheiterns oder bei der Ankündigung einer Krise im Projekt.
Wir haben aus diesen Konzepten einen sog. „ChangeReload“-WS konzipiert, mit dessen Hilfe nicht nur die Change- oder Scheiter-Erfahrungen ausgetauscht werden, sondern sie reflektiert und mit neuen Konzepten konfrontier werden (andere „Brillen“ aufsetzen = Perspektiven einnehmen und etwas lernen über die Bedeutung von Emotionen und deren Berücksichtigung (Stichwort: Spüren lernen), dass daraus neue Anregungen für die Vermeidung von Scheitern und Lösungen/ Handlungsanleitungen deutlich werden, mit deren Hilfe erfolgreicher gearbeitet werden kann.
Dabei ist ergänzend ein systemisches Denkmodell (dazu gibt es ja auch im PM eine lange Debatte und viele Versuche das in den Projektalltag zu integrieren) sinnvoll. Interessanterweise wird ja in vielen Studien immer wieder die steigende Komplexität beklagt – das lässt darauf schließen, dass ein guter Umgang damit immer noch nicht selbstverständlich ist und dass man sich darum dringend kümmern sollte, wie diese Praxis in den Projekten besser etabliert werden könnte (vgl. z.B. Borgert, 2018 und Kahnemann (2012).
Und außerdem die Umsetzung der Erkenntnis aus dem Change Management, dass die Einbeziehung der Beschäftigten grade bei Digitalisierungs- oder Transformations-Projekten ein wesentlicher Faktor zur Vermeidung des Scheiterns ist: ohne deren spezifisches Know-How und Erfahrung, deren Engagement, deren Kenntnis der informellen Wege, der Spezialitäten der „wirklichen“ Prozesse usw. kann es kaum gelingen, eine funktionierende Zukunft im Unternehmen zu bauen. Dazu braucht es ein anderes Menschenbild und das Vertrauen, dass das gelingt und Wege, dieses herzustellen bzw. immer wieder neu zu gestalten..
