Projektaufwände schätzen

Wie viel muss man über eine unsichere Aufgabe (z. B. ein Projekt) vorher wissen, um dafür ein Angebot abzugeben? Wie viel Puffer muss ich aufschlagen? Eigentlich wissen wir oft mehr über diese unsichere Aufgabe als uns bewusst ist. Und dieses Wissen können wir für die Schätzung benutzen.
Anfang Juli 2015 fand das erste Mal die Konferenz "Agile Contracts" in München statt. Das war für mich eine gute Gelegenheit, anderen Beratern und Praktikern zuzuhören, wie sie mit dem Thema umgehen.

In den Gesprächen mit Kollegen und Besuchern fiel mir besonders oft auf, dass viele doch noch denken, dass man die Anforderungen für Projekte am Anfang gut erfassen kann. Die Denkweise ist folgende:

• Um einen Auftrag zu bekommen, muss ich einen Preis nennen.
• Um einen Preis zu nennen, muss ich wissen, welchen Aufwand ich habe.
• Um den Aufwand abzuschätzen, muss ich wissen, wie viel Arbeit in dem Auftrag steckt.
• Um nicht am Ende drauf zu zahlen, muss ich einen Puffer einplanen.
• Damit der Kunde zufrieden ist, brauchen wir voher eine Liste, auf der steht, was er am Ende bekommt. Damit kann ich nachweisen, dass der Kunde genau das bekommen hat, was er bestellt hat.

Viele dieser Punkte nehmen wir als gegeben hin. Wir wissen aus Erfahrung, dass wir uns bei den Projektpreisen oft vertun. Bessere Planung hat uns nicht geholfen. Wie lösen wir also dieses Problem?

Ein guter Weg ist es, diese Annahmen einmal in Frage zu stellen. Ist der Kunde wirklich zufrieden, wenn ich ihm seine alte Anforderungsliste unter die Nase halte? Wenn nicht, liegt es an der Liste oder an anderen Dingen?

Die wichtige Annahme für diesen Beitrag ist die, dass ich den Aufwand ermitteln muss, bevor ich einen Preis nenne.

Die gleiche Annahme steht Nicht-Scrum-Teams im Weg, wenn sie ihre Arbeit schätzen müssen. Nun haben Scrum-Teams gelernt, dass sie mit relativem Schätzen sehr gut leben können. Dazu vergleicht das Team alle fachlichen Anforderungen untereinander. Wir nehmen eine Anforderung als Referenz und geben ihr willkürlich eine relative Aufwandsbewertung von 5 Punkten. Alle anderen Anforderungen werden nun nacheinander mit dieser Zahl verglichen. Im Februar 2014 habe ich schon darüber geschrieben /1/.

Das relative Schätzen funktioniert auf Aufgabenebene sehr gut. Es es ist ausreichend genau. Dadurch, dass es viele kleine Aufgaben gibt, gleichen sich Schätzfehler mit der Zeit wieder aus.

Das gleiche Prinzip können wir auch für Projekte nehmen. Wir können Daten aus der Vergangenheit nehmen und Aufwandspunkte vergeben. Dazu legen wir auch wieder eine Referenz fest: Welches Projekt steht für mittleren Aufwand? Wie stehen die anderen Projekte dazu im Vergleich?

Wenn wir vergangene Projekte betrachten, liegen uns Zahlen vor. Aber welche nehmen wir?

• gebuchte bzw. in Rechnung gestellte Personentage oder die tatsächlich bekannte Zahl?
• Personentage oder Kalenderzeit?
• Interne und externe Kosten?
• usw.

Die Werte aus der Vergangenheit helfen uns bei der Abschätzung. Zum Beispiel können Sie folgende Dinge sagen:

• Aus der relevanten Klasse von Projekten war keines kürzer als X Tage.
• Aus der relevanten Klasse von Projekten war keines länger als X Tage.
• Durchschnittlich dauert diese Art von Projekten von X bis Y Tage mit einer Varianz von Z.
• Der Fehler zwischen Vorhersage und tatsächlichen Werten beträgt von X bis Y Prozent.

Sie lernen aber noch mehr. Nehmen wir an, das Team stuft Projekt A aufwändiger als Projekt B an, obwohl in beiden die gleiche Anzahl an Personentagen abgerechnet wurde. Gemäß der Annahme von Ward und Daniel, dass Software nur einen Nutzen bringt, wenn sich Arbeitsweisen im Unternehmen ändern /2/, müsste es eine Rolle spielen, wie viele Anwender und Geschäftsprozesse von der neuen Software betroffen sind. Das bedeutet, dass in Projekt A mehr Anwender betroffen sein könnten als in Projekt B. Vielleicht ist auch die Zahl der Geschäftsprozesse unterschiedlich.

Die Art der Geschäftsprozesse müsste aus meiner Sicht ebenfalls eine Auswirkungen haben. Kernprozesse laufen häufiger ab. Da gibt es mehr Ausnahmen und damit mehr zu testen. Zudem sind die Anwender bei den Kernprozessen viel vorsichtiger, wenn es um Änderungen gibt.

Tatsächlich bestätigt die Literatur diese Annahmen. Chiara Francalanci vom Polytechnikum Mailand hat 2001 Projekte zur Einführung von SAP-R/3-System ausgewertet /3/. Darin schreibt sie zum Beispiel:

• Die einzelnen Module haben eine größere Auswirkung auf den Gesamtaufwand als das Gesamtsystem /3, S. 41, linke Spalte, Absatz 3/. Das muss so sein, weil die Auswertung der Projekte auf Modulebene statistisch bessere Werte liefert. Wenn man nur den Gesamtaufwand betrachten würde, wäre die Streuung der Werte zu groß. Aber das ist so, weil es eben unterschiedliche Geschäftsprozesse sind. Wenn sie keine Rolle spielten, müssten Gesamtaufwand und Summe der Teilaufwänden von den gleichen Variablen abhängen. Das tun sie aber nicht.
• Die Zahl der Anwender pro Modul spielt eine größere Rolle als die Gesamtzahl der Anwender /3, S. 41, rechte Spalte, Absatz 2/.
• Bei den Kernprozessen ("mission critical work") bedeuten mehr Anwender auch mehr Nachprogrammieraufwand /3, gleiche Stelle/.

Relatives Schätzen auf Projektebene sollte funktionieren. Es ist besser, je mehr Projekte man als Vergleich heranziehen kann. Ich würde mindestens 5 Projekte als Vergleich heranziehen.

Um Projekte relativ zu schätzen, sollte das Team folgende Punkte berücksichtigen:

Aufwandstreiber:

• Wie viele Anwender sollen mit der neuen Software ihre Arbeitsweise ändern?
• Welche Geschäftsprozesse sind von der neuen Software betroffen? 
• Sind dies Kernprozesse?

Unsicherheitstreiber (nach Shenhar/Dvir):

• Hat der Kunde, haben die Anwender schon ein vergleichbares System im Einsatz?
• Wie gut kennt sich das Team mit den Technologien aus, die im neuen Projekt zum Einsatz kommen sollen? Wie gut kannte es sich bei den Vergleichsprojekten damit aus?
• Wie stark ist die Abhängigkeit von anderen Lieferanten oder Abteilungen?
• Wie hoch ist der echte Zeitdruck?

Die Aufwandstreiber geben einen Hinweis auf die zu erwartende Anzahl der Personentage (im Vergleich zu den anderen Projekten). Die Unsicherheitstreiber geben einen Hinweis auf die Puffer, die ich wegen der Unsicherheit einplanen muss, um rechtzeitig fertig zu sein.

Letztendlich ermitteln Sie damit nicht die Kosten für das Projekt, sondern ein realistisches Budget, das der Kunde für sein Projekt einplanen sollte. Hinzu kommt für den Kunden der interne Aufwand. Für SAP-Projekte habe ich bei Zahrnt /4, S. 183/ das Verhältnis von 1 Beratertag zu 1,6 interne Tage gefunden. Das Projekt sollte dafür sorgen, den 2-3fachen Wert wieder einzuspielen. Rechnen wir das mal durch:

• 25 Beratertage à 1.000 EUR (25.000 EUR)
• 40 interne Tage à 500 EUR (20.000 EUR)
• Summe: 45.000 EUR

Um zu bewerten, ob Ihr Preis von 25.000 EUR ein gutes Angebot ist, sollte sich der Kunde fragen, wie wahrscheinlich es ist, dass er nach dem Projekt 90 - 135 Tausend EUR in einer angemessenen Zeit einspielt.

Nutzen Sie doch mal die nächste Teamsitzung dazu, um Referenzklassen für Ihre Projekte bilden.

Anmerkungen

• /1/ Jan Fischbach: Wann sind Sie mit der Arbeit fertig? Wie man seine Abarbeitungsgeschwindigkeit (velocity) ermittelt?, Teamworkblog, erschienen am 01. Februar 2014, abrufbar unter http://www.teamworkblog.de/2014/02/wann-sind-sie-mit-der-arbeit-fertig-wie.html
• /2/ Ward, John ; Daniel, Elizabeth: Benefits Management : Delivering Value from IS and IT Investments. 1. Auflage. New York: Wiley, 2006.
• /3/ C. Francalanci. Predicting the implementation effort of ERP projects: empirical evidence on SAP/R3. Journal of Information Technology, 16:33–48, 2001.
• /4/ Zahrnt, Christoph: IT-Projektverträge: Erfolgreiches Management. 1. Aufl.. Ort: dpunkt.Verlag, Heidelberg, 2009