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.