Wie macht man eine Projektschätzung?

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.

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.

Zweipunktschätzung des Aufwandes

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:

Ausschnitt aus einer WBS mit Schätzungen ("Aufwand Normalfall", "Aufwand Worst Case") und Resultat der Zweipunktschätzung des Aufwandes ("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:

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:

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

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