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:

Kumulative Ansicht

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

 Absolute Ansicht

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.

Ergebnis mit Wahrscheinlichkeit

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

7 Kommentare
  1. bastian sagte:

    wäre super wenn du mal sagen könntest welche exakte funktion du wonach integrierst? habs versucht nachzubauen, aber du hast ja nur textuelle beschreibung. danke im vorraus. integrieren nach n=aufwand war nicht das gewünschte ergebnis

    • Maik Pfingsten sagte:

      Hallo Bastian,

      ich integriere im Grunde über zwei Flächen. Zunächst von Nano-Prozent bis Erwartungswert, dann von Erwartungswert bis Worst-case.

      Ich werde in den nächsten Tagen noch die Erläuterung zur Releaseplanung online stellen. Da ist dann auch mein Excel-Template mit dabei. Dort habe ich eine Formel, die mir das Ergebnis auf Basis meiner Eingaben direkt ausgibt.

      Schönen Gruß aus Köln,

      Maik

  2. bastian sagte:

    Hey Maik

    passt ja super – habe mal die komments abonniert. sind hier nämlich auch auf der suche nach passenden schätzmethoden.

    freu mich auf jeden fall auf das template. wenn du das eh veröffentlichst, dann werde ich mich solange mit anderen methoden befassen.

    gruß

  3. Christoph sagte:

    Hallo Maik,

    vorab vielen Dank, dass Du uns an deinen Erfahrungen teilhaben lässt.

    Nun aber zu meiner Frage:
    Was passiert, wenn ich im Projekt einen absoluten Experten habe und der Worst Case Wert sich aus dem nano-percent Wert und dem Unsicherheitsfaktor 1 zusammensetzt? Dann erhalte ich als Worst Case den Best Case?
    Sollte es dann nicht eher heißen: Worst Case = Expected value + (Unsicherheit x nano-percent)?

    Gruß,
    Christoph

Trackbacks & Pingbacks

  1. […] Pfingsten schlägt in seinem Zukunftsarchitekten Blog die kumulative Aufwandskalkulation vor, in welcher diese oben beschriebenen Faktoren etwas abgedämpft werden, indem man zur […]

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar