In einem beträchtlichen Teil der Softwareprojekte, so zeigten wir in unserem letzten Beitrag (siehe CW Nr. 14 vom 3. April 1992, Seite 58), wird der zu Beginn gesetzte Kosten- und Terminrahmen erheblich überzogen. Dies ist nur zum Teil auf fehlenden Einsatz oder mangelhafte Nutzung systematischer Verfahren zur Aufwandsermittlung zurückzuführen.
Die meisten der untersuchten Projekte wurden in Unternehmen mit langjähriger und ausgeprägter DV-Vergangenheit geplant und durchgeführt. Wie konnte es so häufig zu so gravierenden Fehleinschätzungen des voraussichtlichen Projektvolumens auch durch offensichtlich kompetente und erfahrene Software-Entwickler kommen? Fehlten verläßliche Methoden, fehlte es an deren konsequenter Anwendung? Ein Blick auf unsere Untersuchungsergebnisse scheint solche Vermutungen zu bestätigen: Nur selten wurden systematische Methoden zur Ermittlung des voraussichtlichen Arbeitsvolumens konsequent eingesetzt (siehe Grafik).
In elf Prozent der Projekte erfolgte die Projektkalkulation unter Einsatz entsprechender Methoden, in weiteren 15 Prozent wurden solche Methoden mit erfahrungsbezogenen "ganzheitlichen" Schätzungen kombiniert, während man sich in 57 Prozent ausschließlich auf solch "ganzheitliche" Ansätze verließ. In 13 Prozent unterblieb eine Projektkalkulation. Softwarehäuser gingen zwar häufiger methodengestützt vor, in der Mehrheit der Projekte wurde aber selbst dort auf Methodeneinsatz bei der Projektkalkulation verzichtet.
Tatsächlich wäre es unzulässig, die Problematik der mangelnden Kalkulationstreue auf fehlenden Methodeneinsatz zu reduzieren. In Projekten mit methodengestützter ebenso wie in Vorhaben mit ganzheitlicher Kalkulation kam es zu beträchtlichen Überziehungen des ursprünglichen Rahmens. In 42 Prozent der Projekte, in denen die Kalkulation methodengestützt erfolgte, wurde diese überzogen - gegenüber 44 Prozent der Projekte mit ganzheitlicher Kalkulation. In sieben Prozent blieb man unter dem ursprünglich kalkulierten Aufwand, in 22 Prozent fehlte ein Abgleich.
Zwar waren methodengestützte Aussagen über das voraussichtliche Projektvolumen stabiler als ganzheitliche Ermittlungen, jedoch mußten auch diese zu einem Drittel im Projektverlauf korrigiert werden. Wir müssen hier auf eine detaillierte Auseinandersetzung mit der Leistungsfähigkeit beziehungsweise den Defiziten verschiedener Methoden der Aufwandsermittlung verzichten. Diese hätte den Rahmen unserer Untersuchung gesprengt. Wir können uns hier nur auf die Erfahrungen beziehen, die in den untersuchten Projekten mit Versuchen gemacht wurden, das voraussichtliche Projektvolumen vorherzubestimmen.
Basis für methodengestützte Aufwandsschätzungen war meist die Produktionszeit für einzelne Teileinheiten (function points). Bei solch pointillistischen Betrachtungen wurde der kumulative Effekt von Abweichungen außer Betracht gelassen. Korrekturen oder Veränderungen hatten ja Auswirkungen auf andere Teileinheiten, was wiederum Rückwirkungen zeitigte. Dies alles erforderte Zusatzaufwand, der ohne einschlägige Vorerfahrungen nur schwer aus den nackten Ausgangsdaten abzuleiten war. Nicht zuletzt diese Schwächen methodengestützter Verfahren der Aufwandsbestimmung, suchte man durch "ganzheitliche" Ansätze zu umgehen, in denen man sich wesentlich auf Erfahrungen bezog, die bei der Abwicklung früherer Projekte gemacht wurden.
Keinesfalls können ganzheitliche erfahrungsbezogene Verfahren als eine Vorstufe zum Einsatz formalisierter Methoden gesehen werden. Sie wurden auch in Unternehmen, in denen Software-Entwicklung durchaus sehr professionell betrieben wurde, angewandt, bisweilen in Kombination mit dem Einsatz methodengestützter Verfahren, wobei diesen dann eher eine untergeordnete Bedeutung zukam, als Orientierungsgrundlage für bestimmte Teilaspekte, nicht aber als Berechnungsmodus, der sozusagen selbsttätig zu einem verläßlichen Ergebnis führen würde. Dort, wo einschlägige Vorerfahrungen mit ähnlichen Entwicklungsaufgaben vorhanden waren, lieferte ein solches Vorgehen Ausgangsdaten, auf deren Basis dann relativ verläßliche Einschätzungen des zu erwartenden Arbeitsaufwands möglich erschienen. Bei neuartigen Entwicklungsaufgaben, wo solche Vorerfahrungen nicht gegeben waren, hat auch dieses Verfahren kaum zu tragfähigen oder sogar irreführenden Ergebnissen geführt, vor allem dann, wenn Erfahrungswerte auf neue, andersartige Entwicklungsaufgaben weitgehend analog übertragen wurden.
Zu Fehleinschätzungen trug zweifelsohne die beträchtliche und mehrdimensionale Komplexität von Software-Entwicklungen bei, die sich - zumindest bei innovativen Vorhaben - einer rein additiven Einschätzung entzog. Die Komplexität des Ganzen war nicht durch eine Addition von Einzelkomplexitäten zu errechnen.
Ein Verständnis dieser Komplexität und natürlich in viel stärkerem Maße auch ihre Bewältigung erschloß sich erst in einem mühseligen Prozeß schrittweiser Einarbeitung. Der Ablauf vieler Projekte, die wir untersuchten, war dadurch gekennzeichnet, daß die Komplexität der Entwicklungsaufgabe - und die sich daraus ergebenden Konsequenzen - erst allmählich entdeckt wurden. Dabei ging es nicht allein um die Komplexität der technischen Entwicklungsaufgabe, sondern vor allem auch um die Komplexitäten im Anwendungsbereich, das heißt der Aufgabenstellungen und deren Abhängigkeiten von einer Vielzahl von sehr unterschiedlichen Faktoren; auch die Komplexität des Durchsetzungs- und Realisierungsprozesses spielte eine Rolle. Gerade bei Projekten mit innovativen Aufgaben wurden diese verdeckten, nicht technischen Komplexität en häufig unterschätzt, dies um so mehr, als ein rein technisches Aufgabenverständnis bei den Entwicklern bestimmend war.
Unterschätzung der Komplexität
Das Phänomen, daß in vielen Projekten Verzögerungen gerade in den Frühphasen auftraten, in denen es um eine genauere Bestimmung der Gestaltungsaufgaben ging, dürfte nicht zuletzt darauf zurückzuführen sein. Nun bleibt weiterhin erklärungsbedürftig, warum es immer erneut zu einer Unterschätzung dieser Komplexität und damit des notwendigen Arbeitsaufwands kam - auch durch erfahrene Software-Entwickler, die ja in früheren Projekten bereits mehrfach mit diesem Phänomen konfrontiert worden waren. Fred Brooks führt dies auf den Software-Optimismus zurück: "Alle Programmierer sind Optimisten. Vielleicht fühlen sich gerade jene von dieser Art moderner Hexerei angezogene die an Happy-Ends und gute Feen glauben. Die erste falsche Annahme bei der Zeitplanung des Systemprogrammierens ist: es wird schon alles klappen, das heißt jede Aufgabe braucht so viel Zeit, wie sie brauchen soll." (Brooks, S. 13)
Dieser Neigung, gegen bessere Erfahrung davon auszugehen, daß schon alles klappt, begegneten auch wir immer wieder. Allerdings müssen neben der Psychologie auch die Randbedingungen, unter denen Projekte zustandekamen und durchgeführt wurden, zur Erklärung mit herangezogen werden. Unverkennbar war die Kalkulation vielfach ein Politikum: Instrument in der Auseinandersetzung um den Umfang oder gar die Berechtigung des Entwicklungsprojekts, wobei die ermittelten Zahlen dann nur das Vehikel waren, über das ganz ändere Kontroversen ausgetragen wurden. Oft hatte der Faktor Zeit erhebliches Gewicht für die Genehmigung eines Projekts. Die Durchsetzbarkeit eines Projekts war in vielen Fällen primär eine Frage des Zeitpunkts, zu dem das Softwareprodukt bereitgestellt werden konnte. Nicht selten spielte dieser Aspekt noch eine größere Rolle als die voraussichtlichen Kosten.
Meist wurden solche Projekte als Reaktion auf mehr oder weniger drängende Probleme anvisiert, die Lösungen verlangten. Dabei war dann der Zeitpunkt, zu dem die Lösung zur Verfügung stehen würde, ein Entscheidungsparameter. Deutlich zum Tragen kam diese politische Qualität von Zeitschätzungen in einem Unternehmen, in dem eine Projektvariante nicht zuletzt deshalb den Vorzug erhielt, weil sie in kurzer Zeit realisierbar sein sollte. Dabei wurde das Volumen des geplanten Projekts außerordentlich kontrovers eingeschätzt. Während die Promotoren von einer Laufzeit von zwei Jahren ausgingen, veranschlagten Kritiker einen erheblich höheren Zeit- und Kostenaufwand.
Die Bewilligung des Projekts erfolgte auf der Grundlage der "Kalkulation" der Promotoren. Tatsächlich waren dann nach zwei Jahren Laufzeit des Projekts erst etwa 20 Prozent des Entwicklungsaufwands abgearbeitet. Bisweilen wurde das Projektvolumen ganz offensichtlich wissentlich und bewußt zu niedrig angesetzt, um die interne Durchsetzung des Projekts zu erleichtern.
Die Software-Entwicklungsabteilung eines großen Herstellers wurde vom Vertrieb mit der Entwicklung eines Programms zur automatisierten Fehlersuche in einem der Produkte des Unternehmens beauftragt. Der Projektleiter erarbeitete einen Termin- und Budgetvoranschlag, der allerdings von den Projektmitarbeitern als unrealistisch niedrig abgelehnt wird. Tatsächlich wurde dieser Voranschlag dann aber auf die Forderung des Vertriebs hin noch weiter gekürzt. Man befürchtete, daß beim realistischen Kostenvoranschlag das Projekt im Haus nicht durchsetzbar sein würde. Allerdings unternahmen weder der Projektleiter noch die Auftraggeber im Vertrieb den Versuch, dies bei der Leitung des Vertriebs beziehungsweise der Entwicklungsabteilung durchzusetzen.
Vielmehr gingen Projektleiter und Auftraggeber im stillschweigenden Einverständnis davon aus, daß es im weiteren Projektverlauf schon gelingen werde, den Zeit- und Kostenplan einer realistischen Größenordnung anzunähern. Bestimmend war also die Einschätzung, daß eine Korrektur des Budgets im Projektverlauf leichter durchzusetzen sei als ein realistischer Kostenansatz zu Beginn. In diesem Fall ging allerdings diese Rechnung nicht auf, das Projekt wurde abgebrochen, nachdem statt der ursprünglich angesetzten 15 Arbeitsjahre bereits 30 Arbeitsjahre Investiert worden waren, ohne daß eine lauffähige Version als Ergebnis zustande kam.
Nicht die Kostenkalkulationen liefern in solchen Fällen Kriterien für die Entscheidungen, sondern die Berechnungen orientieren sich umgekehrt an den Kriterien der Entscheidung.
Nun könnte man annehmen, daß solch politischer Druck für die einzelnen Entwickler nicht im selben Maß wirksam sein sollte wie für die Promotoren eines Projekts, daß die Entwickler eher an einer realistischen Aufwandsschätzung interessiert sein müßten, kann ihre Leistung doch später an dieser Schätzung gemessen werden. Aber auch bei ihnen war das Prinzip systematischer Aufwandsunterschätzung wirksam. Ironischerweise führten bisweilen ein starker Legitimationsdruck und die Anforderung, Kosten möglichst exakt vorher zu bestimmen, dazu, daß das Projektvolumen zu niedrig angesetzt wurde.
Die Rolle des Kritikers an unrealistischen Projektkalkulationen scheint jedoch vielfach undankbar gewesen zu sein. Mehrere unserer Gesprächspartner berichteten, daß ihre Versuche, eine realistischere Projektkalkulation durchzusetzen, nur auf geringe Resonanz gestoßen sei. "Ich galt damals als Bremser, der dem Neuen nicht aufgeschlossen war. Heute hat sich herausgestellt, daß ich recht gehabt habe, aber davon will jetzt niemand mehr etwas wissen, so einer unserer Gesprächspartner."
In der Frühphase war Realismus nicht gefragt
In dem von Aktionismus, Erwartungen und unter Umständen Problemdruck geprägten Klima in den Frühphasen von Projekten war Realismus nicht gefragt. Und nach Abschluß des Projekts brachte der Verweis auf die richtige Prognose, die man - unter Umständen vor mehreren Jahren - abgegeben hatte, wenig. War es erst einmal begonnen, so arbeitete die Zeit für das Projekt. Ab einem gewissen Zeitpunkt gab es kaum mehr ein Zurück - wegen des bereits investierten Aufwands, weil Alternativen nicht systematisch verfolgt worden waren und schlicht wegen der inzwischen vergangenen Zeit, in der sich in der Regel der Handlungsdruck weiter verstärkt hat.
Bei einigen Projekten wurde der Zeitpunkt verbindlicher Aussagen über das Projektvolumen bewußt hinausgeschoben um die Entscheidungslage möglichst weitgehend vorzustrukturieren. In dem Maß, in dem Vorarbeiten bereits geleistet und Kosten entstanden waren, erscheint die Übernahme weiterer Kosten als notwendige Folge.
Erklärung für die subversive Einleitung
Dieser Zusammenhang dürfte nicht zuletzt die subversive Einleitung vieler Projekte erklären. In der Regel ging die Rechnung mit der zu niedrig angesetzten Kalkulation des Projektvolumens auf. In den meisten uns bekannten Fällen blieben Überziehungen folgenlos, zumindest für die Verantwortlichen der ursprünglichen Projektkalkulation. Zum Teil waren diese bei Projektende nicht mehr im Projekt beschäftigt, unter Umständen in höhere Positionen aufgerückt und damit nur noch schwer zu belangen. So stellte sich kaum die Gefahr, an den ursprünglichen Zeitvorgaben gemessen zu werden. Die Macht des Faktischen ließ diese rasch als Schnee von gestern erscheinen; eine Nachevaluierung wäre zum akademischen Unterfangen geworden, ganz abgesehen davon, daß sie sich angesichts der zahlreichen Änderungen außerordentlich schwierig gestaltet hätte.
Dieser Folgenlosigkeit nicht eingehaltener Projektkalkulationen begegneten wir selbst in Softwarehäusern, in denen die Projekte während ihrer Laufzeit einer recht stringenten Kontrolle unterworfen waren und ein ständiger Soll-Ist-Abgleich stattfand. Der damit verbundene Druck traf die aktuell Verantwortlichen, häufig aber nicht mehr die Urheber der Kalkulation, die bereits in andere Positionen übergewechselt waren.
Die Folgenlosigkeit solcher Berechnungen muß auch gesehen werden vor dem Hintergrund der institutionellen Verankerung der Abteilungen, in denen Software entwickelt wird, der Freiräume, die sie sich geschaffen haben, und der Hilflosigkeit der Stellen, die über die Projekte entscheiden. Vielfach vermittelte sich der Eindruck, als habe man in den oberen Management-Ebenen resigniert, die Eigendynamik von Software-Entwicklungsprojekten wirklich in den Griff zu bekommen, und lege lediglich Wert darauf, den Schein einer durch exakte Vorausberechnungen gestützten Entscheidung zu wahren.
All dies verleiht dem Umgang mit der Projektkalkulation in vielen Unternehmen stark rituelle Züge: Zahlen als Beschwörungsformeln, an deren Realitätsgehalt keiner so recht glaubt und die doch wirksam ist. "The most important art of a result, a measure, an estimate, a conclusion, or a prediction is not the quantitative statement itself. It is the confidence we can place in the figures." (Gilb, S. 77), Dieses Postulat von Tom Gilb ist reine Theorie. Die tatsächliche Akzentsetzung ist genau entgegengesetzt: Wichtig sind genaue Zahlen, genaue Termine, nicht das Vertrauen, das man in ihre Einhaltung setzt.
Nur ein Minimum an Änderungen und Erweiterungen
Folgenlos allerdings waren unrealistische Aufwandsabschätzungen nicht für die jeweiligen Projekte selbst. Solche Fehleinschätzungen wirken sich nicht nur auf die finanzielle Ebene aus, in Form hoher Kosten. Sie schlugen auch auf die Abwicklung des Projekts wie auf dessen Resultate durch. Ob eine opulente Lösung mit einem Übermaß an Funktionalitäten angeboten wurde oder ein karges Miniprogramm, in welcher Weise der Anwendungsbezug, ergonomische Aspekte etc. berücksichtigt wurden, all dies hing bisweilen nicht so sehr von den Zielvorgaben eines Projekts oder von der Planung der einzelnen Arbeitsschritte ab, sondern schlicht davon, welcher zeitliche und budgetäre Rahmen mit welcher Verbindlichkeit vorgegeben wurde.
So führte der zu gering veranschlagte Aufwand für die Anpassung eine Standardsoftware durch die DV-Abteilung eines Unternehmens dazu, daß an der Schulung und Betreuung der Anwender gespart wurde. Resultat war, daß die angebotenen Funktionen kaum adäquat genutzt wurden. Für ein Projekt, das ein Softwarehaus für einen externen Auftraggeber durchführt, wurden zu Beginn klare Vorgaben für Termin- und Projektvolumen fixiert auf der Grundlage eines, so schien es zunächst, sehr fundierten und genau umschriebenen Projektauftrages. Obwohl sich sehr rasch bei einer genaueren Analyse der vom Auftraggeber gestellten Unterlagen herausstellte, daß ein Teil der Vorgaben fragwürdig war, richtet sich der weitere Projektablauf stark an deren Einhaltung aus - mit der Folge, daß nur ein Minimum an Änderungen und Erweiterungen zugelassen wurde, auch dort, wo ein großzügigeres Vorgehen sinnvoll gewesen wäre.
In zahlreichen Projekten bestimmten die vorgegebenen Termine den Personaleinsatz. Der Versuch, diese einzuhalten, führte zum Beispiel zum massiven Einsatz von kurzfristig angeheuertem Personal - meist mit eher zweifelhaften Auswirkungen, nicht zuletzt auf die Qualität des erzeugten Softwareprodukts. Negativ wirkten sich irdukts. Negativ wirkten sich irreale Zeitabschätzungen, die dann im Verlauf immer wieder korrigiert werden mußten, auch in einigen Projekten auf die Motivation der Entwickler aus. Einige Projekte gerieten durch die Überziehung des ursprünglich anvisierten Kosten- und Terminrahmens unter erheblichen Druck, der allerdings nur in einem der untersuchten Fälle auch zum Abbruch führte.
Zusammenfassend kann festgestellt werden, daß die Ursachen für die geringe Zuverlässigkeit und Stabilität von Vorausschätzungen des Projektvolumens nicht allein in der mangelnden Leistungsfähigkeit und Nutzung von Methoden zu suchen sind, sondern auch wesentlich in dem betriebspolitischen und organisatorischen Umfeld, in dem diese eingesetzt werden. Vieles spricht dafür, daß Versuche, zuverlässigere Aussagen über das zu erwartende Projektvolumen zu erhalten, nicht so sehr an einer weiteren Verfeinerung der Methoden ansetzen müssen als an der Strukturierung eben jenes Umfelds. In den nächsten Folgen werden wir uns mit diesen auseinandersetzen.
Literatur: F.P. Brooks: Vom Mythos des Mann-Monats. Bonn, 1987.
T. Gilb: Principles of Software Engineering Management. Wokingham, 18.