"Durch die Nutzung innovativer Technologien (…) nimmt Geschwindigkeit in unserer vernetzten Welt von heute in allen Facetten eine Schlüsselrolle ein - time to market, time to change, time to value, time to profit, time to volume etc.", konstatieren beispielsweise IDC-Forscher in einer im Dezember 2019 veröffentlichten Studie.
Foto: Who is Danny - shutterstock.com
Dass das Thema Innovationsgeschwindigkeit für Unternehmen in den kommenden Jahren mit hoher Wahrscheinlichkeit tatsächlich noch wichtiger wird als bisher, unterstreicht eine aktuelle McKinsey-Studie. Demnach geht eine überwältigende Mehrheit der Vorstände und Unternehmensentscheider aus der Industrie davon aus, dass sich ihre Branchen in den nächsten fünf Jahren stärker verändern werden als in allen vergangenen Jahrzehnten.
Grundgedanke von Methoden wichtiger als Befolgung jeder Regel
Übereinstimmung herrscht insofern, als dass sich traditionelle Wasserfallmodelle wenig für das Projektmanagement in der Softwareentwicklung eignen. Denn zum einen ist diese Methodik darauf ausgelegt, ein zuvor definiertes Ziel in ferner Zukunft zu erreichen. Zum anderen geht mit dieser Herangehensweise in der Regel die Annahme einher, dass eine Lösung einmal entwickelt werden könnte und anschließend fertig sei. Stellt sich die Frage: Welche agile Methode eignet sich am besten für Projekte ohne zuvor festgelegtes Endergebnis – ist es Scrum, Lean oder doch Design Thinking? All diese agilen Vorgehensweisen haben ihre Vor- und Nachteile und welche sich am besten eignet, kann nur von Fall zu Fall entschieden werden.
Doch unabhängig davon, auf welche Methode die Wahl fällt: Damit sie bei der Umsetzung kundenzentrierter und wirtschaftlich erfolgreicher Produkte und Dienstleistungen behilflich sein kann, reicht es nicht, mechanisch die definierten Rollen zu besetzen sowie den vorgegebenen Schritten zu folgen, ohne sie mit Bedeutung zu füllen. Dies gilt für Product Owner ohne Entscheidungsbefugnis genauso wie für Daily Scrums zu Beginn des Arbeitstags, die von Entwicklerteams nicht konzentriert und ausschließlich dazu genutzt werden, um sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen.
Anstatt sich in unfruchtbaren Diskussionen über die Vor- und Nachteile der jeweiligen Projektmanagementmethode zu verlieren, hilft es oft, sich ihr eigentliches Ziel vor Augen zu führen. Dieses ist die Sicherstellung dreier unterschiedlicher Geschwindigkeitsaspekte, die über den Erfolg von Lösungen entscheiden:
Lieferfähigkeit
Implementierbarkeit
Anpassungsfähigkeit
Am besten gelingt dies, indem die Komplexität in Projekten auf ein Minimum reduziert wird.
Überschaubare Schritte statt großer Sprünge
Denn die Erfahrung zeigt: Projekte scheitern weitaus seltener an der gewählten Projektmanagementmethode als daran, dass zu viel auf einmal in Angriff genommen wird. "Wenn wir schon dabei sind, lasst uns gleich alles auf einen Schlag erledigen", ist eine häufig anzutreffende Einstellung. Diese fußt oftmals auf der Annahme, dass Projekte teurer werden, wenn Dinge mehrfach angegangen und iteriert werden müssen. Tatsächlich ist in der Regel das Gegenteil der Fall. Sollen beispielsweise viele Systeme auf einmal angepasst werden, resultieren daraus unzählige voneinander abhängige Arbeitspakete, und Projekte erreichen schnell einen Grad an Komplexität, der nur schwer zu bewältigen ist.
Das Erfolgsrezept besteht somit darin, alles so einfach wie möglich zu halten und unbekannte Faktoren zu eliminieren. Denn ein Vorgehen in überschaubaren Schritten mit kontinuierlichem Output erzeugt verlässliche Ergebnisse, auf die aufgebaut werden kann. Werden hingegen zu viele Fronten auf einmal eröffnet, nimmt die Zahl der unbekannten Faktoren sprunghaft zu. In der Folge steigt die Komplexität und somit die Wahrscheinlichkeit, dass etwas schief geht. Dass laut McKinsey über 70 Prozent aller groß angelegten digitalen Transformationsinitiativen – von GE über Ford bis hin zu Procter & Gamble – scheitern, ist kein Zufall. Inkrementelle Entwicklungen reduzieren zudem das Risiko von Innovationen, die zwar reibungslos funktionieren, aber an den Bedürfnissen der Nutzer vorbei gehen und aufgrund dessen nicht genutzt werden.
Identifikation der Kundenbedürfnisse
Die Bedürfnisse von Kunden zu identifizieren, noch bevor sie sich dieser selbst bewusst werden, ist das Erfolgsgeheimnis vieler prosperierender Unternehmen. "Wenn ich die Leute gefragt hätte, was sie wollen, hätten sie schnellere Pferde gesagt", lautet ein in diesem Zusammenhang berühmt gewordenes Bonmot, das wohl fälschlicherweise Henry Ford zugeschrieben wird. Nichtsdestotrotz hat es einen wahren Kern und gilt nicht nur für revolutionäre Erfindungen, die unsere bis dahin bekannte Welt komplett auf den Kopf stellen, sondern genauso für die Weiterentwicklung von Lösungen.
Bereits 1997 hat Steve Jobs treffend festgestellt: "Es ist wirklich schwer, Produkte nach Fokusgruppen zu entwerfen. Oft wissen die Leute nicht, was sie wollen, bis man es ihnen zeigt". Inzwischen gibt es diverse wissenschaftliche Untersuchungen, die nahelegen, dass der Apple-Gründer mit dieser Aussage richtig lag. Deswegen fragt zum Beispiel Google bei der (Weiter-)Entwicklung von Apps nur noch selten, welche Features sich User wünschen. Stattdessen präsentiert das Unternehmen neue Funktionen in A/B-Tests und misst mittels Telemetrie, wie User mit den unterschiedlichen Angeboten interagieren.
Unterstützung durch MVPs
Eine bewährte Methode, um kundenzentrierte Angebote zeitnah auf den Markt zu bringen, ist deren Entwicklung mittels eines Minimum Viable Products (MVP). Diese erste veröffentlichte Version eines Produkts oder Services, beinhaltet zum Marktstart zunächst lediglich einen Basisumfang an Funktionen, die allesamt einen direkt erkennbaren Mehrwert für die Nutzer bieten. Weitere Features werden erst im Anschluss implementiert.
Dass sich die Zeit, bis eine Lösung ausgeliefert werden kann (Lieferfähigkeit), mit diesem Vorgehen deutlich verkürzen lässt, erklärt sich von selbst. Gleichzeitig erhöht sich die Implementierbarkeit, da MVPs per definitionem weniger kompliziert sind als spätere Versionen desselben Produkts und beispielsweise oft mit weitaus weniger Schnittstellen auskommen.
Ein weiterer Vorteil dieser Vorgehensweise ist, dass sich durch die Kombination aus einer Entwicklung in zeitlich überschaubaren Sprints und frühen und regelmäßigen Feedback-Runden prüfen lässt, ob Funktionen den ihnen zugedachten Zweck erfüllen. Ist dies nicht der Fall, können Entwicklerteams auf Änderungswünsche direkt reagieren (Anpassungsfähigkeit). Das iterative Vorgehen stellt also sicher, dass das Endprodukt optimal auf die späteren Nutzer angepasst ist – zumindest vorübergehend.
Denn heutzutage kann kaum eine Lösung jemals als "fertig" bezeichnet werden. Stattdessen müssen sie unablässig weiterentwickelt und auf sich ständig ändernde Kundenanforderungen angepasst werden, um nicht auf dem Abstellgleis zu landen. Microservice-Architekturen, Cloud Services und DevOps können sowohl bei diesen stetigen Anpassungen als auch bei der Integration der Lösung in die übrige IT-Infrastruktur wertvolle Dienste erweisen.
ROI ist wichtiger als Zeit und Geld
Klein anzufangen und in der Lage zu sein, Anwendungen zeitnah mit überzeugenden Ergebnissen umzusetzen, hat noch einen weiteren entscheidenden Vorteil: Da frühe Produktversionen zwar nur über einen geringen Funktionsumfang verfügen, diese aber bereits einen funktionalen Mehrwert bieten, können sie dem anvisierten Zielpublikum früh im Entwicklungsprozess bereitgestellt werden. So verursachen die Lösungen nicht nur Kosten, sondern können bereits im unfertigen Zustand ihre Praxistauglichkeit unter Beweis stellen und Umsatz generieren.
Dies führt nicht selten dazu, dass Projektverantwortliche bereit sind, mehr Geld zu investieren oder Projekte länger laufen zu lassen – schließlich sehen sie, dass ihre Investitionen Früchte tragen. Letztlich ist es selbst für Verantwortliche im C-Level-Management wesentlich leichter zu argumentieren, warum für ein bestimmtes Projekt weitere Ressourcen freigemacht werden sollen, wenn sie bereits erste Erfolge vorweisen können. (bw)