Innovative Projekte beinhalten inhärent Unsicherheiten und Risiken, sind vage und stecken voller offener Fragen. Wie meistert man die Herausforderung, solche Projekte quantitativ zu schätzen?.
Ein innovatives Projekt zeichnet sich dadurch aus, dass sich anfangs der Weg zum Projektziel nicht offensichtlich abzeichnet. Und das liegt in der Natur der Sache: Denn wenn der Weg, die Technologie, die Prozesse und Anforderungen zum Erreichen des Projektziels alle offensichtlich wären, dann wäre es kein innovatives Projekt!
Statt zu versuchen alle Unklarheiten, Unsicherheiten und Risiken zu eliminieren, sollte man diese besser akzeptieren, da sie eine inhärente Eigenschaft dieser Art von Projekten ist. Für die technische Umsetzung eigenen sich am besten die bekannten etablierten agilen Softwareentwicklungsmethoden, mit denen der Weg in vielen kleinen Iterationen gefunden wird.
Für viele Stakehoder ist vor der eigentlichen Projektumsetzung aber zunächst eine ganzheitliche Zeit-, Aufwands- oder Kostenschätzung notwendig. Die Herausforderung ist also, wie man von vagen Zielformulierungen und Anforderungen auf eine quantiative Aussage kommt. Der Schlüssel dazu liegt darin, dass man versucht die Aufgaben zuerst qualitativ und relativ zueinander zu schätzen. Es fällt den Menschen schwer konkrete Zahlen zu schätzen, aber viel leichter in Relation zueinander zu schätzen. Also z. B. ist Aufgabe A größer als Aufgabe B?
Wir standen mit unserem Projektteam kürzlich vor der Aufgabe für ein innovatives Projekt bei unserem Kunden, eine solche quantitative Schätzung abgeben zu müssen. Dabei sind wir wie folgt vorgegangen:
1. Vorbereitung
Zunächt haben wir alle uns bekannten Anforderungen und Themen zu dem Projekt auf Karteikarten geschrieben. Das hat es uns später einfacher ermöglicht, die Themen zu organisieren.
2. Qualitatives schätzen der Anforderungen
Im zweiten Schritt haben wir die Themen nach ihrem Aufwand in eine Reihenfolge gebracht. Der Fokus liegt darauf, qualitativ zu bewerten, welche Anforderungen im Vergleich zueinander größer oder kleiner sind. Reihum wurde eine Karte aus dem Anforderungsstapel genommen, vorgelesen und die Anforderung im Team diskutiert. Etwaige Annahmen und Rahmenbedingungen haben wir dabei auf der Karte mit notiert. Die erste Karte wird dann einfach auf den Tisch gelegt. Bei nachfolgenden Karten haben wir dann diskutiert, wo die Anforderung in die bereits ausliegenden Karten einsortiert werden sollte, in Bezug auf die Größe der Anforderung bzw. Komplexität der Umsetzung. Wichtig ist es in diesem Schritt, wirklich eine strenge Reihenfolge von kleinen Anforderungen hin zu großen Anforderungen zu legen.
3. Clustern der Anforderungen
Nachdem wir alle Anforderungen gemeinsam in eine Reihenfolge anhand ihrer Größe geordnet hatten, haben wir die Anforderungen zu Clustern zusammengefasst. Dazu haben wir in unserer Reihenfolge nach Brüchen gesucht, wo zwei Anforderungen, die nebeneinander liegen, sich erheblich in ihrer Größe unterscheiden. Das ist dann eine Clustergrenze. Auch wenn sich das sehr theoretisch anhört, waren die meisten Clustergrenzen für die Teilnehmer offensichtlich. So waren unsere obersten zwei Anforderungen viel größer als die nachfolgenden Karten und haben so auf natürliche Art und Weise ein Cluster gebildet. Bei anderen Clustern haben wir etwas intensiver diskutiert. Dabei haben wir immer wieder die Fragen gestellt, ist die Anforderung größer, kleiner oder vllt. genauso groß wie die anderen Anforderungen darüber oder darunter. Als Clustereinteilung haben wir T-Shirt-Größen genommen, also S, M, L und XL, um es im nächsten Schritt einfacher zu haben.
4. Quantifzieren der Aufwände
Um abschließend konkrete Aufwände aus den geclusterten Themen ableiten zu können, müssen zunächst folgende Rahmenbedingungen des Projektes definiert werden:
- Wie groß wird das Projektteam sein?
- Welche Sprintlänge ist geplant?
Basierend auf diesen Zahlen, haben wir in der Gruppe diskutiert, wie viele Sprints das Projektteam für Themen in den jeweiligen T-Shirt-Größen vermutlich benötigen wird. Bei unserem konkreten Kundenprojekt sind wir davon ausgegangen, dass Themen der Größe S jeweils einen halben Sprint, Themen der Größe M einen Sprint, Themen der Größe L zwei Sprints und Themen der Größe XL vier Sprints benötigen. Diese Einteilung bzw. Abschätzung wird für jedes Projekt unterscheidlich sein. Der quantitative Gesamtaufwand ergibt sich dann in dem man die Zahl der benötigten Sprints mit den Personentagen pro Sprint multipliziert.
In unserem konkreten Fall sind wir von zwei Wochen Sprints mit drei Personen ausgegangen, d.h. 15 Personentage pro Sprint. Unsere Abschätzung hat zwei XL-Themen, drei L-Themen, fünf M-Themen (zwei Anforderungen haben wir zu einer zusammengefasst) und ein S-Thema ergeben. Somit ergibt sich ein geschätzer Gesamtaufwand von 15 Personentagen x (2 x 4 Sprints + 3 x 2 Sprints + 5 x 1 Sprint + 1 x 0,5 Sprint) = 15 Personentage * 19,5 Sprints = 292,5 Personentagen.
Natürlich liegt in der Abschätzung sehr viel Unsicherheit und es ist zunächst mal ein Planungshorizont, mit dem man arbeiten kann. Gemäß dem Fermi-Prinzip ist es aber "wahrscheinlich, dass sich die Abschätzungsfehler zum Teil gegenseitig aufheben – wenn die eine Größe als zu groß geschätzt wurde, wurde eine andere vielleicht als zu klein geschätzt." Auf diese Weise bekommt man mit relativ wenig Aufwand bereits eine Einschätzung der Projektgröße. Wichtig ist, dass mit dem Verlauf des Projektes das Wissen um die Aufgaben konkreter und besser wird. Damit sollte man die Planung kontinuierlich anpassen und überprüfen.
