Critical Issues in Abandoned Information Systems Development Projects

Inhaltsverzeichnis

1 Fakten

2 Besonderheiten von Software-Projekten

3 Kritische Faktoren
3.1 Management bezogene Faktoren
3.2 Technische Faktoren
3.3 Human Factors

4 Umgang mit gescheiterten Projekten

5 Ans¨atze zur Rettung von Projekten in der Krise

6 Ans¨atze zur Verminderung von Fehlschl¨agen

A Literaturliste

1 Fakten

Viele Experten sind der Meinung, daß die Software-Industrie in einer Krise steckt. Trotz der rasanten Weiterentwicklung von Computerprogrammen, scheitert den- noch eine Vielzahl von Softwareprojekten. Eine Umfrage unter 600 Firmen ergab, daß 35 Prozent von diesen mindestens ein fehlgeschlagenes Projekt hatten.

Jennkis, Naumann und Whetherbe befragten die Entwickler von 72 Information System Entwicklungsprojekten in 23 gr¨oßeren amerikanischen Firmen. Dabei wur-de herausgefunden, daß diese Projekt normalerweise 10,5 Monate dauerten. U¨ ber

70 Prozent der Projekte ben¨otigten weniger als 1.000 Manntage und auch die Benutzer dieser Systeme waren in 72 Prozent der F¨alle zufrieden oder sogar sehr zufrieden mit den Systemen.

Die Aufwendungen waren im Schnitt um 36 Prozent h¨oher als geplant. Der Zeitplan wurde in den meisten F¨allen um 22 Prozent u¨berschritten.

Was in dieser Studie allerdings nicht beru¨cksichtigt wurde waren die Gru¨nde, die zu diesen Verz¨ogerungen fu¨hrten.

2 Besonderheiten von Software-Projekten

Im Gegensatz zu anderen Ingenieur-Wissenschaften weisen Softwareprodukte ei- nige Besonderheiten auf, die sehr leicht zu Problemen fu¨hren k¨onnen, wenn sie nicht beachtet werden.

Software-Projekte sind meistens kreativ. Es ist nicht immer einfach zu planen, wie lange ein bestimmter Teil dieses Projekts dauern wird, speziell wenn es sich bei diesem Teil um etwas Neues nicht Vergleichbares handelt. Noch w¨ahrend der Entwicklung k¨onnen Probleme auftauchen, die nicht hervorgesehen wurden odernicht hervorgesehen werden konnten.

Kleine Probleme, die w¨ahrend der Entwicklung entstehen, k¨onnen rasch in Summe große Budgetu¨berschreitungen zu Folge haben. Es passiert zum Beispiel relativ h¨aufig, daß die Korrektur eines Fehlers, andere Fehler verursacht. Auch wenn pl¨otzlich grundlegende Dinge im Entwurf ge¨andert werden mu¨ssen w¨ahrendder Implementierung, kann das zu großen Verz¨ogerungen und Kosten fu¨hren.

Eine weitere Besonderheit von Software-Projekten ist die Vielzahl der Be- teiligten an dem jeweiligen Projekt. Je gr¨oßer das Projekt, umso mehr Leute sind involviert. Diese haben aber meistens ganz andere Sichtweisen und Meinun- gen. Der Entwickler hat Probleme, dem Management und dem Benutzer Dinge zu erkl¨aren. Das Management und die Benutzer dr¨angen auf eine rasche und kostengu¨nstige Fertigstellung. Die Benutzer m¨ochten oft gerne nachtr¨aglich An- forderungen ¨andern, was zu erheblich Kosten und Verz¨ogerungen fu¨hren kann.

3 Kritische Faktoren

Es gibt verschiedene Faktoren, die den Erfolg oder Mißerfolg eines Software- Projekts mehr oder weniger stark beeinflußen k¨onnen. Diese sogenannten kriti- schen Faktoren lassen sich prim¨ar in drei Gruppen einteilen.

3.1 Management bezogene Faktoren

Damit ein Projekt erfolgreich ist, mu¨ssen die Ziele genau definiert sein. Weist be- reits die Systemanalyse Fehler oder Ungenauigkeiten auf, fu¨hrt das zwangsl¨aufig zu groben Fehleinsch¨atzungen. Ist die Analyse in einem Punkt nicht genau und l¨aßt zu viel Spielraum fu¨r Interpretationen, passiert es leicht, daß das Endergebnisnicht mehr den Kundenwu¨nschen entspricht.

Ein ganz wichtiges Kontroll-Instrument ist der Projektplan. Durch ihn ist eine U¨ berpru¨fung der Projektziele erst m¨oglich. Werden hier Fehler gemacht oder Zieleungenau definiert, k¨onnen Fehleinsch¨atzungen nicht oder nicht rechtzeitig erkannt

werden und dadurch zu Verl¨angerungen der Entwicklungszeit und zum Anstieg der Kosten fu¨hren.

Ganz entscheidend ist auch die Zusammenstellung des Projektteams. Dabei gilt es mehrere Faktoren zu beru¨cksichtigen. Da Software-Projekte sehr viel Kom- munikation erfordern, ist es wichtig, daß das Team m¨oglichst gut eingespielt ist und sich auch die einzelnen Mitglieder mit ihren Kollegen gut verstehen. Auch die Erfahrung der einzelnen Entwickler ist sehr wichtig. Es sollten immer einige Mitglieder des Teams schon Projekterfahrung besitzen.

Entwickler neigen leider h¨aufig dazu, m¨oglichst unter sich zu bleiben und alle anderen Beteiligten an dem Projekt aus anderen Bereichen, wie zum Beispiel den Kunden und dem Management, ausschließen zu wollen.

Solche Abgrenzungen entstehen meistens aus pers¨onlicher Spannnung oder weil die Bet¨atigungsfelder zu unterschiedlich sind. Auch scheint es h¨aufig der Fall zu sein, daß Softwareentwickler nicht sehr kommunikativ und kontaktfreudig sind. Allerdings entstehen durch die mangelnde Kommunikation Unstimmigkei- ten, wodurch das ganze Projekt leidet.

Wird das Management nicht einbezogen oder bringt es sich selbst nicht ein, fu¨hrt das oft zu einem Verlust des Gesamtu¨berblicks sowie der Kontrolle. Dadurch werden auftretende Probleme nicht oder zu sp¨at erkannt um darauf noch reagierenzu k¨onnen.

Wird der Kunde von der Entwicklung ausgeschlossen, besteht die Gefahr, daß Wu¨nsche und Bedu¨rfnisse von Kunden nicht erfu¨llt werden. Das fu¨hrt dazu, daß die Kunden erst knapp vor Ende des Projekts das Produkt zu Gesicht bekommen und dann oft gravierende A¨ nderungen verlangen, die natu¨rlich zu entsprechende Verz¨ogerungen und auch Kostensteigerungen verursachen.

Sehr problematisch sind auch Anforderungs¨anderungen w¨ahrend eines laufen-den Projekts. Die Ursachen fu¨r solche A¨ nderungswu¨sche k¨onnen verschiedenen

sein. Wir das Management in die Entwicklung nicht genu¨gend integriert, kann es leicht dazu kommen, daß den Ideen und Wu¨nschen von Kunden zu leicht und schnell nachgegeben wird, ohne die Folgen fu¨r das Projekt zu beru¨cksichtigen, weil der Anreiz von mehr Umsatz und die Angst vor einem ”Abspringen” des Kunden sehr groß sind. Ergibt sich allerdings w¨ahrend der Entwicklung eine Not- wendigkeit, gewisse Anforderungen zu ¨andern, sollte man das auch tun, wenn sich dadurch die Qualit¨at des Endproduktes verbessert. Deshalb sollte in einer guten Planung bereits auf solche F¨alle Ru¨cksicht genommen werden und in der Projektkalkulation eingeplant werden.

3.2 Technische Faktoren

Haben die Projektmitarbeiter nicht genu¨gend Erfahrung mit den ben¨otigten Technologien kann das einerseits zu Verz¨ogerungen fu¨hren, weil sich die Mit- arbeiter erst in die jeweiligen Techniken einarbeiten mu¨ssen und diese Zeit nicht genau abgesch¨atzt werden kann.

Die notwendige Hardware- und Softwareausstattung sollte auch immer recht- zeitig zur Verfu¨gung gestellt werden, wobei auch hier eine gewisse Einarbeitungs-zeit notwendig sein kann.

Bei der Entwicklung eines Systemes muß auch besonders auf die Plattforum, auf der das fertig Projekt laufen soll, geachten werden. Die Endversion sollte auf Systemen laufen, die die Zielgruppe haupts¨achlich verwendet, da sonst ein ansichgutes System nicht eingesetzt werden kann.

3.3 Human Factors

Viele Projektmitglieder neigen trotz ihrer Erfahrung dazu, Dinge zu optimistisch und idealistisch zu sehen. Schon bei der Planung eines einzigen Arbeitstages kann es zu groben Fehlsch¨atzungen kommen. Die einzige L¨osung fu¨r dieses Problem ist,an Hand von ¨ahnlichen ¨alteren Projekten die Dauer und die Kosten abzusch¨atzen.Wie bereits erw¨ahnt, ist die Zusammenstellung des Projektteams sehr wichtig.

Kommt es trotzdem zu Machtk¨ampfen oder Streiterein, muß das Problem durch eine dritte Partei, zum Beispiel einem Projektleiter, rasch und sachlich behandlet werden. Die schlichtende Person muß dabei aber natu¨rlich von allen akzeptiert werden und die Entscheidung, die diese Person trifft, eingehalten werden.

Wird das Management nicht in den Entwicklungsprozeß involviert, kann es zu großen Uneinigkeiten zwischen den beiden Gruppen kommen. Das Manage- ment betrachtet das Projekt oft aus einer ¨okonomischen Sichtweise und hat wenig Verst¨andnis fu¨r Ressourcenengp¨asse, Verz¨ogerungen oder andere Probleme, diew¨ahrend der Entwicklung auftreten k¨onnen. Um Auftr¨age nicht zu verlieren und den Kunden nicht zu ver¨argern, stellt sich das Management oft auf die Seite des Kunden. So werden aus Geldgru¨nden und Unwissenheit Funktionen und Termine

zugesichert, die unm¨oglich eingehalten werden k¨onnen. Auf der anderen Seite nei-gen Entwickler dazu, sich vom Management nicht ”dreinreden” lassen zu wollen. Kritiken und A¨ nderungswu¨nsche, die sich zum Beispiel bei Reviews oder Kun- dengespr¨achen ergeben haben, werden nicht ernst genommen, da die Entwickler davon ausgehen, daß das Mangement davon nichts versteht.

Ist das Projekt einmal weiter fortgeschritten, kann es passieren, daß auf Grund des auftretenden Stresses Team-Mitglieder die Motivation verlieren oder ihre Ar- beit nicht mehr als zielfu¨hrend, nicht herausfordernd oder unwichtig erachten. Gibt man den Entwicklern hingegen bereits in fru¨hen Stadien die M¨oglichkeit zur Mitentscheidung, k¨onnen sie ihre eigenen Vorstellungen in das Projekt ein- fließen lassen und sich besser mit dem Produkt identifizieren. Auch kann die Motivation dadurch gesteigert werden, daß man Entwicker an parallel laufenden Projekten mitarbeiten l¨aßt, wobei man natu¨rlich dabei beachten muß, daß die Arbeisbelastung nicht zu hoch wird.

[...]