Im Interview mit Dr. Klaus Wagenhals

Aktuelle Studien unterstreichen die Dringlichkeit des Themas “Scheitern von IT-Projekten” deutlich. Laut einer Erhebung der Standish Group scheitern weltweit 66 % aller IT-Projekte ganz oder teilweise. Gründe dafür sind unter anderem unrealistische Zeit- und Budgetpläne, unklare Anforderungen und eine mangelhafte Einbindung von Stakeholdern. Eine weitere Studie von McKinsey und der University of Oxford zeigt, dass Großprojekte in der IT im Durchschnitt ihr Budget um 45 % überschreiten und 7 % weniger Funktionen liefern als ursprünglich geplant. Dabei erweist sich die wachsende Komplexität als einer der Hauptfaktoren, der IT-Projekte in Schieflagen bringt.

Dr. Klaus Wagenhals, ein führender Experte für Change-Prozesse, Leadership und Projektmanagement, wird im Interview mit Silicon Valley Europe seine tiefgehenden Einblicke und Erfahrungen zum Thema "Scheitern von IT-Projekten" mit uns teilen. Seit über zwei Jahrzehnten begleitet er Unternehmen aus den Branchen IT, Automotive, Life Sciences und High-Tech und ist Netzmanager von metisleadership. Mit seiner fundierten Expertise als Organisations-Psychologe und Industrie-Soziologe hat er nicht nur Unternehmen durch komplexe Veränderungsprozesse geführt, sondern auch als Autor und Speaker die Diskussion über neue Ansätze im Projektmanagement maßgeblich geprägt.

Dr. Wagenhals erklärt, warum das bloße Befolgen gängiger Standards im Projektmanagement nicht ausreicht und welche Rahmenbedingungen geschaffen werden müssen, um Projekte erfolgreich zu machen. Er zeigt, wie die frühzeitige Einbindung der wichtigsten Stakeholder und eine iterative Vorgehensweise Projekte anpassungsfähiger und resilienter machen. 

Silicon Valley Europe: Herr Dr. Wagenhals, Sie begleiten seit Jahrzehnten Unternehmen durch Change-Prozesse. Was hat Sie an diesem Thema von Anfang an fasziniert?

Dr. Klaus Wagenhals: 

Mich hat fasziniert, dass es in Unternehmen immer wieder einen Punkt gab, an dem klar wurde: „so geht’s nicht weiter“, es braucht „was Neues“ und dass das Gespür für diesen Punkt nicht nur den „Chefs“ zugeschrieben werden kann, sondern auch cleveren Beschäftigten, die sich selbständig um die Trends, die aktuellen Entwicklungen bei den Kunden usw. kümmerten. Vor 30 Jahren, als ich mit dieser Arbeit begonnen habe, waren es meist Prozesse, die optimiert oder neu gestaltet werden sollten – damals schon wie heute – häufig verknüpft mit der Implementierung von IT-Systemen wie z.B. Dokumenten- oder Workflow-Management-Systemen, oder ersten Versuchen, die Kundendaten elektronisch pflegen und aufbereiten zu lassen. Es ging also schon immer um das Zusammenwirken von Prozessen/ Strukturen/ Kultur/ Kompetenz und Potenzial der Beschäftigten sowie um Führung und Technologie. Und bezogen auf dieses Zusammenspiel fand ich faszinierend, dass es Führungspersonen gab und gibt, denen es gelingt, auch die „Schwarz-„ oder „Problem-Seher“ in der Belegschaft sowie die Verunsicherten zu hören, ernst zu nehmen, einzubeziehen und damit nicht nur die Stimmung in der Belegschaft „zu drehen“, sondern auch Fehler, die andere gemacht haben zu vermeiden. Das verweist nicht nur auf ein anderes „Digitalisierungs-Konzept“, als das über jahrzehnte angewendete mechanistisch-gedachte, sondern auch auf eine andere innere Haltung gegenüber den verschiedenen Denkmodellen, Haltungen, Verhaltensweisen von Menschen, die in die Unternehmens-Dynamik  eingebunden sind: es geht nicht nur um oberflächliches Verstehen, sondern um „Mitfühlen“, um ein „Gespür“ für andere Denk- und Verhaltensweisen: das geht nicht ohne eine grundsätzlich humanistische Orientierung und eine Fähigkeit zur Selbstreflexion bzgl. Veränderungen auf der persönlichen Ebene („successful change in companies needs inner change too“).

Silicon Valley Europe: IT-Projekte gelten als besonders fehleranfällig. Wie würden Sie das Ausmaß des Scheiterns basierend auf Ihren Erfahrungen und aktuellen Studien beschreiben?

Dr. Klaus Wagenhals: 

IT- oder Digitalisierungs-Projekte, sind nach unserem Verständnis ja immer Change-Projekte, wenn mit der Einführung neuer Technik Abläufe/ Prozesse und ggf. Strukturen (also z.B. die Zuordnung von Abteilungen) verändert werden und wenn außerdem Folgen in Richtung Zusammenspiel der Menschen (Kulturaspekte) und in Richtung Führung zu erwarten bzw. zu beobachten sind. Ein derartiges Konzept denkt die Auswirkungen einer Intervention an einer bestimmten Stelle – z.B. wenn Kundendaten an verschiedenen Prozess-Orten und Schnittstellen verwendet werden – mit und größer. Diese „systemische Denke“ führt dazu, sich eine Organisation und damit auch ein Projekt wie ein vielgliedriges Mobile vorzustellen, das sich – wenn man an einer Stelle zieht – an mehreren Stellen, die nicht genau vorherzusagen sind, bewegt. Dies drückt die innere Abhängigkeit der eine Organisation bestimmenden Faktoren und deren Eigendynamik aus. Die „Fehleranfälligkeit“ von IT- bzw. Digitalisierungs-Projekten liegt genau in dieser Vielfalt und Unberechenbarkeit von „Organisations-Verhalten“ und sollte daher mittels passender Change-Konzepte verstanden und angegangen werden. Wird Digitalisierung auf die Anpassung bzw. Einführung eines IT-Systems reduziert und „logisch“ nach einem klassischen im PM üblichen Plan abgearbeitet, wird es voraussichtlich viele Scheiter-Gefahren geben.

Insofern wundert es nicht, wenn bei verschiedenen Studien, die wir in den letzten Jahren z.K. nehmen mussten (z.B. McKinsey, PWC, standish group u.a.) von einer Scheiter-Quote von 60-70% die Rede ist und immer wieder dieselben „Scheiter-Punkte“ aufgeführt werden:  

• Das Ziel ist nicht klar – nicht gut kommuniziert
• Der Projektauftrag ist unklar - nicht gut geklärt – dazu immer wieder Debatten
• Pläne sind unrealistisch: Termine werden nicht gehalten - sind „von oben“ vorgegeben - haben mit dem Projektverlauf wenig zu tun (sind oft anders begründet),  Aufwände werden nicht gegen Schätzungen gerechnet – Rückmelde-Systeme fehlerhaft (Ampel ist schon lange auf gelb, obwohl sie auf rot stehen müsste)
• Projektrisiken werden allenfalls zu Beginn formuliert – spielen aber im weiteren Projektablauf häufig keine Rolle; VUCA wird unterschätzt bzw. konzeptionell kaum mitgedacht  (Umgang mit Komplexität, Unsicherheiten usw. - Handlungsanleitungen dazu werden kaum angewendet)
• Projektpersonal1: Die Zuordnung der Linien-Mitarbeiter ist formal klar - informell wird aber multitasking – selbst im agilen Projekt – praktiziert; 
• Projektpersonal2: Fluktuation in Projekten oft hoch - Probleme gleichwertigen Ersatz zu bekommen; Karriere noch möglich?
• Die Stakeholder sind zwar bekannt, aber es wurde versäumt, eine passende Kommunikationsorganisation aufzusetzen und gerade in schwierigen Zeiten zu nutzen
• …

Das dramatische an diesen Studienergebnissen ist, dass sie häufig immer wieder dieselben „Scheiter-Punkte“ festhalten, ohne – wie es in einer „Studie“ angemessen wäre – sauber „in die Tiefe“ zu recherchieren: vielfach genannt werden „Scheiter-Punkte“ wie „kein ausreichendes Budget“ oder „nicht genügend Zeit“ oder auch „unklare“ bzw. „unpräzise Ziele“; das sind für uns keine „Scheiter-Punkte“ ,weil es sich meist um Rahmenbedingungen handelt, die im vorhinein klar sind und die man natürlich – wenn man erfahren genug und konfliktbereit ist – zur Debatte im Gespräch mit dem Auftraggeber stellen kann. Selbst wenn der Rahmen zu wenig Budget vorsieht, hat man die Möglichkeit, ein entsprechendes Risiko-Szenario für alle Beteiligten sichtbar festzuhalten und alle Parteien daran zu orientieren.Ein weiterer immer wiederkehrender „Scheiter-Punkt“ sind die „unklaren“ oder „unpräzisen Ziele“; wenn Projekte – was ja ihre Definition ist – die Organisationsform gerade für unklare, neue, nicht exakt planbare Vorhaben ist, dann mutet dieser „Scheiter-Punkt“ etwas bizarr an und muss wohl uminterpretiert werden: dieser Punkt deutet u.E. eher auf die Unfähigkeit, die Vorgehensweise an den volatilen Gegenstand anzupassen – und könnte als Versuch gedeutet werden, eine „Schuldverschiebung nach oben“ vorzunehmen.

Silicon Valley Europe: Welche Hauptursachen sehen Sie für das Scheitern von IT- und Digitalisierungsprojekten? Gibt es bestimmte Muster, die Ihnen dabei immer wieder begegnen?

Dr. Klaus Wagenhals: 

Ich habe in der Beantwortung Ihrer letzten Frage schon ein paar Andeutungen gemacht, welche Hauptursachen wir dafür sehen, warum IT-/Digitalisierungs-Projekte viel zu häufig nicht gut gelingen:Ein Zielbild für das Projekt, das einerseits nicht ausreichend mit den Betroffenen/ dem Kunden und dem Projekt-Team (ggf inkl. der „dahinter-stehenden Fachabteilungen) entwickelt/ diskutiert ist und das andererseits nicht flexibel genug – angepasst an die offene, ggf nicht klar definierbare Zukunft des Projektgegenstands und des von A nach B laufenden Entwicklungsprozesses (s. dazu das Ceynfin-Modells) – im Laufe des Projekts mitentwickelt wird. 

Damit einher geht ein oft unsauber definierter Projektauftrag: vielfach begibt man sich nicht tief genug „in die Welt des Kunden“ – man bleibt aus Zeitgründen auf der Oberfläche, verzichtet auf eine genauere Definition dessen, was der Kunde von dem jeweiligen IT-System oder dem  nächsten Digitalisierungs-Schritt für sich an Vorteile, an Entwicklungsschritte (bezogen auf welches Ziel?) erwartet und wer ihn bei dieser Sicht begleitet und wer dazu eine andere Sicht hat (damit hätte man z.B. die Gelegenheit, die verschiedenen Interessenlagen herauszuarbeiten im Sinne einer sauberen Stakeholder-Analyse und diese Sichten mit bezug auf ein gemeinsames Ziel abzugleichen)

Ein Planungs-Paradigma, das noch dem klassischen Modell des PM (lineares Durchdenken eines logisch entwickelten Prozesses mit Meilensteinen, usw.) verhaftet ist und mit hoher Wahrscheinlichkeit in einer VUCA-Welt scheitern wird; völlig unberührt von diesen überall nachlesbaren Überlegungen, scheint dieses Paradigma so mächtig, dass selbst renommierte PM-Berater in Reaktion auf die oben zitierten Studien reflexartig immer wieder dieselben Standards des PM „runterbeten“ – was nicht zu einer Beseitigung des (schädlichen) Handlungsmusters, sondern zu seiner ständigen Wiederholung führt. Außerdem ist damit häufig auch eine Planungs-Illusion verbunden: obwohl es zu Beginn eines Projekts häufig „kritische Stimmen bzgl. Erreichbarkeit von Zielen, Aufwänden usw. gibt“ werden diese ignoriert, weil man das Projekt will/ durchführen muss.

Das Nicht-ernst-nehmen der Bedeutung von Risiko- und Stakeholder-Analyse: es ist in den großen Digitalisierungs-Projekten u.E. häufig nicht verstanden, was eine gute Stakeholder-Analyse und der damit verbundene, im Projekt immer wiederkehrende Kommunikations- und Feedback-Rhythmus zum Gelingen eines Projekts beitragen kann  (hier geht es um kluge Beziehungspflege und nutzung quer durchs Unternehmen und Richtung Kunde und Zulieferer – hier scheitern viele an überholten Instrumenten und wiederum am mangelnden Komplexitäts-Denken)

Die mit den oberen Punkten verbundenen Anforderungen an die Projektleitung bzw. diejenigen, die ein Projekt planen bzw. neu aufsetzen, bewegen sich dann gleichzeitig auf zwei weiteren Ebenen: 

• auf der Ebene der Rahmenbedingungen: wenn man über „mangelndes Budget“ oder „mangelnde Zeit“ philosophiert, hilft es zu fragen „warum gibt man einem wichtigen Digitalisierungs-Projekt zu wenig Budget?“ „Gegen welche anderen Projekte/ andere Projekt steht dieses Projekt?“ oder bzgl. Zeit: „welche Klärung der jeweiligen Bedürfnisse der Beschäftigten und welche Beteiligung an der Neu-Entwicklung der Prozesse bzw. der Implementierung eines neuen Systems habe ich eingeplant?“ – die Antworten verweisen dann vielleicht auf ein mangelhaftes Portfolio-Management oder auf Führungspersonen, die sich nicht entscheiden können oder eben – wie oben bereits angesprochen – auf ein verkürztes Change-Konzept…
• auf der Ebene der Schaffung und des Umgangs mit diesen Rahmenbedingungen: wenn hier die Bereitschaft und der Wille, sich für akzeptable Rahmenbedingungen für das Gelingen eines wichtigen Projekts nicht vorhanden sind oder keine Verhaltensvarianten zur fruchtbaren Auseinandersetzung über diese Rahmenbedingungen liegen die Scheiter-Gründe eher darin, sich zu überlegen, welche Anforderungen an eine Rolle und das eigene Verhaltens-Repertoire (also die Persönlichkeit) gestellt werden

Es fehlt an Mut zur „Wahrheit“: „Wer sagt's dem Chef?“ oder „Alle wissen, dass wir die Kapazität nicht haben – dennoch werden die Projekte genehmigt“. (das ist eigentlich „Planungs-betrug“); häufig verbunden mit einer „Illusions-Kultur“ und der Nährung der Hoffnung, gerade mit Hilfe von „BigData“ endlich alle wichtigen Daten zu bekommen, mit denen eine bessere Planung und Zielerreichung erreichbar scheinen.

Silicon Valley Europe: Laut Studien sind unrealistische Erwartungen und Zeitpläne häufige Problemquellen. Wie sollten Unternehmen bei der Projektplanung realistischer vorgehen?

Dr. Klaus Wagenhals: 

Zum einen empfehlen wir, sich klar zu machen, was man mit welchem IT-/Digitalisierungs-Projekt erreichen will – zum Nutzen der Kunden und zum Nutzen der Firma und der Beschäftigten. Hierfür sammelt man am besten alle an dieses Projekt geknüpften Erwartungen von den verschiedenen Playern und macht mit Technikern, Prozess-Spezialisten, Kompetenz-Portfolio/HR-Spezialisten sowie Projekt-Portfolio-Experten einen Gegencheck mit Abgrenzung zu laufenden oder weiteren geplanten Projekten. In diesem Zusammenhang ist die Priorität dieses Projekts im Verhältnis zu den anderen zu klären  (das kann natürlich nur eine Augenblicks-Bestimmung sein, weil das ganze Portfolio ja in heutiger Zeit flexibel angelegt sein sollte).

Zum anderen empfehlen wir, – angelehnt an agile Change-Konzepte – eine Vorgehensweise zu designen, mit der schnelles und iteratives Vorgehen unter Einbeziehung der Betroffenen, ggf der Externen in Kombination mit ebenso schnellen Feedback-Schleifen möglich ist. Dieses Vorgehen sollte in Form einer Roadmap transparent für alle Beteiligten öffentlich sichtbar gemacht und von Zeit zu Zeit kritisch gecheckt und ggf. korrigiert werden. Wenn man auf diese Weise vorgeht, berührt man (wie vorhin deutlich gemacht) mindestens 2-3 weitere Dimensionen, die das System charakterisieren: a) die Kultur: Einbeziehung der Betroffenen und Transparenz des Vorgehens sowie der Entwicklungs-Stationen setzt das Interesse derselben voraus und deren gute Information, aber auch Vertrauen und die Bereitschaft, deren Vorschläge ernst zu nehmen und mit zu verarbeiten. b) die Führung: Führung wandelt sich vom Vorgeber, Überwacher und der Übernahme anderer klassischer Rollen zum Ermöglicher, zum Ideen-Sammler, zum Koordinierer, zum methodischen Unterstützer, zum Überblick-geber, zum Change-Gestalter u.ä. moderner Rollen.

Silicon Valley Europe: Welche Rolle spielt Ihrer Meinung nach die Projektkultur, z. B. mangelnde Kommunikation oder unklare Verantwortlichkeiten, beim Scheitern von Projekten?

Dr. Klaus Wagenhals: 

Wie oben bereits angedeutet, sehen wir die Projektkultur als sehr bedeutend an: nicht nur, dass – wie oben empfohlen – ein iteratives Vorgehen mit mehr Vertrauen in den Prozess und in die Menschen, die ihre Ideen und Vorstellungen und natürlich auch ihre Bedenken dort einbringen, verbunden ist; es ist auch abhängig von Offenheit gegenüber diesen Ideen und Vorstellungen und von deren Einbau in die Neu-Entwicklung und von der Möglichkeit ungestraft Fehler zu machen – allerdings verbunden mit der Möglichkeit und Bereitschaft zu lernen. Dies sind ebenso Kulturaspekte, wie die Klärung der Rollen im Projekt und im Auftraggeber-System (womit auch die Klärung der Verantwortung verbunden ist) und der Umgang untereinander (was wiederum mit bestimmten Werten verknüpft ist/ sein sollte und mit der Frage, wie die gegenseitige Beeinflussung durch Kommunikation und Tat gestaltet ist). 

Insofern muss es bei der Arbeit am Gelingen von Projekten darum gehen, die Werte, die eine selbstbewusste, eigenverantwortliche, ergebnisorientierte, konstruktive Zusammenarbeit ermöglichen, zusammen zu entwickeln und ein Auge darauf zu haben, dass diese – auch in Krisenzeiten – berücksichtigt werden. Weiterhin sollte daran gearbeitet werden, Transparenz zum Auftrag, zu den Zielen, zum Stand des Projekts und seiner Teile, zum gegenseitigen Austausch im Team, aber auch zu den Stakeholdern bis hin zu den nötigen Informationen, um seine Aufgaben erfüllen zu können, herzustellen. Und dafür zu sorgen, dass Fehler ebenso wie neue Ideen eingebracht und passend zum Projekt-Fortschritt bearbeitet und verwertet werden und so Lernen stattfindet. 

Silicon Valley Europe: Sie betonen die Bedeutung agiler und iterativer Ansätze. Wie helfen diese konkret, Projekte resilienter zu machen?

Dr. Klaus Wagenhals: 

Das agile Vorgehen hat den Vorteil, dass in offenen, unklaren und schlecht planbaren Situationen Schritte gegangen werden können ohne alles bis zum Ende durchplanen zu müssen (Zeitersparnis und höhere Flexibilität, weil der Plan ständig verbessert, verfeinert, aber auch verändert, einer neuen Erkenntnis angepasst werden kann). Es beinhaltet eine schnelle, flexible Change-Architektur der Roadmap, die je nach Anforderungen im Fortgang des Prozesses angepasst / verändert werden kann.

Die Iteration – also die schrittweise Erarbeitung z.B. eines neuen Ablaufs oder eines neuen Konzepts – ermöglicht die ständige Einarbeitung neuer Ideen oder Erkenntnisse während des laufenden Prozesses; es braucht keine Change-Requests, keine langwierigen Genehmigungsverfahren usw. In der Iteration bietet sich an, möglichst viele oder die wichtigen Vertreter in einem bestimmten Arbeitsbereich in die Erprobungen der Veränderungen einzubeziehen (z.B. bei Verlagerung der Dokumente in die Cloud oder bei neuen Abrechnungssystemen) und mit ihnen nach einem festgelegten Rhythmus auszuwerten (z.B. mittels einer Evaluations-Schleife).

Dies alles – aber natürlich auch noch andere Punkte - verhindert nach unserer Erfahrung, dass Projekte mit komplexem Gegenstand ins Schleudern geraten. 

Silicon Valley Europe: Welche modernen Tools oder Methoden empfehlen Sie für die effektive Stakeholder-Analyse und Risikobewältigung in IT-Projekten?

Dr. Klaus Wagenhals: 

Stakeholder-Analyse braucht notwendigerweise ein systemisches Bild vom Projekt und der Organisation, in dessen Rahmen es durchgeführt wird/ werden soll. Anhand dieses Bildes wird im Kick-off festgestellt, wer die maßgeblichen Stakeholder (also beeinflussenden Personen/ Teil-Systeme/ Fremd-Systeme) sind und welches Verhältnis sie zu dem Projektgegenstand, zum Projekt-Team und seinen Auftraggebern haben. Das malt man in das bild rein und kennzeichnet dieses Verhältnis mit weit weg= schlechtes Verhältnis/ nahe=gutes Verhältnis, durchgezogene Linie=bestehende/ gute Kommunikation, gestrichelte Linie oder nur mit Anfang und Ende angedeutete Linie=unklare oder gar keine Kommunikation. Daraus wird abgeleitet zu wem überhaupt eine Beziehung aufgebaut werden muss und von wem (vielleicht können hier auch alte Bezüge helfen) und mit welchem Ziel (was kann herausgefunden werden/ was sollte an Information transportiert werden?). Dies wird auf einem Kanban-Board als extra spalte fixiert oder – etwas vorsichtiger – in einer internen Datei  wie z.B. Jira o.ä. festgehalten und während des gesamten Projekts immer wieder reviewt und ergänzt / verändert / aktualisiert.

Wenn es darum geht, eine kundenspezifische Denkweise zu lernen, dann hilft die Methode „Personas bestimmen“ (man versetzt sich in den „idealtypischen Kunden“ und bestimmt seine „Welt“ (also welche Lebensweise er hat/ welche Konsumgewohnheiten / welche Probleme usw.- ein anderes nutzbares tool ist die „affinity map“), um darauf bezogene Produkte/ Dienstleistungen entwickeln zu können (z.B. mit Hilfe von design-thinking).

Risikoanalyse funktioniert von der Grundlage her ähnlich: ausgehend von dem System-Bild wird auf den 5 Ebenen „Projekt-Team“, „Projekt in unserer Organisation (damit ist seine Einbindung in die herrschenden Prozesse und Strukturen inkl. Technikanwendung gemeint)“, „Projekt und Führung/Kultur (inkl. Information)“ sowie „Projekt und Kunde/ Markt“ und „Projekt und Zulieferer“ im Projekt-Team intern unter Einbeziehung wichtiger Stakeholder herausgearbeitet, woran das Projekt scheitern kann. Dann wird unterschieden in solche Risiken, die das Projekt-Team selbst minimieren oder sogar beseitigen kann und in solche, die vom Team nur bedingt beeinflussbar sind; für die erstere Risiko-Gruppe werden quasi-nebenher Rollen und Aktivitäten bestimmt für deren Beseitigung/ Minimierung bzw. deren „unter Kontrolle halten“; für letztere werden Team-Mitglieder bestimmt, die gezielte Maßnahmen z.B. mit „Macht-Playern“ entwickeln sollen, um die dort platzierten Risiken zu minimieren/ zu beseitigen bzw. im Griff zu behalten. Dieser Tagesordnungspunkt wird regelmäßig im Team-Meeting gecheckt oder dann aufgerufen – selbstorganisiert – wenn jemand aus dem Team den Eindruck hat, es müsse eingegriffen werden. Natürlich gibt es bei den unbeeinflussbaren Risiken auch welche, die sich dramatisch auswirken wie z.B. ein gravierender Umsatzrückgang, was ggf die Gefährdung des Projekts bedeutet; dann scheint es angemessen, im Kreis der wichtigsten Stakeholder des Projekts abzuwägen, wie wahrscheinlich das Eintreten dieses Risikos ist und wie man die negativsten Folgen bei Eintritt möglichst wirkungsvoll abfedern kann.

Silicon Valley Europe: Sie sprechen oft von der Bedeutung einer gemeinsamen Vision. Wie sollte diese im Projektalltag entwickelt und kommuniziert werden?

Dr. Klaus Wagenhals: 

Unsere Erfahrung ist, dass es Projekte, die relativ schnell zu Beginn – z.B. im Rahmen des Kick-off zusammen mit dem Kunden – eine gemeinsame Vorstellung zur Zukunft der Situation, die vom Projekt hergestellt werden soll (z.B. papierloses Büro), möglichst farbig und nachvollziehbar beschrieben haben, erfolgreicher waren als andere. 

Ich würde hier empfehlen, sich im Rahmen einer Klausur zusammenzusetzen und – ggf unterstützt von einem externen Moderator – Phantasien zu entwickeln, wie die Zukunft z.B. bzgl. papierloses Büro aussehen kann; hilfreich wird es dazu sein, sich vorher ein paar Leit-Fragen zu entwickeln wie z.b. wie laufen die Prozesse jetzt z.b. per I-phone ab?, wo liegen die Dokumente? In welcher Form? Wie werden neue Leute „eingelernt“? Was passiert, wenn etwas verloren scheint? Usw. Hilfreich könnte dazu auch ein passender Film-Clip sein oder die Vorgehensweise, wie sie Maja Storch beim Erarbeiten Ihrer Motto-Ziele in Ihrem Buch „Selbstmanagement“ dargestellt hat. Natürlich ist es günstig, den Auftraggeber bzw. die „Chefs" des Projekts mit einzubeziehen und dafür zu sorgen, dass die Vision in anschaulicher Form (also z.B. per Grafik oder per Videoclip) und als machbar über alle betroffenen Ebenen in der jeweiligen Organisation hinweg verbreitet wird – ggf. mit Rückmelde-Möglichkeit dazu (z.B.: wurde etwas vergessen).

Silicon Valley Europe: Welche Führungsansätze halten Sie für besonders geeignet, um IT-Projekte in die richtige Richtung zu lenken?

Dr. Klaus Wagenhals: 

Man sollte hier mehrere Dinge unterscheiden: zum einen geht es in einem modernen Projekt – ob zur Digitalisierung, zum Change oder was auch immer – natürlich darum, den Raum aufzumachen für eine tolle, ergebnis-orientierte Zusammenarbeit, für das Erreichen von Ergebnissen, für das Einbringen von Ideen, für die konstruktive Bearbeitung von Problemen und Konflikten, für die eigene Weiterentwicklung. Zum anderen geht es auch darum, dem Team den Rücken zu stärken, die Bedingungen so zu gestalten – ggf in der Auseinandersetzung mit den „Chef-Chefs“ – dass obiges möglich ist, die Außenvertretung des Projekts wahrzunehmen, die Verbindung zum Kunden und zu den internen Stakeholdern, aber auch zu den Zulieferern zu halten und die Zusammenarbeit werte-orientiert zu gestalten. Ob diese Rollen und Aufgaben von einer Person/ Funktion – nämlich dem klassischen Projektleiter, oder wie im agilen Projekt-Zusammenhang von geteilten Funktionen wie dem ScrumMaster, dem ProductOwner usw. wahrgenommen werden – sollte Projekt-spezifisch entschieden werden (passend zur Kultur): shared leadership braucht eine entwickelte Zusammenarbeits-Kultur und ein gelebtes Wertegerüst sowie Rollenklarheit. 

Zum dritten geht es darum, Führung gerade im Zusammenhang mit zunehmender Digitalisierung und weiteren Change-/Transformations-Prozessen neu zu denken: es muss u.E. darum gehen, Führung losgelöst von Positionen oder Stellen als Möglichkeit von jedem andere Menschen z.B. in einem team-Zusammenhang zielgerichtet zu beeinflussen mit Wort und Tat. Also wird Führung – angebunden an Rollen – flexibler praktiziert werden müssen und braucht daher ein grundsätzliches Verständnis darüber, welche Rollen in einem Projekt möglichst exzellent gespielt werden müssen, damit es ein Erfolg wird/ werden kann. Damit verbunden muss geklärt sein, wer welche Kompetenzen und welches Potenzial einbringt, um dies zu gewährleisten – was es also an Weiterbildung, an Lernen usw. braucht, um die bestehenden oder geplanten Herausforderungen sehr gut bewältigen zu können. 

Vieles von diesen Überlegungen ist im Konzept der transformationalen Führung, wie er mittlerweile in vielerlei Publikationen positiv erwähnt wird (vgl. z.B. von Au,(hrsg) 2016) enthalten; wir empfehlen als Ergänzung noch den Ansatz von Blanchard/Hersey (2007) zu nutzen, weil er konkreter auf die situations- und persönlichkeits-angemessene Form des Führens eingeht (allerdings muss dieser Ansatz modernisiert und mit dem Empowerment-Ansatz von Pearce (2003) zusammengebracht werden. Darauf aufbauend hat Schermuly (2021) u.a. nachgewiesen, wie Führungshandeln – gezielt auf verschiedene Dimensionen wie Selbstwirksamkeit, Selbstorganisation usw. bezogen - den in uns allen steckenden Selbstorganisations-Impuls, der mehr und mehr gebraucht wird, anregen kann. Wenn die Teammitglieder, eine orientierende Vision haben, einen Sinn in Ihrem Projekt sehen und genügend Anregungen, sich selbst mit ihren Kompetenzen und Potenzialen einzubringen im Interesse der Verfolgung von Vision und Zielen und wenn sie wahr- und ernstgenommen werden als Sensoren für Change-Notwendigkeiten und als Ideengeber für die Verbesserung von Prozessen/ Strukturen usw. im Interesse einer besseren Marktanpassung, dann ist schon sehr viel getan, um die „Fallen“ im Projekt zu vermeiden und zum Gelingen des Projekts jenseits der Abteilungs-Egoismen und Methoden-Debatten beizutragen.  

Silicon Valley Europe: Was wäre Ihrer Meinung nach der erste Schritt, den Unternehmen unternehmen sollten, um die Erfolgschancen ihrer IT-Projekte zu erhöhen?

Dr. Klaus Wagenhals: 

Ein unverzichtbarer Schritt für den Beginn eines IT-/Digitalisierungs- oder auch Change-Projektes ist die Klärung dessen, was man unter den benutzten Begriffen (also z.B. Digitalisierung) versteht, um welche Verbesserung es wo im Unternehmen geht/ gehen soll zu wessen Gunsten (also Kunde, Mitarbeiterzufriedenheit, Gesetzesvorgaben usw.) und welche Erwartungen daran von wem geknüpft werden/ sind. Dieser Punkt muss u.E. eng verknüpft sein mit einer sauberen Auftragsklärung, die auf der Basis des folgenden Konzepts erfolgt: es handelt sich um ein dynamisches, sich schnell veränderndes System mit hoher Komplexität, für dessen Handeln man multifaktoriell erkennen und handeln muss.  Daran kann dann die Präzisierung der Vision, der abgeleiteten Ziele, der Rollenklärungen usw. angekoppelt werden – jeweils mit Abstimmung der wichtigsten Stakeholder. Aus dieser Phase sollte sowohl eine immer mal wieder zu präzisierende Klärungsschleife für den Auftrag/ die Ziele, als auch für die in einem ersten Wurf entwickelte Roadmap herauskommen.

Silicon Valley Europe: Gibt es aktuelle Trends im Projektmanagement oder Change-Management, die Sie besonders spannend finden und die das Scheitern von Projekten künftig reduzieren könnten?

Dr. Klaus Wagenhals: 

Wir halten drei Trends für wesentlich:

• die Fortführung des agilen Ansatzes, seine weitere Verfeinerung usw. – allerdings finden wir den ständigen Druck auf die Modelle in Richtung Standardisierung und die sog. „Skalierung“ für gefährlich – da müssten sich die Protagonisten klar darüber werden, dass mit Standardisierung immer auch die Gefahr der Vereinheitlichung verbunden ist und mit der sog. „Skalierung“ die einfache Fortschreibung „noch größer“, was dem gleichzeitigen Trend der Individualisierung der Angebote entgegensteht – wahrscheinlich ein immerwährender Widerspruch
• die zunehmende Konzentration weg vom Einzelprojekt (dessen Existenz durch moderne Produktentwicklungs-Prozesse in Frage gestellt wird) hin zu einem gut ausgewogenen Projekt-Portfolio, was aber aufgrund der häufig zu findenden Verleugnung der unterschiedlichen Interessen nur in Ansätzen wirklich erfolgreich ist/ sein kann und hin zur Integration von gesellschaftlichen Transformations-Prozessen (vgl. z.B. pmaktuell, Nr.1/22)
• BeraterInnen wie z.B. Pfläging oder Väth, die deutlich machen, wo die Grenzen der standardisierten Modelle für die Durchführung von tollen, erfolgreichen Change-Projekten bzw. Prozessen liegen und wie wichtig das Besinnen auf einfache Zusammenhänge und die Herausarbeitung und Nutzung reflexions-anregender und weiterführender Fragen ist (wie wir das in unserem Change-Ansatz ebenfalls herausgearbeitet haben – s.dazu unseren Beitrag in Workbook Change Management, 2.Auflage, 2022 oder auf unserer website im Schaufenster ChangeReload) und ForscherInnen wie z.B. Scharmer (2007), der das Konzept des Reload und des Sensing entwickelt hat, mit dessen Hilfe man über nicht-hilfreiche Denkansätze reflektieren und diese überwinden kann („in die Zukunft spüren“).

Silicon Valley Europe: Vielen Dank für diesen wertvollen Beitrag.