Warum so viele Innovationsprojekte scheitern – und was man dagegen machen kann

Image placeholder
Jan Kristof Arndt 13 Juni 2019 – Lesedauer: 4:35 Minuten

Die Wahrscheinlichkeit, dass Ihr nächstes Innovationsprojekt scheitert, beläuft sich – abhängig von ein paar Stellschrauben – auf 75 bis 90 Prozent. So sagt es zumindest die Statistik. Das gilt vor allem für komplexe Unterfangen, also für solche, von denen Sie sich erhoffen, dass Sie spürbar positive Reaktionen am Markt erzeugen und Ihnen helfen, Ihre Wettbewerbsposition zu stärken.

Das klingt irgendwie … na ja, doof. Oder? „Da habe ich schon mal eine tolle Idee – eine, von der ich glaube, dass sie wirklich etwas verändern könnte. Und dann bekomme ich vom Markt doch nur wieder einen auf die Nase.“ Das gilt im Übrigen nicht nur für Sie und Ihr Business, sondern auch für alle anderen Unternehmen. Fragen Sie mal am Flughafen Berlin Brandenburg nach; die können ein Lied davon singen.

Weniger als 30 Prozent aller Innovationsvorhaben werden innerhalb der gesetzten Zeit- und Investitionsgrenzen umgesetzt. Die Flop-Wahrscheinlichkeit kapitalintensiver Projekte mit einem Budgetrahmen von mehr als 1 Million Euro ist 50 % höher als die kleinerer Unternehmungen mit einem kalkulierten Kostenaufwand von max. 350.000 Euro.

Dabei stellt sich die Erkenntnis, dass ein Projekt scheitern wird, nicht einfach über Nacht ein, sondern entwickelt sich oft über einen längeren Zeitraum. Man merkt, dass den eingesetzten Ressourcen nicht der erhoffte Wert gegenübersteht. Anstatt aber gegenzusteuern und den eingeschlagenen Weg zu korrigieren, werden Scheuklappen aufgesetzt - und weiter geht’s, schließlich hat sich bei der Planung irgendjemand irgendwann mal irgendwas gedacht.

Doch dann knallt’s.


Agilität als Antwort auf verstaubtes Prozessdenken

Kennen Sie diese Situation – wenn die Kosten das Budget übersteigen – wenn man sich in Aufgaben verrennt, ohne echten Wert zu schaffen – wenn man am Ende feststellen muss, dass es für die entwickelte Lösung kein entsprechendes Problem am Markt gibt? Falls ja, werden Sie sich die Frage gestellt haben, was Sie hätten anders machen können – an welcher Kreuzung im Projekt Sie nach links und nicht nach rechts hätten abbiegen sollen.

Antworten hierauf liefert die Software-Industrie.

Das Gute vorab: In der Regel liegt es nicht an Ihnen und auch nicht an Ihrer Idee, sondern am gewählten Prozess. Die meisten Projekte folgen in ihrer Umsetzung einer bestimmten Schrittfolge: Zuerst hat man einen Einfall. Man meint einen Ansatzpunkt gefunden zu haben, wie man etwas verbessern kann und überlegt sich, was erforderlich wäre, um aus dieser Überlegung Wirklichkeit werden zu lassen. Anschließend analysiert man den Markt, stellt eine Ressourcenplanung auf – und dann macht man sich auch schon an die Umsetzung. Am Ende – und damit nach mehreren Monaten, manchmal Jahren – testet man die bis dahin entwickelten Prototypen, entscheidet sich auf Basis der Ergebnisse für eine der zur Auswahl stehenden Varianten und stellt diese dann im Rahmen einer aufwändig produzierten Werbekampagne seiner Zielgruppe am Markt vor.

Das Projekt fließt von oben nach unten – von der Idee hin zur Lösung. In der sich mit diesem Thema auseinandersetzenden Literatur wird diese Art der Prozessgestaltung oft mit einem Wasserfall verglichen. Einmal angestoßen, nehmen die Dinge ihren Lauf. So lange noch Budget da ist, macht man weiter. Und weiter. Und weiter … Es geht darum, das Projekt zu Ende zu bringen. Wie das Ergebnis am Markt ankommt, ist schon fast zweitrangig. Sollte die Nutzerakzeptanz hinter den Erwartungen zurückliegen, kann man ja einen neuen Plan definieren, wie das entwickelte Produkt angepasst werden muss, um dieses Mal den ganz großen Wurf zu landen.

In der Software-Industrie verfolgt man hingegen inkrementelle, durch mehrere Iterationen geprägte Umsetzungsansätze. Zu den bekanntesten zählt „Scrum“, ein von Jeff Sutherland und Ken Schwaber definiertes Framework, das uns hilft, komplexe Probleme zu lösen und innovative Produkte zu entwickeln. Scrum basiert auf kurzen Umsetzungsintervallen – auch Sprints genannt – in denen Hypothesen aufgestellt und validiert werden, in denen man Lösungsmaßnahmen erzeugt, testet und aus den Ergebnissen Maßnahmen zur Verbesserung ableitet. Am Ende eines jeden Sprints stellen die Entwickler ein funktionierendes Teilprodukt vor, das so ausgereift ist, dass es grundsätzlich in Produktion gehen könnte. Die Entscheidung hierüber obliegt allerdings allein dem sog. Product Owner, also dem für das Produkt Verantwortlichen. Um hierhin zu kommen, werden alle aus dem klassischen Projektmanagement bekannten Phasen durchlaufen – nur eben schneller, und ausschließlich in Bezug auf das angestrebte Teilprodukt. Da jedes dieser Inkremente auf den Ergebnissen vorangegangener Sprints aufbaut, entsteht am Ende des Projektes ein funktionsfähiges, in diversen Rückkopplungsschleifen getestetes Produkt, bei dessen Integration / Vorstellung am Markt es zu keinen bösen Überraschungen kommen dürfte. Diese Art der agilen Umsetzung erlaubt einem intervallbasiert z.B. auf sich verändernde Kundenanforderungen oder neu aufkommende technologische Trends zu reagieren. So können Falscheinschätzungen schnell korrigiert und Risiken entlang des Wertschöpfungsprozesses wirksam gemanagt werden. Um sicherzustellen, dass Scrum richtig auf- und umgesetzt wird, unterstützt ein ausgebildeter Scrum Master als Prozessexperte den Produkt Owner und das Entwicklerteam. Wer sich nähergehend mit dem Thema auseinandersetzen möchte, sollte einen Blick auf die Leseempfehlungen von scrum.org werfen.


Vorteile einer agilen Projektorganisation im Vergleich zur klassischen Wasserfall-Logik

Es gibt gute Gründe, die gelernte Prozesslogik klassischer Projekte zu hinterfragen und sich agilen Umsetzungsmethoden zu öffnen. Hier eine verkürzte Übersicht:

Empirische Untersuchungen auf Basis fortlaufender Reaktionstests vs. Wage Annahmen am Anfang über zukünftige Nutzerreaktionen

Falls Sie in der Lage sein sollten, die Zukunft vorherzusehen – wunderbar: Dann brauchen Sie sich mit Scrum nicht weiter auseinanderzusetzen. Falls Ihre Kristallkugel aber nicht besser sein sollte als unsere, bleibt Ihnen nichts anderes übrig, als Hypothesen über mögliche Entwicklungen aufzustellen, Experimente durchzuführen, die Ergebnisse auszuwerten, Rückschlüsse zu ziehen und daraus zu lernen. In Wasserfall-Projekten durchläuft man diesen Prozess genau einmal – in agil organisierten hingegen diverse Male (entsprechend der Anzahl der zu durchlaufenden Sprints). Auf diese Art bieten sich zahlreiche Lern- und Anpassungsmöglichkeiten. Wir können direkt auf das Feedback unserer Kunden (und anderer für unser Projekt wichtiger Stakeholder) reagieren. Dadurch sinkt die Flop-Wahrscheinlichkeit unserer Innovationsanstrengungen radikal.

Iterative vs. Sequenzielle Umsetzung

Man kann sich agile Projekte wie einen Spaziergang vorstellen. Anstatt einer einmal definierten Richtung zu folgen, laufen wir immer ein paar Meter, schauen ob wir noch auf dem richtigen Weg sind, gehen diesen weiter oder schlagen einen anderen ein – immer abhängig davon, was das Ziel ist und wie es sich verändert. In Wasserfall-Projekten gibt es nur eine Richtung: Vorwärts! Das Ziel ist bekannt (zumindest meint man das), jetzt geht es nur noch darum es möglichst schnell zu erreichen. Agile Projekte sind weniger starr. Sie tragen der Dynamik heutiger Märkte Rechnung und erlauben uns, flexibel zu sein - und so relevant zu bleiben.

Value-fokussierte vs. Deadline-getriebene Projektumsetzung

In agilen Projekten steht immer der Wert im Mittelpunkt - vor allem der aus User-Sicht. Es geht darum, für seine Zielgruppe wichtige Probleme zu lösen – nicht darum, irgendwelche am Anfang formulierte Zeitvorgaben einzuhalten (als man eh noch keine Ahnung hatte, wie sich das Projekt entwickeln, welche Störereignisse auftreten und den Prozess verlangsamen würden). Man will nicht einfach nur das Projekt beenden, sondern sinnvolle Lösungen entwickeln, die dazu beitragen, Kunden zu begeistern und an das Unternehmen zu binden. Das ist heute eh schon schwer genug. Folgt man der Wasserfall-Logik des klassischen Projektmanagements wird es nicht einfacher.

Selbst-organisierte Aufgabenbearbeitung vs. Befehl und Gehorsam

Vorbei sind die Zeiten, in denen Geistesblitze verordnet und das Erreichen bestimmter Ziele befohlen wurde. Die Entwickler-Teams in agilen Projekten sind cross-funktional besetzt und arbeiten selbst-organisiert. Sie sind verantwortlich für die Umsetzung im Vorfeld definierter Aufgaben. Anders formuliert: Sie entscheiden darüber, wie das Ziel erreicht wird. Entwickler wissen in der Regel sehr genau, wen sie alles an Board haben müssen, um effektiv und effizient arbeiten zu können. Sich zu organisieren, liegt also im Verantwortungsbereich des Dev-Teams – nicht des Product Owners (dessen Rolle nicht mit der des klassischen Projektmanagers verwechselt werden sollte).

Scrum lässt sich – wie auch die anderen Ansätze einer agilen Projektbearbeitung – nicht nur im IT-Bereich einsetzen, sondern da, wo Werte erzeugt und erhalten werden sollen. Falls Sie Unterstützung bei der Umsetzung brauchen, kommen Sie gerne auf uns zu.

- - - - - - - - - - - - - - - -

Bis bald


Jan Kristof Arndt
Autor: Jan Kristof Arndt

Innovationsberater und Autor „Von Regelbrüchen … oder der Kunst, merkwürdig zu sein“

Foto: David Travis auf Unsplash