Wir haben in den vergangenen 15 Jahren sehr viele Projekte aufgesetzt und bei der damit verbundenen Zeit- und Kostenplanung viel Erfahrung gesammelt. Um es vorwegzunehmen – die richtige Schätzmethode zu wählen und anzuwenden ist bis heute eine große Herausforderung. Blicken wir auf ein paar Projekte zurück.

Bereits 2003 haben wir bei einem Automobilzulieferer eine Projektmanagement-Methode eingeführt und ein Projekttemplate aufgesetzt, um Anforderungen eines Audits hinsichtlich Ressourcenplanung und FMEA (Fehlermöglichkeits- und Einflußanalyse) umzusetzen. Das Team aus Vertrieblern und Projektleitern war und ist bis heute sehr erfolgreich und konnte Arbeitspakete und ganze Projekte aufgrund ihrer Erfahrung verblüffend genau vorhersagen. Jedoch war das Definieren eines Projektplans in Einzelschritten und das Schätzen von Dauer und Aufwand für dieselben Leute kaum möglich und führte in ein Durcheinander aus Aufwandsschätzung und Risikozuschlägen. Dieses musste zu Beginn des Projektes erst einmal aufgearbeitet werden.

In einem weiteren Projekt forderten wir von Entwicklern den nötigen Input für unseren Projektplan, um eine erste Kostenschätzung abzugeben. Obwohl wir es auf genau diese Art mehrmals erfolgreich hinbekommen hatten, lagen wir dieses Mal nicht nur mit der Schätzung daneben, die Entwickler waren zum geplanten Projektende immer noch mit Konzept und Design beschäftigt – sie waren schlichtweg komplett überfordert. Nur die Unterstützung erfahrener Kollegen konnte helfen.

In einem anderen Fall musste ein Kunde für die in den nächsten drei Jahren geplanten Rollouts detailliert alle Kosten schätzen und diese Werte, so hatte es das Controlling gefordert, sowohl nach Projektphasen, aber auch nach Jahren und nach interne und externe Kosten aufteilen. Überraschenderweise konnten wir die Werte in kurzer Zeit sehr präzise vorhersagen. Doch dies gelang nur, da wir einen vergangenen Rollout intensiv analysiert hatten und die Auswirkungen der zu erwartenden Mehr- oder Minderaufwände auf die Zeit und Kosten der jeweiligen Projektphase bewertet hatten. Mit diesem Modell konnten wir Kosten und Auslastung einfach prognostizieren.

In einem letzten Beispiel wurde ein Projekt von einem unternehmensweiten Kostenstopp überrascht. So mussten beim Rollout eines Zentralsystems auf Basis Peoplesoft nach dem Fit/Gap die Anforderungen auf höchster Ebene vorgestellt und freigegeben werden. Dazu wurden die Anforderungen nach Aufwand und Komplexität in die Kategorien S, M, L und Spezial aufgeteilt. Die Kategorie Spezial wurde individuell bewertet und für die Kategorien S, M und L konnten aufgrund der Erfahrungen Preisschilder genannt werden. Im Steuerkreis wurden dann die aus Kundensicht beschriebenen Anforderungen inklusive Preis vorgestellt. Das war etwas Neues! Aufgrund der Budgetknappheit wollte selbst das Management genau verstehen, wo der Nutzen liegt und ob die Funktion wirklich benötigt wird.

So entstanden unglaublich schlanke Implementierungen mit hohem "Business Value". Es wurden nur die wirklich erforderlichen Dinge umgesetzt. Und der Fachbereich akzeptierte diese Unvollständigkeit, über die man gemeinsam abgestimmt hatte. All der exponentiell höhere Aufwand durch aufgeblähte Anforderungslisten war weg. Die Vorgehensweise hatte viele Gegner, die es nicht akzeptieren wollten, dass aus den aufwändig ermittelten Anforderungen nur Bruchteile umgesetzt wurden. Aus unserer Sicht aber entstand das, was man heute ein "Minimum Viable Product" nennt, das .

Zusammenfassung der Lessons Learned:

  • Aufwandsschätzungen gelingen meist nur bei bekannten Themen
  • Sie verlieren schnell den Überblick, wo überall Sicherheitspuffer eingeplant sind
  • Es macht keinen Sinn, Mini-Tasks zu schätzen
  • Wer nicht weiß, was zu tun ist, kann auch nicht schätzen (gibt das aber möglicherweise nicht zu)
  • Schätzungen auf Basis vergangener Projekte sind selten möglich, dann aber einfach und meist erfolgreich
  • Es macht Sinn, Anforderungen in Töpfe aufzuteilen und Mischpreise zu kalkulieren
  • Es ist ratsam, die Funktionalität aus der Perspektive des Users in kleinen Elementen zu beschreiben anstatt lange Lastenhefte zu erstellen.

Lassen Sie uns nun in die agile Welt eintauchen, bevor wir auf das Schätzen eingehen:

Die Herangehensweise der Projektleitung, auf den plötzlichen Budgeteinbruch zu reagieren, ist schon nah dran an der heute immer mehr verbreiteten Denkweise rund um die agile Projektmanagement-Methode SCRUM. Der Unterschied besteht darin, dass nicht der Steuerkreis, sondern der Product Owner den Scope verantwortet und während des iterativen Vorgehens festlegt, welche Anforderungen umgesetzt werden. Kein leichter Job. Ein Product Owner muss viele Voraussetzungen mitbringen wie betriebswirtschaftliche Grundlagen und Know-how, analytisches und kreatives Denkvermögen, Marktkenntnisse, eine hohe Belastbarkeit als auch die große Leidenschaft, "sein" Produkt auf den Markt bringen zu wollen. Im Grunde genommen brauchen Sie einen Entrepreneur. Sie brauchen auf keinen Fall einen Projektleiter, der nur steuert, sondern einen Produktspezialisten, der auf jedes Detail in seinem Produkt achtet.

Ebenso verwendet Scrum statt Anforderungen eine Methode, die zeigt, wie eine Funktionalität aus Sicht des Anwenders aussieht und welchen Nutzen er daraus erhalten kann. Zum Beispiel: "Beim Einkaufen möchte ich, dass der Kofferraum automatisch öffnet, so dass ich meine Einkäufe nicht abstellen muss". Oder: "Als Motorradverkäufer möchte ich beim Erstellen eines Angebotes die bereits getätigten Motorradmieten des Kunden angezeigt bekommen, um ihm die Vergütung dieser anzubieten". Dieses "WIE" und "WAS" sind die sogenannten User Stories, die Sie ggf. noch in "Business" und "Technology" gruppieren können. Wir nutzen hierfür außerdem PowerPoint und schreiben jede Story auf eine eigene Folie. Die Auflistung dieser User Stories ist das Product Backlog, welches Sie so sortieren, dass die zuerst zu entwickelnden User Storys oben stehen. Nachdem die zu umfangreichen User Stories zerlegt wurden, werden diese in enger Zusammenarbeit mit den Usern und Fachbereichen in der sogenannten Customer Journey priorisiert. Es wird festgelegt, welche User Story im sogenannten Sprint (ein fest definierter Zeitraum für die iterative Entwicklungs- und Kundenfeedback-Phase) zwingend umgesetzt wird und welche optional ist. Machen Sie aber nicht den Fehler, alles vollständig definieren zu wollen. Besser ist es, schnell das Minimum zu beschreiben, um dann schnell dazu Feedback zu bekommen.

"Und wann ist dies nun alles fertig? Und was kostet es?"

Sie kennen die Fragen der Ungeduldigen so gut wie wir. Bestimmen wir also die Größe der User Stories. Erinnern Sie sich an das Beispiel aus dem Projekt, bei dem wir die Funktionalität rein aus Usersicht beschrieben haben. Hier wurde meist nur noch der Funktionsumfang verglichen. Suchen Sie mal nach Praxisbeispielen aus Ihrem Umfeld und fragen Sie sich "Was ist die Funktion?". Oder spielen Sie folgendes durch: Was macht ein Außenspiegel einer aktuellen S-Klasse? Oder der Sitz? Sammeln Sie alle Funktionen!

Sie ahnen es schon - wir empfehlen Ihnen tatsächlich alle User Stories anhand der Funktionalität zu schätzen. Sie schätzen also keine Aufwände und nicht wie lange einzelne Aufgaben dauern werden. Wenn Sie sich dies nicht trauen, so versuchen Sie zumindest diesen Weg parallel zur klassischen Aufwandsschätzung zu gehen. Aber haben Sie wirklich so gute Erfahrungen damit gemacht? Vergessen Sie auch nicht das Problem mit den Risikozuschlägen. Und wird nicht häufig nur so detailliert geplant, weil jemand nur genau wissen will, was er zu tun hat? Entscheiden Sie selbst. Wir haben noch zwei Argumente, die für das Schätzen der Funktionalität sprechen: Die Funktionalität ändert sich nicht über die Zeit. Und alle, einschließlich der Entwickler, sind gezwungen vom Kunden her zu denken - ein Grundprinzip des Design Thinking, von dem wir sehr überzeugt sind. Alle Beteiligten verstehen so oft besser was zu tun ist und sprechen die Sprache des Kunden.

Funktionalität schätzen: Estimation Meeting

Lassen Sie uns kurz durchspielen, wie so ein Meeting ablaufen könnte. Während der Phase eines Sprints hat der Product Owner die Entwickler eingeladen. Das Meeting ist auf 30 Minuten beschränkt und es gilt, 20 neue User Stories zu schätzen. Darüber hinaus wird durch die Session aber auch sichergestellt, dass jeder einen Überblick gewinnt, versteht, worum es genau geht, Abhängigkeiten erkennt, ein Verständnis für die erforderliche Architektur bekommt und zu große User Stories identifiziert. Zum Vorgehen: Der Backlog ist ausgedruckt, die User Stories liegen auf einem Stapel (eine Story je Seite), der unter den Entwicklern aufgeteilt wird und ohne zu sprechen auf drei Bereiche Small, Medium und Large mit jeweils drei Unterbereichen verteilt wird (d.h. in Summe auf neun Bereiche). Die User Stories werden also keinem Wert zugeordnet, sondern in Relation zueinander gebracht. Nach Zuordnung der eigenen Stories zu den jeweiligen Bereichen und Unterbereichen werden die Stories der Kollegen gelesen und ggf. verschoben. Aber bitte ohne dies zu kommentieren oder sich untereinander abzustimmen. Der Product Owner markiert Stories, die hin- und herspringen. Im Folgenden werden die User Stories mit Werten für die neun Bereiche beschriftet. Agilisten greifen hier gerne auf die nach Mike Cohn angepasste Fibonacci-Reihe zurück (1,2,3,5,8,13,20,40,100) und schreiben diese Werte auf das Blatt der User Story. Nun werden alle zuvor markierten User Stories diskutiert und ein Wert festgelegt. Alle User Stories, die sich nicht im Bereich S befinden, sollten nun aufgeteilt werden. Sie haben als Ergebnis also wirklich nur kleine Stories und können so 5-10 pro Sprint abarbeiten. Der Product Owner entscheidet am Ende des Meetings aufgrund des Input seiner Entwickler über die neue Reihenfolge.

Der Preis pro User Story

Sie haben nun die User Stories bewertet. Auf der anderen Seite kennen Sie all die Gesamtkosten wie z.B. das Team, die Infrastruktur, Nebenkosten, Lizenzen und Reisekosten. So sind Sie in der Lage, einen ersten Durchschnittspreis pro User Story zu kalkulieren, auch wenn Sie sicher diese Rechnung nach den ersten Iterationen wiederholen müssen. Aus den Kostensätzen und den User Stories können Sie nun tolle Modell bauen und sprechen bei Ihren Schätzungen sogar die Sprache des Kunden.

Win-Win? Jetzt wird es spannend…

Bekanntermaßen ist ja der Product Owner der Unternehmer im Unternehmen. Er sollte sich daher nicht die geleisteten Stunden, sondern die Leistung der User Story bezahlen lassen. Es geht ja nicht darum, möglichst viele Stunden zu schreiben, sondern gemeinsam das beste Ergebnis zu erzielen. Gerecht oder gar notwendig wäre dann, dass er eine User Story, die mit wenig Aufwand entwickelt werden konnte und dem Kunden einen großen Business Value liefert, auch zum maximal möglichen Preis anbietet. So verhalten sich beide wirtschaftlich und eine Win-Win-Situation ist möglich. Sie erzielen also einen Preis, der nichts mit den Produktionskosten zu tun hat und der bei der Mehrzahl der User Stories über dem kalkulierten Preis pro User Story liegen sollte.

Projektbudget

Auch wenn Sie noch nicht alle User Stories kennen, so ist doch mit diesem Modell eine Budgetplanung möglich. Verfügt das Projekt über ein Gesamtbudget, so sollte der Product Owner über das Budget für das Minimum Viable Produkt nachdenken und möglicherweise zu Beginn nur dieses freigeben. Die zu erwartenden Tranchen sollten zuvor aber definiert und kommuniziert sein. Auf diese Weise hat der Product Owner die Möglichkeit, ähnlich der Finanzierung eines Start-Ups, von Iteration zu Iteration neues Budget vom vorhandenen Gesamtbudget freizugeben und mit dieser stufenweisen Finanzierung den Return on Investment seines Produkts zu verbessern.

Fazit

Während bei klassischen Projekten wie einem Hausbau die Aufwandsplanung noch sinnvoll sein mag, so hat das Schätzen von Funktionalitäten viele Vorteile und passt hervorragend in die neue Gedankenwelt der Kundennähe. Planung wird durch Rechenmodelle ersetzt!

Pin It