Neulich sprach ich mit einer Bekannten darüber, wie es in ihrem aktuellen Projekt so läuft.

Sie erzählte mir, dass in ihrem Projekt eine Nachschätzung vorgenommen wurde, die zu einer Verdoppelung des Projektaufwands führte. Das hatte natürlich einige Aufregung im Management erzeugt.

(c) Shutterstock

Ich habe mich mit der Bekannten dann mal hingesetzt und das Vorgehen im Projekt Revue passieren lassen. Folgende Erklärungen für die Abweichungen zu der frühen Schätzung zum Projektstart haben wir identifiziert:

  • Schätzannahmen haben sich als nicht zutreffend herausgestellt.
  • Anforderungen haben sich im Laufe der Zeit verändert, einige sind weggefallen, deutlich mehr sind hinzugekommen.
  • Teilweise waren die Anforderungen zum Zeitpunkt der Schätzung noch sehr vage, trotzdem wurde eine Punktschätzung gemacht.
  • Manche Anforderungen waren in der Schätzung einfach nicht enthalten und so auch damals kommuniziert.
  • Im kollektiven Gedächtnis des Projektes und des begleitenden Managements ist als Ergebnis der ursprünglichen Schätzung nur die Zahl für den Gesamtaufwand hängen geblieben. Der sonstige Kontext der Schätzung ist verschwunden.

In dem betrachteten Beispiel sind gleich mehrere Dinge schiefgelaufen. — Welche? Kommunikation der Schätzung, Dokumentation der Annahmen/Rahmenbedingungen, Projektcontrolling (Aufwand und Anforderungen aka CR).

Was ist an Schätzungen eigentlich so schwierig?

Die Hauptreaktion von Vertretern des Managements ist jedoch – etwas vereinfacht – die Frage, warum war die Schätzung nicht genauer?

Was mich zu der Frage bringt: Warum ist es so schwer bei Fachfremden Verständnis, für die Genauigkeit von Aufwandsschätzungen zu wecken?

Insbesondere in frühen Projektphasen gleicht der Wunsch nach einer Aufwandsschätzung häufig dem Blick in die Glaskugel. Die Anforderungen sind nicht oder bestenfalls vage bekannt. Häufig gibt es nur Schlagworte auf Powerpoint Folien, die typischerweise von jedem im Raum anders interpretiert werden.

Das Vorhersagen der Zukunft ist gemeinhin als schwierige Aufgabe akzeptiert. Nur bei der Softwareentwicklung scheint dies nicht zu gelten. Seltsam.

Dabei hat Steve McConnel dies im Kontext der Softwareentwicklung bereits 1997 als Cone of uncertainty beschrieben. Die Forschung, die dieses Konzept untersucht hat, ist sogar noch älter. Die Unsicherheit in den frühen Projektphasen wird mit einem Faktor 4 in beide Richtungen angegeben. Das heißt der tatsächliche Aufwand kann um den Faktor vier höher sein, oder nur 1/4 der ersten Schätzungen betragen.

Welche Konsequenz ergeben sich daraus?

Alle an IT Projekten Beteiligten müssen akzeptieren, dass zu Beginn getroffene Aussagen zu Aufwänden nur sehr ungenau sein können. Dies sollte sich in den kommunizierten Aussagen widerspiegeln, d. h. die Schätzungen sollten als Spanne angegeben werden (z. B. mittlerer Wert und unteres sowie oberes Quartil).

Es ist Aufgabe des Projektmanagements, mit diesen systemimmanenten Unsicherheiten umzugehen. Im Laufe des Projekts müssen Entscheidungen darauf abzielen, die Unsicherheiten zu reduzieren, also beispielsweise den Scope festlegen, die Änderung von Anforderungen managen und den Projektaufwand verfolgen.

Warum überhaupt Schätzen?

Wenn doch die Schätzungen eh nie stimmen, warum überhaupt die Mühe machen zu schätzen?

Nun, ich finde, es gibt gute Gründe für das Schätzen in Softwareentwicklungsprojekten. Es kommt dabei auf den Zweck an, den ich verfolge.

Wenn die Schätzung Basis für eine Investitionsentscheidung ist, kann es eine hilfreiche Strategie sein, nicht in einer Big Bang Entscheidung das gesamte Budget freizugeben, sondern inkrementell vorzugehen. In der agilen Softwareentwicklung hat sich dafür der Begriff Minimal Viable Product etabliert. Also in einem ersten Schritt eine für die Endkunden nutzbare Version bauen und in Produktion bringen. Dann aus den gewonnenen Erfahrungen lernen und das Produkt schrittweise weiterentwickeln.

Wenn es um die Frage der Machbarkeit geht, kann der Vergleich mit ähnlichen Produkten eine Orientierung geben. Das Konzept von Story-Point Schätzungen agiler Softwareentwicklungsteams basiert auf dieser Idee der relativen Größenschätzung.

Was bleibt?

  1. Schätzen bleibt schwierig: Letztlich treffen wir auf Basis von Annahmen Aussagen, die mit einer gewissen Wahrscheinlichkeit eintreten oder auch nicht. Dies sollten wir allen Beteiligten immer wieder ins Bewusstsein bringen.
  2. Schätzen ist notwendig, um Entscheidungen zu unterstützen.
  3. Schätzen sollte einem definierten Zweck dienen, da wir dann die Herangehensweise auf diesen Zweck ausrichten können.

Das Vorhersagen von zukünftigen Ereignissen bleibt schwierig, dennoch müssen wir es versuchen.

Literatur

McConnell, S (2006). Software Estimation: Demystifying the Black Art. Microsoft Press. p. 38. In: wikipedia.org, 07. November 2022, https://en.wikipedia.org/wiki/Cone_of_Uncertainty#cite_note-McConnell2006_38-4, letzter Zugriff: 07. November 2022.