Software-Rollout (Teil 1) – Woran scheitern Rollouts und wie lässt sich das vermeiden?

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:

1. Keine User-Orientierung im Anforderungsmanagement & Scope Creep: Bereits vor dem Rollout selbst müssen User-Bedürfnisse angemessen adressiert werden. Vor diesem Hintergrund wird ebenfalls die Make-or-Buy-Frage geklärt. Projekt-Scoping wird in vielen Fällen zu sehr in Silos gedacht. Es müssen jedoch „verschiedene Brillen“ getragen werden, um User-Bedürfnisse treffend abzubilden. Insbesondere zum Start des Projektes ist daher ein Anforderungskatalog anzulegen, um eine Idee zu bekommen, in welche Richtung das Projekt laufen muss. Hierfür ist eine Product Roadmap essenziell. Änderungen sind grundsätzlich jederzeit möglich, jedoch sollte die Vision des Rollouts stabil und belastbar sein. Ohne die Möglichkeit, Anforderungen anzupassen, würde ein Produkt eingeführt werden, das womöglich niemand braucht. Daher sind Anforderungen konsequent auszuformulieren und von Ende zu Ende zu denken. Ist dies nicht der Fall, „kriechen“ immer mehr kurzfristige, aber fundamentale Änderungen in den Scope des Projektes (sogenannter Scope Creep), sodass schwergewichtige und kostspielige Änderungsprozesse eingeleitet werden müssen.
2. Kein Management Commitment: Führungskräfte übernehmen bei Veränderungsvorhaben eine zentrale Rolle. Sie werden hierbei auch als Change Agents bezeichnet und haben eine wichtige Vorbildfunktion für ihre Mitarbeitenden. Es muss klar sein, dass die Nutzung des neuen Systems ausdrücklich erwünscht ist – das ist durch die Führungsebene vorzugeben und vorzuleben. Ebenso ist eine frühzeitige, transparente und nachvollziehbare Kommunikation unabdingbar, die die Gründe und Ziele sowie das Vorgehen erklärt. Für Pilotprojekte ist es beispielsweise wichtig, dass die notwendigen Ressourcen bereitgestellt werden. Diese „Promoter“ müssen im Rahmen des Stakeholdermanagements identifiziert werden. Gleichzeitig wird ein Software-Rollout nicht ausschließlich auf Gegenliebe stoßen. Interessenskonflikte mit anderen Stakeholdern müssen vorab aufgedeckt und gemanagt werden, beispielsweise indem konkrete Mehrwerte aufgezeit werden. 
3. Fehlendes Change Management: Besonders häufig wird das Change Management vernachlässigt. Dabei ist insbesondere bei Software-Rollouts die Adaption der Nutzenden sehr wichtig. Schließlich sollen sie am Ende das System nutzen und durch dieses in ihrer täglichen Arbeit unterstützt werden. Hierfür sollte man sich (und den Usern!) stets die Frage stellen: „Was benötigen meine User, um das Produkt erfolgreich zu nutzen?“ Warum genau Change Management so wichtig ist, erklären wir ebenfalls in dieser Artikelreihe.
4. Unsaubere Methodik und fehlende Expertise: Insbesondere große Rollouts benötigen eine sorgfältige Planung und ein methodisch sauberes Vorgehen. Wenn alle Mitarbeitenden durch diese Veränderung betroffen sind, ist es kein alltäglicher Rollout, sondern bedarf entsprechender Expertise. Beispielsweise die Einführung von Microsoft 365 oder ein neues Warenwirtschaftssystems sind hierbei hochgradig komplex. Doch nicht nur das System selbst spielt hierbei eine wesentliche Rolle, sondern auch das Umfeld, in dem wir uns bewegen. Welche Abhängigkeiten existieren? Welche Interessensgruppen gibt es? Gibt es ähnliche Projekte, die in der Vergangenheit durchgeführt wurden und als Anhaltspunkt dienen können?
5. Ressourcenengpässe: Rollouts sind nicht die einzigen Projekte, die durchgeführt werden müssen. Projekte greifen weitestgehend auf denselben Ressourcenpool zu und können nur entsprechend einer Priorisierung durchgeführt werden. Gleichzeitig stehen sich in vielen Fällen Projektgeschäft und Tagesgeschäft gegenseitig im Weg, sodass eines davon gar zum Erliegen kommen kann. In diesem Fall empfiehlt sich der Einsatz externer Ressourcen, um das Projektgeschäft zu stemmen und in die Zukunft des Unternehmens zu investieren. 

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: 

• Brain Projekte: Die hier zu lösende Kundenaufgabe ist neu und von extremer Komplexität. Sie erfordert höchstes methodisch-fachliches Wissen und professionelle Fähigkeiten. Als Kernanforderungen solcher Projekte an die Mitarbeitenden werden Kreativität, Innovation und Pionierleistungen bei neuen Ansätzen, Konzepten und Techniken genannt. Hier sind vor allem überragende intellektuelle Fähigkeiten gefragt, um die zugrundeliegenden Herausforderungen zu meistern. 
• Grey Hair Projekte: Diese Projekte verlangen eine individuelle Lösung, sind jedoch in ihren Anforderungen an Kreativität und Innovativität geringer einzuschätzen als Brain Projekte. Die zu lösende Aufgabenstellung ist im Grundsatz bekannt und Lösungsansätze aus anderen Projekten können darauf übertragen werden. Hier ist auf nutzbare Erfahrungen und Vorwissen aus früheren Projekten (Stichwort: Lessons Learned) sowie das Urteilsvermögen vorhandender Mitarbeitenden zurückzugreifen.
• Procedure Projekte: Der hier zu bearbeitende Problemtyp ist gut bekannt und die einzelnen Lösungsschritte liegen weitgehend fest. Aufgaben können oft auch ohne Erfahrungen gelöst werden.

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?