Scheitert die IT-Transformation ausgerechnet an der IT?

Allzu oft liest man in den Medien, dass erneut eine Großbank gescheitert ist, ein als Quanten­sprung kommuniziertes Trans­formations­projekt durchzuführen. Sei es, dass der Scope deutlich reduziert werden musste, die Laufzeit verlängert wurde oder die Kosten explodierten. Aber auch der Worst Case ist keine Seltenheit – in den letzten Jahren war mehrfach zu beobachten, dass Projekten gänzlich “der Stecker gezogen” worden ist.

von Golo Gröhnke, LPA Gruppe

Die Kunst der Transformation in der sich rasant entwickelnden Welt der IT flößt den Verantwortlichen Respekt ein. Es ist unbestritten, dass eine IT-Transformation in der Bankenwelt ein komplexer und herausfordernder Prozess ist, der durch regulatorische, aber auch kundenspezifische Anforderungen, technologische Veränderungen sowie Wettbewerbsdruck beeinflusst wird. Banken leiten – von diesen Faktoren beeinflusst – Initiativen ein, um ihre Geschäftsmodelle, Organisationsstrukturen und technologischen Plattformen zu transformieren.

Der Wandel des Projektmanagements vom klassischen Wasserfallmodel zu einer agilen Vorgehensweise ist dabei bei weitem kein Garant für Erfolg – ggf. begünstigt Agilität, falsch umgesetzt, sogar einen Misserfolg.

Während klassisches Projektmanagement den Umfang festlegt und Zeit und Aufwand variabel gestaltet, fixiert sich agiles Projektmanagement auf die Faktoren Zeit und Aufwand und gestaltet den Umfang variabel.”

Sicherlich liefern agile Werte und Ansätze wie z. B. Scrum oder Kanban interessante Impulse. Dennoch garantieren sie allein für sich noch kein erfolgreiches Projekt.

Die folgende Grafik verdeutlich die unterschiedlichen Spannungsfelder zwischen Plan-gesteuertem (klassisch) und Nutzen-gesteuertem (agil) Vorgehen.

Doch woran scheitern Projekte in der IT-Transformation konkret? Sind es unzulängliche Qualitätsstandards von Softwareherstellern und die daraus entstehende hohe Anzahl an Defects bei der Implementierung? Sind es veraltete Architekturen der Banken, die starr und inflexibel sind? Sind es zu komplexe Businessprozesse, die nicht so einfach an die Digitalisierung angepasst werden können? Die Liste an Gründen kann beliebig weitergeführt werden. Am Ende sind es dann doch die Methoden, die projektspezifisch angewendet werden müssen, um ein Projekt erfolgreich durchzuführen.
Aus diesem Grund lassen sich allen IT- Verantwortlichen in einem Projekt, seien es Projektleiter Abteilungsleiter, Verantwortungs-Aspiranten oder operativen IT-ler wertvolle Erfahrungen mitgeben, wie jeder Einzelne seinen Beitrag zum Erfolg optimieren kann.

Tipp 1: Klare Definition und Kommunikation des Projekt-Scope

Der Projekt-Scope ist die Grundlage für jegliche Projektplanung. Er definiert, was das Projekt leisten soll, welche Anforderungen es erfüllen muss und welche Grenzen es hat.

Eine klare Definition der Projektziele hilft, die Erwartungen aller Beteiligten zu managen, den Zeitplan einzuhalten und unnötige Diskussionen zu vermeiden.”

Daher sollte der Projekt-Scope zu Beginn des Projektes mit dem Auftraggeber/Sponsor geklärt und insbesondere schriftlich fixiert werden. Dazu gehört nicht zuletzt auch, was eben nicht im Scope inbegriffen sein soll. Die Projekt-Ziele müssen regelmäßig überprüft und bei Bedarf angepasst werden, um so auf erfolgsrelevante Veränderungen im Projektumfeld reagieren zu können. Jegliche Veränderung des Scopes, zusätzlicher Umfang genauso wie Reduzierung, muss dabei einen, im Vorfeld klar strukturierten, Change-Request-Prozess durchlaufen.

Doch selbst wenn der Scope vermeintlich klar definiert wurde, gibt es immer wieder Überraschungen, z.B. welche Infrastruktur genutzt wird oder woher bestimmte Daten tatsächlich bezogen werden.”

Wird bei der Infrastruktur beispielsweise auf moderne Cloud-Lösungen wie z. B. GCP, Azure oder AWS zurückgegriffen oder handelt es sich um reine Vor-Ort (On-Prem) Lösungen? Werden die Daten in unterschiedlichen Legacy-Systemen vorgehalten oder können sie vielleicht aus einem Data-Warehouse (DWH) bzw. Data Lake gefeeded werden?

Nur wer weiß, was zu tun ist, kann sagen, wann er fertig wird.“

Praxisbeispiele zeigen deutlich auf, dass es immer wieder zu Differenzen zwischen Abteilungen kommt, wenn es darum geht, Softwarelösungen für einen bestimmten Geschäftsbereich zu implementieren, wenn sie zum Beispiel einen erheblichen Einfluss auf eine Querschnittsfunktion wie z. B. Compliance haben. Oft wird das Zusammenspiel zwischen einer langjährig bestehenden Business-Lösung und Compliance aus der Vergangenheit akzeptiert. Getreu dem Motto „wurde bisher immer so gemacht“. Doch wenn sich die Business-Lösung ändert, meldet Compliance oft Mitspracherechte an „jetzt muss das Zusammenspiel geändert und zusätzliche Anforderungen eingehalten werden“. Der sich daraus ergebene Zielkonflikt zwischen dem Projekt (Einführung der neuen Software für den Geschäftsbereich), und Compliance (neue Anforderungen und angepasstes Zusammenspiel), kann mangels Kompromissbereitschaft dann durchaus bis auf höchste Ebenen eskaliert werden.

Genau hier ist es deshalb von essenzieller Wichtigkeit, dass zu Beginn des Projekts schriftlich fixiert wurde, was „in-scope“ und was „out-of-scope“ ist.”

Tipp 2: Fokussierung auf den Mehrwert und die Machbarkeit

Ein großes IT-Transformationsprojekt kann schnell zu einem komplexen und unübersichtlichen Unterfangen werden, wenn man stets versucht, alle Aspekte zu berücksichtigen und eine perfekte Lösung zu finden. Dies kann zu Verzögerungen, Kostensteigerungen und Qualitätsverlusten führen. Deshalb ist es essentiell, sich auf diejenigen Aufgaben zu fokussieren, die einerseits den größten Mehrwert zur Erreichung des Projektziels schaffen und andererseits realistisch umsetzbar sind. Dies wiederum bedeutet, Prioritäten zu setzen, Kompromisse zu machen und sich nicht zu sehr in Details zu verlieren.

Welche Aufgaben aber stiften den größten Mehrwert? Gerade bei Integrationsprojekten, ist es aufwändig zu definieren, welche Systeme Mehrwert-maximierend harmonisiert werden sollten. Eine deutlich differenzierte Sicht ist erforderlich, wenn man zum Beispiel Stammdatensysteme mit Produktsystemen vergleicht.

Stammdatensysteme beherbergen grundlegende, meist langlebige Daten, die sich nur selten ändern und von vielen unterschiedlichen, oft auch voneinander unabhängigen Geschäftsprozessen verwendet werden.”

Eine skalierte Kostenersparnis und eine höhere Datenqualität werden deshalb hier schnell erreicht. Produktsysteme hingegen werden für unterschiedliche Use Cases genutzt und weisen daher sehr spezifische, oft transaktionsbasierte Datenstrukturen auf. Von den Verantwortlichen ist die Kosten- und Nutzenanalyse deshalb akribisch und umfänglich vorzunehmen – sowohl hinsichtlich der technischen als auch der fachlichen Aspekte.

Bei Betrachtung besonders der technischen Aspekte wie Kosten für Wartung, Betrieb oder Lizenzen darf nicht vergessen werden, die Qualität und Quantität der im Unternehmen vorhandenen erforderlichen technischen Skills der Mitarbeitenden zu berücksichtigen.”

Gibt es z.B. für das jeweilige Vorhaben die notwendigen S. RPA-Kenntnisse für Workflow Automatisierungen.

Tipp 3: „divide et conquera“ – oder die Macht des Teamworks

Die Interpretation „Team – Toll ein anderer macht‘s“ wird immer belächelt. Aber genau darin kann die Stärke eines IT-Projektleiters liegen.

Es ist eine Kunst, richtig zu delegieren! Themen fachlich zu verstehen, ist unbedingt notwendig.”

Diese aber selbst operativ umzusetzen, ist allzu häufig absolut kontraproduktiv. Es kommt darauf an, dem Team die Umsetzung anzuvertrauen und nur als Kontrollinstanz zu fungieren. Anders formuliert: Wenn IT-Projektleiter jedes Detail kennen, wozu braucht es dann noch weitere Projektmitarbeiter wie z. B. Entwickler, Techniker, DBAs oder Analysten? In der Konsequenz heißt das aber auch, dass nicht nur die Aufgaben an sich zu delegieren sind, sondern auch die damit einhergehende Verantwortung einschließlich einer Rechenschaftspflicht. Diese muss aktiv von der aufnehmenden Partei angenommen und mit allen Konsequenzen verstanden werden.

Richtig kommunizieren, angemessen delegieren, Notwendiges kontrollieren.

In großen komplexen IT-Transformationsprojekten liegt die Gesamtverantwortung eines IT-Programm- bzw. IT-Projekts auf den Schultern des jeweiligen Programm- bzw. Projektleiters. Diese im Sinne eines erfolgreichen Programms/Projekts auf mehrere Schultern zu verteilen ist sinnvoll, hier greifen die Aufgaben und Verantwortlichkeiten von Teil-Projektleiter oder Team-Leads. Die jeweiligen Teams können sich beispielsweise auf bestimmte Themen wie z. B. Test & Testautomatisierung, Infrastruktur, Entwicklung oder Architektur etc. fokussieren. Mittels in festen Intervallen stattfindenden Jour-Fixe kann der holistische Gesamtblick des Programm-/Gesamtprojektleiters aufrechtgehalten und dem Projektsponsor Rede und Antwort gestanden werden.

Im Sinne einer transparenten Kommunikation ist anzumerken, dass die drei dargestellten Tipps lediglich ein Anfang sind. Es gibt noch viel mehr, was es zu von jedem IT-ler zu berücksichtigen gilt. Folgende Stichworte sollten Stoff zum Nachdenken geben:

Meeting-Kultur: Der olympische Gedanke „dabei sein ist alles“ trifft hier nicht zu
 Risikomanagement: Vor der Welle surft es sich deutlich leichter
 Fehler-Kultur: Man lernt weniger aus Erfolg als aus Misserfolg
 Kommunikation: Nur redenden Menschen kann geholfen werden
 Know-how: “don’t assume” – entweder man weiß es oder man muss es in Erfahrung bringen

IT-Transformation – das Fazit

Große Transformationsprojekte sind eine spannende und anspruchsvolle Aufgabe für jeden IT-Projektleiter. Mit diesen drei Tipps kann jeder IT-ler – unabhängig davon, wie im Projekt eingesetzt – die Erfolgschancen erhöhen und die Herausforderungen meistern. Nicht im technischen Detail liegt allzu oft das Risiko – vielmehr scheitern Transformationsprojekte an managementstrategischen Herausforderungen. Golo Gröhnke, LPA