Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.07.2002 - 

Softwareprojekte managen/Plädoyer für ein Umdenken in der Softwareentwicklung

Warum viele Projekte scheitern

Seit Jahrzehnten wird geforscht und entwickelt, viele tausend Seiten wurden mit Prozessbeschreibungen gefüllt, Softwareprojekte verschlangen Milliardenbeträge. Dennoch bleibt die Erfolgsquote niedrig, die viel diskutierte Softwarekrise hält an. Es ist an der Zeit, die bisherige Vorgehensweise im Projekt-Management in Frage zu stellen. Von Jens Coldewey*

Die alljährliche Umfrage der Standish Group brachte es an den Tag: Trotz insgesamt positiver Entwicklung in den letzten Jahren lieferten im Jahr 2000 nur 28 Prozent der Projekte den versprochenen Leistungsumfang zum geplanten Zeitpunkt, im geplanten Budget und mit der spezifizierten Qualität. Kann es wirklich sein, dass wir bis heute nicht gelernt haben, Software zu entwickeln? Zählen wirklich fast 80 Prozent der Projektleiter zu den "Nieten in Nadelstreifen"? Die Schlussfolgerungen aus der Studie gehen den meisten Prozessverantwortlichen leicht von den Lippen: Wir brauchen eben genauer definierte Entwicklungsprozesse, mit mehr Metriken versehen und enger überwacht. Auch wenn diese Folgerung in manchen Spezialbereichen sinnvoll sein mag, erinnert sie doch auf den meisten Feldern der Softwareentwicklung fatal an Jerry Weinbergs erstes Gesetz schlechten Managements: "Wenn etwas nicht funktioniert, mache mehr davon."

Nachdem wir mittlerweile bei Prozessbeschreibungen angelangt sind, die mehr als 9000 Seiten umfassen und nur noch als CD vertrieben werden, nachdem Milliarden Mark beziehungsweise Euro in Projekte investiert wurden, hat sich offenbar die Zuverlässigkeit der Projekte noch immer nicht verbessert. Möglicherweise wird es Zeit, darüber nachzudenken, ob unsere Ansprüche an ein erfolgreiches Projekt-Management und unsere Vorstellungen von der "Reife" einer Entwicklungsorganisation eigentlich sinnvoll sind. Wir sollten unsere Grundannahmen hinterfragen.

Projekterfolg nur Glücksache

Beginnen wir mit der Definition eines erfolgreichen Projekts.

These 1: Ein Projekt, das pünktlich mit dem zuvor definierten Umfang im gegebenen Budget und mit der vereinbarten Qualität abgeschlossen wird, ist nicht die Folge guten Projekt-Managements.

Vielmehr hat der Projektleiter einfach Glück gehabt, oder so umfangreiche Puffer eingeplant, dass das Projekt auch mit deutlich geringerem Aufwand machbar gewesen wäre, also schlecht gewirtschaftet. Diese These ist gewagt genug, um genauerer Diskussion zu bedürfen. Die Standish-Definition eines erfolgreichen Projekts schreibt alle Parameter fest, die dem Projektleiter zur Verfügung stehen, um ein Projekt zu steuern. Abgesehen von trivialen Aufgaben ist es aber mittlerweile praktisch unmöglich, alle Eventualitäten des Projektverlaufs vorauszusehen. Krankheit, technische Probleme oder organisatorische Veränderungen treffen praktisch jedes ernsthafte Projekt und führen dazu, dass von der ursprünglichen Vorgehensweise abgewichen werden muss. Dafür kann der Termin verschoben, der Umfang abgespeckt, das Team in sehr engen Grenzen vergrößert oder eben an der Qualität gespart werden. Wer einen Projektleiter daran misst, dass er keines dieser Dinge tut, bleibt die Antwort schuldig, wie ein Projekt denn sonst gesteuert werden kann - einmal abgesehen von der Option unbezahlter Überstunden.

Die Praxis zeigt hier eine Reihe von Möglichkeiten auf, die aber eher unter die Rubrik "Tarnen und Täuschen" fallen. Die häufigste Variante besteht darin, den weichsten Teil der Spezifikation kreativ zu interpretieren, in der Regel sind das Festlegungen zur Qualität der Software. Eigenschaften wie Wartbarkeit oder Erweiterbarkeit sind so schwer präzise zu spezifizieren und zu messen, dass hier in der Regel auf den "Stand der Kunst" verwiesen wird - und sich so Zeit und Aufwand sparen lässt. Die Rechnung kommt später, wenn das Projekt längst "erfolgreich" beendet wurde und schon kleinste Erweiterungen zu riesigen Aufwänden führen.

These 2: Ein Projekt, das den vereinbarten Umfang pünktlich im Budget mit der vereinbarten Qualität ausliefert, muss noch lange nicht erfolgreich sein.

Hier sind nicht die zweifellos vorhandenen Schwierigkeiten gemeint, überhaupt genau genug zu spezifizieren, was ein System leisten soll. Es geht vielmehr darum, dass sich die Anforderungen an ein System mit der Zeit ändern. Projektlaufzeiten von einem Jahr und mehr vergehen in der Regel nicht, ohne dass es neue fachliche Erkenntnisse gäbe oder sich die Anforderungen des Marktes geändert hätten. Wer im Sinne der Standish-Definition erfolgreich sein möchte, muss solche "Moving Targets" verhindern, liefert sich aber dem Risiko aus, ein System zu liefern, das bei der Inbetriebnahme schon veraltet ist.

Viele Systeme falsch geplant

Mit den immer kürzer werdenden Produktzyklen ist die Wahrscheinlichkeit, das falsche System geplant zu haben, sogar unangenehm hoch. Ein Projektleiter, der in der Lage ist, das Projekt mit solchen Änderungen zu führen, ist zwar nicht erfolgreich in dem Sinne, dass er den ursprünglich vereinbarten Umfang liefert, aber das "erfolglose" Projekt mag dem Auftraggeber den deutlich höheren Nutzen bringen. Ein klares Indiz dafür, dass der obigen Standish-Definition eines erfolgreichen Projekts das falsche Modell zugrunde liegt.

These 3: Ein wirtschaftlich erfolgreiches Projekt erbringt meistens nicht den geplanten Funktionsumfang.

Diese dritte These folgt unmittelbar aus der zweiten. Wer wirtschaftlich erfolgreich sein will, muss Erkenntnisse einfließen lassen, die sich erst im Projektverlauf ergeben. Dies können neue Marktentwicklungen sein, aber auch neue Lösungsansätze, die sich erst später herausbilden. Erfolgreiche Projekte liefern das aus, was zum Zeitpunkt der Auslieferung benötigt wird, nicht das, was beim Projektstart geplant wurde.

Softwareentwürfe sind keine Mathematik

Die Vorstellung, es sei möglich, ein derartig komplexes System wie Software im Voraus vollständig und detailliert zu entwerfen, entstammt eher dem Wunschdenken, Software möge doch eher dem Hausbau ähneln, als der Realität heutiger Systeme. Wer argumentiert, dass schließlich auch extrem komplexe Systeme wie die Mathematik durch vollständige Durchdringung entworfen wurden, man also bei der Software den gleichen Weg beschreiten solle, übersieht, dass die Mathematik über mehrere tausend Jahre entwickelt wurde, während für ein durchschnittliches Projekt nur wenige Quartale zur Verfügung stehen. Wer andererseits diese These für eine Binsenweisheit hält, sei auf die Kriterien verwiesen, nach denen in den meisten Organisationen Budgets verteilt und Projektleiter beurteilt werden.

These 4: Unternehmensweite Prozesse stören bei der Abwicklung erfolgreicher Projekte mehr, als dass sie helfen.

Um die Projektabwicklung zu erleichtern, wurden in den vergangenen zwei Jahrzehnten viele Millionen Seiten Papier zu Entwicklungsprozessen verarbeitet, die meist von Methodenabteilungen entworfen und "durchgesetzt" wurden. Wenn aber schon die Definition eines erfolgreichen Projekts strittig ist, muss auch die Rolle von Prozessen bei der Entwicklung hinterfragt werden.

Je größer ein Projekt ist, um so mehr Regeln müssen für eine reibungslose Zusammenarbeit eingehalten werden. Je größer der potenzielle Schaden eines Systems ist, um so besser müssen die Maßnahmen zur Qualitätssicherung von außen überprüfbar sein. Darüber herrscht weitgehend Einigkeit. Allerdings scheinen die meisten unternehmensweiten Prozesse diese Regeln nach dem Motto "Viel hilft viel" umzusetzen: Je mehr Formalismus und je mehr Zwischenergebnisse eingeplant werden, um so besser. Dabei wird aber ein wichtiges Gesetz übersehen: Überflüssige Regeln kosten überproportional viel Geld.

Zudem verzögern unnötige Zwischenprodukte den Projektablauf, was gerade in hart umkämpften Märkten leicht dazu führen kann, dass die Konkurrenz schneller ist und eine Nische besetzt, also das Projekt scheitert. Überflüssig in diesem Sinne sind alle Regeln, die weggelassen werden können, ohne den langfristigen wirtschaftlichen Erfolg des Projekts zu gefährden. Die Praxis zeigt, dass je nach der Erfahrung des Teams und den Anforderungen des Projekts zwischen 50 und 90 Prozent der Regeln überflüssig sind - das Team könnte ohne sie auch arbeiten und hätte deutlich mehr Zeit, für die gute Qualität der verbliebenen Dokumente zu sorgen. Eine solche radikale Schlankheitskur muss aber vom ganzen Team über das gesamte Projekt hinweg überprüft und nachjustiert werden.

Lernen im Projekt wird verhindert

Das von den meisten modernen Prozessen vorgesehene Customizing zu Beginn des Projekts durch den Projektleiter ignoriert nicht nur die menschliche Fähigkeit, im Projektverlauf zu lernen, sondern auch die Erfahrung, die im Team versammelt ist. Nur wenn das Vorgehen dem Team und dem Projekt nicht überdetailliert vorgegeben wird, sondern flexible Anpassungen zulässig und erwünscht sind, kann mit optimaler Effizienz entwickelt werden. Die Forderung, alle Entwicklungsvorhaben in der Organisation müssten dem gleichen Verfahren folgen, ist bestenfalls nur zu teuer.

These 5: Prozesse ersetzen weder Ausbildung noch Erfahrung.

Die Vorstellung, mit Hilfe eines Prozesses sei es möglich, auch mit unerfahrenen Entwicklern erfolgreiche Projekte zu machen, ist so verbreitet, dass sie in kaum einer Diskussion fehlt. Dass gute Entwickler und Architekten viele Jahre benötigen, um ausreichend Erfahrungen zu sammeln, scheint gerne übersehen zu werden. Prozessbeschreibungen können formale Schritte festlegen, Qualität entsteht durch die geschickte Auswahl aus Alternativen, für die Erfahrung und Ausbildung notwendig sind.

Die diskutierten Thesen können zu einem neuen Projekt-Management führen. Statt sich auf die Verfolgung von Plänen und die Einhaltung von Prozessen zu konzentrieren, schafft es eine Arbeitsumgebung für motivierte Teams, die im engen Kontakt mit den Kunden komplizierte Projekte eigenverantwortlich abwickeln. Die Arbeit wird von hohen Qualitätsansprüchen ebenso geleitet wie von ständigem Feedback. Änderungen sind nicht das Zeichen, dass zuvor Fehler gemacht wurden, sondern Ausdruck eines Lernprozesses. Dieses neue Management ist es, das unter dem Schlagwort "agile Entwicklung" in letzter Zeit für breite Diskussion gesorgt hat. Ob es einen Ausweg aus der Softwarekrise zeigt, bleibt abzuwarten. Erste Umfragen deuten darauf hin, dass mehr als doppelt so viele Projekte letztlich erfolgreich abgeschlossen werden konnten - vorausgesetzt, dies wird nicht an der Einhaltung von Plänen, sondern an wirtschaftlichen Resultaten gemessen. (as)

*Jens Coldewey ist unabhängiger Berater. Er hilft großen Organisationen bei der Einführung objektorientierter Konzepte und agiler Entwicklung.

Abb.1: Agiles Projekt-Management

Am Beispiel der Zusammenarbeit im Team zeigt sich, wie komplex scheinbar einfache Zusammenhänge im Projekt sein können. Agile Verfahren versuchen dem zu entsprechen, haben aber auch ihre Gefahren (rote Pfeile). Quelle: Jens Coldewey

Abb.2: Trübe Aussichten

Nur wenige IT-Projekte sind laut Umfrage der Standish Group erfolgreich. (Zahlen für 2001 noch nicht veröffentlicht). Quelle: Standish Group