In Rolloutprojekten geht es darum, eine Lösung, ein Produkt oder einen Prozess auf einer breiten Basis einzuführen, sei es innerhalb eines Unternehmens, über verschiedene Standorte oder Regionen hinweg oder für eine größere Anwender:innnen-Basis. Rolloutprojekte zeichnen sich oft durch ihre Skalierung, den Zeitdruck, die Komplexität und die Koordination zwischen verschiedenen Teams und Stakeholdern aus. Diese Parameter sorgen dafür, dass Rollouts unter Projekten besonders häufig fehlschlagen. In diesem Beitrag werfen wir einen Blick auf zehn besonders wirksame Vorgehensweisen, um garantiert jedes Rolloutprojekt zum Scheitern zu bringen.
Auf Platz 1 der wirksamsten Methoden, um einen Rollout frühzeitig scheitern zu lassen, ist eine unzureichende Planung. Sie kennen es sicherlich: Für eine umfassende Planung ist keine Zeit, da das Management bereits ungeduldig auf Ergebnisse wartet. Am besten werden Führungskräfte für 2 - 3 Tage in einen War Room versammelt, um am Ende einen Plan aufzustellen, der bis zum Ende des Rollout-Projektes gültig ist. Da die Hochlaufkurve (linear ansteigend!) bereits im Folgemonat Ergebnisse vorsieht, muss auch ganz schnell mit der Umsetzung begonnen werden.
Am besten wird überhaupt keine Pilotphase eingeplant, da die theoretische Planung sollte doch ausreichen. Falls nun aber doch ein Pilot durchlaufen wird, sollten die Erkenntnisse möglichst ignoriert werden oder es dürfen zumindest keine Konsequenzen für die zuvor aufgestellte Termin-, Ablauf- sowie Ressourcenplanung daraus abgeleitet werden. Die unzureichend definierten und dokumentierten Prozesse unterstützen das nahende Chaos.
Es zeigt sich recht schnell, dass man dem aufgestellten Plan schon früh hinterherrennt. Da helfen auch kreative Fertigmeldungen und zusätzliche Abstufungen in den Meilensteinen nur zeitweise weiter. Hier hilft das Prinzip Hoffnung, dass in Zukunft schon alles schneller wird und wir die Plankurve erreichen, was der Hockey Stick im Forecast bis Ende des Quartals/Jahres/Projektes auch verdeutlicht. Ein neuer Forecast muss also her - Hauptsache am Ende des Quartals/Jahres/Projektes liegt der Forecast wieder auf dem ursprünglichen Plan. Nun benötigt der neue Plan noch einen treffenden Namen, dieser ist wahlweise Wiederherstellungsplan, Aufholplan, Rehabilitationsplan oder auch Recovery Plan.
Mit den ersten Planabweichungen ist der richtige Weg schon eingeschlagen, das Vertrauen in die Projektleitung schwindet. Jetzt könnten wir aber die Anzahl der Lenkungsausschüsse, Steuerungskreise oder Steering Commitees erhöhen, die mindestens einmal, gerne auch mehrmals pro Woche stattfinden sollten. Nur so wird sichergestellt, dass das Rollout-Team auch ausreichend mit Prüfaufträgen, Aktionspunkten und Gremienvor- und -nachbereitung ausgelastet ist. Dabei ist aus Auftraggeber-Sicht darauf zu achten, dass Entscheidungen möglichst oft herausgezögert werden und zusätzliche Ressourcen nicht zur Verfügung gestellt werden.
Um unter anderem in den Gremien auch immer neue Zahlen präsentieren zu können, muss der Reporting-Zyklus verkürzt werden. Einmal pro Woche ist dafür in der Regel nicht ausreichend. Damit einhergehend muss auch die Detailtiefe erhöht werden, so dass vor lauter Zahlen aus unsicheren und widersprüchlichen Quellen nichts mehr abgeleitet werden kann, um das Projekt sinnvoll zu steuern. Dann dauert es auch nicht mehr lange und die eine Excel-Datei, in der alles zusammenläuft, nimmt Kurs auf 100 MB und stürzt regelmäßig ab.
Rollouts haben die Eigenschaft, in vielen Iterationen dieselben oder zumindest ähnliche Aktivitäten umzusetzen. Für ein Scheitern des Projektes ist es nun wichtig, Fehler immer und immer wieder zu begehen. Dies funktioniert besonders gut, indem vermieden wird, aus Fehlern zu lernen. Auf regelmäßige Retrospektiven, wie sie in agilen Projekten zu finden sind, sollte also verzichtet werden. Wirklich Zeit hat dafür ohnehin niemand, zudem müssten sie auch noch gut vorbereitet werden.
Durch ein effektives Prozessmanagement können standardisierte Abläufe definiert werden, um sicherzustellen, dass die Implementierung konsistent und effizient erfolgt. Es bringt Struktur, erhöht die Kontrolle, hilft bei der Erreichung von Qualitätsstandards und sorgt für Skalierbarkeit. Dies steht einem Scheitern des Projektes allerdings im Weg. Gut, dass es in den meisten Fällen ohnehin vernachlässigt wird. Und wenn es schon dedizierte Prozessmanager:innen im Projekt gibt, dann werden entweder sie oder die dokumentierten Prozesse gekonnt ignoriert. Es gilt schließlich kurzfristige Brände zu löschen, Eskalationen einzufangen und die Zahlen hochzubringen. Um Prozesse kümmert man sich daher lieber später.
Viele Rollout-Projekte haben direkte Auswirkungen auf einen Teil der Mitarbeitenden im Unternehmen. Diese bringt man recht einfach gegen das Projekt auf, in dem eine frühzeitige Identifikation und Einbindung relevanter Stakeholder vermieden wird. Auswirkungen des Rollouts auf die Organisation und die Mitarbeitenden sind zu ignorieren - so steigen schon früh die Widerstände. Frühzeitige Schulungen und Unterstützungsangebote sollten daher vermieden werden. Und wenn schon Feedback von den Stakeholdern eingesammelt wird, so sollte dies zumindest konsequent unbeachtet verbleiben.
Kaum ein großes Rollout-Projekt wird ohne Unterstützung von Lieferanten umgesetzt. Egal, ob IT-Dienstleister, Technologieanbieter, Logistikunternehmen, Beratungsunternehmen oder Infrastrukturdienstleister - alle arbeiten stets zum Wohle des Projektes. Verträge können daher unkonkret gehalten werden, da auf die gelieferte Leistung in der gewünschten Qualität vertraut und auf Anreizsysteme verzichtet werden kann. Das reduziert auch die notwendige Kommunikation zwischen Unternehmen und Lieferanten und macht Rollen wie Lieferantensteuerungen oder Partnermanagement überflüssig.
Alle bisher aufgeführten Punkte zeigen nur einen Ausschnitt der Verantwortlichkeiten einer Projektleitung. Der beste Weg, das Projekt schon früh scheitern zu lassen, ist, all diese Themen auf den Schultern einer Person abzulegen. Ein Rollout-Management-Team, welches je nach Größe des Projektes diverse Rollen wie (regionale) Rollout-Manager, Prozessmanager, Projektoffice, Daten-/Businessanalysten, Changemanager oder Testmanager umfasst, stünde diesem Scheitern nur im Wege.
Erfahrene Projektmanager:innen dürfte keiner dieser zehn Punkte überrascht haben. Und doch erleben wir diese Fehler in der Praxis immer wieder. Besonders in stressigen Phasen fallen die verantwortlichen Personen, egal ob Auftraggeber:innen, Linienverantwortliche oder Projektmanager:innen in typische Verhaltensmuster und tappen in diese Fallen.
Mit dem Wissen darüber und der praktischen Erfahrung in unzähligen Projekten, sorgen wir gerne dafür, dass Ihr Rolloutprojekt nicht scheitert, sondern ein Erfolg für Unternehmen und Mitarbeitende wird. Wir freuen uns auf einen Austausch mit Ihnen!
