Aufwandsschätzungen sind Verhandlungen

Soll eine Software erstellt werden, kommt es zuerst zur Aufwandsschätzung. Diese mag zwar oft wie eine Berechnung wirken, doch im Grunde ist sie der Versuch zu erraten, wie hoch der Aufwand am Ende ausfallen wird.

Der Aufwand einer Aufgabe hängt maßgeblich von ihrem Umfang und ihrer Komplexität ab. Doch gerade die Komplexität lässt sich kaum abschätzen. Sie wird systematisch unterschätzt, da wir (Menschen) gedanklich zu Vereinfachungen und Verallgemeinerungen neigen.

Die Komplexität ist auch konzeptionell nicht vollständig auflösbar. Dafür müsste sie weiter konkretisiert werden. Mit jeder Stufe der Konkretisierung wird die verbleibende Unsicherheit geringer. Versucht man diese auf ein Minimum zu reduzieren, müsste man alle Funktionen bis zur Ausführungsebene herunter brechen. Programmcode repräsentiert Funktionen auf Ausführungsebene. D.h. Programmcode ist bereits die tiefste Konzeptionsebene. Geht man jedoch so tief hat man die Arbeit eigentlich getan. Man muss aus Gründen der Wirtschaftlichkeit relativ früh abbrechen und unterschätzt damit den Aufwand zwangsläufig.

Wie gut eine Aufwandsschätzung ist und wie nah sie an dem später tatsächlich angefallenen Aufwand liegt, hängt von der Erfahrung des Entwicklungsteams ab. Erfahrene Teams kennen ihren Faktor, den sie aufschlagen müssen, um diesen Effekt weitestgehend zu kompensieren.

Verhandlung

Eine Aufwandsschätzung ist fast immer Grundlage eines Preises. Dieser fließt in eine Verhandlung mit dem potentiellen Auftraggeber ein. Der eigenen Schätzung stehen möglicherweise andere Schätzungen weniger erfahrener Teams oder Dienstleister entgegen, die deutlich geringer ausfallen können. Es kann aber auch sein, dass der zu erwartende Mehrwert der Software für den Auftraggeber nur einen sehr begrenzten Spielraum für die Kosten zulässt. Es gibt viele Faktoren, die in eine Preisverhandlung einfließen.

Schnell ist der Punkt erreicht, an dem die eigene Aufwandsschätzung als „zu hoch“ eingestuft wird. Ihre „Berechnung“ wird dann schnell in Frage gestellt. Zuerst werden die „nice to have“ Features gestrichen, die keinen hohen Mehrwert liefern. Ab einem gewissen Punkt kann man keine Funktionalität streichen. Erfahrungswerte wie der obligatorische Aufschlag von 200% auf die unterschätzte Komplexität müssen dann weichen. Hohe Aufwände werden selbst intern noch einmal in Frage gestellt und müssen einem Zweckoptimismus weichen.

Die Aufwandsschätzung wird zum Spielball der Verhandlungsparteien.
Sie wird selbst zur Verhandlung.

Die Konsequenzen liegen auf der Hand. Die Realität holt früher oder später alle ein. Zum Fertigstellungszeitpunkt wird mit hoher Wahrscheinlichkeit eine unvollständige Software vorliegen. Es kommt vermutlich zu Nachverhandlungen und einer angespannten Situation für alle beteiligten.