Kennen Sie ein IT-Projekt, das am Ende genau den Aufwand gekostet hat, der schon bei Projektstart geschätzt worden ist? Oder ist es nicht vielmehr so, dass spätestens zur Projektmitte zusätzlicher Bedarf angemeldet werden muss? Trotzdem arbeitet das ganze Team in den letzten Wochen fieberhaft und macht Überstunden, um den zugesagten Endtermin halten zu können.

Aufwandsschätzung für ein IT-Projekt ist immer ein heißes Thema. Der Vertrieb möchte einem Kunden ein "gutes" Angebot für sein IT-Vorhaben vorlegen und erwartet vom Projektleiter, dass er ihm einen "vertriebsorientierten" Aufwand dafür nennt. Der Aufwand darf nicht zu hoch angesetzt werden, sonst ist die Konkurrenz möglicherweise billiger. Andererseits darf der Projektleiter ihn auch nicht zu niedrig ansetzen, denn dann droht der Auftrag ein Verlustgeschäft zu werden. Die Kunst der Aufwandsschätzung liegt gerade darin, trotz aller Unsicherheiten und Unwägbarkeiten - unklare Spezifikationen, Stakeholder mit gegensätzlichen Interessen, technische Risiken, Ressourcenengpässe etc. - einen wahrscheinlichen Aufwandswert zu ermitteln, auf dessen Basis man ein verbindliches Angebot erstellen kann. Einfach den Wert zu nennen, den der Vertrieb erwartet, oder die Schätzung den Betriebswirten zu überlassen kann schnell im Desaster enden.

Ähnlich wie beim Autokauf interessiert den Auftraggeber eines Softwareprojekts nicht, wie die Software produziert wird. Er hat lediglich eine klare Vorstellung über die wichtigsten Funktionen, über Antwortzeitverhalten, Stabilität und Zuverlässigkeit, eventuell auch über die Bedienerfreundlichkeit. Fest verankert sind in der Regel dagegen Vorstellungen über den Liefertermin und das Projektbudget.

Jedes IT-Vorhaben ist also bestimmt von den Eckwerten Budget, Termin und Kernfunktionalität. Sie bilden das magische Dreieck, innerhalb dessen die Softwareentwicklung wie ein Spinnennetz mit allen ihren unbestimmten Parametern gesponnen werden muss. Dieses Netz ist in alle Richtungen dehnbar. Es enthält die Freiheitsgrade für die spätere Entwicklungszeit: die Detailfunktionen, die Zusammensetzung des Projektteams und den Umgang mit Risiken und Unvorhergesehenem. Wird das Netz zu stark gedehnt, weil das aufgespannte Dreieck zu knapp bemessen ist, reißt es.

Die Aufwandsschätzung für ein geplantes IT-Vorhaben muss sicherstellen, dass diese Eckwerte ein Dreieck aufspannen, das genügend Platz für das "Entwicklungsnetz" bietet.

Die bekanntesten Schätzverfahren

Es gibt zahlreiche Schätzmethoden. Sie unterscheiden sich durch die Art der Quelldaten und durch die Form der Ermittlung der Zieldaten. Im Wesentlichen lassen sich Schätzmethoden in drei Kategorien untergliedern:

- Produktschätzungen, die die Funktionalität der zu erstellenden Software messen, ohne die innere Struktur zu kennen;

- Prozessschätzungen, die den Aufwand jedes Entwicklungsschritts ermitteln;

- Analogieschätzungen, die den Aufwand aus dem benötigten Aufwand vergleichbarer IT-Vorhaben ableiten.

Die Schätzmethoden können unter verschiedenen Strategien eingesetzt werden:

- Pricing to win, bei der der Aufwand aus den beim Auftraggeber zur Verfügung stehenden Mitteln abgeleitet wird;

- Kombination verschiedener Schätzmethoden;

- Expertenbefragung, bei der ein Experte den Aufwand aus seiner Erfahrung heraus schätzt (genau genommen ebenfalls eine Kombination aus verschiedenen Schätzmethoden);

- Schätzklausur, eine Art Expertenbefragung, in der mehrere Experten gemeinsam schätzen.

Zu den bekanntesten Schätzverfahren gehören Cocomo und Function Point. Function Point ist eine Kombination aus Produkt- und Analogieschätzung. Mit ihr misst man zunächst die Komplexität der zu erstellenden Software, also eine Produktschätzung, und ermittelt dann die Aufwände auf Basis vergleichbarer, anderer Projekte, also eine Analogieschätzung, die in einer Erfahrungsdatenbank abgelegt sind. Die Mühe, eine Datenbank mit vergleichbaren Projekten anzulegen und zu pflegen, ist enorm und übersteigt die Möglichkeiten kleiner und mittlerer Unternehmen. Ähnlich ist es mit vielen anderen Methoden, sie sind zu komplex oder aufwändig, der Eigenaufwand, den sie erfordern, steht in keinem Verhältnis zu ihrem Nutzen.

Weit verbreitet ist die Expertenschätzung, da sie am einfachsten zu organisieren ist. Sie ist eine Kombination aus Produkt-, Prozess- und Analogieschätzung, jedoch in einer wenig systematischen Form. Bei diesem Verfahren überlegt sich der Entwickler die wichtigsten Funktionen der zu erstellenden Software, nimmt die groben Entwicklungsschritte wie Analyse, Design, Codierung, Test und schätzt dann pro Funktion und Entwicklungsschritt den Aufwand aus seiner Erfahrung heraus. Den ermittelten Wert versieht er mit einem zehnprozentigen Risikozuschlag. Obwohl dieses Verfahren recht simpel ist, kommt der so ermittelte Wert dem realen Aufwand erstaunlich nahe, wenn der Entwickler sehr viel Erfahrung hat. Wenn jedoch das IT-Vorhaben technologisch neu ist oder kein Experte zur Verfügung steht, ist dieses Verfahren nicht anwendbar.

Wenig Erfahrung, gute Ergebnisse

Die Expertenschätzung kann so systematisiert werden, dass sich auch mit weniger Erfahrung gute Schätzergebnisse erzielen lassen. Der Aufwand wird durch Kombination verschiedener Schätzverfahren iterativ ermittelt: Es werden mehrere Schätzmethoden angewendet, die jede für sich ungenau sein kann und deshalb mit einem weniger großen Eigenaufwand verbunden ist. Durch Vergleich der Einzelergebnisse und Analyse der Unterschiede werden dann in weiteren Iterationen die Quelldaten für jede Methode so lange präzisiert, bis alle Methoden das gleiche Schätzergebnis liefern. Diese Schätzung erfolgt in Form eines Workshops, in der die Schätzung durch einen "Schätzexperten" moderiert und gesteuert wird.

Dieser Schätzexperte kann ein erfahrener Entwickler aus dem Unternehmen oder ein externer Berater sein. Es ist nicht notwendig, dass er Fachkenntnisse zu dem geplanten IT-Vorhaben besitzt. Er muss jedoch aus seiner Erfahrung heraus in der Lage sein, Risiken zu erkennen und abzuschätzen, ob die Anforderungen für eine Kalkulation ausreichend definiert sind und welche Entwicklungsschritte mindestens zur Realisierung des IT-Vorhabens notwendig sind.

Zur Vorbereitung der Schätzung erhält er alle verfügbaren Unterlagen wie Anforderungsdefinition, Benutzerhandbücher, Dokumentationen von Vorgängeranwendungen, Informationen über vergleichbare Projekte.

An der Schätzung sind der Schätzexperte und der designierte Projektleiter, bei großen Vorhaben mindestens ein weiterer fachlich versierter Mitarbeiter beteiligt. Sofern bereits Teammitglieder und ihre Aufgaben bekannt sind, sollten diese "ihr" eigenes Aufgabenpaket ebenfalls vorab schätzen.

Unwägbarkeiten in der Risikoliste

Zu Beginn werden potenzielle Risiken betrachtet. In einer Risikoliste werden alle gefährlichen Unwägbarkeiten separat erfasst, ihre Entrittswahrscheinlichkeit und ihre Auswirkungen auf das Projekt bewertet. Je mehr Gefahren berücksichtigt werden, desto geringer ist das Risiko einer zu niedrigen Aufwandsschätzung.

Als Schätzmethoden sollten mindestens eine Produkt- und eine Prozessschätzung erfolgen. Als Produktschätzung kann eine vereinfachte Form von Function Point angewendet werden.

Zunächst wird die Funktionalität der zu erstellenden Software in kleinere Funktionspakete zerlegt. Je mehr über die zu erstellende Software bekannt ist, desto elementarer können die Funktionen zugeschnitten werden und desto geringer wird damit das Risiko einer Fehleinschätzung. Die Funktionspakete ergeben sich durch die Anforderungsdefinition, die Betrachtung der ein- und ausgehenden Daten oder die bereits bekannte Benutzeroberfläche. Eine zusätzliche Informationsquelle stellt, falls vorhanden, die Dokumentation der Vorgängeranwendung dar. Sind die Pakete sinnvoll "geschnürt", gewichtet das Gremium sie entsprechend ihrer Komplexität. Der Schätzexperte unterstützt diesen Prozess durch fachkundige Befragung.

Jedes einzelne Paket wird dann direkt mit Erfahrungswerten aus anderen Projekten verglichen, das heißt, man vergleicht den Aufwand für eine komplexe Funktion mit dem früher benötigten Aufwand einer ähnlich komplexen Funktion. Hat man noch keine Vergleichswerte, weil es etwa das erste IT-Projekt in dem Unternehmen ist, kann ein externer Berater als Schätzexperte mit seiner Erfahrung helfen. Die Summe der Einzelaufwände ergibt dann den geschätzten Gesamtaufwand. Damit hat man einen ersten Näherungswert für den Aufwand, der jedoch mit Sicherheit noch sehr ungenau ist.

Für die Prozessschätzung wird der Entwicklungsprozess in alle abzusehenden Aktivitäten zerlegt. Dazu gehören auch das Projekt-Management oder das Konfigurations-Management und beim Projekt-Management wiederum der Aufwand für Team-Meetings oder Verhandlungen mit dem Auftraggeber. Der Schätzexperte unterstützt hier bei der Definition der Einzelaktivitäten.

Bei den Entwicklungsschritten wird der Aufwand für jede Aktivität und jede Elementarfunktion separat geschätzt. Da das Entwicklungsteam zu diesem Zeitpunkt noch nicht feststeht, wird ein Team mit mittlerer Erfahrung angenommen. Jede Aktivität wird daraufhin überprüft, ob eines der gefundenen Risiken aus der vorab erstellten Risikoliste sich auf den Aufwand auswirkt. Zu jeder Aktivität schätzt man einen Minimalwert so, als ob alles optimal laufen würde, einen Normalwert und einen Maximalwert, in den die gefundenen Risiken eingehen. Ist für eine Aktivität noch kein Risiko erkennbar, wird der Maximalwert um mindestens zehn Prozent höher als der Normalwert angenommen. Denn auch wenn jetzt noch kein Risiko bekannt ist, es wird mit Sicherheit später eines eintreten.

Die kalkulierten Werte werden anschließend summiert und aus den Summen der Minimal-, Maximal- und Normalwerte jeweils der Mittelwert gebildet. Mit statistischen Verfahren, etwa der Normalverteilung, kann dann ermittelt werden, mit welcher Wahrscheinlichkeit welcher Aufwand benötigt wird. Die Erfahrung hat gezeigt, dass der Aufwand, der mit 80-prozentiger Wahrscheinlichkeit angenommen wird, sich mit den Ergebnissen der Produktschätzung deckt, die ja wiederum auf Erfahrungswerten basiert. Wählt man einen Wert mit größerer Wahrscheinlichkeit, steigt die Gefahr, dass der geschätzte Aufwand zu hoch angesetzt wird, da ja viele Risiken (hoffentlich) gar nicht eintreten.

Diese Schätzwerte, eventuell wurden noch weitere Schätzungen zum Beispiel über die Analogiemethode angewendet, werden nun miteinander verglichen. Mit Sicherheit weichen die Werte nach diesem ersten Durchgang voneinander ab. Im nächsten Schritt sind nun die Gründe für die Abweichungen zu finden. Mögliche Ursachen sind etwa das Vergessen wichtiger Funktionen in der Produktschätzung oder eine zu leichte Bewertung für eine komplexe Funktion. Oder es wurde der Aufwand für eine komplexe Funktion bei den Einzelaktivitäten unterschätzt. Durch die sukzessive Analyse der Abweichungen werden die Quelldaten für die einzelnen Schätzmethoden präzisiert. Nach höchstens drei Iterationen sollten dann die Schätzwerte nicht mehr gravierend voneinander abweichen.

Vorgehen passt zur Projektstruktur

Die Erfahrung hat gezeigt, dass diese Form der Aufwandsschätzung für mittelgroße Projekte maximal einen Tag dauert. Für sehr große Projekte, bei denen am Anfang noch sehr viel unbekannt ist, sind manchmal mehrere Schätzrunden erforderlich.

Dafür erkennen die Projektverantwortlichen im Schätz-Workshop rechtzeitig, wo Unklarheiten sind und welche zusätzlichen Informationen sie für eine hinreichend gesicherte Aufwandsschätzung noch benötigen.

Wegen der Moderation des Schätzungsprozesses durch einen Außenstehenden sowie infolge der Anwendung von mehreren Methoden und die dadurch mögliche Präzisierung der Quelldaten erzielt diese Strategie einen guten Wert für den zu erwartenden Aufwand.

Sie liefert Informationen darüber, ob das IT-Vorhaben innerhalb des magischen Dreiecks von Budget, Termin und Kernfunktionalität realisiert werden kann, wie groß die Teamstärke sein und wie das Spinnennetz gewebt werden muss, damit die Rahmenbedingungen eingehalten werden können. Auf dieser Basis lässt sich dann eine Projektstruktur und ein Vorgehen wählen, das das Erreichen des Ziels absichern kann. (bi)

*Helga Lüpschen ist freie Journalistin in Aachen.

Abb.1: Systematisierte Expertenschätzung

Die Expertenschätzung wendet mehrere Methoden an, die jede für sich ungenau sein kann und deshalb mit einem weniger großen Eigenaufwand verbunden ist. Durch Vergleich wird so lange präzisiert, bis alle Methoden das gleiche Ergebnis liefern. Quelle: Tema

Abb.2: Ein Spinnennetz knüpfen

IT-Projekte im magischen Dreieck von Funktion, Budget und Termin. Quelle: Tema