Kommt Ihnen die folgende Szene bekannt vor?

Auftraggeber: "Wir wollen eine Software für unsere Kundenverwaltung. Was kostet das?" Anbieter: "Dazu brauchen wir mehr Details, eine Spezifikation oder die Anforderungen." Auftraggeber: "Naja, so grob werden Sie das doch einschätzen können." Anbieter: "200 Personentage, plus minus 30%." Auftraggeber: "Das ist zu hoch." Anbieter: "Ich kann auch weniger schätzen. Wie hoch soll es denn sein?" Auftraggeber: "Wie jetzt? Was soll das heißen?" Anbieter: "Solange ich nicht mehr Details weiß, ist es egal, was wir schätzen. Je nachdem, was wir schätzen, passt die Planung dann eben mehr oder weniger gut zu den künftigen realen Aufgaben und Aufwänden. Und für die gehe ich nach den mir vorliegenden Informationen von 200 Personentagen, plus minus 30% aus." Auftraggeber: "Dann muss ich mich am Markt nochmal umschauen."

Sie können sicher sein, dass der Auftraggeber einen Anbieter finden wird, der eine ihm genehme Schätzung abliefert. Aber genauso sicher ist, dass der Auftraggeber sich dann über viele Change Requests, Verzögerungen und Budgetüberschreitungen ärgern wird.

Das Dilemma mit den Aufwandsschätzungen

Die einführende Szene ist symptomatisch dafür, wie Aufwandsschätzungen in der Praxis behandelt werden. Weder Auftraggeber noch Auftragnehmer sehen sie als eine sorgfältig durchzuführende Aufgabe an, die dem Projektleiter die Basis für eine seriöse Projektplanung liefert. Vielmehr vermischen sie die Aufwandsschätzung mit nicht fachlichen Aspekten wie z.B. Preisverhandlungen. Das ist dann auch der Grund, warum Projekte, insbesondere IT-Projekte, meist empfindlich teurer werden als ursprünglich geplant. Es wäre falsch deswegen zu glauben, dass die Methoden der Aufwandsschätzung nichts taugen. Auch liegt es keineswegs in der Natur der Sache, dass IT-Projekte ihr Budget überziehen. Vielmehr verhindern grundlegende Managementfehler, dass Aufwandsschätzungen korrekt durchgeführt werden. Um zu genaueren Aufwandsschätzungen zu kommen, ist es nicht nötig, die Schätzmethoden zu verbessern – diese sind vollauf ausreichend. Vielmehr müssen als erstes weit verbreitete Fehleinschätzungen und Irrtümer beseitigt werden, die es unmöglich machen, Aufwandsschätzungen sorgfältig und neutral durchzuführen.

Im Folgenden stelle ich die meiner Erfahrung nach wichtigsten Irrtümer und Fehler zum Thema Aufwandsschätzungen vor und versuche jeweils, Hinweise zu geben, wie sie überwunden werden können.

Die elf wichtigsten Irrtümer der Aufwandsschätzung

Fehler 1: Auftraggeber setzen Aufwandsschätzung und tatsächlichen Arbeitsaufwand gleich

Der Kunde – egal ob intern oder extern – will am Anfang eines Projekts sofort wissen, wie lange es dauert und was es kostet, selbst dann, wenn noch nicht alle Anforderungen auf dem Tisch liegen. Sobald die Spezifikationen und Anforderungen bekannt sind, erwartet er sogar eine exakte Vorhersage der Aufwände, von der nicht abgewichen werden darf. Auftraggeber gehen intuitiv davon aus, dass das Projekt genau so abgearbeitet wird, wie geschätzt wurde und verstehen nicht, dass für das eine Arbeitspaket mehr Aufwand als geschätzt anfällt, für das andere dafür weniger. Überspitzt formuliert: Auftraggeber wollen als Auftragnehmer Propheten, die heute wissen, was im nächsten Jahr passiert.

Deshalb wollen Auftraggeber die geschätzten Aufwände drücken. Sie denken, dass dann auch die Durchführung billiger wird. Aber eine niedrigere Schätzung ändert nichts am tatsächlich notwendigen Aufwand, um eine bestimmte Leistung zu erbringen. Nehmen wir z.B. an, Sie wollen so schnell wie möglich mit dem Taxi von München nach Augsburg fahren. Deshalb nehmen Sie den Taxifahrer, der die Fahrzeit am niedrigsten schätzt, z.B. auf fünf Minuten, und nicht den Taxifahrer, der 30 Minuten geschätzt hat. Allerdings müssen Sie als Fahrgast jetzt damit leben, dass der Taxifahrer alle fünf Minuten einen Nachschlag fordert und sie wesentlich später ankommen werden als Sie auf Basis der Schätzung geplant hatten. Aufgrund der Zeit und Nerven kostenden Verhandlungen, der Verzögerung und dem gestiegenen Preis werden Sie mit diesem Taxifahrer nie wieder fahren wollen.

Dieses Beispiel soll zeigen, dass für die tatsächliche Arbeit die Aufwandsschätzung völlig egal ist. Die Schätzung dient nur der Planung von Zeit und Kosten. Sowohl Auftraggeber als auch Auftragnehmer sollten sich im Klaren darüber sein, dass sie den größten Nutzen von der Aufwandsschätzung und der darauf aufbauenden Planung dann haben, wenn diese möglichst nah an der Realität sind.

Wenn der Auftraggeber die vom Auftragnehmer geschätzten Aufwände auf dem Verhandlungsweg drückt, dann wird der Auftragnehmer bei einem Festpreisvertrag in seine Schätzung einen großen Puffer einbauen und im Vertrag klar definieren, welche Forderungen des Auftraggebers als berechtigter Claim und welche als Change Request anzusehen sind. Er schützt dadurch das knappe Projektbudget, da er nur die berechtigten Nachforderungen selbst tragen muss, der Kunde aber alle Change Requests bezahlen muss. Bei einem meiner Projekte bestand der Leistungsumfang am Ende zu 30% aus Change Requests, was meiner Ansicht nach viel zu viel ist, da damit sowohl der Verwaltungsaufwand im Projekt als auch die Reibungsverluste unangemessen steigen. Der hohe Anteil an Change Requests zeigt auch auf, wie wenig am Anfang an den Anforderungen gearbeitet wurde.

In einem Unternehmen, in dem ich früher gearbeitet habe, ging die Gleichsetzung von Aufwandsschätzung und tatsächlichem Arbeitsaufwand soweit, dass die Projektmitarbeiter ihre Aufwände nur so buchen durften, wie sie geschätzt worden waren und nicht, wie sie tatsächlich gearbeitet hatten. Ich habe es auch schon erlebt, dass die Mitarbeiter zwar geringere Ist-Aufwände als die Schätzung buchen durften, wenn sie schneller vorankamen, nicht aber höhere Aufwände, wenn die Schätzung zu optimistisch war. Am Ende des Projekts feierten wir dann und lobten uns dafür, dass wir das Budget eingehalten hatten.

Wenn Aufwandsschätzung und tatsächlicher Arbeitsaufwand gleichgesetzt werden, lügen sich die Projektbeteiligten in die eigene Tasche und verhindern eine wirksame Projektsteuerung, da es keine echten Ist-Werte ergibt. Schlimmer noch ist, dass dadurch keine Projektnachbetrachtung möglich ist, aus der man für zukünftige Projekte lernen kann.

Um langfristig die Aufwandsschätzungen immer näher an die Realität zu bringen und so höhere Planungssicherheit bezüglich Budget und Termin zu haben, ist es als erster Schritt unbedingt notwendig, dass die Projektmitarbeiter ihre Aufwände so erfassen, wie sie tatsächlich gearbeitet haben. Nur so können Projektleiter und Unternehmen mit Hilfe der Erfahrungswerte lernen, immer besser zu planen. Ein Projektleiter kann dann z.B. erkennen, welche Mitarbeiter immer zu vorsichtig und welche zu optimistisch schätzen. Im nächsten Projekt kann er das ausgleichen und eine bessere Schätzung abgeben.

Fehler 2: Projektleiter erkennen Aufwandsschätzungen nicht als wesentliches Element des Stakeholdermanagements

Aufwandsschätzungen sind für den Projektleiter eigentlich die wichtigste Schnittstelle zwischen Kunde und Lieferant. Schließlich liefern sie die Basis für die Verträge, die Terminplanung, die benötigten Ressourcen und vieles mehr.

Obwohl Aufwandsschätzungen zentral für die Projektarbeit sind, vernachlässigen Projektleiter, Auftraggeber und Auftragnehmer sie dennoch oder behandeln sie mit wenig Professionalität. Die Konsequenz daraus ist, dass Auftragnehmer die Aufwandsschätzungen entweder bewusst niedrig halten, um dem Auftraggeber zu gefallen, und dann über Change Requests oder Nachforderungen das Budget schrittweise erhöhen. Oder sie führen die Aufwandsschätzungen sehr großzügig durch, wenn dies gegenüber dem Auftraggeber durchsetzbar ist. Die Schätzungen enthalten dann viele versteckte Puffer, um die zu erwartenden Unsicherheiten abzufedern.

Dabei sollten sowohl Auftraggeber wie auch Auftragnehmer großes Interesse an einer verlässlichen Aufwandsschätzung haben, um eine gute Kalkulation zu erhalten. Für den Projektleiter ist dies genauso wichtig, damit er nicht andauernd Budget nachfordern muss, was ihn gegenüber dem Auftraggeber unglaubwürdig macht.

Die Konsequenz aus diesem unprofessionellen Umgang mit Aufwandsschätzungen ist, dass Projektleiter den Ruf haben, ihre Projekte würden immer länger dauern und teurer werden als geplant. Und es sieht in der Tat auch so aus, als wenn kein Puffer ausreichen würde, um termin- und budgetgerecht zu bleiben. Sollten Sie als Projektleiter dies ausnahmsweise doch schaffen, dann werden Sie vom Auftraggeber und von anderen Projektleitern hören, dass das Projekt wohl sehr klein und einfach gewesen sein muss oder Sie vermutlich exorbitant viel Puffer eingeplant hätten.

Fehler 3: Projektleiter und Teammitglieder glauben, dass das Bauchgefühl ausreichend für eine gute Schätzung ist

In vielen Firmen, in denen ich gearbeitet habe, gab es immer nur eine Technik für die Aufwandsschätzung: das Bauchgefühl. D.h. Projektleiter und ggf. Teammitglieder schätzen die Arbeitsaufwände und Dauern intuitiv ab, es gibt weder Erfahrungsdatenbanken noch Bewertungsverfahren für die Komplexität oder den Umfang der Aufgabe.

Bei einem sehr erfahrenen und guten Projektleiter, der sein Team gut kennt, ist das eine wertvolle Methode. Doch was passiert, wenn ein Projektleiter, der bisher Software-Entwicklungen geleitet hat, die Aufwände für ein Infrastrukturprojekt schätzen soll und das Team nicht kennt? Dann hilft ihm seine Erfahrung nur sehr wenig.

Beim intuitiven Schätzen kann sich der Projektleiter nicht auf Fakten stützen und er kann nur mit seiner Erfahrung (und der des Teams) punkten. Deshalb ist er vielen Angriffen des Managements, des Projektsponsors und auch des Fachbereichs ausgeliefert, wie z.B.:

• Ihr schätzt zu hoch, um eine ruhige Kugel schieben zu können! (bei internen Projekten)
• Ihr schätzt zu hoch, um mehr zu verdienen! (bei externen Projekten)
• Ihr schätzt so hoch, weil Ihr euch noch gar nicht sicher seid, was zu tun ist!

Wenn das Bauchgefühl als Schätzmethode bevorzugt wird, ist dies zugleich ein Hinweis darauf, dass die Aufwandsschätzung im Unternehmen nicht systematisch durchgeführt wird. Meist ist dort eine Reihe von weiteren typischen Fehlern bei der Aufwandsschätzung anzutreffen:

• Das Team schätzt einmal am Anfang eines Projekts und dann nie wieder. Dies sehe ich häufig bei Wasserfallprojekten, obwohl es dort Phasen gibt, die separat geschätzt werden könnten.
• Die Teammitglieder geben spontan eine Schätzung ab, ohne sich ausreichend Zeit zum Nachdenken zu nehmen.
• Es werden falsche Parameter für die Schätzung verwendet, z.B. wird die Arbeitskapazität eines Mitarbeiters mit 220 Personentagen pro Jahr angesetzt, was keine Ausfallzeiten und Linientätigkeiten berücksichtigt.
• Die Aufwandsschätzung erfolgt erst nach Vertragsabschluss.
• Es werden unternehmensweit nicht dieselben Schätztechniken angewendet.
• Es werden keine Erfahrungswerte gesammelt.
• Die Schätzwerte werden nicht regelmäßig überprüft und angepasst.

Bisher habe ich noch kein Unternehmen kennengelernt, das einheitliche Schätztechniken verwendet und diese systematisch weiter entwickelt. Den besten Ansatz habe ich bei einem Großunternehmen erlebt, dessen Projektmanagement ich als sehr ausgereift empfand. Dort müssen für IT-Projekte alle Aufwände durch mindestens zwei verschiedene Schätztechniken kalkuliert werden. Dadurch ist zum einen gewährleistet, dass nicht nur nach Bauchgefühl geschätzt wird, zum anderen wird den Beteiligten die Unsicherheit von Schätzungen deutlich vor Augen geführt.

Fehler 4: Projektbeteiligte halten gute Aufwandsschätzungen für unnütz und zu aufwendig

Um die oben beschriebenen Schwierigkeiten zumindest teilweise zu überwinden, gibt es die bekannten Techniken zur Aufwandsschätzung. Diese helfen nicht beim Stakeholder Management als solches, bringen die Diskussion aber auf eine sachlichere Ebene als das Bauchgefühl.

Allerdings verkennen viele Projektverantwortliche den Wert und den Nutzen guter Schätzungen. Sie sehen nicht, dass eine aussagekräftige Aufwandsschätzung die Qualität des Projektmanagements deutlich verbessern kann und dass eine schlechte Schätzung die Reputation des Projektleiters mindert. Zudem herrscht das Vorurteil, dass Schätzverfahren, vor allem die algorithmischen Verfahren, zu kompliziert und aufwendig seien.

Aus diesen Gründen verzichten Auftragnehmer meist darauf, sorgfältige Aufwandsschätzungen durchzuführen. Auch unter dem Druck der Auftraggeber, möglichst schnell zu liefern, stellen sie für die Aufwandsschätzung keine ausreichenden Ressourcen zur Verfügung. Statt dessen werden auf die Schnelle Schätzwerte erstellt, die oftmals wenig Aussagekraft haben. Dies wird verstärkt durch die weit verbreitete Einstellung, dass ohnehin alles teurer werde und länger dauere, weswegen die Aufwandsschätzung lediglich als Indikator tauge.

Um zu verstehen, warum Aufwandsschätzungen überhaupt durchgeführt werden sollen, müssen wir uns zunächst klar werden, welche Ziele sie haben. Sie dienen der

• Klärung des Aufwands für die zu erbringenden Projektleistungen in Personentagen
• Eingrenzung und Begründung von Unsicherheiten für geschätzte Aufwände
• Kalkulation des Projektbudgets, zumindest für die nächste Phase (je nach Vorgehensmodell)
• Terminplanung aufgrund der geschätzten Personentage
• Ermittlung des Projektaufwands (so früh wie möglich) und der zeitigen Bereitstellung der Ressourcen
• Vergleichbarkeit von Umfang und Komplexität von Projekten. Damit ermöglichen sie, dass die Schätzungen mit Hilfe von Erfahrungswerten immer präziser werden.
• Beurteilung der Durchführbarkeit eines Projekts (Personenkapazität, Kostenumfang, Zeitumfang, Terminplanung) und der Entscheidungsfindung über die Genehmigung des Projekts
• gezielten Einflussnahme auf die strategische Gesamtplanung des Projektportfolios: Welches Projekt machen wir zuerst, welches sind die "niedrig hängenden Früchte"?

All diese für das Projektmanagement zentralen Ziele können nur erreicht werden, wenn die Aufwandsschätzungen hinreichend zuverlässig sind! Selbstverständlich ist Schätzen keine genaue Vorhersage und auch keine deterministische Berechnung, sondern eine Planung der Zukunft, der Annahmen zu Grunde liegen. Diese sind zusammen mit dem Schätzergebnis zu dokumentieren, da sie sich im Verlauf des Projekts ändern können. Die Kunst der Aufwandsschätzung besteht darin, so nah wie möglich an die Realität zu gelangen.

Der Projektleiter muss deshalb durchsetzen, genügend Zeit und Ressourcen für saubere Aufwandsschätzungen zu bekommen. Genauso sollte der Auftraggeber im eigenen Interesse darauf bestehen, dass die Aufwände auf zwei Arten geschätzt werden, um den ersten, meist auf dem Bauchgefühl beruhenden, Schätzwert zu validieren.

Welche Methode für die Aufwandsschätzung konkret eingesetzt wird, hängt von vielen Faktoren ab, wie z.B. der Projektgröße, den bereits bestehenden Erfahrungswerten, der Qualifikation der Schätzer und vor allem der über das Projekt zur Verfügung stehenden Information. Für jede Situation gibt es neben der intuitiven Schätzung nach Bauchgefühl mindestens eine andere Methode, die sowohl im Aufwand angemessen als auch im Ergebnis ausreichend ist.

Selbst für kleine Projekte kann z.B. die Expertenschätzung nach dem Delphi-Verfahren ohne großen Aufwand durchgeführt werden. Dabei bittet der Projektleiter mehrere Spezialisten, die Arbeitspakete anonym und unabhängig zu schätzen. Der Projektleiter sammelt die Schätzungen und überprüft, ob es größere Abweichungen gibt. Bei Bedarf kommentiert der Projektleiter diese, gibt sie an die Schätzer zurück und bittet um eine erneute Schätzung. Je nach Abweichungen können mehrere Schätzrunden durchlaufen werden, bis die Zahlen in einem für die aktuelle Situation sinnvollen Rahmen liegen. Aus den Schätzwerten können Mittelwerte und auch Unsicherheiten für die weitere Planung gebildet werden.

Neben den Methoden der Expertenschätzung gibt es noch:

• Kennzahlverfahren (z.B. Standardwertmethode, Extrapolationsmethode)
• Vergleichsverfahren (Analogieverfahren)
• Algorithmische Verfahren (z.B. Function Point, Use Case Point, Story Point)

Kennzahl- und Vergleichsmethoden bedingen, dass das Unternehmen abgeschlossene Projekte auswertet und deren gemessenen Aufwände zentral in einer Schätzdatenbank sammelt. Dies ist selten der Fall, was sehr zu bedauern ist, denn auf einer solchen Datenbasis lassen sich sehr schnell aussagekräftige Schätzungen durchführen. Dies gilt vor allem für Standardprojekte, wie z.B. eine BAPI-SAP-Schnittstelle anzusprechen oder einen lesenden Zugriff auf eine Oracle-Datenbank. Kennzahlmethoden sind bei Offshore-Providern in Indien beliebt. Sie schätzen nur den Aufwand für die Entwicklung und ermitteln davon ausgehend mit festen Prozentsätzen die Aufwände für die anderen Phasen.

Für wiederkehrende Projekte mit Auftragscharakter kann auch eine Tabelle mit Standardwerten eingesetzt werden, wie sie Tabelle 1 zeigt. Kennzahlenmethoden haben den großen Nutzen, dass nicht jeder Projektleiter erneut eine individuelle Schätzung erstellen muss.

Bei der Vergleichs- bzw. Analogiemethode werden Messdaten aus früheren Projekten gesammelt und für das zu schätzende Projekt ein möglichst ähnliches, bereits abgeschlossenes Projekt ermittelt. Die Aufwandsschätzung wird dann durch einen Vergleich zwischen den beiden Projekten erstellt. Ich persönlich empfehle, die Vergleichsmethode bis zur ersten abgeschlossenen Projektphase zu verwenden, da sie sehr schnelle und doch aussagekräftige Ergebnisse liefert, solange das Projekt noch nicht im Detail geplant ist.

Die algorithmischen Verfahren stellen zweifelsohne den höchsten Anspruch an die Schätzer, da es sich dabei um sehr mathematische Methoden handelt. Um sie anzuwenden, müssen die Schätzer entsprechend ausgebildet sein. Zu den algorithmischen Verfahren gehört u.a. die Use-Case-Point-Methode, die meiner Einschätzung nach für die Software-Entwicklung am besten geeignet und auch am meisten eingesetzt wird. Voraussetzung für ihren Einsatz ist, dass die Use Cases bereits definiert sind. Ich empfehle daher, sie bei Software-Entwicklungen nach der ersten Projektphase einzusetzen.

Fehler 5: Viele Auftraggeber und Führungskräfte halten Aufwandsschätzung für exakte Vorhersagen

Vielen Kunden und Führungskräften ist nicht bewusst, dass

• "Schätzen" nicht "Errechnen" bedeutet;
• Schätzen stets ein Beurteilungsfehlerrisiko birgt;
• die Schätzung umso genauer ist, je detaillierter die Projektstruktur ist; (Ich stimme nicht der Meinung zu, dass eine große Detailtiefe zu erhöhten Puffern und zu höheren Schätzungen führt.)
• die Schätzgenauigkeit zu Beginn des Projekts gering ist und während des Projektverlaufs immer besser wird;
• Schätzergebnisse nur im Nachhinein überprüfbar oder verifizierbar sind;
• die Schätzung nicht gleich der real anfallenden Kosten ist (s. Fehler 1).

Hinzu kommt, dass Schätzungen vielen Einflussfaktoren unterliegen, die bei der Schätzung zu beachten und während des Projekts zu überwachen sind. Wichtige Einflussfaktoren sind:

Team

Wie erfahren sind die Teammitglieder? Kennen sie die im Projekt eingesetzten Technologien? Sind den Teammitgliedern die Unternehmensprozesse, z.B. für die Qualitätssicherung bekannt?

Projektkomplexität

Geht es um die einfache Implementierung einer Software oder muss ein komplexes IT-System mit vielen Schnittstellen zu anderen Systemen abteilungsübergreifend entwickelt werden?

Infrastruktur und Entwicklungsumgebung

Wie gut unterstützt die verwendete Entwicklungsumgebung die geplanten Arbeiten, z.B. durch einfaches Refactoring? Haben die Entwickler eine ruhige Arbeitsumgebung, so dass sie sich konzentrieren können?

Qualität

Welche Qualität, z.B. hinsichtlich Ausfallsicherheit wird erwartet? Wird die Software zur Steuerung eines Kraftwerks entwickelt oder für den internen Kunden, um die Ablage besser zu organisieren?

Kunde

Wie stark ist er involviert? Welche Kompetenzen hat er auf dem Gebiet? Hat er genug Zeit, um seiner Mitwirkungspflicht nachzukommen und aus fachlicher Sicht die Entwicklung zu unterstützen?

Risikobereitschaft

Welches Gesamtrisiko ist das Team und jeder Entwickler bereit, auf sich zu nehmen? Ist die Unternehmenskultur risikofreudig oder risikoavers?

Die mangelnde Vertrautheit vieler Projektverantwortlicher mit den Charakteristika von Schätzung und die zahlreichen Einflussfaktoren tragen dazu bei, dass die Aufwandsschätzung einen schlechten Ruf hat. Der Projektleiter muss daher dem Auftraggeber zum einen erklären, welchen Wert und welchen Nutzen eine gute Aufwandsschätzung gerade für die Planungssicherheit hat. Zum anderen muss er auch transparent machen, worin die Grenzen der Aufwandsschätzung bestehen.

Fehler 6: Auftraggeber und Vorgesetzte glauben, dass die Aufwände einer professionellen Entwicklung genau so niedrig sind, wie wenn sie selbst programmieren würden

Viele Entscheider und Führungskräfte haben früher selbst Software entwickelt. Manche von ihnen programmieren hin und wieder immer noch für den eigenen Bedarf – z.B. eine Kontaktdatenbank – und sie wundern sich, warum das, was sie selber in einer Stunde programmieren zu können glauben, so teuer sein soll. Aus ihrer Sicht schätzen Auftragnehmer und Mitarbeiter die Entwicklungsaufwände viel zu hoch ein. Führungskräfte kennen aber zum einen die Details und Komplexität der Systeme nicht und berücksichtigen zum anderen nicht, dass für eine professionelle Entwicklung umfangreiche Qualitätssicherungsmaßnahmen unentbehrlich sind, die sie selbst bei Eigenentwicklungen für den persönlichen Bedarf niemals einsetzen würden.

Diese Einstellung führt zusammen mit den bisher genannten Fehlern zum nächsten Fehler, der für die konstruktive Projektarbeit fatale Folgen haben kann.

Fehler 7: Auftraggeber glauben, dass IT-Fachleute immer zu hohe Kosten und zu lange Dauern schätzen

Der Fachbereich eines Finanzdienstleisters, bei dem ich die IT-Entwicklung leitete, wollte das Online-Banking auf mehrere Währungen erweitern. Bisher wurden nur die Währungen Euro, Britisches Pfund, US-Dollar und Yen unterstützt. Jetzt sollte in einem Projekt u.a. die Währungsbasis auf insgesamt 25 Währungen erweitert werden, darunter Rubel, Indonesische Rupie und türkische Lira. Als ich bei der Projektbesprechung die im dreistelligen Personentageberreich liegende Aufwandsschätzung vorstellte, eskalierte die Situation. Die Vertreter der Fachabteilung empörten sich darüber, dass wir für zusätzliche Währungen einen so hohen Aufwand geltend machten. Sie waren der Ansicht, dass doch nur in den Auswahllisten mehr Währungen eingetragen und ein paar Umrechnungen programmiert werden müssten. Zudem gäbe es dies ja schon für die bestehenden Währungen, so dass doch eigentlich gar nicht programmiert sondern nur konfiguriert werden müsste.

Wir hatten große Schwierigkeiten, dem Fachbereich zu erklären, dass türkische Lira und Indonesische Rupia dazu führten, dass die Eingabefelder zu klein waren, dadurch das ganze Layout betroffen war und somit ein Teil der Bedienungsoberflächen umprogrammiert und demzufolge auch mit allen möglichen Anwendungsfällen und zwar in allen Währungen getestet werden müsse.

Bei einem anderen Unternehmen, in dem ich gearbeitet habe, erstellten die Fachabteilungen ein Anforderungsdokument, für das die IT-Abteilung den Realisierungsaufwand abschätzte. Da die Fachabteilungen bei allen Projekten ausnahmslos der Meinung waren, die IT habe viel zu hoch geschätzt und damit implizit den Entwicklern vorwarfen, sie würden zu langsam arbeiten, trafen wir uns zusammen mit den Führungskräften, um die Aufwandsschätzung zu besprechen. Leider unterstützten die Führungskräfte der IT-Abteilung die eigenen Mitarbeiter nicht, so dass die Aufwandsschätzung nach den Vorstellungen der Fachabteilung reduziert wurde.

Es kam, wie es kommen musste: Am Ende des Projekts stellten wir fest, dass durch Change Requests der Projektaufwand von den ursprünglich geschätzten 900 Personentagen auf 1200 Personentage angewachsen war. Der Termin wurde entsprechend nach hinten geschoben. Auch die Qualität war nicht ausreichend, so dass die Nachfolgereleases in Schwierigkeiten kamen. Wir mussten massiv Überstunden leisten und waren in einen Teufelskreis geraten, aus dem wir nicht mehr herauskamen.

In Situationen wie den oben beschriebenen muss der Projektleiter ein starkes Rückgrat haben, wenn er in die Diskussion mit dem Auftraggeber geht. Je mehr er sich auf verlässliche Schätztechniken und auf dokumentierte (!) Erfahrung berufen kann, desto sachlicher wird die Diskussion und die Auftraggeber sind eher bereit, die Schätzung zu akzeptieren. Der Auftraggeber sollte beim Gespräch mit dem Auftragnehmer darauf vertrauen, dass die Aufwandsschätzung nach bestem Wissen erfolgte. Es nützt beiden Seiten mehr, wenn er sich die Annahmen, unter denen die Aufwandsschätzung entstand, erklären lässt, anstatt pauschal eine Reduzierung der Schätzung zu verlangen. Wenn ihm deutlich wird, welche Funktionen einen besonders hohen Aufwand bewirken, kann er ggf. selbst dazu beitragen, den Entwicklungsaufwand spürbar zu reduzieren, indem er z.B. die Anforderungen entsprechend verändert. Zudem muss er sich stets bewusst sein, dass es sich um eine Schätzung handelt, die mit Unsicherheiten behaftet ist.

Fehler 8: Projektleiter glauben, dass die Größe der Arbeitspakete keine Rolle für die Schätzgenauigkeit spielt

Zu hohe Schätzungen können dazu führen, dass ein Projekt nicht durchgeführt wird oder benötigtes Kapital und Ressourcen sinnlos und ohne Mehrwert für das Unternehmen gebunden sind. Zu niedrigere Schätzungen führen dazu, dass die Qualität leidet, der Termin nicht eingehalten werden kann und das Budget überzogen wird. Die Komplexität eines Projekts nicht zu erkennen führt meist dazu, dass Aufwände zu gering und Zeiten zu optimistisch geschätzt werden, so dass am Schluss der Leistungsumfang drastisch reduziert wird und ein Produkt auf den Markt gebracht wird, das in den Regalen liegen bleibt. Das Blackberry Playbook von RIM ist ein plakatives Beispiel dafür: Als Konkurrenzprodukt zum iPad gedacht, kündigte RIM seinen Tablett-PC Playbook bereits im September 2010 an, die Auslieferung erfolgte aber erst Ende April 2011. Allerdings war sein Funktionsumfang so gering, dass das Playbook zum Flop wurde.

Damit die oben beschriebenen Probleme für alle Projektbeteiligten möglichst klein bleiben oder erst gar nicht entstehen, sind zum einen genaue Aufwandsschätzungen erforderlich, zum anderen müssen die Projektbeteiligten eine klare Vorstellung über die Komplexität des Projekts haben. Ein angemessener, gut gegliederter Projektstrukturplan ist Voraussetzung für diese beiden Bedingungen.

Der erste, aus meiner Sicht unerlässliche Schritt für die Aufwandsschätzung besteht deshalb darin, das Projekt in zweckmäßige Arbeitspakete zu strukturieren. Dabei hat die Größe der Arbeitspakete meiner Erfahrung nach einen wesentlichen Einfluss auf die Genauigkeit der Schätzung. Wenn ich ein Arbeitspaket z.B. auf 100 Personentage Aufwand schätze, kann ich keine sinnvolle Aussage über benötigte Pufferzeiten treffen. Entweder wird dann der Puffer vernachlässigt, was fatale Folgen haben kann, oder er wird einfach prozentual mit z.B. 10% aufgeschlagen, was einerseits genauso willkürlich ist und andererseits zu Pufferzeiten führt, die gegenüber dem Auftraggeber schwer zu begründen sind. Arbeitspakete mit einer Größe von mehr als ca. 20 Personentagen sind meist ein Hinweis darauf, dass die Aufgabenstellung noch nicht hinreichend genau definiert ist und man sie deswegen nicht weiter gliedern kann. Wenn umgekehrt Arbeitspakete sehr granular definiert werden, besteht die Gefahr, dass sie durch Aufrundungen künstlich vergrößert werden – z.B. weil man für den Puffer statt 0,1 Tagen 0,5 Tage ansetzt. (Im Artikel Über Hürden zum Erfolg. Critical Chain im Praxiseinsatz" finden Sie weitere Informationen zu Puffern bei Aufwandsschätzungen.)

Für eine gute Schätzung dürfen die Arbeitspakete deshalb weder zu klein noch zu groß sein. Wenn die Aufgaben bis auf Stundenebene detailliert werden, wird der Plan zu umfangreich und der Aufwand für die Schätzungen wird zu hoch, vor allem wenn ein Verfahren wie die Delphi-Methode verwendet wird. Andererseits lassen Arbeitspakete von 20 oder mehr Personentagen sehr viel Spielraum für Interpretation, was Überwachung und Fortschrittskontrolle erschwert. Ich empfehle deshalb, das Projekt in Arbeitspakete von ca. 5 bis 10 Personentagen zu strukturieren, diese lassen sich sehr genau schätzen und hinterher auch überwachen. Auch Scrum schlägt aus gutem Grund vor, dass Sprints maximal 20 Arbeitstage dauern sollten. Natürlich können hin und wieder auch deutlich größere Arbeitspakete sinnvoll sein, wenn es sich um eine in sich geschlossene, klar definierte Aufgabe mit hohem Arbeitsaufwand handelt, wie z.B. die Durchführung von einheitlichen Benutzerschulungen bei einem großen Roll-Out.

Fehler 9: Projektverantwortliche glauben, dass das gesamte Projekt bereits zu Beginn korrekt geschätzt werden kann

Auftraggeber erwarten, dass die erste Aufwandsschätzung während der gesamten Projektlaufzeit gültig bleibt und reagieren mit Unverständnis, wenn sich die Schätzungen im Projektverlauf ändern. Selbst viele Projektleiter sehen die erste Schätzung als eine statische Größe an, die sie nicht wieder zu aktualisieren brauchen.

Aber gerade bei größeren Projekten liegen zu Beginn noch nicht alle für die Aufwandsschätzung benötigten Informationen vor. Erst nach Analyse und Design (wenn wir das Wasserfallmodell verwenden) ist der Leistungsumfang und das Vorgehen so detailliert spezifiziert, dass eine genaue Schätzung möglich ist. Dennoch gehen viele Projektleiter und Auftraggeber davon aus, dass eine präzise Schätzung bereits vorher möglich ist. Als Konsequenz ergeben sich sehr hohe Ungenauigkeiten bei den späteren Projektphasen, insbesondere bei der kostenintensiven Entwicklung und beim Testen.

Um möglichst gute Schätzwerte zu erhalten, die der später zu erbringenden Leistung möglichst nahe kommen, sehe ich folgende Grundprinzipien.

• Eine möglichst genaue Schätzung von Aufwand und Dauer ist die Grundlage für eine möglichst effiziente Entwicklung. Sind die Schätzungen zu hoch, dann verführt dies z.B. dazu, zusätzliche Nice-to-have-Funktionen zu programmieren. Wenn die Schätzung dagegen zu knapp ist, werden Überstunden sowie Wochenendarbeit erforderlich und die Qualität leidet.
• Die Schätzgenauigkeit hängt sehr stark von der Qualität der zur Verfügung stehenden Informationen und dem Detaillierungsgrad der Projektanforderungen ab. Auch die beteiligten Personen beeinflussen die Schätzgenauigkeit (s. Fehler 10). Kurz: Je mehr ich über das Projekt weiß, desto genauer kann ich es schätzen.
• Für eine genaue Schätzung ist ein angemessener Aufwand erforderlich.
• Schätzung ist ein iterativer Verfeinerungsprozess. Es genügt nicht, einmal vor Projektbeginn zu schätzen.

Es ist somit unmöglich, ein großes Projekt für alle Phasen genau zu schätzen. Solange die Anforderungen nur sehr grob definiert sind, beträgt die Schätzungenauigkeit für die Phasen Entwicklung und Testen weit über 50%. Als Faustregel gilt: Wenn ich 10% über das Projekt weiß, dann kann die Schätzung um den Faktor 10 falsch sein, wenn ich 50% weiß, kann ich immer noch um den Faktor 2 daneben liegen.

Deswegen plädiere ich (s. Fehler 4) dafür, zu Beginn eines Projekts zunächst mit groben Schätzverfahren zu arbeiten, um eine schnelle Abschätzung für die gesamten Projektkosten zu erhalten, die demgemäß auch noch entsprechend unsicher ist. Sobald die Anforderungen klar sind, können detailliertere Schätzverfahren, wie z.B. Use Case Point, zum Einsatz kommen und die Unsicherheit der zu erwartenden Projektkosten deutlich reduzieren.

Vorbildlich gelöst ist das Problem der iterativen Aufwandsschätzung bei Scrum: Hier schätzt das Team nur den Aufwand für den nächsten Sprint, denn für diesen weiß jedes Teammitglied genau, was zu tun ist. Aber auch beim Wasserfallmodell ist ein iteratives Schätzen sinnvoll und notwendig: Hier sollte immer nur die nächste Phase genau geschätzt werden.

Fehler 10: Viele Projektleiter übersehen, dass die Präferenzen der Schätzer die Qualität der Schätzung entscheidend beeinflussen.

Völlig unabhängig von der Qualifikation oder Leistungsfähigkeit eines Mitarbeiters beeinflusst sein persönlicher Charakter die Tendenz seiner Aufwandsschätzung. Überaus vorsichtige und gewissenhafte Mitarbeiter werden vermutlich die Aufwände eher hoch einschätzen, um sicher zu gehen, dass sie auf jeden Fall fertig werden können. Andere Mitarbeiter halten vielleicht die Arbeit schon für getan, wenn sie den Lösungsweg sehen und unterschätzen dadurch den Aufwand für die Umsetzung. Der Projektleiter sollte diese Präferenzen kennen, um die Schätzungen der Mitarbeiter bewerten und ggf. gezielt nachfragen zu können. Wenn z.B. ein besonders vorsichtiger und ein besonders optimistischer Schätzer bei der Delphi-Methode ein Arbeitspaket gleich einschätzen, sollte der Projektleiter trotzdem unbedingt nachfragen. Vermutlich hat der optimistische Schätzer ein Problem entdeckt, das dem anderen Schätzer gar nicht bewusst war.

Wenn Sie ein neues Team übernehmen, dessen Präferenzen Sie noch nicht kennen, dann können Sie folgende Übung machen, um in Erfahrung zu bringen, wie das Team und auch einzelne Personen schätzen.

Mit Schätzspiel Team-Präferenzen spielerisch kennen lernen

Die Aufgabe an das Team besteht ganz einfach darin, in mehreren Runden abzuschätzen, wie viele Geldmünzen sich gerade im Raum befinden. Zunächst schreiben Sie auf ein Whiteboard oder eine Flip-Chart die Namen der Teilnehmer untereinander auf und fügen rechts davon vier weitere Spalten an (s. Tab. 2).

Sie erklären den Teilnehmern kurz, dass Sie eine spielerische Übung zum Thema Schätzen machen wollen. In der ersten Runde fragen Sie die Teilnehmer danach, was sie spontan schätzen, wie viele Münzen wohl im Raum sind. Wenn Sie erfahrene Teammitglieder haben, werden ggf. Fragen aufkommen wie z.B.: Nur Euro-Münzen? Auch Münzen ohne Wert? Sollen wir die Münzen in Ihrem Geldbeutel mit schätzen? Das ist ein gutes Zeichen, denn diese Kollegen werden beim Lesen der Anforderungen sehr gute und wichtige Fragen stellen, wenn das Dokument ungenau oder lückenhaft ist. Wichtig ist, dass Sie darauf achten, dass jetzt noch keine Diskussion darüber entsteht, wer wie viele Münzen hat. Damit sie sich nicht gegenseitig beeinflussen, sollen die Teilnehmer ihren Namen und ihre Schätzung auf einen Zettel schreiben und Ihnen geben, so dass Sie in die erste Spalte die "nach Bauchgefühl" geschätzten Werte eintragen können.

In der nächsten Runde darf jeder seine eigenen Münzen zählen. Basierend auf dieser Information soll dann jeder eine erneute Schätzung zunächst auf einen Zettel schreiben und dann abgeben. Für diese Runde sollten Sie die Teilnehmer bitten, nicht miteinander zu diskutieren, da ansonsten ein verzerrtes Bild entsteht. Die neuen Schätzwerte tragen sie nun in die Spalte "Runde 2" ein.

Für die nächste Runde bitten Sie – je nach Teamgröße – zwei bis fünf Mitglieder zu sich und addieren deren Münzzahlen. Diese Summe geben Sie dem Team bekannt, so dass alle wie bereits gehabt eine erneute Schätzung abgeben können. Diese Werte tragen Sie in "Runde 3" ein.

Zum Schluss geben Sie die Diskussion für einen festen Zeitraum (maximal 15 min) frei und lassen nochmals alle individuell schätzen, was jetzt offen per Zuruf geschehen kann.

Am Ende erhalten Sie vielleicht eine Tabelle wie diese:

Tabelle 2: Ergebnis einer Schätzübung im Team.
Bild vergrößern

In den meisten Fällen werden die Werte, zumindest der Durchschnitt (oder Median), immer genauer der realen Zahl entsprechen. Überraschungen sind aber durchaus möglich. Bei einem Team von zwölf Personen ist es mir passiert, dass die drei von mir ausgewählten Kollegen zufälligerweise gerade sehr viel Kleingeld dabei hatten, wodurch die Aufwandsschätzungen am Ende viel zu hoch waren.

Wenn Sie das ganze auflockern wollen, können auch Sie für die Überraschung sorgen und sich vorher bei der Bank mehrere Rollen 10 Cent-Münzen besorgen, die Sie am Ende der Übung auf den Tisch legen.

Das oben angewandte Verfahren ist eine Anlehnung an das oben kurz beschriebene Delphi-Verfahren. Mit dieser Übung lernen Sie zum einen die Präferenzen der Teammitglieder kennen, zum anderen schaffen Sie in Ihrem Team ein Bewusstsein für die Schwierigkeiten der verschiedenen Methoden zur Aufwandsschätzung.

Sie können dies auch dem Team mit den folgenden "Lessons Learned" verdeutlichen:

• Schätzungen aus dem Bauch heraus haben eine hohe Unsicherheit
• Je mehr Informationen ich habe, desto genauer kann ich schätzen
• Überraschungen sind bei Schätzungen immer möglich

Fehler 11: Viele Projektleiter glauben, dass sie ein neues Schätzverfahren problemlos einführen können

Wenn Sie eine neue oder überhaupt die erste Schätzmethode einführen wollen, ist Vorsicht geboten. Damit ist stets ein Veränderungsprozess verbunden, der auf vielfältige Widerstände stoßen kann. Projektmitarbeiter können sich z.B. kontrolliert und überwacht fühlen, wenn statt intuitiver Einschätzungen plötzlich Zahlen und Fakten verwendet werden sollen. Zudem können die Mitarbeiter es als Missachtung ihrer Kompetenz empfinden, wenn an die Stelle ihrer Erfahrung Formeln und Zahlentabellen treten. Auf jeden Fall benötigen Sie als Projektleiter die Unterstützung des Teams und des Kunden, da diese direkt an der Schätzung beteiligt sind. Evtl. brauchen Sie sogar die Unterstützung des ganzen Unternehmens, wenn z.B. eine Schätzdatenbank mit Erfahrungswerten aufgebaut werden soll.

Wenn Sie diese Aspekte nicht berücksichtigen, kann es Ihnen gehen wie dem frisch gebackenen Leiter eines Design Office, der ein Template für Aufwandsschätzungen erstellte. Dieses sollten die Mitarbeiter ab sofort für alle Projekte verwenden, unabhängig von der eingesetzten Technologie und dem betroffenen System, egal ob SAP-Konfiguration, Java-Entwicklung oder auch .Net-Webentwicklung. Das Template war eine vereinfachte Mischung aus Function Point Methode, Use Cases und Bauchgefühl. Um es zu validieren, ließ der Leiter des Design Office Projekte aus jedem Bereich nachschätzen, um sie dann mit den tatsächlichen Werten zu vergleichen. Das ist grundsätzlich ein sinnvolles Vorgehen, damit ein neues Verfahren möglichst schnell erfolgreich ist. Allerdings versäumte in diesem Fall der Leiter des Design Office, den betroffenen Personen zu erklären, warum er so vorgeht, wozu diese Arbeiten sinnvoll sind und welchen Nutzen sie langfristig davon hätten. Die Entwickler hatten den Eindruck, es würde darum gehen, ihnen Ineffizienz nachzuweisen und sie torpedierten das Vorhaben. Die dadurch entstehenden Auseinandersetzungen beschädigten die Zusammenarbeit so nachhaltig, dass der Leiter Design Office die Stelle wechseln musste.

Wenn Sie als Projektleiter oder als Leiter eines PMO in Ihrem Unternehmen ein systematisches Vorgehen bei der Aufwandsschätzung etablieren und bestimmte Schätzmethoden einführen wollen, sollten Sie unbedingt folgende Punkte berücksichtigen:

• Holen Sie die Unterstützung des Oberen Managements ein. Nur mit seiner Unterstützung können Sie den Veränderungsprozess in Gang setzen.
• Erklären Sie den betroffenen Mitarbeitern ausführlich den Zweck und den Nutzen von Aufwandsschätzungen.
• Schulen Sie die Entwickler und Teamleiter in den einzusetzenden Schätzverfahren.
• Erklären Sie den Kunden, warum Sie welches Schätzverfahren verwenden und welchen Nutzen dies für die Kunden hat.

Fazit

Viele vorgefasste Meinungen und festgefahrene Irrtümer verhindern, dass Aufwandsschätzungen für IT-Projekte ihren Nutzen für Auftraggeber, Auftragnehmer und Projektleiter entfalten können. Alle Projektbeteiligten können hierbei wertvolle, wenn auch zunächst nur kleine Beiträge leisten, damit sich systematische und professionelle Aufwandsschätzungen in der Praxis etablieren:

• IT-Abteilungen sollten die tatsächlichen Aufwände ihrer Projekte strukturiert nach Arbeitspaketen aufzeichnen, um so die Grundlage für künftige Schätzverfahren zu schaffen.
• Projektleiter sollten für jedes Projekt einen Projektstrukturplan erstellen, der als Schätzgrundlage geeignet ist. Selbst wenn zunächst immer noch nur nach Bauchgefühl geschätzt wird, verbessert eine systematische Gliederung der durchzuführenden Aufgaben bereits die Schätzgenauigkeit.
• Auftraggeber und Auftragnehmer sollten in den Vertragsverhandlungen nicht über die Höhe der Aufwandsschätzung diskutieren, sondern sich über die zugrunde liegenden Annahmen und die gestellten Anforderungen verständigen.

Dies sind Grundlagen, au