Feuerholz wird mit einer Axt gespalten

Wie macht man eine Projektschätzung?

Lesezeit 8 min

"Divide et impera – teile und herrsche" Gaius Julius Cäsar

Dies ist der einfachere und beliebtere Fall: zu einem Projekt sind bereits eine ausführliche Spezifikation (ein Pflichtenheft) sowie eine grobe technische Lösung (eine Systemarchitektur) vorhanden. Wenn noch nicht, dann kann man eine Grobschätzung machen.

Mehr als 100 Seiten Spezifikation und noch immer kein Kaffee?

Ein Beispiel für eine Projektschätzung war die Entwicklung einer Steuerung für eine professionelle Kaffeemaschine. Um die Kaffeemaschine mit ihrer Produktvielfalt und mit den zahlreichen Konfigurationsmöglichkeiten, Produkt- und Reinigungsprozessen, Sprachen und Wartungsoptionen einfach zu bedienen, wurde ein vollgrafischer Touchscreen spezifiziert. Daraus resultierte eine Software, die durch die vielen Abhängigkeiten zur Hardware und vor allem zur Mechanik der Maschine noch komplizierter wurde.

Die fertig ausgearbeitete Spezifikation beinhaltete mehr als hundert Seiten und dazu noch denselben Umfang an Beschreibungen der mechanischen Abläufe. Mit dieser Information war eine genauere Projektschätzung für ein Fixpreisprojekt möglich.

Das ganze Projekt bis zur fertigen Steuerung umfasste am Ende mehrere Personenjahre Arbeit. Dieses Gesamtprojekt wurde von unseren Ingenieuren am Anfang auf genauer als 10 % Abweichung abgeschätzt. Und das alles, ohne am ersten Espresso aus der Maschine auch nur gerochen zu haben ...

Was erwartet Sie?

Und auf separaten Seiten:

Wir arbeiten schon seit vielen Jahren mit dieser Schätzmethode und haben dazu eine Tabellenkalkulationvorlage entwickelt. Zusätzlich existiert für die Projektabschätzung ein Software-Werkzeug, welches wir bei genügend Interesse als Freeware anbieten, bitte kommentieren Sie unten, wenn Sie Interesse haben.

Work Breakdown Structure (Projektstrukturplan)

Wieso ein System Design?

Obschon es im engeren Sinn nicht zur Abschätzung gehört, macht es Sinn, das System Design anzuschauen. Das Resultat des System Design besteht aus einer «Black Box»-Spezifikation des Produkts und einer «White Box»-Beschreibung der Lösung. Diese beiden Dokumente müssen für eine Abschätzung nicht bis ins letzte Detail fertig sein.

Das Kriterium, ob die System Design Phase für die Projektschätzung genügend fortgeschritten ist, besteht darin, dass die offenen Punkte keine Risiken für den Aufwand mehr beinhalten. Im Umkehrschluss heisst das, dass in der System Design Phase alle mit einem Aufwandsrisiko behafteten Spezifikationen geklärt sein müssen (z.B. ob die Bedienschnittstelle einen Touchscreen hat oder nur eine Sieben-Segment-Anzeige). Dasselbe gilt für die Schlüsselkomponenten und -technologien, die ausgewählt sein müssen (z.B. Betriebssystem, Hauptprozessor). Häufig heisst dies, dass kleine Prototypen oder Piloten erstellt werden, die diese Schlüsselelemente verifizieren.

Die System Design Phase dient also einerseits dazu, den genauen Projektumfang zu dokumentieren und die Lösung grob zu skizzieren. Andererseits dient sie der Risikominderung, nicht nur von technischen, sondern auch von Kommunikationsrisiken, denn sie macht das gewünschte Resultat des Projekts für alle Stakeholder explizit klar.

Aufteilung in Arbeitspakete durch den Projektleiter

Für die Work Breakdown Structure (WBS), auch Projektstrukturplan (PSP) genannt, wird das Projekt über mehrere Ebenen in Arbeitspakete unterteilt. Wie viele Ebenen (z.B. Unterprojekt, Projektphase, Arbeitspaket) hängt stark von der Grösse, das heisst der Komplexität des Projekts ab. Für die maximale Grösse der Arbeitspakete auf der untersten Ebene sind höchstens vierzig Personenstunden anzustreben.

Diese Aufteilung in Arbeitspakete führt der Projektleiter am effizientesten allein durch. Manchmal macht es Sinn, dass einzelne Unterprojekte (z.B. Hardware-Entwicklung, Mechanik) durch die entsprechenden Fachspezialisten erstellt werden.

Phase Komponente Arbeitspaket Ergebnis Beschreibung Annahmen Verbleibende Risiken

Software Design

Modul 1 spezifiziere Modul Modulspezifikation "Black Box"-Spezifikation erstellen    
    definiere Komponenten, Package-Diagramme, Schnittstellen Modularchitektur "White Box"-Architektur erstellen Kommunikations-stacks können vom Chiphersteller übernommen werden  
    definiere Tests Testspezifikationen ersten Testplan für Tester erstellen   Testframework Kunde noch nicht klar

Ausschnitt aus einer grösseren WBS

Natürlich muss die WBS alle Aufgaben des Projekts beinhalten, inklusive Projektmanagement. Zusätzlich macht es Sinn, die Pakete nicht als reine Handlungspakete zu definieren, sondern vor allem über ihre Ergebnisse beziehungsweise Resultate. Dadurch gibt es keine Überlappung zwischen Paketen und das Kriterium für den Abschluss des Paketes ist klarer.

Eine kurze Beschreibung der Arbeitspakete ist immer hilfreich, und auch erste Annahmen und über die Schätzung hinaus verbleibende Risiken können schon dokumentiert werden.

WBS ist eigentlich ein alter Hut, die Methode wurde in den 1950er-Jahren kodifiziert und hat den Vorteil, dass die Struktur nicht nur zur Schätzung, sondern auch zur Projektverfolgung verwendet werden kann.

Projektstruktur und Projektlebenszyklus

Nun sollen also alle Aufgaben des Projektes erfasst werden. Wie stellt man das am einfachsten sicher? Hier kommt der Projektlebenszyklus ins Spiel. Wenn man einmal aufschreibt, «wie wir hier solche Projekte durchführen», hat man schon einen solchen erstellt.

Es gibt als Vorlage auch Standardzyklen wie, z.B. V-Modell, RUP (Rational Unified Process) oder Scrum. Ein solcher Projektlebenszyklus kann dazu dienen, die übergeordnete Struktur für die WBS zu liefern. Diese muss dann nur noch mit den projektspezifischen Arbeiten ausgefüllt werden.

Eine Vorlage für die Projektstruktur

Sind nun zum ersten Mal alle Teilaufgaben und Arbeitspakete eines Projekts entlang dieser Struktur erfasst, hat man gerade eine Vorlage für weitere Projekte. Man kann die Arbeiten löschen, die das Projekt nicht braucht, und neue hinzufügen.

Wenn man diese auch der Vorlage hinzufügt und zusätzlich im Projektverlauf vergessene Arbeiten nachführt, hat man mit der Zeit eine WBS-Vorlage, mit der man eigentlich gar nichts mehr vergessen kann. So ist eine wichtige Fehlerquelle, die zu Minderschätzungen führt, ausgeschaltet.

Aufwand der Pakete schätzen im Team

Wie werden nun realistische Aufwände für die einzelnen Arbeitspakete geschätzt? Hier verwenden wir Planning Poker. Planning Poker erlaubt es, das Expertenwissen effizient und ohne Befangenheit vom ganzen Team abzuholen. Dies ist auch der Grund, wieso für diese Phase möglichst das ganze Team einbezogen werden sollte. Diversität führt zu besseren Schätzungen: Manchmal ist der Einwand des Neulings berechtigt und dank Planning Poker kommt er mit seiner Meinung auch zu Wort.

Eine wichtige Aufgabe des Moderators des Planning Poker ist es, die Annahmen und verbleibenden Risiken für die einzelnen Pakete, die in der Diskussion aufkommen, direkt in der WBS zu dokumentieren. Sie werden dann für die Risikoabschätzung verwendet. Meist findet das Team auch noch Aufgaben, die bei der Erstellung der WBS vergessen gingen, auch diese werden natürlich hinzugefügt.

Zweipunktschätzung

Für die meisten Menschen ist es relativ einfach zu sagen, wie viel Zeit sie im Normalfall, das heisst im häufigsten Fall, für eine Aufgabe brauchen. Auch wie lange sie im schlimmsten Fall brauchen, ist nicht so schwer zu sagen. Wenn man beide Werte vergleicht, dann zeigt sich, wie viel Risiko der Aufgabe beigemessen wird.

Dies kann man ausnützen, indem man einen gewichteten Mittelwert bildet, der den Normalfall gegenüber dem schlechtesten Fall doppelt gewichtet. In anderen Worten verwendet man für die Planung den Wert, der auf einem Drittel des Weges zwischen normalem und längstem Aufwand liegt.

Zum Beispiel hat man für den Normalfall zwei Tage, also 16 Stunden geschätzt, für den schlimmsten Fall fünf Tage, also 40 Stunden. Man nimmt ein Drittel der Differenzen (1/3 von 24 Stunden, ergibt 8 Stunden) und addiert diese zum Normalfall, die Schätzung wäre dann also 24 Stunden. Die Hintergründe dieser Methode finden Sie im technischen Teil.

Das sieht dann so aus:

Arbeitspaket Ergebnis Aufwand Normalfall/ Ph Aufwand Worst Case/ Ph Schätzung/ Ph
spezifiziere Modul Modulspezifikation 20 40 27
definiere Komponenten, Package-Diagramme, Schnittstellen Modularchitektur 40 40 42
definiere Tests Testspezifikation 8 28 15
Gesamtaufwand       84

Ausschnitt aus einer WBS mit Schätzungen ("Aufwand Normalfall", "Aufwand Worst Case") und Resultat der Zweipunktschätzung ("Schätzung"), berechnete Werte kursiv, Ph: Personenstunden

Parameterschätzung

Wie man "unmöglich" abschätzbare Aufgaben schätzt

Für manche Aufgaben ist die Schätzung schwierig, weil es versteckte Aufwände sind: zum Beispiel Design, Test oder Debugging. Wie soll ich wissen, wieviele Fehler der Prototyp haben wird?

Hier kann man anhand von Parametern schätzen, basierend auf Zahlen aus bereits durchgeführten Projekten oder indem man auch diese Faktoren mit Planning Poker schätzt. Diese Parameter ergeben dann den Prozentsatz des Aufwands, der für Test und Debugging in Relation zur eigentlichen Implementation aufgewendet werden muss.

Eine solche Parameterschätzung könnte so aussehen:

Arbeitspaket Ergebnis Parameter
Schätzung der Parameter für ein "durchschnittliches Feature"    
Spezifiziere Feature Abschnitt in Spezifikation 0.1
Designe Feature Abschnitt in Designdokument 0.2
Implementiere Feature Sourcecode (kompiliert ohne Fehler) 1.0
Generiere und implementiere Tests Testcode 0.3
Teste und debugge Feature Sourcecode (funktioniert ohne Fehler) 0.4
Gesamtaufwand/ Implementationsaufwand   2.0

Parameterschätzung für komplette Entwicklung gegenüber der reinen Implementation, Aufwände relativ zur Implementation geschätzt, berechnete Werte kursiv

Dieser Faktor wird dann in der Schätzung verwendet:

Arbeitspaket Implementation Normalfall/ Ph Implementation Worst Case/ Ph Gesamtaufwand Normalfall/ Ph Gesamtaufwand Worst Case/ Ph Schätzung/ Ph
Feature 1 8 16 16 32 21
Feature 2 20 40 40 80 53
Feature 3 40 48 80 96 85
Gesamtaufwand         159

Ausschnitt aus einer parameterbasierten Schätzung, reiner Implementationsaufwand für jedes Feature als Zweipunktschätzung, daraus durch Multiplikation mit der Parametersumme (2.0) Berechnungen der Werte für die Schätzung des Gesamtaufwands per Feature, berechnete Werte kursiv, Ph: Personenstunden

Wo es noch einfacher geht

Für gewisse Arbeitspakete kann man sich die Schätzung mit Planning Poker ganz sparen: zum Beispiel für die wöchentliche Projektsitzung. Bei dieser ist normalerweise ziemlich genau definiert, wie lange sie dauert – also multipliziert man die Sitzungsdauer mit der Anzahl Wochen, die das Projekt voraussichtlich dauert, mal der Anzahl beteiligte Personen – und schon hat man eine genaue Schätzung für diese Aufgabe.

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

Stichworte/ Tags

Kommentare

Keine Kommentare

Was ist Ihre Meinung?

* Diese Felder sind erforderlich

Teilen auf

Lassen Sie uns Ihre Idee/ Ihr Projekt diskutieren