Wird mein Projekt so viel kosten wie die Pazifikküste lang ist?

Das Schätzen im (Software-)Projektgeschäft ist eine gefürchtete Disziplin. Mit einer Schätzung übernimmt man Verantwortung, für den Verkaufserfolg eines noch nicht genehmigten Projekts sowie für den (kommerziellen) Erfolg eines erteilten Auftrags. Um die Unwägbarkeiten einer Schätzung sichtbar zu machen wird in Intervallen geschätzt, getroffene Annahmen werden dokumentiert und Risiken aufgeschrieben.

Ein Intervall soll dabei den Grad der Verlässlichkeit ausdrücken, der sinkt, wenn die Anzahl der zu bestimmenden Parameter steigt, bzw. das Wissen über die einzelnen Parameter sinkt. Ein gängiges und pragmatisches Intervall sollte dann eine beispielsweise 90-prozentige Sicherheit geben, dass heißt, der Schätzer ist sich zu 90% sicher, dass sein Wert in diesem Intervall liegt. Bei zehn Schätzzahlen sollten somit neun im angegebenen Intervall liegen (siehe z.B. bei aim42.org).
Ein größeres Intervall senkt aber natürlich die Brauchbarkeit der Schätzung; jeder Mitarbeiter im Projekt will aber einen guten Beitrag leisten; auf quasi-offene Intervalle kann man kein Budget errichten. Somit erfordert es ersteinmal Selbstdisziplin, sich seine eigene “Unfähigkeit” einzugestehen. Einen Test, der diese Schwierigkeit aufzeigt, hat Steven McConnell erdacht (Blog www.codinghorror.com) — der innere Projektleiter ist schon recht streng, da braucht es oft gar keinen äußeren.

Eine Frage finde ich im Kontext von Projektschätzungen besonders interessant:

(What is the) Total length of the coastline of the Pacific Ocean?

Die Länge einer Küstenlinie ist tatsächlich schwer zu schätzen, da – tatsächlich – kein absoluter Wert dafür existiert (siehe Coastline paradox auf Wikipedia). Für die Länge einer Küstenlinie gibt es tatsächlich nur Näherungen, die vom angewendeten Maßstab abhängen – je kürzer der Maßstab, desto länger die Küste.

Granularität spielt hier (wie bei der Küstenlinie der Maßstab) eine entscheidende Rolle. Am Anfang ist die Schätzung mehr oder weniger 'en bloc', es gibt vielleicht eine grobe Aufteilung, aber auch die nicht explizit. Danach kommen Schätzungen im Team, die grobe Arbeitspakete bereits konkret beschreiben. Oft unter Zeitdruck werden wesentliche, z.B. integrative, Aufgaben übersehen – die Schätzung für das Gesamtprojekt sinkt massiv – bei kleinerem, aber in diesem Falle leider trügerischem, Schätzintervall.

Mit höherer Detaillierung der Schätzung, möglicherweise schon im Projektverlauf, kommt dann ein anderer Effekt ins Spiel: Die Aufgaben werden sehr detailliert und kleinteilig, ein gewisser Grundumsatz bei einem einzelnen Schätzpunkt, 1h, 2h, oder ein halber Tag wird minimal, “sicherheitshalber”, angenommen, auch wenn nur eine Konfigurationsdatei geändert werden muss. Als Folge steigt der geschätzte Aufwand wieder an, über das Ziel hinaus.

Was daraus folgt: Nach der ersten Expertenschätzung die Architektur dokumentieren, die Projektphasen (Test, Installation etc.) im Verlauf durchdenken, Aufwände aller Stakeholder abklären etc.
Dadurch können Lücken in der Schätzung und damit ein zu geringer angenommener Aufwand vermieden werden. Ab einer gewissen Größe der Schätzpunkte bringt dann aber eine Aufteilung keinen Mehrwehrt; so wie es nichts bringt, eine Küstenlinie mit einem Metermaßstab abzumessen. Diese Problematik adressieren auch agile Methoden wie Scrum, die sehr stark darauf fokussieren, zum richtigen Zeitpunkt die richtige Granularität eines Werkstücks zu betrachten und solche Schlangenkurven zu vermeiden.

Danke an Peter Hruschka und Gernot Starke, bei deren Seminar "IMPROVE" ich viele gute Anregungen zum architekturellen Projektmanagement mitnehmen konnte.