Cookie

< zur Übersicht

08.09.2022
E-Commerce Beratung
Isabel Hartwig | Consultant

Mit agilem Anforderungsmanagement zum erfolgreichen E-Commerce Projekt

Verfolgt man Studien zum Erfolg von IT-Projekten, kommen diese oft zu einem ähnlichen Ergebnis: rund ein Drittel der betrachteten IT-Projekte scheitern komplett, mindestens 60 % verfehlen die Ziele und nur jedes fünfte Projekt kann als Erfolg gewertet werden. So oder so ähnlich erschreckend fällt das Fazit aus.
Natürlich ist es wichtig sich den konkreten Hintergrund einzelner Berichte anzusehen und mit kritischem Blick zu betrachten, aber ein Eindruck bleibt: Trotz Studien, Ursachenanalysen und viel Projektmanagement-Know-How im Markt gibt es offensichtlich keinen deutlichen Sprung in den Erfolgsquoten von IT-Projekten in den letzten Jahren. Dabei scheint die Zauberformel zum Erfolg bekannt zu sein.
Wie Sie Ihr IT-Projekt, z.B. auch die Implementierung oder das Replatforming eines Online-Shops, erfolgssicher gestalten können, verraten wir hier.

Warum laufen IT-Projekte häufig an den Zielen vorbei?

Eine Studie als Beispiel: Seit 1994 analysiert die Standish Group mit dem Chaos Report IT-Projekte und beschäftig sich mit den Ursachen von Projekterfolgen und Misserfolgen. Über 50.000 Einzelprojekte wurden seither betrachtet. Nicht überraschend kommt auch die Standish Group regelmäßig zu dem Ergebnis, dass nur eins von drei Softwareprojekten erfolgreich ist. Überraschender ist es, dass sich trotz leicht verbesserter Ergebnisse und tiefer Ursachenforschung in den letzten Jahren das Verhältnis von kritischen und erfolgreichen Projekten nicht wesentlich verändert hat. Die Analysten und Autoren ziehen das Fazit, dass Projektmanagementtools und reine Projektmanagementexpertise nicht der Schlüssel zum Erfolg sind.
Der Kern des Problems, welchen die Standish Group im Chaos Report 2020 beschreibt, können wir aus eigenen Erfahrungen bestätigen: In einer idealen Welt wäre das gewünschte Projektergebnis zu Beginn glasklar. Alle einzusetzenden Lösungen wären bekannt, das Produkt wäre in allen Facetten verstanden, die Rahmenbedingungen blieben unverändert und wir könnten uns sicher sein, dass der Nutzer es lieben wird. So sind IT-Projekte aber leider nicht: Sie sind geprägt von einer langen Entwicklungszeit, sich schnell verändernden Erwartungen von Nutzern, einem Umfeld rasanter technischer Weiterentwicklung und hohem Wettbewerbs- und Kostendruck.  Alle einzusetzenden Lösungen wären bekannt, das Produkt wäre in allen Facetten verstanden, die Rahmenbedingungen blieben unverändert und wir könnten uns sicher sein, dass der Nutzer es lieben wird. So sind IT-Projekte aber leider nicht: Sie sind geprägt von einer langen Entwicklungszeit, sich schnell verändernden Erwartungen von Nutzern, einem Umfeld rasanter technischer Weiterentwicklung und hohem Wettbewerbs- und Kostendruck.
Daraus ergibt sich per se ein Widerspruch: klassische Projekte sind nach Definition endlich, zeitgebunden und durch den Projektrahmen begrenzt. Software ist aber nicht endlich, sie besitzt einen Lebenszyklus wie ein Produkt. Ein Produkt, welches von Nutzern in einer sich schnell verändernden Umgebung nachgefragt werden und für Begeisterung sorgen soll. Etwas, was zum Projektstart noch Standard war, kann heute schon überflüssig sein oder durch neue Lösungen auf dem Markt besser umgesetzt werden. In den letzten Jahren haben wir auch gelernt, dass Krisen Rahmenbedingungen grundlegend verändern und kurzfristige substanzielle Änderungen in Projekten erfordern.

Die Zauberformel der Agilität

Dass sich schnell ändernde Anforderungen und Flexibilität in Projekten vereinen lassen, zeigen agile Vorgehensmodelle (beispielsweise nach dem Scrum Framework). Sie bieten nachweislich einen höheren Nutzen als klassische Verfahren – und zwar durch höheren Return on Investment basierend auf einer schnellen Lieferung und einer höheren Produktivität der Teams. Sie können auch in langen Projekten kurzfristigen Bedarf erfüllen und schnell Nutzen stiften. Sie sind krisensicherer und geben einen größeren Rahmen für Innovationen.
Agile IT-Projekte sind deutlich erfolgreicher als klassische Wasserfallprojekte, die insbesondere bei großen und komplexen Projekten, häufiger scheitern.

Die Grundlage allen agilen Arbeitens, das agile Manifest, wurde bereits vor mehr als 20 Jahren formuliert. Seitdem hält Agilität Einzug in Projekte, Managementmethoden und auch als Ausrichtung für Unternehmensstrukturen.
Die formulierten Prinzipien sehen unter anderem vor, stehts in enger Zusammenarbeit des Projektteams mit dem Kunden, schnell und pragmatisch Produkte von hohem Nutzen zu schaffen. Prozesse sind hier weniger wichtig als direktes Kundenfeedback, welches in aufeinanderfolgenden Entwicklungsschritten zu einer nutzerorientierten Verbesserung beiträgt.

  • Werte im agilen Manifest:

    "Individuen und Interaktionen mehr als Prozesse und Werkzeuge
    Funktionierende Software mehr als umfassende Dokumentation
    Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
    Reagieren auf Veränderung mehr als das Befolgen eines Plans"

IT-Projekte kommen heute eigentlich kaum noch ohne agile Elemente aus. Begriffe wie Kanban, Sprint, Backlog sind allgegenwärtig. Um den vollen Vorteil von Agilität zu entfalten und Projekte mit Erfolgsgarantie umzusetzen, reicht das Einbeziehen einzelner Methoden und Elemente nicht aus. Der Erfolg liegt vielmehr darin, Agilität in der Projektkultur, der Haltung und der Zusammenarbeit in Projekten zu etablieren. Es bedarf bei allen Projektbeteiligten dem tiefen Bewusstsein der agilen Werte und dem Willen, das Ergebnis aktiv mitzugestalten.

Erfolgsfaktor: agiles Anforderungsmanagement

Dass Projektziele, Kundenwunsch und das entwickelte System übereinstimmen, erreicht man am besten, indem man sich schrittweise dem Ziel nähert und in kurzen Zyklen, z.B. zweiwöchigen Sprints, Erwartungen und Ergebnisse offen reflektiert. Dazu sind agile Vorgehensmodelle am besten geeignet. Der maßgebliche Erfolgsfaktor ist hier ein agiles Anforderungsmanagement. Es bringt Flexibilität und Zielerreichung zusammen und beschreibt, einfach gesagt, den Transfer von Wissen der Nutzer und Stakeholder in das Entwicklungsteam.
Agiles Anforderungsmanagement unterscheidet sich in vielen Punkten vom klassischen Vorgehen. Dazu haben wir einige Punkte gegenübergestellt:

  Klassisches Vorgehen Agiles Anforderungsmanagement
Produktziel In der Konzeptionsphase wird ein möglichst komplettes Bild vom Endprodukt festgelegt, welches im Projektverlauf konstant bleibt. In der Konzeptionsphase wird ein grobes Bild des Endproduktes erstellt, welches eher einer Vision entspricht und sich während des Projektverlaufes verändern kann.
Beschreibung Anforderungen werden nach einem konkreten Satzbaumuster aus Software-Systemsicht beschrieben (weniger aus Nutzersicht). Die Lösung wird gegebenenfalls vorweggenommen.

Beispiel: [Bedingung] „Wenn ein Neukunde im Onlineshop bestellen möchte [Anforderungswort] „muss“ [Subjekt] „im Checkout“ [Objekt] „eine Gastbestellung“ [Aktion] „ausgewählt werden können“
Anforderungen werden als User Stories formuliert. Die Lösung wird während später folgender Refinements erarbeitet.
„Eine User Story ist eine informelle, allgemeine Erklärung eines Software-Features, die aus der Sicht des Endbenutzers verfasst wurde. Ihr Zweck ist es, zu zeigen, welchen Wert ein Software-Feature für einen Kunden hat.“ Quelle: Atlassian

Beispiel: [Als {Rolle}] Als Neukunde [möchte ich {etwas tun}] möchte ich [um zu {Ziel}] als Gast bestellen können.
Dokumentation Das Lastenheft ist das zentrale Dokument, in dem alle Anforderungen an den Onlineshop detailliert festgelegt sind. Das Product-Backlog ist das zentrale Dokument für alle User Stories. Es wird im Projektverlauf mit neuen User Stories ergänzt und neu priorisiert. Ein grobes Lastenheft mit geringem Detaillierungsgrad kann als Startdokument zu Beginn eines Projektes sinnvoll sein.
Zeitpunkt im Entwicklungsprozess Anforderungen werden zu Beginn des Projektes, vor der Entwicklungsphase aufgenommen und nach der Konzeptionsphase im linearen Entwicklungsprozess umgesetzt.
Müssen Anforderungen angepasst werden oder kommen neue hinzu, werden diese über ein festgelegtes Change-Request-Verfahren in das Projekt aufgenommen.
Alle Projektdokumente und Pläne müssen angepasst und auf einen neuen Stand gehoben werden.
User Stories werden regelmäßig in festgelegten Entwicklungszyklen betrachtet, detailliert, neu aufgenommen und nach Feedback optimiert (Iterativer Ansatz zur kontinuierlichen Verbesserung).
In Refinements findet eine Prüfung mit den Mitgliedern des Entwicklungsteams statt, um die notwendige Klarheit für die Umsetzung der Anforderungen zu schaffen.
Detaillierungsgrad Jede Anforderung wird zu Projektbeginn detailliert aufgenommen und beschrieben. Entsprechend der Priorisierungen steigt der Detaillierungsgrad der Anforderungen
(detailliert werden nur Anforderungen mit hoher Priorität, also die mit hohem Nutzen und zeitnaher Umsetzungswahrscheinlichkeit).
Feedback & Test Die Kommunikation zum Projekt erfolgt schwerpunktmäßig zum Projektbeginn während der Konzeptionsphase. Das erste Feedback zur Entwicklung erfolgt am Ende in der Testphase. Die Entwicklung erfolgt schrittweise in kurzen zeitlichen Abständen mit Auslieferung einzelner kompletter Funktionalitäten (inkrementelles Vorgehen) mit direktem Test und Feedback.

5 Tipps für ein erfolgreiches Anforderungsmanagement

1. Agiles Anforderungsmanagement ist eine Teamaufgabe
Anforderungen beschreiben, definieren und transparent machen ist die Aufgabe des gesamten Teams. Jedes Teammitglied bringt einzigartige Sichtweisen und Einblicke ein. Das gemeinsame Verständnis für die Umsetzung kann nur erreicht werden, wenn sich alle Beteiligten austauschen. So entsteht durch kollektive Intelligenz ein bestmögliches Ergebnis. Das bedeutet aber nicht, dass kein Requirements-Engineer mehr benötigt wird. Er nimmt eine zentrale Rolle ein. Bei ihm laufen alle Fäden zusammen, er sorgt dafür, dass Meetings stattfinden, alle Stakeholder beteiligt werden und die Dokumentation erfolgt. Ein Requirements-Engineer entwirft auch initial die ersten User Stories auf Basis der Kundenwünsche und stellt diese zur Diskussion ins Team.


2. Direkte Kommunikation zwischen Nutzer, Stakeholder und Entwicklungsteam
Es sollte in Projekten ermöglicht werden, dass sich Entwickler mit Stakeholder direkt und regelmäßig austauschen können.  Denn: „Der schnellste Weg, um über eine Sache klar zu werden ist das Gespräch“ (Friedrich Dürrenmatt). Entwickler können die Nutzer viel besser im Gespräch verstehen als durch das Lesen von Dokumenten. So können bessere Lösungen gefunden werden. Schnelles, direktes Feedback verkürzt zudem die Zykluszeit und verbessert die Qualität.

3. Einfachheit und Übersichtlichkeit 
Der Grundsatz ist: nicht alles ist wichtig. In klassischen Projekten werden umfassend sämtliche Anforderungen aufgenommen mit dem Ergebnis, dass erfahrungsgemäß 20-40% nicht umgesetzt werden. Effektiver und übersichtlicher ist es, große Anforderungen erstmal auf höherer Abstraktionsebene aufzunehmen (Epics) und dann in kleine problemorientierte User Stories aufzubrechen. Erst wenn die Umsetzung relevant wird, wird spezifiziert und abgestimmt. So kann man leicht den Überblick behalten und sich auf die Umsetzung fokussieren.

4. Der richtige Einsatz von Tools
Es gibt viele Tools, die für ein agiles Projektvorgehen geeignet und notwendig sind, wie z. B. Jira und Confluence.  Eine gute Dokumentation und Nachvollziehbarkeit für das gesamte Projektteam ist ein absolutes Muss. Das Projektwissen muss daher zentral verfügbar sein und darf nicht bei einzelnen Ressourcen liegen. Unser Tipp: Um den Überblick zu behalten, formuliert man kurze prägnante Beschreibungen, gegebenenfalls in Stichworten anstelle von langen Texten. Leider schleicht es sich manchmal in Projekte ein, dass plötzlich über die Dokumentationstools kommuniziert wird – hier sollte man vorsichtig sein. Der Wunsch nach Nachvollziehbarkeit der Kommunikation, sollte nicht die direkte Kommunikation ersetzen.

5. Kultur und Offenheit
Zu agilen Projekten gehört Mut. Vor allem, weil es gegebenenfalls andere Arbeitsweisen erfordert als man sie aus klassischen Projekten kennt. Zum Beispiel eine offene Fehlerkultur: Es gibt kein Scheitern, jede Erfahrung gehört dazu, trägt zur Verbesserung bei und führt zur Zielerreichung. Dazu gehört auch eine gelebte Feedbackkultur.  Denn ansonsten gilt Peter Druckers berühmter Satz: „Culture eats Strategy for Breakfast“.

Fazit

Aus vielen Projekten heraus wissen wir, wie schwierig es sein kann Agilität in Projekten als Kernhaltung zu implementieren und iterativ mit Anforderungen an das Endprodukt umzugehen.
IT-Projekte sind aber kostenintensiv und oft damit verbunden bei Misserfolgen anderen Unternehmensbereichen zu schaden, so dass es keine Frage sein sollte, wie agil ein Projekt aufgestellt ist.
Wenn Sie einen Partner suchen, um in das Thema Agilität einzusteigen oder ein Projekt radikal agil umsetzen wollen: Wir sind dabei.


Weiterführende Artikel zum Thema

< zur Übersicht