Aufwandsschätzung

Mit System oder Bauchgefühl?

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

Nicht nur für uns Ingenieurbüros, sondern für fast alle Unternehmen sind Aufwandsschätzungen ein notwendiges Übel. Wie sonst soll man entscheiden können, ob eine Produktentwicklung kommerziell Sinn macht? Wie sonst soll man wissen, bis wann das Produkt fertig entwickelt ist, wann es auf den Markt kommt?

Es ist immer schwierig, den Aufwand richtig abzuschätzen. Ganz besonders, wenn man etwas Ähnliches noch nie gemacht hat oder wenn dem Produktmanager oder dem Kunden noch gar nicht ganz klar ist, was am Ende genau herauskommen soll.

Schätzungen entstehen oft unter Zeitdruck und auf gut Glück. Nicht selten wünscht sich der Schätzer sehnlichst einen Hellseher zu Hilfe, der durch etwas Magie der Schätzung auf die Sprünge hilft und die Ungenauigkeit einer Kalkulation entschärft… Denn meist fällt es auch erfahrenen «Gurus» schwer, nur mit Bauchgefühl zu erwartende Aufwände korrekt zu beziffern. Ist also Schätzung wirklich nur Zufall oder doch eher ein Handwerk?

Wir denken, dass es sich um ein Handwerk handelt, deshalb haben wir Vorgehensweisen für solche Handwerker aufgeschrieben.

Ab wann lohnt sich eine systematische Schätzung?

Für Ingenieurfirmen wie Solcept können schon Fehlschätzungen von 10% bei Fixpreis-Projekten existenzbedrohend sein. In der Produktentwicklung können sie zu Verlusten durch späten Markteintritt, falsche Allokation der Entwicklungsressourcen oder zu schlechter Qualität durch eine überhastete erste Auslieferung führen.

Auch wenn im Projekt hochentwickelte Technologien eingesetzt werden, ist die Schätzung ein Handwerk, das es erlaubt den Aufwand, zwar nicht ganz exakt, aber doch systematisch und meist genau genug zu kalkulieren. Wenn man es richtig macht, kann man im gleichen Schritt gerade auch die Risiken des Projekts erfassen.

Solcept hat seit der Gründung auf systematische Schätzungen gesetzt und ist als Ingenieur-Boutique auf gute Planung angewiesen. Wir machen für jedes Projekt eine systematische Aufwandsschätzung. Schon für Projektumfänge von ein bis zwei Personenmonaten zahlt sich dies aus.

Das Wichtigste dabei ist der Denkprozess, der bei der detaillierten Auseinandersetzung mit dem zukünftigen Projekt stattfindet. Denn ein Plan wird im Lauf eines Projekts immer angepasst – dank der Übersicht aus der Planungsphase können wir später sehr viel flexibler und gezielter auf Änderungen reagieren.

Was ist der grundsätzliche Ablauf?

Es gibt ziemlich viele Schätzmethoden, vor allem für Software, z.B. in [R. D. Stutzke: «Estimating Software Intensive Systems», 2005, ISBN 0-201-70312-2]. Davon sind viele sehr aufwändig, komplex oder beruhen auf Erfahrungen aus Gebieten ausserhalb der embedded Entwicklung.

Was wir brauchen, sind Methoden, welche relativ einfach in der Handhabung ist und die sich gut für verschiedene Projekte von der Fritteusensteuerung bis zum Luftfahrtsensor anwenden lassen. Die hier beschriebenen Methoden haben gemeinsam, dass sie relativ einfach in der Anwendung sind und mit wenig A-Priori Wissen oder Branchen-Projektdaten auskommen.

Bei Entwicklungsprojekten, ob intern oder extern geht es am Ende immer um Geld und Termine. Wir schätzen daher den Aufwand in Stunden, weil diese Stunden einfach in monetären Aufwand und in Termine umzurechnen sind, im Gegensatz z.B. zu Komplexitätsmassen wie Story Points.

Das Grundprinzip und damit das grobe Vorgehen ist bei allen Aufwandsschätzungen gleich, egal, welche der beiden Methoden man anwendet:

1. Das Projekt wird in kleine und damit genauer schätzbare Pakete aufgeteilt. Damit nichts vergessen geht, werden diese entlang sinnvoller Strukturen gegliedert. Am effizientesten ist es, wenn diese Strukturen immer möglichst ähnlich und dadurch wiederverwendbar sind.
2. Dann werden die Aufwände für die einzelnen greifbaren Pakete geschätzt. Dazu werden bewährte Methoden verwendet, um Expertenwissen optimal zu nutzen.
3. Die Schätzresultate werden zusammengezählt, so dass die Summe auch die Unsicherheit der Schätzung als Reserve abbildet. Dazu werden verschiedene Modelle für die Unschärfe verwendet.
4. Zusätzlich werden nun noch mögliche Risiken und ihre Eintreffenswahrscheinlichkeiten geschätzt.

Et voilà – schon hat man eine plausible, systematische Schätzung, ohne Hellseherei und mit deutlich reduzierten Fehlern.

Der Unterschied zwischen den Kalkulationsmethoden liegt vor allem in der Art der zu schätzenden Teilpakete und ihrer Struktur. Ist die Spezifikation noch ungenau, dann ergibt sich aus der Grobschätzung ein Schätzbereich, der für die getroffenen Annahmen gilt. Wenn das Projekt klarer ist, dann liefert die Projektschätzung eine Zahl, die gemäss unserer Erfahrung 10% bis 20% Abweichung vom realen Projektaufwand hat.

In jedem Fall ist es essentiell, vorab ausgiebig mit allen Interessenten am Projekt, mit Produktmanagement, Kunden, Service etc. zu sprechen, um zusätzlich zum Lastenheft so viele weitere Informationen wie möglich zu erhalten – auch diejenigen zwischen den Zeilen.

Wann verwendet man welche Schätzmethode?

In der Praxis ist es sehr oft so, dass für ein Projekt beide Arten von Schätzungen zum Zug kommen.

Zu Beginn, wenn noch wenig Information da und das Projekt nur grob spezifiziert ist, wird die Grobschätzung verwendet (auch ROM-Estimation (Rough Order of Magnitude: grobe Grössenordnung)), also eine Schätzung, welche einen groben Bereich für den Aufwand liefert. Für solche Schätzungen von noch wenig spezifizierten Projekten verwenden wir eine Methode, welche das Projekt nach Funktionen gliedert.

Macht das Projekt nach der Grobschätzung kommerziell Sinn, führen wir eine System Design Phase durch, in der in gegenseitiger Absprache mit dem Produktmanager Lasten- und Pflichtenheft und vor allem auch erste Lösungsansätze und -varianten entstehen. Zum Beispiel werden die Schlüsseltechnologien und -komponenten ausgewählt. Daraus lässt sich eine Projektstruktur mit allen Arbeitspaketen erstellen, um das beabsichtigte Produkt zu entwickeln. Diese Struktur ist dann die Grundlage für die genauere Projektschätzung.

Die Projektschätzung lässt sich mit kleinen Abwandlungen auch für Projekte verwenden, welche keine Produktentwicklungen sind, die Grobschätzung ist stark auf die Funktionen eines Produkts (Soft- und Hardware) fixiert und lässt sich daher ohne Anpassungen nur für die Abschätzung von Entwicklungen verwenden.

Da auch wir immer besser werden möchten, geben Sie unten bitte Kommentare, Ideen, Vorschläge und Fragen ein. Ich werde sie dann in eine nächste Version einfliessen lassen.

Andreas Stucki

Haben Sie zusätzliche Fragen? Haben Sie eine andere Meinung? Wenn ja, mailen Sie mir oder kommentieren Sie Ihre Gedanken unten!