Chane-Management und IT-Projekte gehören zusammen. Wenn IT-Projekte startet werden, wenn die dazu gehörenden Budgets freigegeben werden, wenn über mehrere Jahre geplant wird, manchmal mit internationaler Reichweite, dann denken umsichtige Projektmanager früher oder später an das begleitende Change-Management.

Mit Change-Management ist hier nicht der kontrollierte Umgang mit Änderungswünschen und neuen Anforderungen an das IT-System gemeint. Change-Management in diesem Artikel und auf dieser Website meint: Planung und Durchführung von Aktivitäten, die eine umfassende, bereichsübergreifende, inhaltlich weitreichende Fähigkeit zur Veränderung im Sinne der Strategieumsetzung in einer Organisation bewirken sollen.

Freiheit vs. Steuerung

IT-Systeme einzuführen ist nicht immer ein Spaziergang. Ob die Einführung von den Mitarbeitenden blockiert oder unterstützt wird, ob damit verbundene neue Prozesse funktionieren oder nicht, entscheidet sich nicht auf der technischen Ebene, sondern in den Köpfen der Beteiligten und in der Zusammenarbeit.

Wenn ich an die IT-Grossprojekte denke, die ich in den letzten 15 Jahren im Change-Management begleiten durfte, dann ist das Kernproblem: zentrale Steuerung vs. dezentrale Gestaltungsfreiheit. Dieser Grundkonflikt ist in den meisten Organisationen bewusst angelegt. Ihn produktiv aufzulösen ist Teil der Grundidee und der Funktionsweise jeder Form von Matrix.

Die Einführung oder der Wechsel von IT-Systemen ist ein Eingriff in die Selbstbestimmtheit von Kundengruppen oder internen Einheiten. Auch wenn der Systemwechsel sinnvoll ist und die Beteiligten dem im Prinzip zustimmen – die Migrationsphase ist meist eine Belastung für alle. Wenn die IT-Abteilung entscheidet, dass ein System ausgewechselt oder neu eingeführt wird, dann bedeutet das für die Nutzer, dass sie ein neues System erlernen, veränderte Prozesse befolgen, nach dem Go-live Fehler im System ertragen, insgesamt Zeit und Nerven für etwas einsetzen müssen, das eigentlich einfach nur da sein und funktionieren soll.

Rangeleien und Machtkämpfe

Das Ringen der betroffenen Nutzergruppen um Einflussnahme einerseits und der steuernden Projektorganisation um Durchsetzung ihrer Vorgehensweise andererseits ist vielfältig. Auf verschiedenen Ebenen wird gerangelt, politisch agiert oder operativ gestritten. In vielen einzelnen Fragen muss mühsam Einigung erreicht werden, weil der oben genannte Grundkonflikt noch nicht entschieden ist, eben der der zentralen Steuerung vs. dezentralen Gestaltungsfreiheit.

Letztlich werden IT-Wechsel aufgrund übergeordneter Gründe notwendig. Wenn im Zusammenhang mit IT-Projekten Veränderungen im Verhalten und in den Einstellungen erreicht werden, die ein Verstehen und eine Akzeptanz für strategisch notwendige Veränderungen ermöglichen, wird alles andere einfach und die Organisation beginnt, sich im Sinne der Strategie zu bewegen (siehe Grafik).

Dabei gilt, dass Veränderungen auf der Faktenebene viel schneller zu schaffen sind als Veränderungen auf der Ebene des Verhaltens und der Einstellungen. Systemwechsel geschehen nicht aus Selbstzweck. Solange auf der rein operativen, technischen Ebene gedacht und gearbeitet wird, bleibt alles ein kleinteiliges Ringen um den nächsten Schritt.

Standards vs. Individualität

Es geht meist umd Anforderungen aus verschiedenen Richtungen. Vielleicht soll ein System in verschiedenen Abteilungen eines Unternehmens eingesetzt werden. Oder es soll sogar in unterschiedlichen Ländergesellschaften verwendet werden.

Damit ist klar, dass Change-Management und IT-Projekte zusammengehören. Eine wesentliche Herausforderung besteht darin, die Anforderungen dezentraler Einheiten gegeneinander abzugleichen und einen Systemkern zu definieren, der für alle gelten soll. Der Vorgang der Standardisierung hat immer mit Wünschen und Verlusterfahrungen zu tun, mit Disziplin und Akzeptanz, mit dem Blick auf die eigenen Interessen und auf die gemeinsame Sache.

Change durch Veränderungsdynamik

Ob Standardisierung gelingt, hängt wesentlich davon ab, ob ein integrativer Weg beschritten wird, ob Betroffene zu Beteiligten gemacht werden, um hier einen altbekannten Grundsatz des Veränderungsmanagements zu nennen. Change-Management und IT-Projekte: Das bedeutet wesentlich, geeignete Formen der Zusammenarbeit zu definieren und einen produktiven Dialog der Beteiligten herzustellen.

Projekt vs. Linie

Projektmanager arbeiten quer zur Linie. Wenn’s gut läuft und sie ihr Team ebenso wie die Anwender des Systems erfolgreich mitnehmen, entfalten sie die Potenziale bereichsübergreifender Zusammenarbeit. Wenn’s mühsam ist, leiden sie an Gegenwind und daran, dass Linienvorgesetzte immer wieder am längeren Hebel sitzen, dass sie «overruled» werden von gegenläufigen Business-Prioritäten.

Es hilft alles nichts und auch die dezentralen Einheiten werden dem zustimmen: IT-Grossprojekte brauchen ein starkes, professionelles Projekt- oder Programm-Management mit einem gut funktionierenden PMO und einer Governance-Struktur, die dezentrale Anliegen systematisch einbindet und zugleich für verbindliche Entscheidungen sorgt.

Change-Management zu IT-Projekten muss sich daher auch mit Steuerungsstrukturen und Entscheidungsverhalten befassen. Das erfordert vor allem, dass an der Spitze, auf der Ebene der Projekt-Sponsoren im oberen Management, Einigkeit über Ziele und den Umgang mit gegenläufigen Prioritäten besteht. Ganz praktisch bedeutet dies, dass sich auch die Führungskräfte an der Spitze bewusst Veränderungsmanagement betreiben müssen. Ist dieses «Backing» nicht gegeben, strampeln sich Projektmanager ab, weil sie für etwas kämpfen, das an der Spitze nicht mit aller Konsequenz gewollt ist.

Unser vs. euer Zeitplan

Ob die Zusammenarbeit zwischen zentraler Steuerung und dezentralen, betroffenen Anwendergruppen glatt läuft, zeigt sich am deutlichsten am Einhalten oder Nicht-Einhalten von Zeitplänen. Oft gibt es ganz unterschiedliche Einschätzungen dazu, welche Deadlines realistisch sind. Ob Deadlines gehalten werden, entscheidet sich am Ressourcen- und Budgeteinsatz, der wiederum vom verbindlichen Umgang mit gesetzten Prioritäten abhängig ist, womit wir wieder beim Konflikt Projekt vs. Linie sind. Weil in den meisten IT-Projekten das Reporting ein zentrales Element der Zusammenarbeit ist, zieht sich der Streit um Zeitpläne oft durch. Mit jeder auf gelb oder rot gestellten Ampel wird darüber diskutiert, ob das Projektmanagement realistisch geplant hat und ob die dezentralen Projektressourcen ihrer Mitwirkungspflicht nachgekommen sind.

Es ist wie beim Monopoly-Spielen: Insbesondere die Diskussion über den Zeitplan, aber auch viele andere operative Fragen führen immer wieder auf den Grundkonflikt zurück und auf die Klarheit, mit der dieser Grundkonflikt adressiert wird: zentrale Steuerung vs. dezentrale Gestaltungsfreiheit. Das begleitende Change-Management zu IT-Grossprojekten ist zu einem guten Teil Konflikt-Management und das Verhandeln widersprüchlicher Erwartungen und Ansprüche.

Waschen und nass dabei werden

Am schwierigsten ist es, wenn vordergründig alle der Sinnhaftigkeit einer Systemeinführung zustimmen, gleichzeitig aber keine Zeit oder kein Verständnis dafür da ist, dass Einzelinteressen sich dem Gesamtgefüge des Projekts unterordnen müssen. Wasch mich aber mach mich nicht nass – es ist ja so verständlich und ganz im Sinne von Organisationen, die einerseits den Erfolg dezentraler Einheiten oder Kundengruppen wollen, andererseits Prinzipien durchgehender Steuerung fordern.

Change-Management und IT-Projekte: Das bedeutet wesentlich, Transparenz über unvermeidbare Konflikte herzustellen und Wege zum Aushandeln von Lösungen einzuschlagen. Zum Glück ist das in der Realität schlussendlich gut möglich, denn im Grunde ist ja allen Beteiligten klar, dass es am Ende nicht darum geht, wer die Sieger und wer die Verlierer sind, sondern wie man gemeinsam erfolgreich zum Ziel kommt.

Weiterführende Links in diesem Zusammenhang

Bildquelle: www.gograph.com