In dieser Artikelreihe werden wir uns mit Software-Rollouts auseinandersetzen und Wege aufzeigen, wie Worst-Case-Szenarien vermieden oder zumindest minimiert werden können. Wir werden die wichtigsten Bestandteile untersuchen, um einen erfolgreichen Rollout zu gewährleisten, welcher das Vertrauen der User stärkt und den Erfolg des Unternehmens sichert. Zum Auftakt gehen wir auf die Ausgangssituation ein. Weitere Beiträge drehen sich um Rolloutverfahren, Framework, Change Management und das Setup nach dem Rollout.
Stellen Sie sich vor, Sie arbeiten in einem Unternehmen, das einen wichtigen Software-Rollout geplant hat. Nach monatelanger Planung und Entwicklungsarbeit ist endlich der Start des langersehnten Rollouts gekommen. Doch der Tag, der mit Hoffnung und Vorfreude beginnen sollte, verwandelt sich in einen Alptraum. Die Vorstellung eines erfolgreichen Rollouts, bei dem die neue Software reibungslos in Betrieb genommen wird und den Arbeitsablauf optimiert, weicht einer bitteren Realität: Die User sind mit unerwarteten Problemen konfrontiert, die von Fehlfunktionen bis hin zu Datenverlust und Sicherheitslücken reichen. Der Service Desk ist überlastet, während die User aufgrund der neuen Funktionen überfordert sind und vom neuen System fast nichts wussten. Das Vertrauen in die IT schwindet und die Auswirkungen auf die Wettbewerbsfähigkeit des Unternehmens sind verheerend.
So oder so ähnlich haben Sie Software-Rollouts sicherlich schon kennengelernt. Viel Arbeit, viel Stress und am Ende kommt Murks raus. Und keiner ist zufrieden. Die User nicht. Die Stakeholder nicht. Das Projektmanagement nicht. Die Entwickler nicht.
Das klingt allerdings sehr vermeidbar, finden wir. Tauchen wir also ein in die düstere Welt des Alptraum-Rollouts und lernen wir, wie wir uns von diesem Szenario abwenden können, um einen erfolgreichen Software-Rollout zu ermöglichen. Vielleicht können wir aus dem obigen Szenario ja noch etwas lernen.
Weniger als 30% aller Rollout-Projekte werden als erfolgreich eingestuft. Diese Zahl geht aus dem Chaos Report der Standish Group aus dem Jahr 2021 hervor. Die Zahl ist erschreckend gering, wenn man bedenkt, wie teuer IT-Projekte sind oder werden können, wenn das Budget überschritten wird.
Wir haben uns überlegt, welche Ursachen zum Scheitern eines Software-Rollouts führen können. Die wesentlichsten Ursachen haben wir in fünf Punkten zusammengefasst:
So, nun haben wir einen Überblick über klassische Herausforderungen des Projekt- und Rolloutmanagements. Wir sehen also, dass das ganze Thema nicht ganz so einfach ist. Oft ist das Einbringen von externer Expertise ein wirksamer Hebel, um die beschrieben Herausforderungen zu meistern. Die Frage ist nun: Wie gehen wir vor?
Zwar ist das Scheitern eines Projektes eine eher subjektive Beobachtung (solange es sich nicht um einen Projektabbruch handelt), doch ist offenkundig, dass sich die Zufriedenheit mit Projektergebnissen in den meisten Fällen in Grenzen hält, wenn wir uns den Chaos Report der Standish Group ansehen.
Was können wir es also besser machen? In den nächsten Artikeln dieser Artikelreihe werden wir ein Framework zum Rollout Management vorstellen und vertiefend auf die wichtigsten Themen bei einem Software-Rollout eingehen.
Zunächst einmal ergibt es aber Sinn, sich mit der Ausganssituation auseinanderzusetzten und sich die Frage zu stellen, in welchem Umfeld ich mich eigentlich bewege. Dieses Verständnis ist für den Erfolg eines Rollouts elementar.
David Maister hat eine Kategorisierung nach Projektkomplexitäten vorgeschlagen, die inzwischen weite Verbreitung in der Literatur gefunden hat. Er unterscheidet zwischen Brain, Grey Hair und Procedure Projekten:
Wie hilft eine solche Kategorisierung weiter?
Indem Sie Ihr Projekt in eine dieser Kategorien einordnen, können Sie besser entscheiden, welche Art von Ressourcen (Fachwissen, Erfahrung, Kreativität usw.) für den erfolgreichen Rollout benötigt werden. Dies lässt sich auch ganz gut anhand der Stacey Matrix veranschauchlichen.
Je nach Komplexität, Innovationsgrad und Bekanntheit von Umfang und Vorgehensweise des Projekts können Sie gezielt die am besten benötigte Ressource und qualifizierten Teammitglieder auswählen. Je komplexer und unvohersehbarer ein Rollout in Umfang und Vorgehensweise ist, desto eher ist der Rollout als Brain Projekt einzuordnen. Ebenso können Sie ableiten, welche Art von externer Untersützung benötigt wird, beispielsweise durch eine Unternehmensberatung wie Cassini. Darüber hinaus hilft es Ihnen dabei, sich in die Projektanforderungen hineinzudenken und diese zu bestimmen.
Neben der Bestimmung der Art des Rollout-Projekts ist es auch entscheidend zu verstehen, welche Ziele mit dem Rollout erreicht werden sollen. Hier kann man allgemein zwischen vier Zieldimensionen in einem Rollout unterscheiden:
Wenn alle vier Ziele erfüllt sind, dann haben wir also einen guten Rollout. Klingt simpel, oder?
Ganz so einfach ist es in der Praxis leider nicht, denn die Ziele stehen teilweise im Widerspruch zueinander. Die IT-Kosten gering zu halten und gleichzeitig alle Anforderungen der User zur höchstmöglichen Qualität abzubilden, ist sehr herausfordernd. Hier müssen Kompromisse gefunden werden, um das bestmögliche Ergebnis für alle Zieldimensionen zu ermöglichen. Eine nachhaltig erfolgreiche Software erfüllt im Laufe ihres Einsatzes Ziele in jeder dieser vier Kategorien. Softwareprojekte, die jedoch zu viele Ziele dieser Kategorien gleichzeitig verfolgen, übersteigen häufig die Veränderungsfähigkeit des Unternehmens, sodass ein sehr hoher Aufwand, etwa für Schulungen, anfällt.
Wir halten fest: Rollouts gelingen dann, wenn die Ziele und die Stakeholder bekannt sind, sodass ein passender Ansatz dafür gewählt werden kann. Die Stolpersteine, die wir aufgezeigt haben, können durch das richtige Vorgehen umgangen und abgeschwächt werden. Dafür ist im ersten Schritt zu verstehen, in welchem Umfeld wir uns bewegen. Basierend auf diesen Erkenntnissen, ist ein Ansatz zu wählen, wie die Software ausgerollt, wer alles mit einbezogen werden muss und welche Ressourcen man braucht.
Im nächsten Beitrag unserer Reihe befassen wir uns damit, wie man sich für die richtige Art von Rollout entscheidet. Hierbei geht es insbesondere um die Herangehensweise: Big Bang oder iteratives Vorgehen?
