Von Karsten Hoffmann

Die SW-Entwicklung nach dem Wasserfall-Modell basiert auf klaren Festlegungen zum Projektablauf und zu der zu schaffenden Funktionalität. Sie birgt in der Regel jedoch höhere Risiken, ist unbeweglicher und ergibt nicht selten eine unbefriedigende Produktqualität. Mit dem Spiralmodell und dessen erfolgreicher Umsetzung in zahlreichen Projekten steht ein agilerer SW-Entwicklungsprozess zur Verfügung. Dieser kommt der objektorientierten Vorgehensweise sehr entgegen (Generalisierung – Spezialisierung). Richtig angewandt hilft eine solche Vorgehensweise, technische und kaufmännische Risiken zu vermindern. Außerdem ermöglicht sie eine höhere Flexibilität hinsichtlich kurzfristiger Änderungen, ein einfacheres Qualitätsmanagement, ein leichteres Controlling und eine gleichmäßigere Auslastung. Risiken bestehen hier hinsichtlich klarer Festlegungen und eines damit verbundenen eindeutigen Vertragsmodells (Festpreis). Auch wenn sich in den praktisch etablierten Entwicklungsprozessen Elemente beider Basismodelle kombinieren, verlangen heutige Anforderungen die stärkere Berücksichtigung des iterativen Moments und ein entsprechend gestaltetes IT-Projektmanagement.

Typische Probleme bei heutigen IT-Projekten

Entwicklungsprojekte im IT-Bereich gibt es seit Jahrzehnten, seit über 20 Jahren werden sie durch systematische Projektmanagement-Methoden begleitet. Dennoch leiden viele, insbesondere größere IT-Projekte immer wieder an bekannten „Krankheiten“:

• Die Kosten für die Projektdurchführung werden höher als geplant. Insbesondere in den letzten Phasen Realisierung und Test treten plötzlich deutlich höhere Aufwände zutage.
• Der Fertigstellungstermin wird überzogen. Im günstigeren Fall betrifft dies nur firmeninterne Abläufe, die nun erst später mit Hilfe des neuen Systems abgewickelt werden können, im ungünstigen Fall gehen durch die spätere Inbetriebnahme Kundenumsätze verloren oder es drohen sogar Vertragsstrafen.
• Die erstellte Software hat nicht die gewünschte Qualität. Dies äußert sich z. B. in (zu) hohen Fehlerraten, der Instabilität des Systems, wenig benutzerfreundlichem Dialogverhalten oder auch in einer nicht akzeptablen Performance. Ein anderes Problem ist die oft inaktuelle Funktionalität: Die Software enthält Funktionen, die so gar nicht mehr benötigt werden, es fehlen aber Funktionalitäten, deren Anforderung sich erst im letzten halben Jahr ergeben hat.
• Das fertige IT-System bedarf höherer Aufwände für Administration und Pflege als zunächst erwartet. Die Übernahme des Systems in einen normalen „Tagesbetrieb“ gelingt oft nicht ohne markante zusätzliche Betreuungsaufwände in einer Übergangsphase.

Insgesamt sind die Beteiligten oft nicht glücklich mit dem erzielten Resultat. Die Fachabteilung des Auftraggebers ist enttäuscht, da sie nicht das bekommen hat, was sie längst erwartet hatte, die Geldgeber streiten mit dem Auftragnehmer um die Schuld für Zusatzkosten, der Auftragnehmer selbst hat wieder mal „draufgezahlt“. In noch schlimmeren Fällen kommt das neue System gar nicht zum Einsatz, nach langem Streit haben nur noch die Juristen das Sagen, der Projektleiter wird entlassen, ein „Sanierer“ versucht vielleicht noch zu retten, was zu retten ist, Millionenbeträge müssen einfach abgeschrieben werden. Durch solche und ähnliche Erfahrungen verfestigt sich beim Management der Eindruck, IT-Projekte seien teuer und lohnen sich nicht. Zukünftige Projekte werden nur noch genehmigt, wenn ein früher Return on Investment überzeugend nachgewiesen werden kann.

Aber auch die Gründe für die typischen Probleme insbesondere umfangreicher IT-Projekte sind vielen bekannt. So ist es in einem Projekt mit neuer Technologie und neuen Partnern sehr schwer, die Aufwände bereits zu Beginn genau abzuschätzen; technische Risiken werden oft erst (zu) spät erkannt; QS-Maßnahmen werden nur solange sauber eingehalten, solange das Budget noch im Lot ist – beim ersten Zeitverzug oder bei Stundendefiziten wird oft als Erstes bei den QS-Maßnahmen eingespart, oft werden die Anwender auch zu wenig einbezogen; zur Erhöhung der Aktualität der Anforderungen wird zwar oft ein Change-Request-Verfahren etabliert, doch dieses soll nur in Ausnahmen benutzt werden, da es ja zusätzliche Kosten verursacht; die Administrationsaufwände sind in ihrem Umfang erst zu erkennen, wenn das neue System (zumindest in einer ersten Version) vorliegt.


... Weiterlesen in PDF-Ausgabe (Kostenlose Leseprobe)

---> Zum Inhaltsverzeichnis von PMaktuell - Heft 1/2003