Richtig schätzen

Das Dilemma mit der Schätzung

Leider gehört es fast zum Branchenstandard Budgets und Zeitpläne in Softwareentwicklung zu überziehen. Oft werden bereits in der Angebotslegung unhaltbare Zusagen auf Basis schlechter Schätzungen gemacht. Dies gilt auf jeden Fall bei sequentiellem Projektmanagement (Wasserfall-, V-Modell, etc.), wenn es sich um Festpreisangebote handelt. Oder es werden überhaupt keine Schätzungen durchgeführt und das Angebot wird „Daumen mal Pi“ angefertigt.
Sogar bei agilen Softwareprojekten wird meist vor der Beauftragung ein sinnvolles Budget festgelegt und eine Roadmap erstellt. Die Basis dafür ist eine Aufwandschätzung, die vor der Detailspezifikation durchgeführt wird. Was glauben Sie wie groß die Unsicherheit in dieser Schätzung ist?

Kampf dem Konus und der Wolke

Zu Projektstart beträgt die Unsicherheit der Schätzung (Aufwand, Budget, Dauer, Anforderungen) den 16-fachen Wert verglichen zum Projektende. Nach 30% der Projektdauer reduziert sich diese Unsicherheit von 16-fach auf 1,5-fach (vgl. Boehm).
Dieser Reduktion der Unsicherheit wirkt jedoch der Requirements Creep entgegen, der ca. 1,5% bis 3% pro Monat der Projektlaufzeit beträgt. Wenn man „schlechtes“ Projektmanagement betreibt, bildet sich daher eine Art „Wolke“. Statt einer Verbesserung ergeben sich Schwankungen in der Unsicherheit auch während des Projekts. Daher sollten zwei Dinge beachtet werden: einerseits ist es sehr wichtig bei der Schätzung die Mechanismen zu kennen, die sich positiv und negativ auf die Unsicherheit auswirken. Andererseits ist es eine Kernaufgabe des Projektmanagements, schleichenden Funktionszuwachs unter Kontrolle zu halten. Dies gilt sowohl bei sequentiellem, als auch bei agilem Vorgehen.
Folgende Mechanismen wirken sich auf Schätzungen aus: 

• Parkinson Regel
• Größennachteil
• Gesetz der großen Zahlen
• Requirements Creep
• Conway’s Law
• Brook‘s Law
• Studentensyndrom
• Politische Einflüsse
• Yesterdays Weather Principle
• Konus der Ungewissheit
• Garbage in Garbage out Principle
• Beobachtungsfehler: Oberserver Bias, Expectancy Bias, Selection Bias, Response Bias
• Wahrnehmungsfehler: Anchoring, Halo / Horns Effect, Bandwagon Bias, Emerging Preferences
• Unkalibrierte SchätzerInnen
• Einflüsse durch das Schätzverfahren

Gerne erzählen wir Ihnen bei Kaffee und Kuchen oder in einem Seminar mehr zu diesem Thema und wie man positive Mechanismen nutzen und negative vermeiden kann.

Unser Ansatz zur Schätzung

Wir sind uns als Softwarehersteller dieser Zusammenhänge bewusst. Wir versprechen Ihnen immer die Wahrheit über unsere Einschätzungen zu sagen. Durch den frühen Einsatz von geeigneten Aufwandschätzverfahren können wir schon vor Projektstart fundierte Aussagen über Kosten und Projektdauer zu tätigen. Unser DAGσPERT Verfahren, das Sie bei der Angebotslegung einsetzen können, ist eine Kombination bewährter Schätztechniken. DAGσPERT basiert auf Microsoft Excel und bedeutet: Delphi Aufwandschätzung für Gruppen unter Verwendung der Standardabweichung σ und der Program Evaluation and Review Technique.

DAGσPERT zum Gratis-Download

Eine kostenlose Version von DAGσPERT finden Sie hier, im Rahmen von individuellen Coachings erhalten Sie übrigens eine Version mit erweiterter Funktionalität. Oder laden Sie weEstimate, die smartsized Version von DAGσPERT, auf Ihr iPhone.
Wir unterrichten Aufwandschätzung für IT- und Softwareprojekte seit einigen Jahren an der Fachhochschule Technikum Wien. Dies sorgt neben unserer Praxiserfahrung auch für einen entsprechenden theoretischen Background. Vielleicht möchten Sie im Rahmen eines Seminars mehr über Schätzung erfahren? Gerne bieten wir Ihnen individuell auf Ihre Aufgabenstellung maßgefertigte Trainings an.
Das CSS Softwareteam wünscht gutes Gelingen bei Ihren Schätzungen – und mögen Sie beim Wort „Orakel“ künftig eher an eine Datenbanklösung denken als an Kaffeesud-Lesen für Ihre nächste Softwareprojekt Schätzung!