Releaseplanung und Aufwandsschätzung ist eine der Kernaufgaben des Systemingenieurs. Die Projektmanager benötigen die Zahlen des Systemingenieurs. Aber viele hochspezialisierte Entwicklungsingenieure scheuen sich, dazu etwas zu sagen. Somit ist die Aufwandsschätzung und die Releaseplanung die Schnittstelle zwischen Systemingenieur und Projektmanager.

Die hier beschriebene Vorgehensweise habe ich 2004 entwickelt, da ich als Troubleshooter immer wieder in den Meetings gefragt wurde: “Und, Herr Pfingsten, wie lange benötigen wir für den dafür?”. Mir ist zu dieser Zeit das Buch “Bärentango” von Tom DeMarco in die Hände gefallen, in der er eine Methode über Risikomanagement beschreibt. Sofort war mir klar: Wenn ich ein paar Punkte anpasse, kann ich die Vorgehensweise auch für die Aufwandsschätzung nutzen.

Das erste Mal habe ich auf dem PM-Forum 2006 in Hannover über meine Vorgehensweise zur Aufwandsschätzung einen Vortrag gehalten.

Warum ist Aufwandsschätzung so schwierig?

Der Manager fragt den Entwickler, wie viel Aufwand er für die Lösung benötigt. Der Entwickler antwortet “Etwa 300 bis 500 Stunden”. Welcher Wert wird nun genommen? Klar: 150 Stunden!

Aber warum? Oft wissen die Manager, dass die Entwickler eine Reserve einplanen, die  aus Sicht des Managers aber oft zu hoch ist. Also teilt er die Aussage des Entwicklers durch zwei. Das Verhalten versteht der Entwickler sofort und wird seine Aussagen zukünftig mit zwei multiplizieren. Keine sinnvolle Vorgehensweise!

Zusätzlich sind Aufwandsschätzungen unpräzise. Das hat weitere Gründe:

1. Extremer Zeitdruck
   In der Regel werden Schätzungen immer unter extremen Zeitdruck abgegeben – „Ich brauche eine Aussage in den nächsten zwei Stunden.“
2. Abhängig von der Erfahrung
   Wenn ich einen absoluten Spezialisten mit zwanzig Jahren Erfahrung frage, werde ich definitiv eine andere Aussage erhalten, als von einem Hochschulabsolventen.
3. Die Wahrheit der Zahl
   Anforderungen sind oft verbal beschrieben und damit interpretierbar. Das kennen wir und gehen damit um. Wenn ich etwas als rosa bezeichne, ist das für meine Tochter auch gerne violett, pink, lila oder so.
   Wenn wir aber über Zahlen reden, passiert in unserem Kopf ein fataler Kurzschluss: Zahlen sind nicht interpretierbar. Das bedeutet, wenn ich 100 Stunden sage, dann ist das für den Gegenüber auch 100 Stunden, nicht 99 Stunden und nicht 101 Stunden. Aber das führt dazu, das unser Kopf dummerweise zu uns sagt, das ist wahr. Egal wie falsch die 100 Stunden sind.
4. Ungenauigkeit über die Zeit
   Es gibt einen Punkt, in dem der echte Aufwand mit der Schätzung übereinstimmt! Das ist beim Abschluss des Projektes, relativ gesehen = 1. Vorher gibt es immer eine Unsicherheit. Je weiter wir bei einem Projekt am Anfang stehen, umso größer ist die Unsicherheit. Eine Studie von Tom DeMarco aus den 80er-Jahren hat folgendes ergeben: Zu Beginn eines Projektes liegen die Schätzungen 400% über den Aufwand oder betragen 25% vom wirklich benötigten Aufwand:

 

Wie können wir besser schätzen?

Es gibt einige Anforderungen, die bei effektiven Aufwandsschätzungen wichtig sind:

1. Effizient und nicht komplex
2. Effektiv, aber nicht schlampig
3. Nachvollziehbar und nicht individuell
4. Ausgewogen und keine einseitige Sicht
5. Verlässlich und nicht fehlerbehaftet

Was benötigt eine gute Aufwandsschätzung?

Aufwandsschätzung ist nicht einfach. Es gibt aber einige Faktoren aus der Praxis, die eine gute Aufwandsschätzung beschreiben:

1. Entkoppelung der Ergebnisse
   Wir müssen die Ergebnisse von der Quelle entkoppeln. Das bedeutet, wir benötigen einen Faktor, mit dem wir die Erfahrung des Entwicklers berücksichtigen können.
2. Unsicherheit einplanen
   Wir müssen die Möglichkeit haben, zu der Zahl eine Unsicherheit mit anzugeben. Zum Beispiel 300 Stunden Aufwand mit einer Wahrscheinlichkeit von 80%, dass wir es damit schaffen.
3. Einfache Vorgehensweise
   Die Vorgehensweise muss einfach und für jeden nachvollziehbar sein. Ich habe verschiedentlich Methoden ausprobiert, und wenn mich nach fünf Minuten alle nur noch komisch angeschaut haben, dann war die Methode nicht einfach.
4. Nachvollziehbar nach Monaten
   Aufwandsschätzungen sind oft ein Puzzlestück vor einer größeren Entscheidung. Und Entscheidungen brauchen Zeit. Bei Angeboten können bis zu sechs Monate vergehen, bis ein Auftrag fixiert ist. Die handelnden Personen sind aber dann schon in anderen Projekten verschwunden, und das neue Projektteam muss deren Schätzungen nach Monaten nachvollziehen können.

Wie können wir besser schätzen?

Der erste Schritt ist, die Unsicherheit zu benennen. Dazu frage ich zunächst drei Informationen bei den Entwicklern ab:

1. Der Nano-Prozent-Wert
   Wie viel Aufwand brauchst du, wenn alles super läuft? Wenn kein Server abrauscht, kein Kunde dauernd anruft, wenn alles perfekt ist. Hier erhalte ich eine Aussage in Stunden (wichtig: Aufwand, nicht Dauer!). Relativ gesehen ist die Wahrscheinlichkeit „null“, damit das Problem zu lösen.
2. Der erwartete Wert
   Was glaubst du – ohne mal zwei durch zwei – wird der Aufwand sein (wichtig: Aufwand nicht Dauer!)? Aus Sicht des Entwicklers ist die Wahrscheinlichkeit, relativ gesehen, „eins“, das Problem zu lösen.
3. Der Unsicherheitsfaktor
   Wie viel Berufserfahrung hast du? Wie gut kennst du dich mit der Materie aus? Hier bilde ich einen Faktor zwischen 1 und 10. Eins bedeutet, ich kann den Kollegen nachts aus dem Bett zerren und er kann mir die Lösung runterbeten. Zehn bedeutet, er hat einen fragenden Blick und hält mich für einen komischen Typen.
4. Der maximale Wert
   Den maximalen Wert errechne ich aus dem Nano-Prozent-Wert multipliziert mit dem Unsicherheitsfaktor.

Diese Informationen kann ich im folgenden Bild darstellen:

Hier sehen wir nun eine vereinfachte Verteilung. Diese können wir integrieren und erhalten die sogenannte kumulative Sicht:

 

Inhaltlich haben wir die gleiche Aussage wie vorher. Wir haben nur von einer relativen in eine absolute Aussage gewechselt. Relativ gesehen haben wir bei 350 Stunden eine Wahrscheinlichkeit von 0%, dass wir eine Lösung schaffen. Das haben wir absolut gesehen auch. Relativ gesehen haben wir ebenfalls eine Wahrscheinlichkeit von 0%, dass wir 1000 Stunden benötigen. Absolut gesehen bedeutet es, dass wir mit 1000 Stunden zu 100% klar kommen.

Jetzt können wir den nächsten Schritt unternehmen und die absolute Wahrscheinlichkeit auf 80% setzen. Damit erhalten wir einen Aufwand von 650 Stunden bei 80% Wahrscheinlichkeit es zu schaffen.

Nun haben wir eine Aussage über den Aufwand mit einer zusätzlichen Information, wie wahrscheinlich es ist, mit den Aufwand zurecht zu kommen. Durch diese Vorgehensweise können wir nun besseren Schätzungsaussagen abgeben:

1. „Wir schaffen es“ (80% Wahrscheinlichkeit oder mehr).
2. „Wir können einen Versuch wagen(60% – 80% Wahrscheinlichkeit).
3. „Wir haben eine 50/50 Chance“ (50% Wahrscheinlichkeit).
4. „Wir haben absolut keine Chance, es zu schaffen“ (Weniger als 50%).

Zusammengefasst sind die Schritte:

1. Schätze den optimistischen und den erwarteten Aufwand.
2. Definiere den Unsicherheitsfaktor (1…..10).
3. Kalkuliere den pessimistischen Aufwand.
4. Übertrage die kumulative Sicht in die absolute Sicht.
5. Definiere die gewünschte Wahrscheinlichkeit und lies den Aufwand ab.

Das Ergebnis

Damit haben wir eine einfache Vorgehensweise, um Aufwände zu schätzen und mit der Aussage eine Wahrscheinlichkeit zu verknüpfen. Wenn wir das für jedes einzelne Arbeitspaket durchführen, können wir die Aufwände zusammenrechnen und den Durchschnitt der Wahrscheinlichkeiten bilden. Somit haben wir für ein gesamtes Projekt die Abschätzung geschaffen. Nebenbei haben wir die Argumentation, was eine Reduktion der Aufwände bedeuten würde: die Reduktion der Wahrscheinlichkeit. Meine Erfahrung ist, dass Manager dann aufmerksam werden. Sie sind jetzt mit Verantwortlich, wenn die Aufwände so gekürzt werden, dass die Wahrscheinlichkeit zum Beispiel auf 20% sinkt. 

Auch die Dokumentation fällt wesentlich leichter. Wir brauchen nur noch zwei Informationen dokumentieren:

• Warum haben wir den Unsicherheitsfaktor (1 …. 10) gewählt?
• Warum haben wir die Wahrscheinlichkeit (0% – 100%) gewählt?

Die anderen Informationen sind durch die Entwickler gegeben worden.

Oft ergeben die Schätzungen mit dieser Vorgehensweise eine viel höheres Ergebnis als bisher. Was logisch ist, denn klassische Projekte verdoppeln oder dreifachen gerne mal ihr Budget. Aber wir können mit der Vorgehensweise auch bewusst auf Lücke setzen! Wir können bei einzelnen Arbeitspaketen die Wahrscheinlichkeit auf bis zu 50% absenken und den Aufwand definiert reduzieren. Damit wissen wir sofort, welche Arbeitspakete ein Risiko darstellen.

Der Ausblick

Mit dieser Form der Aufwandsschätzung habe ich nun die Grundlage geschaffen, für die Entwicklungsprojekte die Kosten abzuschätzen. Der nächste Schritt ist die darauf aufbauende Releaseplanung. Ich habe das in einem weiteren Tutorial zusammengefasst: Nachvollziehbare Releaseplanung für komplexe Systeme

Als Systemingenieur in der Automobilentwicklung bewerte ich seit Jahren technische Lastenhefte. Dadurch habe ich so ziemlich alles gesehen: von chaotischen Lastenheften, bis hin zu Lastenheften, die absolut super waren. Ich habe Lastenhefte bewertet, als Projekte noch in der Initialisierungsphase waren. Ebenso habe ich Lastenhefte bewertet, als ich sechs Monate vor SOP (Start der Produktion) ein […]