20071112zn Vectorsoft IT-Projektmanagement

Das erfolgreiche Softwareprojekt scheint noch immer ein Buch mit sieben Siegeln zu sein. Laut Chaos Report der Standish Group sind im Jahr 2006 rund 19 Prozent der gestarteten Vorhaben in der Softwareentwicklung komplett fehlgeschlagen. Die Gründe für das Scheitern sind dabei so vielfältig wie die IT-Vorhaben selbst.

eit 1994 – als der erste wegweisende Bericht der Standish Group erschien – kann die Softwareentwicklung gewaltige Fortschritte verbuchen. Denn während damals nur rund 16 Prozent der Vorhaben erfolgreich verliefen, sind es heute immerhin 35 Prozent. Trotzdem treten immer noch bei 46 Prozent der Projekte Probleme auf. Und das, obwohl die Standish Group die Faktoren für erfolgreiche Softwareprojekte schon seit Jahren klar benennt. Woran liegt es also, dass dennoch die meisten IT-Projekte problematisch sind oder gar vollständig scheitern?

Ein erfolgreiches Vorhaben zeichnet sich im Allgemeinen dadurch aus, dass es im geplanten Zeitrahmen, zu den definierten Kosten und in der erwünschten Qualität fertig gestellt wird. Die Standish Group differenziert zwischen drei verschiedenen Projekt-Typen: Beim erfolgreichen Projekt wird die Software im geplanten Zeit- und Kostenrahmen fertig gestellt. Dabei bietet die Applikation alle Funktionen und Eigenschaften wie vereinbart. Ist die Software zwar fertig und lauffähig, überschreitet das Vorhaben jedoch das Budget oder den Termin und wurden weniger Funktionen und Eigenschaften geliefert als vereinbart, zählt es zu den gefährdeten Projekten. Und schließlich gilt als gescheitertes Projekt, wenn es noch vor Fertigstellung der Software zum Abbruch kommt, das Projektteam kein Ergebnis abliefert oder dieses noch vor der Installation verworfen wurde. Legt man diese Definition zugrunde, verwundert es nicht weiter, dass nur wenige Projekte von Erfolg gekrönt sind. Einige Kritiker behaupten sogar, dass man Projekten des Typs 1 in einem durchschnittlichen Manager- oder Informatikerleben so gut wie nie begegnet.

Erfolg oder Misserfolg eines Softwareprojekts ist somit im ersten Schritt davon abhängig, wie real der Aufwand abgeschätzt wird. Allzu sportliche Ziele sind dabei von vorneherein zum Scheitern verurteilt. Aber auch Faktoren wie unklare oder unvollständig definierte Anforderungen und unzureichende Basisinformationen haben in der Regel Fehlplanungen zur Folge. Darüber hinaus spielen Erfahrungswerte eine große Rolle: Wer bereits mehrere IT-Vorhaben geplant hat, kann den Zeitaufwand besser abschätzen. Allerdings ist auch hier Realismus gefragt. Eine einmalige kürzere Projektzeit eignet sich nicht unbedingt als Grundlage für zukünftige Schätzungen. Wichtig ist, dass der geschätzte Aufwand während des Projekts laufend angepasst wird. Denn werden eventuelle Überschreitungen noch während des Vorhabens bemerkt, lassen sich Folgeaktivitäten noch rechtzeitig anpassen. Ist das nicht der Fall, fällt die letzte Phase des Projekts dem Termindruck zum Opfer: Die Testphase, was sich wiederum auf die Qualität der Software auswirkt. Hilfreich für ein besseres Zeitmanagement ist das Einplanen von Zeitpuffern, auf die im Notfall zugegriffen werden kann. Häufig kommt es jedoch vor, dass gewonnene oder eingeplante Reserven nicht zum richtigen Zeitpunkt genutzt, sondern im Laufe des Projektablaufs verschwendet werden. Ein weitestgehend umfassendes Konzept, das möglichst viele Parameter berücksichtigt, kann hier helfen. So scheitern viele IT-Vorhaben aufgrund mangelhafter Lösungsansätze. Sind nicht die richtigen Mitarbeiter am Projekt beteiligt, stimmen Inhalt, Dauer, Umfang, Vorgehensweise oder die technischen Komponenten nicht, ist es nahezu unmöglich, das Vorhaben erfolgreich zu beenden. Nur wenn ausreichend Zeit für die Vorphase eingeplant wird, lässt sich eine solide Basis für das Projekt schaffen.

Ein Projekt mag sich noch so gut im geplanten Zeit- und Kostenrahmen bewegen. Solange die Software am Ende nicht den Anforderungen des Anwenders entspricht, gilt das Vorhaben als gescheitert – oder zumindest als gefährdet. Eine wichtige Rolle spielt daher die Qualitätssicherung. Dabei geht es nicht nur darum, die Vorstellungen und Anforderungen des Benutzers im Vorfeld abzufragen. Das Projektteam sollte vielmehr im laufenden Dialog mit dem Anwender stehen. Erst dann ist es möglich, eine Software zu entwickeln, die den Wünschen ihres Benutzers möglichst nahe kommt. Diese Methode hat sich in der Praxis aus mehreren Gründen als sinnvoll erwiesen. Zum einen kommt es immer wieder zu Kommunikationsdefiziten zwischen Entwicklern und Anwendern. Beispielsweise nimmt der Anwender bestimmte Funktionen oder Eigenschaften als selbstverständlich an, ohne sie explizit zu formulieren. Oder der Entwickler setzt beim Anwender ein höheres technisches Verständnis voraus, als tatsächlich vorhanden ist. Wird das permanente Gespräch aufrechterhalten, klären sich solche Missverständnisse im Laufe der Zeit meist von selbst auf. Zum anderen ist eine solche Vorgehensweise für den Anwender hilfreich, um sich bereits vorab ein Bild der Software zu machen. Sollte die Applikation nicht seinen Vorstellungen entsprechen, kann er rechtzeitig intervenieren – bevor das gesamte Projekt zum Scheitern verurteilt ist.

Der kontinuierliche Dialog mit dem Anwender als wichtiger Faktor für ein besseres Projektmanagement ist keineswegs neu, sondern wird von der Standish-Group bereits seit längerem propagiert. Tatsächlich haben sich die von der Standish-Group genannten Faktoren für erfolgreiche Softwareprojekte in den letzten Jahren kaum geändert. Sowohl 1999 als auch 2006 zählten zu den Top-Drei-Faktoren die Beteiligung der Anwender, die Unterstützung durch das oberste Management sowie die Formulierung klarer Geschäftsziele. Fehlendes Wissen bezüglich des ‚Wie’ kann somit nicht die Ursache für das Scheitern so vieler Projekte sein. Vielmehr scheint es an der Umsetzung zu hapern. Der Verdacht liegt nahe, dass es möglicherweise auch an der Grundhaltung vieler Softwareentwickler liegt. Software-Ingenieure halten ihre Arbeit oftmals für einzigartig – und sehen somit keine Notwendigkeit, sich professionelleren Methoden zu öffnen.

Wie bei fast allen Projekten spielen auch bei IT-Vorhaben die beteiligten Mitarbeiter die wichtigste Rolle. Sie sind nicht nur verantwortlich für die Qualität des Ergebnisses, sondern sie verursachen auch den überwiegenden Teil der Kosten. Ohne Motivation, ohne Fachwissen und ohne gewisse Softskills kommt ein Projekt erst gar nicht zustande oder wird im besten Fall frühzeitig abgebrochen. Der Projektmanager muss daher sehr sorgfältig planen, steuern und kontrollieren. Eine zentrale Voraussetzung ist, die geeigneten Mitarbeiter für das Projekt zu finden. Gefragt sind dabei nicht nur technisches Know-how und Erfahrung, sondern auch »weiche« Eigenschaften wie Kommunikations- und Teamfähigkeit.

Das gilt auch für den Projektmanager: Um Mitarbeiter zu führen und IT-Projekte erfolgreich abzuschließen, bedarf es weit mehr als nur fachliches Know-how. Hier ist Methoden- und Sozialkompetenz, soziales Verständnis und Einfühlungsvermögen gefragt – Eigenschaften, die durchaus nicht auf alle Projektmanager zutreffen. Der Grund: Oftmals steigen Softwareentwickler aufgrund ihrer herausragenden fachlichen Kompetenz ins Projektmanagement auf. Dass hier jedoch Fachwissen eher eine Nebenrolle spielt, insbesondere bei größeren Projekten, bleibt dabei unberücksichtigt. Vier Grundsätze des guten Managements beschreibt auch Tom DeMarco in seinem Buch »Der Termin«:

Dass kompetente Projektleiter rar gesät sind, zeigt sich auch in der Praxis. Die größten Wissenslücken sind im Projektmanagementbereich zu finden – so zumindest das Ergebnis einer Umfrage von Forrester unter 218 IT-Entscheidern großer Unternehmen. 59 Prozent planen Schulungsmaßnahmen für ihre Mitarbeiter und weitere 25 Prozent wollen erfahrene Projektmanager einstellen.

Ein Projektleiter kann allerdings nur dann sein Team gut führen, wenn er vom obersten Management entsprechend unterstützt wird. Schnelle und konsequente Entscheidungen bei der Ressourcenzuteilung, beim Setzen von Prioritäten sowie bei der Lösung von Konflikten sind mit ausschlaggebend für den Erfolg eines Projekts.

»Agile Prozesse« ist der einzige Faktor der Standish-Group, der unter den Faktoren von 1999 noch nicht zu finden war. Nach Umfragen der Agile Alliance sind 81 Prozent aller agilen Entwicklungsprojekte erfolgreich. Dennoch hat sich die Methode noch nicht wirklich durchgesetzt: Nur 17 Prozent der nordamerikanischen und europäischen Unternehmen setzen laut Forrester agile Prozessmethoden ein. Möglicherweise liegt es daran, dass diese Entwicklungsmethoden besondere Anforderungen an das Projektmanagement stellen – beispielsweise an die eingesetzten Werkzeuge, an die Vorgehensweisen, aber auch an die Softskills der Projektbeteiligten.

Dabei ist die agile Softwareentwicklung nicht mehr ganz neu. Sie entstand ursprünglich als Gegenbewegung gegenüber Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell, die als zu schwergewichtig und bürokratisch kritisiert wurden. Softwareentwicklungsprozesse sollten mehr auf die technischen und sozialen Probleme bei der Softwareentwicklung eingehen, einfach umzusetzen und flexibel anzupassen sein. Anfang der 90er Jahre erschienen die ersten Ansätze zu agiler Softwareentwicklung. Als Kent Beck u.a. 1999 das erste Buch zu Extreme Programming veröffentlichte, erreichte die agile Softwareentwicklung große Popularität. Mittlerweile gibt es neben Extreme Programming noch weitere agile Methoden wie beispielsweise Crystal Methodiken, Scrum und Adaptive Software Development.

Im Gegensatz zu plangesteuerten Prozessen erfassen agile Prozessen die Kundenwünsche schrittweise. Sie sind so konzipiert, dass auch spät veränderte Anforderungen rasch in die Entwicklung der Software einbezogen werden, was vor allem durch kurze Iterationszyklen und die regelmäßige Erstellung von Inkrementen erreicht wird. Die Zufriedenheit des Kunden hat höchste Priorität und seine Mitwirkung stellt einen kritischer Erfolgsfaktor dar. Der Austausch über Dokumente ist passé, stattdessen steht die direkte face-to-face-Kommunikation im Mittelpunkt. Darüber hinaus wird die eigene Effektivität regelmäßig überprüft und verbessert.

Wie sich Softwareprojekte verbessern lassen, ist mittlerweile kein Geheimnis mehr. An Studien und Praxisempfehlungen für erfolgreiche Softwareprojekte mangelt es nicht. Die Herausforderung liegt bei der Umsetzung. Die Verantwortlichen müssen bereit sein, sich professionelleren Methoden zu öffnen. Erst dann kann sich die Zahl der erfolgreichen Softwareprojekte auch langfristig erhöhen.

Zehn Faktoren für erfolgreiche Projekte nach der Standish-Group

User Involvement

Executive Management Support

Clear Business Objektives

Optimizing Scope

Agile Process

Project Manager Expertise

Financial Management

Skilled Ressources

Formale Methodology

Standard Tools and Infrastructure

Copyright © 2003-2012 ap Verlag GmbH