Helmuth Bergen, GMO Gesellschaft für moderne Organisationsverfahren, Hamburg

Ein EDV-Projekt läßt sich vom Aufwand her wie folgt gliedern:

15% Planung

25% Organisation

35% Programmierung

40% Test

10% Dokumentation

________________________________

125%

Ergebnis: Ein Projekt muß den Zeitplan mindestens um 25 Prozent überschreiten? Dieser Scherz ist alt; die Problematik, die er beschreibt, ist nach wie vor aktuell.

Offensichtlich liegt es daran, daß die Gründe fehlerhafter Aufwandsschätzungen vielfältig sind. Es beginnt damit, daß der Begriff "Schätzung" in der Datenverarbeitung mit "vage Vermutung" gleichgesetzt wird und Schätzungen entsprechend dadurch zustande kommen, daß einige, die sich berufen fühlen (gewöhnlich beim Mittagessen oder anderweitiger Verrichtung), ihre Ansichten, Mutmaßungen sowie Informationen aus zweiter und dritter Hand austauschen. Dabei ist es nicht seiten daß über das System, dessen Erstellung die Schätzung gibt, keine oder nur geringe Festlegungen bekannt sind, das macht es leicht, über Aufwand - oder noch besser Preis - ein kompetentes Urteil abzugeben. Denn während ein Verkäufer im 1. Lehrjahr sich nach dem Preis für ein System zum Transport von Kartoffeln befragt (sich je nachdem, ob er in der Stadt oder auf dem Lande aufgewachsen ist ein Einkaufsnetz oder einen Lkw vorstellend), gelernt hat weitere Auskünfte zu erfragen gehört es zum Image eines echten EDV-Experten, bei einer gleichartigen Frage nach dem Preis, beispielsweise eines Finanzbuchhaltungssystems, prompt und mit weltmännischer Überzeugung einen Beitrag von 20 000 Mark zu nennen - oder auch zwei Millionen, je nachdem, was er gerade so schätzt.

Damit sind wir bei einem weiteren Aspekt: Derjenige, der ein klar definiertes System zu schätzen hat, muß die Problemstellung kennen, muß auf diesem Anwendungsgebiet Kenntnisse, besser Erfahrungen, haben, um "zu wissen, worum es geht".

Ordentlicherweise wird eine solche Schätzung dadurch objektiviert, daß ein oder zwei Gegenschätzungen unabhängig vorgenommen werden, wobei es der Sorgfalt der Schätzungen dienlich ist, wenn die Schätzenden von der "Gefahr" ausgehen müssen, die Schätzung gegebenenfalls auch realisieren zu dürfen.

Wer mit hinreichender Aussagekraft schätzen will, kommt nicht umhin, seine eigenen Erfahrungswerte zu ermitteln, wobei folgende Punkte berücksichtigt werden sollten:

- Klare organisatorische Regelung der Abläufe in der Systementwicklung, wobei festzulegen ist, welche Tätigkeiten in welchem Umfang erforderlich sind; dazu gehören Schnittstellen und Prüfkriterien, die eine Kontrolle - ermöglichen (was bedeutet: "zu 80 Prozent fertig"? "ausgetestet"?).

- Eine sichere und eindeutige Zuordnung des Aufwandes (besser noch: der Kosten) zu den jeweiligen Tätigkeiten.

- Getrennte Erfassung oder zumindest Isolierung der Störfaktoren (im wesentlichen ein psychologisches Problem, das in der Regel die Tatsache betrifft, daß unproduktive Zeiten "untergebuttert" werden, wenn Mitarbeiter gezwungen sind, lückenlos über ihren Aufwand zu berichten).

- Statistische Erfassung der wichtigsten Einflußgrößen wie Systemumfang, Teamgröße, Schwierigkeitsgrad, Programmiersprache, Datenvolumen Komplexität, Hilfsmitteleinsatz.

Den hierfür erforderlichen erheblichen manuellen Aufwand auf ein vertretbares Maß herunterzudrücken, ist einer der Vorteile eines guten Projekt-Planungs und Kontrollsystems. Wie können die gewonnenen Daten nun für die Planung nutzbar gemacht werden?

Die bisher eingesetzten Methoden sind gleichermaßen ungenau und fehleranfällig. In einem Fall sucht man ein Projekt vergleichbarer Größenordnung und bricht den dadurch vorgegebenen Gesamtaufwand über ein relativ willkürlich gewähltes Raster auf Phasen-Stufen- und Aktivitätsebene herunter. Hat man zu Anfang den Vergleichsmaßstab richtig gewählt, kann man davon ausgehen, daß man immer "ungefähr" richtig liegt; wenn das allerdings nicht der Fall ist oder Störfaktoren auftreten - beides zusammen ist der Regelfall -, taugt der Phasenplan nicht so viel wie das Papier, auf dem er abgebildet ist.

Dazu kommt ein äußerst unangenehmer Nebeneffekt: Da die Gliederung willkürlich ist, ist es in den ersten Phasen (Konzeption, Design, Organisation) wo die Schnittstellen zwangsläufig weniger klar sind, möglich, scheinbar "im Plan" zu bleiben, die

Bugwelle der vergessenen, fehlerhaften, unvollständigen Informationen "schlägt" dann regelmäßig die Programmierung oder den Test, wirkt sich also zu einem Zeitpunkt aus, wo Änderungen am mühsamsten und aufwendigsten sind.

"Adding manpower to a late software project makes it later" sagt Brooks (Projektltr. des Systems OS/360 bei IBM) in seinem Buch "The Mythical Man Month".

Im anderen Fall wird ein möglichst repräsentativer Teil des Systems herausgenommen und in dem Tätigkeitsbereich untersucht, wo die Einflußfaktoren am sichersten zu bestimmen (die "Soft"ware am "härtesten") sind, in der Programmierung. Hier wird nun exakt ermittelt, welcher Aufwand sich für Programmentwurf und Codierung aus Art und Anzahl der Dateien, Tabellen, Funktionen und Zugriffsformen ergibt. Diese Werte werden dann extrapoliert auf den gesamten Tätigkeitsbereich der Programmierung, ferner

alle Programme und den gesamten Prozeß der Systementwicklung.

Die Nachteile beruhen darauf daß eine solche, ohnehin riskante Extrapolation über mehrere Ebenen dann versagt, wenn auch nur ein Faktor nicht berücksichtigt (zwei Minuten Bleistiftspitzen für ein Modul zu vergessen, bedeutet am Ende eine Terminverschiebung von zwei Wochen) oder nicht repräsentativ gewichtet wurde.

Fassen wir zusammen:

Zu einer aussagekräftigen Aufwandsschätzung bedarf es

- einer klaren, eindeutigen und verbindlichen Beschreibung aller Tätigkeiten des Systementwicklungsprozesses,

- einer möglichst exakten Zuordnung von Aufwand (und Kosten) zu diesen Tätigkeitskategorien,

- einer statistischen Erfassung der wesentlichen Einflußgrößen

- einer Bestimmung dieser Einflußfaktoren in dem Maße und zu dem Zeitpunkt, wie sie festgeschrieben werden.

Vielleicht gelingt es uns so eines Tages, dem Projektmanager, dessen Haltung bislang je nach charakterlicher Disposition durch Fatalismus, Angst vor Magengeschwüren oder den Glauben an das Gute im Menschen geprägt ist, einen Schuß Hoffnung mit auf den Weg zu geben. Auf daß 100 Prozent wieder 100 Prozent werden.