Gut geschätzt ist halb gewonnen

Eine der wesentlichen Voraussetzungen für die Projektplanung ist die Aufwandschätzung. Da der Endtermin eines Projekts in der Regel zum Auftragszeitpunkt bereits vorgegeben ist, berechnen sich aus der Aufwandschätzung die Kosten sowie die zur Erreichung des Endtermins erforderliche Teamgröße.

Wenn die Aufwandschätzung nicht zutrifft, ist eine Schieflage im Projekt kaum vermeidbar.

Lassen Sie mich mit einer Anekdote aus meiner Zeit als frischgebackener Projektmanager beginnen. Im Rahmen eines Angebotsprozesses brachte ich mehrere Tage damit zu, aus einem groben Anforderungsdokument heraus die Arbeitspakete zu definieren, zu schätzen, mit Experten zu diskutieren und penibel zu planen. Stolz präsentierte ich das detaillierte Excel-Sheet dem zuständigen Senior Projektmanager. Der würdigte es keines Blickes, ließ sich stattdessen in 10 Minuten den Projektinhalt schildern und rechnete dann: „Hm, in 6 Monaten sollst Du fertig sein. Für das Projekt brauchst Du somit ein Team mit 3 – nein, mit 4 Leuten. 6 Monate mal 4 Personen = knapp 500 Personentage – wieviel hast Du ausgerechnet?“

Unsere Zahlen lagen weniger als 10 Prozent voneinander entfernt.

Das ist fast 10 Jahre her.

Seitdem habe ich unterschiedliche Schätzmethoden bewusst(er) angewendet. Über meine persönlichen Erfahrungen mit den von mir eingesetzten Methoden möchte ich im Folgenden berichten. Es geht mir dabei nicht darum, die Schätzmethode so zu beschreiben, dass der Leser sie anwenden kann – dafür sei auf einschlägige Literatur verwiesen.

Richtung

Zunächst unterscheidet man bei Schätzungen die beiden grundsätzlichen Ansätze „Top Down“ oder „Bottom Up“.

Top Down

Der Top Down-Ansatz findet häufig Anwendung, wenn sich noch gar keine sinnvollen Arbeitspakete bilden lassen, z. B. weil der Projektauftrag noch zu unspezifisch ist. Hierbei wird das Vorhaben zunächst in grobe Teile zergliedert – häufig nach den Projektphasen (Konzeption, Entwicklung, Test) – und diese dann mit einem der weiter unten genannten Verfahren geschätzt.

Meine Erfahrung: Die Größenordnung des zu erwartenden Aufwands lässt sich mit einer Top-Down-Schätzung auf hohem Abstraktionslevel sehr schnell, aber auch nur grob abschätzen. Für eine Bewertung, ob ein Projektvorhaben realisiert werden soll, oder eine Gegenprobe zu einer Bottom-Up-Schätzung ist das Verfahren geeignet.

Bottom Up

Mir ist meist der Bottom-Up-Ansatz begegnet. Hierbei zerlegt man das Projekt in granulare Arbeitspakete („Work Breakdown Structure“) und versucht, den Aufwand für diese überschaubaren Pakete zu bewerten. Der Gesamtaufwand ergibt sich aus der Summe der Einzelaufwände.
Der Bottom-Up-Ansatz ist sehr beliebt, da die Genauigkeit recht hoch ist.

Meine Erfahrung: Meine Beobachtung ist, dass die Einzelschätzung von Arbeitspaketen im Bereich von 5 bis maximal 20 Personentagen (PT) häufig sehr gut ist.

Die von den Teammitgliedern „gefühlte Genauigkeit“ wird zwar sogar noch höher, wenn die Arbeitspakete feingranularer werden, allerdings steigt dann das Risiko, dass Pakete übersehen werden, so dass die Schätzgüte insgesamt nach meiner Beobachtung bei noch kleineren Paketen nicht weiter zunimmt.

Bei Arbeitspaketen größer als 20 PT sind hingegen die Schätzabweichungen der Pakete verhältnismäßig hoch, weil häufig zu viel versteckte Komplexität übersehen wird.

Beim Bottom-Up-Ansatz besteht nach meiner Beobachtung ein relativ hohes Risiko, dass Arbeitspakete komplett übersehen werden.

Unabhängig von der Richtung, aus der man sich der Schätzung nähert, wird man an einem gewissen Punkt ein Arbeitspaket mit einem Aufwand versehen müssen. Dazu gibt es verschiedene Verfahren, die nachfolgend vorgestellt werden.

Schätzverfahren

Vergleichende Verfahren (analoge Schätzungen)

Bei analogen Schätzungen verwendet man Erfahrungen aus vergangenen Projekten für die Schätzung des aktuellen Vorhabens. Das analoge Verfahren kann auf unterschiedlichen Detaillevels verwendet werden (gesamtes Projektvorhaben: „für den letzten Webshop haben wir x PT Aufwand benötigt, d.h. der neue Webshop wird ebenfalls x PT Aufwand erfordern“, oder einzelne Fragmente: „die letzte Eingabemaske hat y PT Aufwand benötigt,…“).
Genaugenommen handelt es sich bei allen folgenden Verfahren ebenfalls in irgendeiner Weise um vergleichende Verfahren, da auch ein Experte bei seiner Schätzung auf seine Erfahrung zurückgreift und somit implizit einen Vergleich mit vergangenen Projekten durchführt.

Meine Erfahrung: Softwareprojekte zeichnen sich regelmäßig gerade dadurch aus, dass sie nicht gut vergleichbar sind, weil der Aufwand von sehr vielen Faktoren abhängt: vom Team, von der Technologie, vom technischen oder organisatorischen Umfeld und vielem mehr. Entsprechend habe ich analoge Verfahren nur genutzt, um Ergebnisse aus anderen Verfahren zu validieren.

Parametrische Verfahren (Messen, Zählen, Wiegen)

Bei parametrischen Verfahren wird die Anzahl von Objekten unterschiedlicher Objektklassen ermittelt und bewertet. Im Ergebnis erhält man eine Tabelle, die (vereinfacht) wie folgt aussieht:

Die Anzahl der jeweils zu ändernden Objekte ist in der Regel verhältnismäßig früh im Projektverlauf relativ gut abschätzbar. Wir unterscheiden meist zwischen „Oberflächenelement“, „Service“ und „Datenbankentität“ mit je drei bis vier Komplexitätsstufen („niedrig“, „mittel“, „hoch“ – gelegentlich „sehr hoch“) und der Unterscheidung „neu“ oder „geändert“.

Der Aufwand für die jeweiligen Objektklassen sollte als Erfahrungswert aus vergangenen Projekten vorliegen oder muss möglichst realistisch abgeschätzt werden.

Meine Erfahrung: Der Knackpunkt bei dieser Methode ist, ob eine gute Bewertung des Aufwands für die unterschiedlichen Objektklassen vorliegt. Insbesondere bei Folgeprojekten zu einem bestehenden Produkt kann dies durchaus der Fall sein, vor allem wenn man sich in den vorhergehenden Projekten die Mühe gemacht hat, nach Projektende den tatsächlichen Aufwand je Objektklasse zu ermitteln und diese Erfahrung in die neue Schätzung einfließen kann.

Mit der parametrischen Schätzung lässt sich der Projektaufwand relativ schnell in einem kleinen Team (Designer/Projektmanager) ermitteln.

Ich habe die parametrische Schätzung häufig als alleiniges Verfahren für die Schätzung genutzt – allerdings tatsächlich nur dann, wenn ich wusste, dass die Basiswerte („Aufwand je Objektklasse“) in vernünftiger Qualität vorlagen. In diesen Fällen war ich mit den Ergebnissen im Allgemeinen zufrieden.

Expertenschätzung (Fachschätzung)

Das Verfahren, welches mir am häufigsten begegnet, ist die Expertenschätzung. In der Regel befragt der Projektmanager bei diesem Verfahren das Kernteam, das für das Projekt verantwortlich ist – also die Designer, Entwickler und Tester (eben die Experten).
Es gibt hier verschiedene „Spielarten“. Man kann die Experten getrennt/geheim befragen („Standard-Delphi-Methode“) oder in einem Workshop zusammensetzen („Breitband Delphi-Methode“).

Meine Erfahrung: Die Breitband Delphi-Methode – ich nenne sie gerne „Schätzworkshop“ – hat den Vorteil, dass die Arbeitspakete aus unterschiedlichen Gesichtspunkten bewertet werden und die Expertise der einzelnen Mitarbeiter optimal einfließt.

Der Aufwand für die Ermittlung der Schätzzahlen kann allerdings relativ hoch werden. Für mittelgroße Projekte von rund 500 PT haben wir mit dieser Methode bis zu drei Tagen für eine Schätzung benötigt – mit fünf oder mehr Leuten sind da 2–3% des Projektvolumens schnell für die Schätzung „vertan“. Das Risiko, sich im Workshop in Details zu „verlieren“, ist recht hoch.

Andererseits führt die gemeinsame Diskussion auch zu einem gemeinsamen Verständnis des gesamten Projektauftrags. In der Projektdurchführung, wenn dann alle Teammitglieder an den einzelnen Aufgaben arbeiten, ergibt sich häufig nicht mehr die Möglichkeit, solch ein gemeinsames Verständnis aufzubauen. Bewertet man den Schätzworkshop nur im Hinblick auf das Ziel der Aufwandschätzung, finde ich persönlich den Aufwand, den man für den Workshop investiert, zu hoch, da die Genauigkeit des Ergebnisses häufig nicht besser ist als z. B. bei einem parametrischen Verfahren. Unter dem Gesichtspunkt des gemeinsamen Verständnisses und der gemeinsamen Entwicklung erster Lösungsideen rechtfertigt sich allerdings aus meiner Sicht der Aufwand für den Schätzworkshop.

Da das Verfahren in der Regel „Bottom Up“ durchgeführt wird, gelten die oben genannten Einschränkungen.

Messbare Verfahren (algorithmische Modelle)

Es gibt noch weitere Schätzverfahren, die ich selbst jedoch noch nicht im Einsatz erlebt oder verwendet habe. Daher verzichte ich auf eine Bewertung, möchte sie aber trotzdem hier nennen, da sie als gute Einstiegspunkte in weiterführende Literatur dienen können.

Function Point Analysis: im Wesentlichen ein stärker strukturiertes parametrisches Verfahren. Definierte Objektklassen (Eingabeschnittstelle, externe Schnittstelle, etc.) werden gezählt, gewichtet und mit einem bestimmten Wert multipliziert.

COCOMO: Es werden im Wesentlichen die erwarteten „Lines of Code“ gezählt und mit einem gewichteten Einflussfaktor multipliziert.

Methodische Tipps

Ich möchte noch zwei methodische Tipps erwähnen, die aus meiner Sicht nicht in die obige Systematik passen, aber bei der Aufwandschätzung sehr dienlich sind.

Drei-Punkt-Verfahren

Statt einer einzigen Aufwandszahl werden drei Zahlen geschätzt:

1. Der Aufwand, der mindestens für das Arbeitspaket erwartet wird: co (cost optimistic)

2. Der Aufwand, der realistisch erwartet wird: cm (cost most likely)

3. Der maximal erwartete Aufwand: cp (cost pessimistic).

Der „erwartete“ Schätzwert ce (cost expected) errechnet sich wie folgt:

ce = (co + 4 cm + cp) / 6

Beispiel: „optimistisch“ liegt der Aufwand für ein Arbeitspaket bei 25 PT, „realistisch“ bei 35 PT und „pessimistisch“ bei 87 PT.

Dann ist der erwartete Aufwand: (25 + 4 * 35 + 87) / 6 = 42 PT.

Prinzipiell ist das Drei-Punkt-Verfahren bei allen oben genannten Methoden anwendbar, häufig wird es bei der Expertenschätzung eingesetzt.

Meine Erfahrung: Ein Effekt aus dem obigen Beispiel traf bei uns recht häufig zu: optimistischer und realistischer Aufwand lagen relativ eng zusammen, während der pessimistische Aufwand relativ hoch war. Frei nach Murphy „alles was schiefgehen kann, wird auch schiefgehen“ konnten wir mit Einsatz der Dreipunktschätzung die Schätzgüte nochmals erkennbar verbessern, weil Risiken besser in die Schätzung einfließen.

Risikobewertung

Apropos Risiken: Das Risikomanagement ist eine Management-Methode, die nach meiner Beobachtung derzeit an Bedeutung gewinnt.

Im Rahmen einer Risikoanalyse können die Risiken quantitativ bewertet werden (Eintrittswahrscheinlichkeit x Schadensausmaß). Aus meiner Sicht ist es empfehlenswert, diese Risikobewertung in die Aufwandschätzung für das Gesamtprojekt einfließen zu lassen.

Beispiel: Das Risiko, einen wichtigen Mitarbeiter nicht einsetzen zu können, liegt bei 50%. Der Einsatz eines weniger eingearbeiteten Mitarbeiters führt zu 20 PT Mehraufwand. D.h. in der Planung sehe ich 50% x 20 PT = 10 PT für dieses Risiko vor.

Zusammenfassung

Als Zusammenfassung sind im Folgenden die genannten Methoden in Form einer Mindmap aufbereitet:

Ich selbst wende in der Regel zwei der genannten Verfahren unabhängig voneinander an, um die jeweiligen Ergebnisse zu validieren (oft die Expertenschätzung „Bottom Up“ und die Analogie „Top Down“).

Und auch mein Senior Manager aus dem Eingangsbeispiel war – wie wir jetzt wissen – methodisch korrekt. Er wendete ganz einfach eine Analogie auf einem sehr hohen Abstraktionslevel – nämlich dem gesamten Projektvorhaben – an.


Links, Quellen, weitere Informationen:

[1] PMBOK Guide, A Guide to the Project Management Body of Knowledge, 4th Edition, Project Management Institute (http://www.pmi.org), 2008

[2] Oliver Hummel: Aufwandsschätzungen in der Software- und Systementwicklung, Spektrum Verlag, 2011

[3] Tom DeMarco & Timothy Lister: Waltzing with bears, Managing Risk on Software Projects, Dorset House Publishing, 2013

[4] Projektmagazin: Spotlight „Wie schätze ich Aufwände“, 2012 (https://www.projektmagazin.de/spotlight/wie-schaetze-ich-aufwaende)

[5] Wikipedia Artikel zu den verschiedenen Verfahren:
http://de.wikipedia.org/wiki/Work_Breakdown_Structure

http://de.wikipedia.org/wiki/Delphi-Methode

http://de.wikipedia.org/wiki/Drei-Zeiten-Methode

http://de.wikipedia.org/wiki/Function-Point-Verfahren

http://de.wikipedia.org/wiki/Cocomo