methodenfabrik

Bei der Aufwandsbestimmung in Projekten erfolgt zu Beginn meist eine Beschreibung der Arbeitsergebnisse, anschließend eine Zerlegung in Arbeitsschritten und schließlich wird zumeist im Team für jeden Eintrag der “Scope-Liste” ein Aufwand in Personentagen geschätzt. Diese klassische Vorgehensweise hat in der täglichen praktischen Arbeit das folgende Problem:
Je nach Erfahrung und Zusammensetzung im Schätzteam sowie im Entwickler-Team wird der Aufwand entweder unter- bzw. überschätzt. Der Architekt schätzt zur Umsetzung 10 PT und der Junior-Entwickler der es im Projekt wirklich umsetzen soll benötigt 20 PT. Schon passt die “richtige” Schätzung nicht mehr zum realen Projekt.

Wenn nun die Komponente 1 mit 50 Personentagen geschätzt wird und Komponente 2 mit 100 so sind das stehende feste Werte. Nachdem nun die Komponente 1 umgesetzt und “fertig” ist, könnte man feststellen, dass aber 80 PT investiert wurden. Wenn dieser Soll-Ist Vergleich hergestellt wird dann ist das schon ein gutes Zeichen für das Projektcontrolling. Meist werden diese Abweichungen aber (lediglich) auf der Zeitleiste durch ein Verschieben eines Meilensteines ausgedrückt und die Erfahrung dass die Umsetzung 60% länger gedauert hat wird für die Komponente 2 ignoriert -> der Plan sieht 100 PT vor und dieser Meilenstein wird wohl wieder nicht gehalten.
Liegt diese Information aber vor und wird genutzt – könnte man für die Komponente 2 von Vornherein 160 PT einplanen. Wenn das aufgrund der engen Zeitvorgaben nicht möglich ist, kann über eine Teamvergrößerung oder eine Scope-Verringerung entschieden werden.  Bei der Vergrößerung des Teams bitte an den exponentiell wachsenden Kommunikationsaufwand denken!
Das Verfahren kann man in einem agilen Projektumfeld sehr gut in die Iterationen einbauen. Statt im oberen Beispiel “nur” einer Messung und damit einer Anpassung der Aufwand-/Zeitleiste könnte das im agilen Umfeld nach jeder Iteration stattfinden. Das wird dann auch recht schnell aufwendig und unübersichtlich. Idee:
Die Aufwandszahlen werden nicht in Zeit (PT) sondern in einer anderen Stellvertreter-Einheit – z.B. Kilogramm oder Höhenmeter bewertet. Das Team bewertet eine Arbeitseinheit mit 10 Kg und die zweite relativ dazu. Ist es mehr oder weniger Aufwand die zweite Tätigkeit umzusetzen? So entsteht für das gesamte Projekt eine Arbeitsliste statt mit Personentagen in Kilogramm. Das Projektgewicht ist dann keine Zeiteinheit von z.B. 90 PT sondern 900 Kg. Nun ist man gezwungen diese Einheit in Zeit umzurechnen. Das erfolgt über eine “Performance” Kennzahl. In der ersten Iteration liegt diese noch nicht vor – wird aber auch geschätzt. So könnte man annehmen dass ein Mitarbeiter an einem Tag eine Leistung äquivalent zu 10 Projekt-Kg umsetzen kann. Nach einer Iteration wird erfasst wieviele Aufgaben abgeschlossen werden konnten und ermittelt deren Gewicht – z.B. 330 Kg.  Wenn nun 3 Personen 10 Arbeitstage an der Fertigstellung gearbeitet haben um diese 330 Kg zu leisten, so liegt die Team-Performance statt bei den angenommenen 10 Kg/Person und Tag – bei 11 Kg/Person und Tag. Mit dieser Kennzahl ist es nun recht einfach bei Kenntnis der Kapazitäten im Team über die Zeit den Endtermin aus den verbleibenden 570 Kg und dem Wissen von 11 Kg/Person und Tag zu errechnen.
Wenn das Verfahren in einem etwas größeren Umfeld eingesetzt wird und die Projektabarbeitung viele Iterationen umfasst, wird diese Performance-Zahl über die Zeit immer genauer. Der Projektleiter kann dann über die Zeit den Termin für das Ende der Entwicklung immer genauer voraus-berechnen.

Das Verfahren ist ebenso in Bereichen einsetzbar die nicht die Softwareentwicklung zum Inhalt haben. Alle Teile / Aufgaben / Phasen eines Projektes wo Sie heute noch Personentage ermitteln – können von der Schätzung über die Umsetzung bis zum Abschluss in relativen Einheiten  ausgedrückt werden. So wird die Schätzung der Einzelaufgaben über die Zeit nicht nur fortgeschrieben, sondern auch der tatsächlichen Performance der Abarbeitung abgepasst.