Erfolgreiche Produktentwicklung mit dem Retainer-Modell

Und genau diese Projekte sind im E-Commerce in den letzten Jahren immer komplexer geworden. Weil die Anforderungen komplexer geworden sind, sind E-Commerce-Projekte gewachsen wie die Dinosaurier – Projektvolumina von 1.000 Projekttagen und mehr sind keine Seltenheit (obwohl vielleicht “nur” 400 Projekttage 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.

Marktanforderungen ändern sich schneller als der Projektfortschritt

Im besten Fall wird das erkannt, neu geplant und als “Change Request” anders als ursprünglich geplant umgesetzt. Marktanforderungen haben sich in einer VUCA-Welt einfach schneller verändert, als das Projekt vorangeschritten ist. Kann passieren. Das “Projekt” endet daher 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.

Sponsored Post

Unterschätzte Risiken

Beliebte Gewerbeversicherungen

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.

„Etappenziele“ setzen

Daher wird versucht, mit “Etappenzielen” einen Kompromiss zu finden. Es wird im Vorfeld versucht, die Anforderungen an ein MVP, ein “Minimum Valuable Product”, zu definieren, das heißt 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!

Die Vorteile des Retainer-Modells in der Produktentwicklung

Der (Denk-)Fehler im System ist dabei die Idee, ein Projekt, Gewerk, “Stück Software”, einen Leistungsumfang – das heißt 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 – das heißt 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).

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. Und 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) – das heißt 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.

Die Angst vor Fehlentwicklungen im Projekt

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 – das heißt 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 daher 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.