Was sollte man bei Aufwandsschätzungen beachten?

Lesezeit 5 min

Die Strasse scheint in der Weite zum Horizont schmaler, die Aufwandsschätzung leider nicht, sie wird in der Weite der Zukunft breiter...

"Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen" Dänisches Sprichwort

Wir sehen immer wieder, dass das Thema Aufwandsschätzung zu Diskussionen zwischen Entwicklern, Projektleitern und Management führt. Daher haben wir hier unsere Gedanken und Erfahrungen zu diesem Thema "für Manager", d.h. für die Konsumenten solcher Zahlen zusammengefasst:

Die Durchführung der eigentlichen Schätzung ist hier nicht das Thema, dafür haben wir eigene Blogseiten für das Projektteam:

Wieviel Vertrauen hat die Schätzung verdient?

Meist ist eine Schätzung von Entwicklungsaufwänden und vor allem Entwicklungskosten einfach eine Zahl, welche für die Planung gebraucht wird, d.h. als Grundlage von Entscheiden. Die Zahl kann gebraucht werden als Grundlage für eine Kostenrechnung, als Grundlage einer Time-to-Market Planung oder gar, um die Investition in die Produktentwicklung vor dem Verwaltungsrat oder Investoren zu rechtfertigen.

Leider hat diese eine Zahl eine Geschichte. Dieser Hintergrund wirkt sich auf das Vertrauen aus, welches man in die Zahl haben kann. Das Vertrauen hängt von zwei Faktoren ab: 

  • Informationsstand zum Zeitpunkt der Schätzung: Was war zum Zeitpunkt der Schätzung vom Projektziel schon bekannt: nur eine Produktidee oder bereits alle Details eines kompletten Lasten- oder Pflichtenheftes?
  • Schätzmethodik und damit auch Schätzaufwand, der getrieben wurde: Wurde die Schätzung von einer Person einfach so als Zahl in den Raum gestellt oder gab es eine strukturierte Schätzung, z.B. nach einer dieser Schätzmethoden?

Es wäre also angemessen, die Zahl mit einem Disclaimer zu versehen, der aussagt:

  • wie gut man der Schätzung vertrauen kann
  • für welche Entscheide man sie verwenden sollte
  • für welche Entscheide es sich anbieten würde, die Schätzung zu verifizieren und zu verbessern

Wenn der Geschäftsleiter z.B. die erste, intuitiv optimistische Schätzung vom Produktmanagement-Workshop für seinen Business Case verwendet, dann kann er fast sicher sein, dass er mit einem um Faktoren höheren Budgetnachtrag nochmals eine Präsentation halten darf...

Daher lohnt es sich, vor der Verwendung des Projektaufwandes in Entscheiden nachzufragen, woher die Schätzung kommt, wie sie entstanden ist und auf welchem Informationsstand sie beruht. Und es auch auszuhalten, wenn der neue Informationsstand eine Schätzung hervorbringt, bei der der Business Case nicht mehr so rosig aussieht. Wobei sich dann die Frage stellt, ob es nicht besser ist, dass jetzt eine realistischere Schätzung auf dem Tisch liegt als später eine massive Budgetüberschreitung?

Wie "genau" können Schätzungen überhaupt sein?

Cone of Uncertainty (Trichter der Unsicherheit)

Eine Schätzung ist immer mit Unsicherheit behaftet. Je weiter weg z.B. das Ende des abzuschätzenden Projektes liegt, desto grösser ist die Unsicherheit, d.h. die rechte Öffnung des Trichters. Was heisst das nun für die Planung? Einen Teil der Unsicherheit kann man mit systematischer Schätzung einfangen. Den Rest kann man einerseits in die Planung einbeziehen, andererseits kann man nach einiger Zeit eine neue Schätzung machen, welche dann genauer sein sollte.

Woher kommt dieser Trichter?

Der Grund für diesen Trichter sind die Risiken, welche in jedem Projekt stecken:

  1. Risiken des Projektumfangs ("Scope"): was gehört zum Projekt und was nicht (welche Features, welche Schnittstellen, welche Normen...)
  2. Technische oder allgemeiner Realisierungsrisiken: was alles nicht funktionieren kann
  3. Abschätzungsrisiken: generelle Schätzfehler, meist ist der Mensch zu optimistisch...

Die Risiken, welche das Projekt beinhaltet, ergeben auch die Öffnung des Trichters nach hinten: je weniger Risiken ein Projekt birgt, desto genauer kann ich schätzen.

Schätzung oder Versprechung?

Viele Schätzungen beginnen ihr Leben als dahingeworfene Zahl an einer Sitzung, als erste Grössenordnung, meist mit grossem Optimismus. Diese Zahl sollte nicht als Versprechen für den Aufwand des Projektes genommen werden.

Wenn wir als Solcept wirklich ein Versprechen abgeben (z.B. wenn wir einen Fixpreis anbieten), dann treiben wir ziemlich viel Aufwand, um eine genügende Genauigkeit zu erreichen, z.B. führen wir eine System Design Phase durch und eine strukturierte Schätzung.

Wieso tun wir das? Weil wir damit die Risiken eingrenzen:

  1. Umfangsrisiken: eingegrenzt mit klaren Anforderungen
  2. Technische Risiken: eingegrenzt mit Architektur und Rapid Prototypen
    die restliche Risiken werden identifiziert und sind Bestandteil des versprochenen Umfangs (genannt "Risikomanagement")
  3. Abschätzungsrisiken: eingegrenzt mit strukturierter Schätzmethodik

Wie gehen wir bei Solcept vor?

Wenn Sie am Anfang eines Projektes doch schon eine Schätzung haben möchten, dann führen wir eine Grobschätzung durch, basierend auf den gewünschten Funktionen oder Annahmen darüber und unseren Erfahrungswerten für Dokumentation, Test und Integration.

Nach der System Design Phase, in der eine Systemspezifikation und eine Systemarchitektur entstehen, können wir eine Projektschätzung durchführen, zumindest über den Teil, der schon klar ist. Diese ist bedeutend genauer. Jede nächste Phase kann dann so geschätzt werden, sobald der Umfang der Phase (d.h. die Anforderungen, welche das Produkt nach der Phase erfüllen soll) klar ist.

Wieso stimmen Schätzungen "nie"?

Es gibt verschiedene Gründe, wenn Schätzungen "nie" stimmen:

  • Verschärftes Parkinsonsches Gesetz: Es gibt das Gesetz von Parkinson: "Work expands so as to fill the time available for its completion" ("Arbeit dehnt sich in genau dem Maß aus, wie Zeit für ihre Erledigung zur Verfügung steht"). Wenn die Führung Verfechter dieses Gesetzes in seiner verschärften Form ist: "...also bewilligen wir aus Prinzip nur einen Drittel der Schätzung", dann ist es klar, dass die Schätzungen nie stimmen können.
  • Schlechte Schätzmethodik: Viele Organisationen machen keine strukturierten Schätzungen.
  • Optimismus-Schätzung: Die Organisation bleibt an der erste Zahl hängen, die z.B. im Produkt-Workshop genannt wurde.
  • Vorgabe statt Schätzung: Die Schätzung ist schon als Vorgabe bekannt ("für den Preis wurde es verkauft").
  • Nicht genug Ressourcen: Für eine Schätzung stehen nicht genügend Experten und v.a. nicht genügend Zeit zur Verfügung.
    • Unsere Erfahrung zeigt, dass für eine belastbare Projektschätzung ca. 1% des nachmaligen Projektaufwandes gerechnet werden müssen.
      Sie sagen nun: dass ist zuviel, nur für eine Schätzung! Und da haben Sie vollkommen Recht, denn es entstehen bei der Projektschätzung als weitere Resultate auch gerade die Planungsgrundlage für das Projekt, nämlich alle Aufgaben (Work Breakdown Structure/ Projektstrukturplan) und die erste Liste aller Risiken

Nehmen Sie nie ein Abschätzung (ob intern oder von exterenen Lieferaten) einfach als Zahl hin, sondern hinterfragen Sie diese: ist es ein Wunsch, eine wirklich fundierte "bottom-up" Abschätzung oder eine politisierte Zahl?

Andreas Stucki

Was ist Ihre Meinung? Bitte kommentieren Sie hier!

Stichworte/ Tags

Kommentare

Keine Kommentare

Was ist Ihre Meinung?

* Diese Felder sind erforderlich

Teilen auf

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren