Der langsame Tod der Dinosaurier “eCommerce-Projekte”

eCommerce-Projekte sterben aus. Warum? Weil die Anforderungen im digitalen Handel immer weniger in Form von “Projekten” zu erfüllen sind. Wir erinnern uns: Projekte sind gekennzeichnet durch einen Anfang und ein Ende, es gibt eine “Projektplanung” in Form eines Gantt-Diagramms, und diese Planung ist dann bitteschön auch einzuhalten – oder zumindest ist ihr nahe zu kommen. Daran, wie gut das gelingt, bemisst sich dann schließlich auch die Qualität des “Projektmanagements”.

Agile Projekte
Stetig wachsende Anforderungen
Und genau diese Projekte sind im eCommerce in den letzten Jahren immer komplexer geworden. Weil die Anforderungen komplexer geworden sind, sind eCommerce-Projekte gewachsen wie die Dinosaurier – Projektvolumina von 1.000 PT und mehr sind keine Seltenheit (obwohl vielleicht “nur” 400 PT geplant waren). Und damit nicht genug: Weil “Projekte” solcher Volumina eben auch eine entsprechend lange “Projektlaufzeit” haben, überholen sie sich selbst – sprich: was zu Beginn in der Planung vorgesehen war, ist nach einigen Monaten “Projektlaufzeit” gar nicht mehr aktuell, richtig oder zielführend. Im besten Fall wird das erkannt, neu geplant und als “Change Request” anders als ursprünglich geplant umgesetzt. Marktanforderungen haben sich einfach schneller verändert, als das Projekt vorangeschritten ist. Kann passieren. Das “Projekt” endet also nicht, es geht weiter. Es wird umgebaut – bevor es überhaupt endet – und deswegen ist es auch kein Projekt mehr (Projekte haben ja ein Ende), sondern einfach nur noch ein frustrierender Moloch. Und “Schuld” daran haben irgendwie alle Beteiligten und irgendwie Keiner.

Deswegen sind diese Dinosaurier-“Projekte” in ihrer Größe nicht überlebensfähig.

Und ihr Aussterben hat schon längst begonnen: Zeitgemäße Softwareentwicklung wird heutzutage gerne “agil” vorangetrieben. Wir sprechen dann nicht mehr von einem “Projekt”, sondern wir entwickeln ein (Software-)“Produkt”, das in Releases kontinuierlich weiterentwickelt wird. Ende offen. Auf Grundlage einer eher grob skizzierten und auch variablen “Produktvision”. Entsprechend wird der alte “Projektmanager” zum “Product Owner”. Zumindest das veraltete Framework eines “Projektes” mit Anfang und Ende hätten wir damit verlassen.
Agile Projekte “mit der Brechstange”
Auf der kaufmännischen Ebene zwischen Auftraggeber und Dienstleister hat sich das agile Modell allerdings bisher wenig durchgesetzt: Der Auftraggeber muss für seine Budgetplanung in der Regel vor Beginn eines “Projektes” wissen, was es kosten soll – und was er für sein Geld bekommt. Wie wir es nennen, ist ihm egal. Mit welchen Methoden wir arbeiten, ob wir sprinten, ein Lastenheft erstellen oder ein Backlog pflegen vielleicht auch – aber was er für sein Geld bekommt und was es kostet, das will er nun mal wissen. Punkt.

Diese Denkweise, kaufmännisch ein “Werkvertrag”, passt natürlich wunderbar in die alte Welt der “Projekte”, wo es ja ein Ende gibt und man irgendwann einen Strich unter die ganze Angelegenheit ziehen kann, es passt allerdings weniger gut in die agile Welt der quasi endlosen Produkt-Entwicklung. Wo es kein Ende gibt, gibt es keinen Endpreis.

Also wird versucht, mit “Etappenzielen” einen Kompromiss zu finden. Es wird im Vorfeld versucht, die Anforderungen an ein MVP, ein “Minimum Viable Product”, zu definieren, also quasi die Minimalausprägung dessen, was man zum Start haben möchte. Das wird dann mit einem Preis versehen, und wir haben … ein gutes, altes Projekt. In der Hoffnung, es ist kleiner, überschaubarer und besser planbar, als die eingangs beschriebenen Dinosaurier-Projekte. Diese MVPs werden dann in Releases weiterentwickelt, und jedes Release kann wunderbarerweise wieder ein kleines, überschaubares Projekt sein. Das ist der Kompromiss und oft der aktuelle Stand der Dinge in vielen Auftraggeber-Dienstleister Beziehungen im Umfeld der agilen Softwareentwicklung.

Allerdings produziert auch dieses Modell oft unerwünschte Nebeneffekte, unter denen Auftraggeber und Dienstleister gleichermaßen leiden. Zum Einen sind diese MVPs und die anschließenden Releases am Ende doch nicht so klein und überschaubar, dass eine mehr oder minder traditionelle Projektplanung den Scope realistisch greifen kann, zum Anderen erleben wir gerade den Trend, dass sich Anforderungen des Marktes und Möglichkeiten der Technik inzwischen so schnell ändern, dass es am Ende trotzdem wieder zu Anpassungen am ursprünglichen Vorhaben geben soll, die in Form von Change Requests (CRs) ergänzt werden und die Projektlaufzeit und das Budget über die Planung hinaus anspannen. Und auch hier entstehen dann 

insbesondere im Projektmanagement erhebliche zusätzliche Aufwände, um CRs von Anforderungen aus dem ursprünglichen Scope zu trennen und zu dokumentieren. Same same but different!
Fehler im System
Der (Denk-)Fehler im System ist dabei die Idee, ein Projekt, Gewerk, “Stück Software”, einen Leistungsumfang – also irgendetwas vorher klar definiertes mit einem Aufwand und einem Preis zu versehen. Dabei geht es in Wahrheit eigentlich nur darum, dass sich Auftraggeber passend zu ihrem Vorhaben Know-how und Arbeitszeit sichern – also Ressourcen.

Am besten sind Unternehmen mit wachsendem und sich veränderndem IT-Bedarf in diesem Umfeld aufgestellt, wenn sie sich völlig unabhängig von einem konkreten Projekt oder Projektziel über einen definierten Zeitraum bei ihrem Dienstleister Ressourcen sichern, die es ihnen ermöglichen, flexibel auf Markt- und Kundenanforderungen zu reagieren und damit in Sachen IT handlungsfähig zu werden.

Dazu muss zu Beginn eines solchen Zeitraums (z. B. 12 Monate) nur ein grober Rahmen gesteckt und/oder (darauf basierend) ein Investitionsbudget definiert werden. Die Ressourcen werden dann vom Dienstleister passend zum gemeldeten Bedarf mit Personal hinterlegt und als Retainer in gleichen monatlichen Raten abgerufen und abgerechnet (z. B. 20 PT/Monat).

Ressourcen Planung
Vorteile des Retainer-Modells
Dieses Vorgehen schafft diverse Vorteile:

  • Es gibt ein klares Budget und damit absolute Kostensicherheit auf Auftraggeberseite. 
  • Es schafft trotzdem maximale Flexibilität: Monat für Monat kann der Auftraggeber neu entscheiden, wie und mit welcher Priorität die fest zugesicherten Ressourcen eingesetzt werden sollen – was im nächsten Monat in welcher Reihenfolge entwickelt werden soll. 
  • Der Aufwand für Projektkoordination sinkt radikal, wenn es keine Projekte mehr gibt. 
  • Es entfällt eine Projektplanung, die über den Zeitraum eines Entwicklungszyklus (Sprint) – also maximal vier Wochen – hinausgeht. 
  • Und – noch viel wichtiger – das für alle Beteiligten nervenraubende Dokumentieren von Planabweichungen und die Diskussion, was eine neue Anforderung ist und was “von Anfang an so geplant war” – bei Funktionen, die Monate im Voraus und unter anderen Annahmen konzipiert wurden. Das entfällt einfach.
Kein Haufen “Nullen und Einsen”
Der Grund übrigens, warum viele Auftraggeber sich mit dem hier skizzierten Retainer-Modell trotzdem schwer tun, ist ein leider sehr hartnäckiger “Phantom-Grund”: Das Budget steht fest – also aus Auftraggeber-Perspektive die Kosten. Aber was für das Budget entwickelt wird eben noch nicht. Das schürt die Sorge, man könne für sein Budget im schlimmsten Fall “einen Haufen Nullen und Einsen” erhalten, dessen Funktion eben nicht gewährleistet ist und die ggf. weit davon abweicht, was man ursprünglich im Kopf hatte.

Dieses “Risiko” besteht theoretisch. Aber es ist sehr unwahrscheinlich, in der Praxis kommt es nicht vor. Denn jedem Entwicklungszyklus (=Sprint) folgt eine Abnahme und Freigabe durch den Auftraggeber. Jeden Monat wird also gecheckt und sichergestellt, dass dem Output der Entwicklung ein adäquater Business Value für den Auftraggeber gegenübersteht. Und – ganz abgesehen davon – können wir nicht erkennen, dass die guten, alten “Dinosaurier-Projekte” hier eine lupenreine Bilanz vorweisen können. Oder kennen Sie ein IT-”Projekt”, bei dem man über eine exzellente Projektplanung und einen klar definierten Scope Budget und Qualität gleichermaßen im Vorfeld sichergestellt hätte?

Genau! Deswegen sterben sie ja auch aus, die Dinosaurier.


Diese Artikel könnten Sie auch interessieren:

Frontend Hui!, Backend Pfui!

eCommerce-Prüfverfahren der SHOPMACHER liefert bemerkenswerte Ergebnisse: Unter der Motorhaube waren geprüfte Shops 2019 nicht ideal aufgestellt.

10 Pflicht ToDos - Whitepaper

Sie fragen sich, wie es nach dem GoLive Ihrer eCommerce Plattform weiter gehen soll? Antworten finden Sie in unserem Whitepaper "10 Pflicht-ToDos nach dem GoLive". Einfach hier downloaden ...

SHOPMACHER
eCommerce GmbH & Co. KG
Am Campus 5 in 48712 Gescher
Fon +49 2542 8703-0
[email protected]