Die IT-Anwender klagen über Budget- und Terminüberschreitungen und fühlen sich durch die Erhebungen von Marktforschern in ihrer Einschätzung bestätigt, dass Softwareentwicklung derzeit eher unkalkulierbarem Kunsthandwerk als einer glasklar zu definierenden Ingenieursarbeit gleicht. Laut "Chaos Report" der Standish Group schlagen 52 Prozent aller IT-Projekte fehl, 15 Prozent werden komplett abgebrochen. Da der Projekterfolg oder -misserfolg am geschätzten Aufwand gemessen wird, stellt sich die Frage, wie verlässlich diese Schätzungen sind und in wie vielen der maladen Projekte die gestellten Anforderungen in dem vorgegebenen Rahmen nicht umzusetzen waren.

Die Risiken der Aufwandsschätzung sind bekannt: Unklar und unvollständig definierte Anforderungen, unzureichende Basisinformationen, Vorgehensweisen wie Bauchwert-, Analogie- oder Price-to-win-Methode sowie die allzu menschliche Tendenz, stets sehr optimistisch zu planen und Schätzungen als Motivationsanreiz zu nutzen. Dennoch ist eine realistische Planung möglich.

Die Arbeit wird nicht weniger

Ausgangspunkt jeder Vorbereitung sollte die Erkenntnis sein, dass Aufwandsschätzungen für Softwareprojekte notgedrungen praxisfern ausfallen und ein Scheitern programmiert ist, solange nicht bekannt ist, wie die gestellten Anforderungen umgesetzt werden. Liegt zu Beginn des Projekts nur ein Grobkonzept vor, so ist eine Schätzung lediglich mit einer Ungenauigkeit von minus 50 Prozent bis plus 100 Prozent oder schlechter möglich. Die Bewertung ist auch deshalb so unscharf, weil im Lauf jedes Projekts zwar zusätzliche, als notwendige erachtete Arbeiten hinzukommen, aber niemals Aufgaben entfallen.

Eine realistische Schätzung in einer frühen Projektphase ist daher nur möglich, wenn ein IT-Dienstleister den Kunden aufgrund einer langjährigen Zusammenarbeit gut kennt und seine fachlichen Anforderungen abschätzen kann. Zudem verfügen manche Großunternehmen über solche Erfahrungswerte aus den eigenen Projekten.

Fazit: Anwenderunternehmen, die eine realistische Aufwandsschätzung möchten, müssen entweder den Erfahrungswerten der IT-Dienstleister vertrauen oder ein eigenes IT-Konzept als Basis der Berechnung unterhalten.

Wissenschaftliche Methoden

Zunehmend werden wissenschaftlich fundierte Gewichtungsmethoden, die auf "Lines of Code" (Cocomo II), "Function Points" oder Use Cases (Essenzschritt-Verfahren) basieren, in Betracht gezogen. In der Praxis haben sie bisher aber wenig Bedeutung, da der Aufwand stets gewaltig ist und die benötigten Eingangsgrößen im Vorfeld selten bekannt sind. Die Verfahren verlangen zudem, die Parameter firmenspezifisch anhand eigener Projekte zu erheben. Dazu ist eine ausreichende Anzahl vergleichbarer Vorhaben erforderlich, was nur Großunternehmen leisten können.

Bewährt hat sich dagegen die Modulmethode, bei der auf Basis des IT-Konzepts alle zu realisierenden Module in Komplexitätsgruppen eingeteilt und mit Erfahrungswerten für den Realisierungsaufwand versehen werden. Je nach eingesetzter Technik werden dann noch prozentuale Zuschläge für Tests, Qualitätssicherung, Integration, Inbetriebnahme und Querschnittsaufgaben dazuaddiert.

Fazit: Formale Gewichtungsmethoden sind nur in Großprojekten anwendbar. Einfache Metrikmodelle, angereichert mit Erfahrungswerten, bilden aber bereits ein solides Fundament.

Schätzung laufend anpassen

Während des Projektverlaufs wird die Schätzbreite immer geringer und liegt zum Projektende natürlich bei null. Leider unterbleibt es oft, während des Projekts die Aufwandsschätzung zu überprüfen und anzupassen, da die erste Schätzung zur Budgetfestlegung, als Zielvorgabe und damit als Messlatte für den Projekterfolg zementiert wurde. Werden die Überschreitungen erst nach Ausschöpfen des Budgets bemerkt, können Folgeaktivitäten nicht rechtzeitig angepasst werden. Dies führt dazu, dass Test- und Qualitätssicherung dem Budget- und Termindruck zuerst geopfert werden, da diese am Ende des Projekts stehen. Unter anderem ist das ein Grund für die beklagte sinkende Softwarequalität.

Fazit: Wer fortlaufend die Aufwandsschätzung überprüft, kann die Planung frühzeitig überarbeiten.

Risiken quantifizieren

Auf jeden Fall gilt es, zumindest die Unsicherheit zu quantifizieren und damit Wissen zu gewinnen, wie verlässlich der ins Auge gefasste Termin und das Budget ist. Für scheinbar unkalkulierbare Einflüsse auf Entwicklungsprojekte wie fehlerhafter Zeitplan, Inflation der Anforderungen, Mitarbeiterfluktuation, Spezifikationskollaps und schwankende Produktivität gibt es branchenspezifische Erfahrungswerte unter der Web-Adresse http:// www.systemsguild.com/riskology/. Mit Hilfe eines Excel-Sheets sind Schätzungen möglich, mit welcher Wahrscheinlichkeit Projekte abgeschlossen werden können. Das heißt, es lassen sich Termine nennen, zu denen sich ein Projekt keinesfalls, mit einer Wahrscheinlichkeit von 50 Prozent und auf jeden Fall fertig stellen lässt. Der erste Zeitpunkt wird als Nano-Prozent-Datum bezeichnet, weil die Wahrscheinlichkeit im Nano-Prozentbereich liegt.

Allzu optimistisch neigen Entwickler dazu, diesen früheste Termin als Zieldatum zu nennen. Sinnvoller ist es, die Unsicherheit zu konkretisieren: Welcher Zeitpunkt ist tatsächlich akzeptabel? Ist der Abgabetermin jedoch unverrückbar, sollte die Frage gestellt werden, ob sich der Funktionsumfang reduzieren lässt.

Fazit: Der Wunschtermin sollte in jedem Fall nach dem Nano-Prozent-Datum liegen und darüber hinaus die quantifizierten Unsicherheiten berücksichtigen.

Sicherheitsreserven einplanen

Abhängig von der jeweiligen Unternehmenskultur werden für die einzelnen Aktivitäten in Softwareentwicklungsprojekten große Sicherheitsreserven einkalkuliert. Trotzdem scheitern sehr viele IT-Projekte, weil Zeitpuffer im Vorfeld ungenutzt verstreichen und weil IT-Fachleute oft in mehreren Projekten im Einsatz sind. Verzögerungen schlagen sich auf den Zieltermin nieder, gewonnene Zeit wird hingegen selten genutzt. Eine bessere Lösung ist, wenn in einzelnen Teilabschnitten gewonnene Sicherheitsreserven in einen globalen Projektpuffer einfließen (Kritische Kette).

Diese Sicherheitsreserven müssen tatsächlich vorhanden sein und auch verwaltet werden. Das ist eher in Großprojekten möglich, weil dort zumeist Sicherheitsreserven einkalkuliert werden. In kleinen Zwei-bis-drei-Mann-Teams wird dagegen häufig knapp und ohne Sicherheitsreservern geplant. Zudem verlangt dieses Vorgehen nichts weniger als einen Paradigmenwechsel in der Unternehmenskultur: Genauso selbstverständlich, wie Zeitreserven aufgebaut werden, müssen sie den Projektteams zur Verfügung stehen, die in ihren Arbeiten in Zeitnot geraten sind.

Fazit: Aufwandsschätzungen müssen auf Sicherheitsreserven untersucht werden. Diese Reserven werden dann in einem Projektpuffer gesammelt, damit sie nicht im Projektablauf verschwendet werden.

Eine kontinuierliche Aufwandsschätzung und die Bestimmung der entsprechenden Schätzbreite erfordern eine solide Basis und viel Aufwand schon im Vorfeld eines Projektes. Es ist allerdings eine Mühe, die sich sehr wahrscheinlich für beide Seiten lohnt, für den Auftraggeber wie für den Dienstleister. Angesichts der hohen Quoten gescheiterter IT-Projekte ist es eigentlich verwunderlich, dass dieser Aufwand so selten betrieben wird. (jha)