Projekt-Management in der Praxis (Teil 22)

Systematische Bewertung des Projekterfolgs unterbleibt oft

23.10.1992

Bei über einem Drittel der von uns untersuchten Projekte schätzten die Beteiligten den Erfolg kritisch oder kontrovers ein. Dabei fehlen allerdings systematische Versuche zur Evaluierung fast völlig.

Wie erfolgreich waren die untersuchten Projekte? Die Beantwortung dieser Frage erweist sich als außerordentlich schwierig und konfrontiert sofort mit dem Problem, nach welchen Maßstäben Erfolg gemessen werden kann.

Wie schwierig eine Erfolgsbewertung ist, zeigt eine Gegenüberstellung zweier fast gleichzeitig betriebener, personell eng verknüpfter Projekte eines Softwarehauses. Eines davon wurde zügig und ohne größere Probleme abgewickelt und deshalb zunächst auch als voller Erfolg gehandelt. Der Auftraggeber erhielt das entwickelte Softwaresystem termingerecht und nahm es ohne größere Nachbesserungswünsche ab, setzte es dann aber nie ein. Im anderen Projekt traten im Lauf des Entwicklungsprozesses erhebliche technische, personelle und organisatorische Schwierigkeiten auf. Der Projektabbruch drohte; eine Verlängerung der Laufzeit und Aufstockungen des Budgets waren notwendig, durch die sich aber nicht vermeiden ließ, daß das Projekt ohne Gewinn blieb. Der Auftraggeber setzte das entwickelte Softwareprodukt ein und erweiterte es im Lauf der nächsten Jahre erheblich, was zu Anschlußaufträgen für das Softwarehaus führte.

Welches dieser Projekte war erfolgreich? Die Bewertung kann völlig anders ausfallen, je nachdem, ob sie nach primär projektbezogenen oder primär produktbezogenen Maßstäben erfolgt. Unter projektbezogenen Maßstäben schneidet das erste Projekt besser ab, unter produktbezogenen das zweite. Kompliziert wird die Angelegenheit noch dadurch, daß eine Bewertung immer beide Aspekte mit einbeziehen muß: Eine Überziehung des Projektbudgets stellt sich sehr unterschiedlich dar, je nachdem, wie das Endergebnis ausfällt; die Qualität einer Software muß immer auch gesehen werden in Relation zu dem Aufwand, den sie erforderte.

Eine fundierte objektivierte Erfolgsbewertung der Projekte war vor allem unter produktbezogenen Maßstäben im Rahmen unserer Untersuchung nicht möglich. Dazu hätten wir die tatsächliche Nutzung und die subjektive Wertung durch die Anwender über einen längeren

Zeitraum, die Erfahrungen bei der Wartung und Weiterentwicklung des Systems, die Wirtschaftlichkeitseffekte etc. systematisch erfassen müssen. Solche zweifellos wichtigen Ermittlungen hätten den Rahmen, der uns gesetzt war, bei weitem gesprengt.

Für die projektbezogene Bewertung standen uns als Erfolgskriterien zur Verfügung, ob Projekte sich überhaupt zu Ende führen ließen sowie die Einhaltung des vorgegebenen Termin und Budgetrahmens.

Aus den Vereinigten Staaten liegen Untersuchungsergebnisse vor, die zeigen, daß es in einem erheblichen Teil der Softwareprojekte nicht gelungen war, Planung und Steuerung des Entwicklungsprozesses in den Griff zu bekommen. Jedes sechste Softwareprojekt, so ergaben Untersuchungen von T. De Marco und T. Lister, wurde ohne vertretbares Resultat abgebrochen. Bei Großprojekten mit mehr als 25 Arbeitsjahren war es, wie C. Jones zeigte, sogar jedes vierte Projekt.

Eine Befragung, die vom Plenum Institut in 200 deutschsprachigen Unternehmen durchgeführt wurde, ergab, daß in jedem zweiten IT-Projekt Kosten und Termine überzogen wurden.

Die Ergebnisse unserer Untersuchung bestätigen tendenziell diese Zahlen. Daß von den untersuchten Projekten nur zwei abgebrochen wurden, dürfte im wesentlichen damit zusammenhängen, daß wir uns vor allem mit bereits abgeschlossenen oder kurz vor dem Abschluß stehenden Vorhaben beschäftigten. Im Umfeld stießen wir jedoch immer wieder auf Entwicklungsvorhaben, die unvollendet blieben oder nach teilweise recht aufwendigen Vorarbeiten nicht in Gang gekommen waren.

Kritisch zu bewerten ist ein Großteil der Projekte, wenn man die Einhaltung von Kosten und Terminvorgaben als Bewertungskriterium heranzieht. In Folge 5 unserer Serie haben wir aufgezeigt, daß eine Kalkulation des Zeit- und Kostenrahmens oft überhaupt fehlte (15 Prozent) oder im Projektverlauf korrigiert wurde (48 Prozent); 39 Prozent dieser revidierten

Planungen waren dann immer noch nicht einzuhalten. Nur in 21 Prozent der Projekte, die zum Untersuchungszeitraum abgeschlossen waren, gab es zu Projektbeginn definitive Aussagen über Kosten und Termine, blieben diese im Projektverlauf unverändert und wurden auch realisiert (vgl. Abbildung 1).

Softwarehäuser und Anwenderunternehmen unterscheiden sich hier vor allem dadurch, daß erstere wesentlich seltener Projekte ohne definitive Aussagen über Termin- und Kostenrahmen begannen. Sie differieren auch in ihrer Kalkulationstreue: Bei 40 Prozent der abgeschlossenen Projekte in Softwarehäusern konnten die zu Beginn des Projekts vorgelegten und später nicht mehr modifizierten Kalkulationen eingehalten beziehungsweise unterschritten werden, dagegen nur bei 11 Prozent der Vorhaben in Anwenderunternehmen.

In produktbezogener Sicht bieten sich unterschiedliche, unter Umständen konkurrierende Bewertungsmaßstäbe an: anwendungsorientierte Kriterien (Nutzungsintensität, Häufigkeit von Fehlanwendungen etc.) ebenso wie systembezogene (Änderbarkeit, Wartbarkeit etc.), und allgemein kurz -, mittel- und langfristige Aspekte.

Auch hier liegen Untersuchungsergebnisse aus den Vereinigten Staaten vor, die den Erfolg von Softwareprojekten unter produktbezogenen Aspekten recht zweifelhaft erscheinen lassen. Eine Untersuchung, die im Auftrag des US-Rechnungshofs durchgeführt wurde, ergab, daß nach 9 Software-Entwicklungsprojekten mit einer Auftragssumme von 6,8 Millionen Dollar nur Software im Wert von 320 000 Dollar verwertet wurde, davon 60 Prozent erst nach Überarbeitung. Ähnlich stellte die Diebold Corporation fest, daß 47 Prozent der Software-Investitionen in Anwendungen flossen, die nie zum Einsatz kamen, und daß nur 5 Prozent der neuen Software ohne große Modifikationen funktionierte.

Nach einer 1985 durchgeführten Studie von Cox haben sogar 95 Prozent aller Softwareprojekte kein verwertbares Ergebnis produziert (47 Prozent der in Auftrag gegebenen Software wurden zwar bezahlt, aber nicht geliefert, 29 Prozent ausgeliefert, aber nicht benutzt, 19 Prozent aufgegeben oder neu erstellt).

Mögen auch gewisse Zweifel an der Repräsentativität dieser Untersuchungen angebracht sein, so sind doch diese Zahlen in jedem Fall ein Indiz, daß ein erheblicher Teil der entwickelten Software nie oder erst nach aufwendigen Modifikationen genutzt wurde.

Auch die eher zufälligen Informationen, die wir im Rahmen unserer Untersuchung erhielten, deuten auf eine erhebliche Ausschußquote hin. Bei einigen Projekten kam es überhaupt nicht zu einer Anwendung der entwickelten Software, obwohl es sich durchweg um sehr aufwendige und umfangreiche Vorhaben handelte. In einem Großteil der Projekte waren erhebliche Nachbesserungen erforderlich beziehungsweise ließ die Nutzungsintensität der entwickelten Software zu wünschen übrig.

Dabei bekamen wir mit Sicherheit nur die Spitze des Eisbergs zu sehen, weniger weil uns die relevanten Informationen nicht zugänglich gemacht wurden, als weil sie nicht verfügbar waren. In den meisten Projekten fehlte ein systematisches Feedback aus der Anwendungspraxis und bestand auch ein erstaunliches Desinteresse vieler Entwickler und vor allem Projektverantwortlicher gegenüber dem weiteren Schicksal der Produkte ihrer Arbeit. Dies war vor allem in Softwarehäusern, aber immer wieder selbst dort festzustellen, wo Entwickler und Anwender in einem Unternehmen beschäftigt waren.

Auf diesem Hintergrund müssen nun die Angaben unserer Gesprächspartner - in der Regel Projektleiter, Projekt-Manager oder deren Stellvertreter - gesehen werden, die wir baten, den Erfolg ihrer Projekte zu bewerten. Sie bezogen sich dabei nur in wenigen Fällen auf das

Ergebnis einer systematischen, "offiziellen" Evaluierung.

Die Befragten sahen über die Hälfte der Projekte im eigenen Unternehmen oder beim Auftraggeber als vollen Erfolg an, 22 Prozent gelten als Teilerfolg nur 2 Prozent als völliger Mißerfolg. 13 Prozent der Projekte werden kontrovers bewertet, bei weiteren 9 Prozent war die Meinungsbildung noch im Fluß (vgl. Abbildung 2).

In der subjektiven Wertung der Projektverantwortlichen erscheint also in einem beträchtlichen Teil der Projekte deren Erfolg zumindest umstritten oder zweifelhaft. Nun ist eine solche Beurteilung nicht zuletzt eine Frage der Maßstäbe, an denen man sich orientiert.

Unter den - von uns vorgegebenen - Kriterien, auf die man sich bei der Einschätzung des Erfolgs der Projekte bezog, stand erwartungsgemäß die Zielerreichung an erster Stelle, wobei hier zu 85 Prozent die Erfüllung der - mehr oder minder präzise - gestellten Vorgaben gemeint war. Deutlich seltener wurden Termineinhaltung (52 Prozent) und Nutzungsintensität (41 Prozent) genannt. Es folgten wiederum mit einigem Abstand Nutzungsfreundlichkeit (35 Prozent), Reklamationen (30 Prozent), Budgeteinhaltung (30 Prozent) und schließlich Programmästhetik (11 Prozent) (vgl. Abbildung 2).

Bemerkenswert an diesem Ergebnis erscheint vor allem, daß Budget- und Termineinhaltung in über zwei Dritteln beziehungsweise der Hälfte der Projekte in die Wertung nicht eingingen. Abweichungen in diesem Bereich gelten tendenziell als läßliche Sünden, die nur dann nicht verziehen wurden, wenn sie den Arbeitsabschluß überhaupt gefährdeten.

Dies scheint erstaunlicherweise selbst für einen beträchtlichen Teil der Softwarehäuser zu gelten, zumindest bezogen sich auch dort unsere Gesprächspartner nur zu 38 Prozent auf Budgeteinhaltung und zu 48 Prozent auf Termineinhaltung als Kriterien des Erfolgs.

Auch die eher produktbezogenen Kriterien Nutzungsintensität und Nutzungsfreundlichkeit spielen für die Einschätzung keine zentrale Rolle, insbesondere in den Softwarehäusern, wo sie nur ein Drittel beziehungsweise Viertel unserer Gesprächspartner nannten. Dies steht im Einklang mit dem geringen Feedback, das man aus der Anwendungspraxis erhielt, und dem begrenzten Interesse, das man letztlich für diese bekundete.

Kennzeichnend für die eher entwicklungs- und nicht anwendungsorientierte Sichtweise ist auch, daß 70 Prozent unserer Gesprächspartner das Urteil der Projektverantwortlichen als ausschlaggebend für die Erfolgsbewertung ansahen, während nur 30 Prozent der Befragten in diesem Zusammenhang die Anwender angaben.

Man muß diese Zahlen mit Vorsicht bewerten: Sie spiegeln subjektive Einschätzungen von Gesprächspartnern wider, die selbst unmittelbar in das Projektgeschehen involviert waren, also Partei sind. Unsere detaillierten Recherchen in einzelnen Projekten vermittelten allerdings weitgehend denselben Eindruck. Dies gilt für die Einschätzung der Erfolgsquote, wobei vieles dafür spricht, daß eine systematische Evaluierung noch ungünstigere Werte als die Beurteilung durch unsere Gesprächspartner ergeben würde. Als stabil stellte sich auch die egozentrische, entwicklungsbezogene Sichtweise heraus, in der die Entwickler ihre Projekte beurteilten.

Bemerkenswert scheint uns dabei nicht so sehr die Tatsache, daß ein beträchtlicher Teil der Projekte die gesetzten Vorgaben nicht einhalten konnte beziehungsweise nicht zu einem befriedigenden Resultat führte. Angesichts der Komplexität und der Rahmenbedingungen vieler Entwicklungsvorhaben war dies kaum anders zu erwarten. Überraschend für uns war das weitgehende Fehlen von systematischen Versuchen zu einer differenzierten Evaluierung des Erfolgs von Projekten - vor allem unter anwendungsbezogenen Aspekten - und einer gründlichen Auseinandersetzung mit dessen Ursachen. Nur in zwei der untersuchten Projekte begegneten wir einer systematischen Nachevaluierung in Form eines abschließenden Reviews. Ohne Zweifel besteht hier eines der schwerwiegendsten Defizite in der gegenwärtigen Praxis der Software-Entwicklung.

Literatur: C. Jones, Programmer Productivity, Issues for the Eighties. New York 1981

De Marco, T.; Lister, T.: Peopleware, Productive Projects and Teams. New York 1987