Schluss mit Pi mal Daumen Realistische Aufwandsschätzung schnell und systematisch

Teil 1:
Typische und leicht vermeidbare Fehlerquellen
Realistische Aufwandsschätzung schnell und systematisch

Vorab die Projektaufwände richtig zu schätzen, ist für Sie genauso unwahrscheinlich wie ein Sechser im Lotto? Karsten Lüth zeigt Ihnen, wie Sie zumindest im Projekt Ihre Trefferquote erhöhen. In dieser Artikelreihe erfahren Sie, wie Sie typische Fehler vermeiden und mit einer geeigneten Schätzmethode systematisch und realistisch Ihre Aufwände abschätzen.

Management Summary

Schluss mit Pi mal Daumen Realistische Aufwandsschätzung schnell und systematisch

Teil 1:
Typische und leicht vermeidbare Fehlerquellen
Realistische Aufwandsschätzung schnell und systematisch

Vorab die Projektaufwände richtig zu schätzen, ist für Sie genauso unwahrscheinlich wie ein Sechser im Lotto? Karsten Lüth zeigt Ihnen, wie Sie zumindest im Projekt Ihre Trefferquote erhöhen. In dieser Artikelreihe erfahren Sie, wie Sie typische Fehler vermeiden und mit einer geeigneten Schätzmethode systematisch und realistisch Ihre Aufwände abschätzen.

Management Summary

Wir empfehlen zum Thema Planen
13.06.2024
1.495,00,-
Methoden des modernen Portfoliomanagements

Die richtigen Dinge tun – für mehr Fokus, Agilität und Produktivität im Unternehmen! In unserem E-Learning-Seminar lernen Sie in nur 4 Workshops, wie Sie Ihr Portfolio mit modernen Methoden organisieren und ausbauen. Mehr Infos

Wer schätzt, braucht für den Spott nicht zu sorgen – wer jemals für ein Projekt die Kosten oder die Dauer abgeschätzt hat, dürfte diese Erfahrung bereits gemacht haben. Ein Projekt verläuft selten so wie angenommen. Meistens geht irgendetwas schief, kostet mehr oder dauert länger. Und die einfachste Methode, um die Krise eines Projekts darzustellen, ist der Vergleich der abgeschätzten Kosten mit den tatsächlichen.

Kostensteigerungen gibt es nicht nur bei großen Bauvorhaben (wie z.B. beim BER, Stuttgart 21 oder bei der Elbphilharmonie). Die Kosten von Software- und IT-Projekte "explodieren" ebenso häufig, wie beispielsweise das Projekt KoPers der Stadt Hamburg und des Landes Schleswig-Holstein. Wie im "Schwarzbuch" des Bundes der Steuerzahler nachzulesen ist, verdoppeln sich Kosten und Laufzeit des Projekts. Laut einer Studie im Harvard Business Review werden die Kosten in IT-Projekten im Durchschnitt um 27% überzogen (Flyvbjerg, B. und Budzie, A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, September 2011).

Den Status eines Projekts darzustellen, ist schwierig und häufig nicht für jeden verständlich. Es ist deutlich einfacher, zwei Zahlen zu betrachten, diese gegenüberzustellen und sich dann kopfschüttelnd zu fragen, wie man sich derart verschätzen konnte.

Keiner will der Buhmann sein

Eine der Folgen dieser Situation konnte ich schon bei zahlreichen Kunden miterleben: Es wird immer schwieriger, Projektmitglieder dazu zu bewegen, Abschätzungen für Kosten, Aufwände und Zeitbedarf zu machen. Die Sorge, Ziel von Kritik zu werden, sobald die tatsächlichen Kosten die abgeschätzten übersteigen, ist häufig so groß, dass selbst erfahrene Projektmitglieder es vermeiden, an einer Aufwandsabschätzung mitzuarbeiten.

In den Organisationen gibt es kaum etablierte Methoden und Werkzeuge, um Abschätzungen zu erstellen und bei den Abschätzungen, die schließlich entgegen aller Widerstände erstellt werden (irgendwie muss das Budget für das neue Projekt ja beantragt werden) ist es meistens unklar, welche Methoden verwendet und welche Annahmen getroffen wurden oder wie hoch die Genauigkeit der Prognose ist.

Und dann passiert nicht selten folgendes: Die Qualität der Abschätzungen verschlechtert sich weiter. Die tatsächlichen Kosten der Projekte weichen immer stärker von den Prognosen ab. Das Vertrauen der Stakeholder in die Organisation sinkt. Die Kritik an die Projektmitglieder wächst, was wiederum dafür sorgt, dass diese erst recht vermeiden, an weiteren Abschätzungen mitzuwirken. Dadurch gehen wichtige Erfahrungen und Motivation verloren, die bei den zukünftigen Abschätzungen fehlen und die Chancen auf eine realistische Prognose weiter mindern.

Diese dreiteilige Reihe soll Ihnen helfen, Prognosen leichter und mit System zu erstellen. Im ersten Teil erläutere ich Ihnen die Gründe für die z.T. groben Fehlschätzungen und gebe Ihnen erste Tipps, wie Sie Aufwände realistischer abschätzen können. Im zweiten Teil stelle ich Ihnen einige gängige Methoden vor, um Abschätzungen durch Experten oder durch algorithmische Methoden durchzuführen. Im dritten Teil erfahren Sie, wie Sie die Wahrscheinlichkeiten von Prognosen bestimmen können, um möglichst genaue Aussagen treffen zu können.

Fehlerquellen: Warum wir schlecht schätzen

Erstaunlicherweise sind die Ursachen von Fehlabschätzungen überschaubar und allgemein bekannt. Sie werden am Ende eines Projekts im Lessons Learned-Bericht dokumentiert und beim nächsten Projekt erneut ignoriert.

Ungenaue, missverständliche und instabile Anforderungen

Probleme mit den Anforderungen gehören zu den häufigsten Ursachen für Kostenerhöhungen im Projekt. Am Projektbeginn – wenn die Verantwortlichen die Aufwände abschätzen – liegen selten vollständige und eindeutig formulierte Anforderungen vor, und die unter Zeitdruck stehenden Anforderungsmanager und technischen Experten analysieren diese häufig nur ungenügend. Erst im Projektverlauf zeigen sich dann die Schwierigkeiten bei der Umsetzung. Häufig reicht der Kunde zusätzliche Anforderungen nach oder modifiziert bestehende. Schließlich führen missverständliche Anforderungen zu teuren Fehlern in der Entwicklung. Denn da das Testteam die gleichen Anforderungen verwendet, entdeckt es die Fehler nicht selbst, sondern erst der Kunde nach der Fertigstellung.

Übermäßig strikte Anforderungen erhöhen ebenfalls die Kosten. Gerade im technischen Bereich ist es nicht immer ersichtlich, wie exakt die geforderten Leistungen eingehalten werden müssen. Wenn zum Beispiel gefordert wird, dass ein System alle Datenbankabfragen innerhalb von zwei Sekunden bearbeiten muss, dann kann der Realisierungsaufwand im Vergleich zu einem System das lediglich mindestens 90% aller Abfragen innerhalb von zwei Sekunden bearbeitet extrem hoch sein.

Fortsetzungen des Fachartikels

Teil 2:
Welche Schätzmethode eignet sich am besten?

Sie können die Qualität Ihrer Aufwandsschätzungen kontinuierlich verbessern, indem Sie konsequent Erfahrungswerte sammeln und systematische Methoden einsetzen. Karsten Lüth stellt Ihnen hierzu Metriken, Kostenmodelle und Schätzmethoden vor.

Teil 3:
So berechnen Sie die Genauigkeit Ihrer Prognosen

"Mit einer Wahrscheinlichkeit von 25% wird es morgen regnen" – bei Prognosen ist es üblich, die Eintrittswahrscheinlichkeit mitaufzuführen. Um Ihre Aufwände möglichst präzise und glaubwürdig angeben zu können, sollten auch Sie ermitteln, wie …

Alle Kommentare (2)

Rainer
Lingmann

Ich möchte vier Aussagen kommentieren: 1. "Daher sollten Sie es vermeiden, die Aufwände zu unterschätzen, selbst wenn Sie diese dann eventuell zu hoch abschätzen. Wie Sie ihr Angebot gestalten, ist natürlich eine ganz andere Frage. Sie können gezwungen sein, einen niedrigen Preis anzubieten, um ein Auftrag bekommen zu können." Es gibt leider keine sichere Seite der Aufwandsschätzung. Denn wie Sie richtig schreiben, greift bei zu hohen Abschätzungen Parkinsons Gesetz. Es ist also keine Option, bewusst hoch zu schätzen, dann aber doch niedrig anzubieten im Wissen darum, dass man ja hoch abgeschätzt hat. Die Kosten werden nach Parkinson nämlich die geschätzten Werte auf jeden Fall erreichen und damit den niedrigen Angebotspreis überholen. 2. "Beim agilen Projektmanagement (wie z.B. Scrum) ... erfolgt [die Planung] ausschließlich für den nächsten Sprint." Das ist falsch. Die Feinplanung erfolgt nur für den nächsten Sprint, das ist richtig. Es sollte aber bei gut verstandenem agilen Vorgehen sehr wohl eine Releaseplanung geben, also eine langfristige Planung, wann voraussichtlich welcher Leistungsumfang erbracht sein kann. 3. "Die kurze Dauer eines Sprints erleichtert die Abschätzungen. ... Das gilt zunächst jedoch nur für einen Sprint, nicht für das gesamte Projekt." Agile Planung ist empirische Planung. Nach meiner Erfahrung ist die langfristige Planung agiler Projekte deutlich verlässlicher als die klassischer Projekte, weil sie keine Vermutungen macht, sondern weil sie konkret erbrachte Leistungen der ersten Sprints auf den Rest des Vorhabens hoch rechnet. Diese Hochrechnung ist oft schon sehr früh erstaunlich verlässlich. 4. "Die Agilität, insbesondere die Möglichkeit, während des Projekts die Anforderungen anzupassen, macht es schwieriger, die Gesamtkosten zu Beginn des Projekts abzuschätzen." Niemand zwingt irgendjemanden, in einem agilen Projekt die Anforderungen zu ändern. Es ist total erlaubt, sich vorher zu überlegen, was man wohl haben möchte, und das dann Schritt für Schritt auch so umzusetzen.

 

Karsten
Lüth

Hallo Herr Lingmann, vielen Dank für ausfühlichen und interessanten Kommentare! zu 1. Sie haben natürlich Recht, wenn Sie sagen, dass es keine sichere Seite der Aufwandsabschätzung gibt. Werden Aufwände aber unterschätzt, dann können Effekte auftreten, die deutlich teurer sind als bei überschätzten Aufwänden. Ein Beispiel sind schlecht analysierte Anforderungen: wird der Aufwand eines Projektes unterschätzt, dann werden häufig die Anforderungen nur sehr oberflächlich analysiert und die dadurch entstehenden Kosten können extrem hoch sein. zu 2. Schwaber und Sutherland haben es so ausgedrückt: "A Product Backlog is never complete." Auch wenn die Abschätzungen der Anforderungen des Product Backlogs kontinuierlich vorangetrieben werden (auch über den nächsten Sprint hinaus), wird in der Regel nicht davon ausgegangen, dass der Product Backlog vollständig ist. Das hat auch Auswirkungen auf die Planung. zu 3. Natürlich machen die Erfahrungen des ersten Sprints die Abschätzung weiterer Aufgaben einfacher und verläßlicher und mit jeden weiteren Sprint verbessert sich in der Regel die Genauigkeit der Abschätzungen. Zu Beginn des Projektes hat man diesen Vorteil jedoch nicht. zu 4. Anforderungen flexibel anpassen zu können, ist eine der Motivationen für agile Methoden. Oder, um Schaber und Sutherland zu zitieren: "The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful." Dieses Vorgehen hat enorm viele Vorteile, bringt aber auch einige Schwierigkeiten mit sich, wenn sehr früh eine Abschätzung des Gesamtaufwandes benötigt wird.