Johannes Bergsmann

Immer noch sind erschreckende Statistiken im Bereich Software-Projektabwicklung ein Faktum. Die Standish Group spricht gar davon, dass 75% aller Softwareprojekte scheitern beziehungsweise nicht termin- oder kostengerecht fertig gestellt werden. Könnten andere Engineering-Branchen wie die Fahrzeugindustrie, der Anlagenbau, die Elektronikindustrie mit diesen oder ähnlichen Tatsachen überleben? Warum ist dies in der Software-Branche anders? Muss dies so sein?

Software-Projekte ..

Ein Software-Projekt ist im Grunde nichts Ungewöhnliches im Vergleich zu anderen Projekten. Es ist ebenfalls gekennzeichnet durch die klassischen Projekteigenschaften:

• inhaltliche Zielsetzung und Neuartigkeit ("Ich möchte ein neues ERP-System"),
• zeitliche Zielsetzung ("Echtbetrieb des neuen Systems ab 1.9.2006"),
• beschränkte Ressourcen ("Kosten darf es max. € 500.000,-"),
• Komplexität ("Es gibt verschiedenste Schnittstellen zu anderen Systemen,

die Altdaten sind zu übernehmen...").

Daraus resultiert natürlich ein entsprechend erhöhtes Risiko (technisch, zeitlich, organisatorisch, personell, finanziell...). Um diese Risiken einigermaßen beherrschbar zu machen, gibt es eine Vielzahl an Methoden und Vorgehensweisen, die in den klassischen Engineering-Bereichen auch bereits meist mit Erfolg angewandt werden:

• detaillierte und klare Spezifikationen,
• ausführliche Projektplanung,
• Risikoanalyse des Projekts (vor Projektstart),
• begleitendes Qualitätsmanagement,
• begleitendes Controlling (laufend),
• ausführliche Tests während der Entwicklung und vor der Auslieferung.

Für IT-Projekte gibt es diese Methoden und Vorgehensweisen natürlich ebenfalls. Die Wissenschaft hat fast seit Beginn der ersten Software-Projekte entsprechende Methoden bereitgestellt und weiterentwickelt.

... sind anders!

Doch warum werden diese Methoden in den IT-Projekten oft nicht verwendet oder angenommen? Die Gründe dafür sind sehr vielschichtig. Aus Sicht der IT stellen sich die Problembereiche in den vorher genannten Methoden und Vorgehensweisen wie folgt dar:

• Detaillierte und klare Spezifikation

Ein gutes Projekt beginnt damit, dass sich der Auftraggeber klar ist, was er eigentlich benötigt, warum er es benötigt und was er damit erreichen will. In der Spezifikation werden diese Punkte gesammelt und damit wird maßgeblich die Qualität des Projekts beeinflusst. Es gilt das Motto "Sage mir wie dein Projekt beginnt, und ich sage Dir, wie es endet." Da eine gute Spezifikation auch aufwändig zu erstellen ist, ist einer der Hauptfehler, das hier aus Zeit- und Ressourcen-Gründen versucht wird, zu sparen. In vielen Fällen wird versucht, die "Verantwortung" auf die Lieferanten abzuschieben, was jedoch meist schief geht, da der Auftraggeber dann dem Lieferanten komplett ausgeliefert ist.

Ein weiteres großes Problem im Bereich der Spezifikation ist, dass - wenn überhaupt - sehr oft nur die funktionalen Bereiche der Software ("Das System soll Artikel wie folgt erfassen ...", "Wir benötigen einen Report X" ...) im Detail spezifiziert werden. Die nicht funktionalen Bereiche (Qualität, Ergonomie, Sicherheit, ...) werden zumeist gar nicht oder oft nur sehr ungenau spezifiziert ("Das System soll ausreichend performant sein.", "Die Software soll bei einem Absturz keine Daten verlieren" ...). Ein exzellenter Projektleiter und ein ebensolches Projektteam können natürlich Fehler in der Spezifikation zudecken und dem Projekt trotzdem noch zu einem Erfolg verhelfen. In den meisten Fällen jedoch werden Fehler in der Spezifikation den Projektverlauf massiv beeinflussen.

• Ausführliche Projektplanung und Risikoanalyse des Projekts

Dies ist natürlich nur dann sinnvoll möglich, wenn vorher auch die Anforderungen klar spezifiziert wurden. Da dies - wie vorher dargestellt - vielfach nicht oder nur unzureichend passiert, wird die Projektplanung und Risikoanalyse großteils nur auf der Basis von Vermutungen, Annahmen und vagen Schätzungen durchgeführt, was natürlich ab einem gewissen Komplexitätsgrad zwangsläufig zum Scheitern verurteilt ist.

• begleitendes Qualitätsmanagement und ausführliche Tests

Qualität kostet Geld! Und die meisten Auftraggeber beauftragen natürlich entsprechend sparsam. Jedoch wird hier leider nur dem Anschein nach und sehr kurzfristig gespart. Schlechte Qualität wirkt sich meist langfristig aus. Die Wartungs- und Betreuungskosten steigen dadurch an. Oft können durch schlechte Qualität verursachte Kosten auch nicht leicht erfasst werden und verschwinden dann meist in den Gemeinkosten (z.B. wenn aufgrund eines Designfehlers die Benutzer für einen Vorgang unnötig viel Zeit benötigen, der bei optimalem Design auch in der Hälfte der Zeit abzuwickeln wäre).

• begleitendes Controlling (laufend)

Ein Software-Projekt befindet sich immer in einem Spannungsfeld aus den Parametern Funktionalität, Zeit, Kosten und Qualität. Wenn man diese Parameter nicht permanent kontrolliert und entsprechende Maßnahmen zur Gegensteuerung durchführt, verändern sich diese Parameter fast unvermeidbar von selbst und führen am Projektende oft zu unliebsamen Überraschungen. Meist ist es so, dass sich die Funktionalität/Leistung erhöht. Da die Kosten oft pauschaliert sind und Terminüberschreitungen auch nur in geringem Maß toleriert werden, sinkt meist die Qualität der Ergebnisse entsprechend.

Das muss nicht so sein!

Software-Projekte sind objektiv betrachtet eigentlich nicht anders als klassische Engineering-Projekte! Da leider in der Vergangenheit viele Personen, Unternehmen und Organisationen schlechte Erfahrungen in Software-Projekten und -Produkten gemacht haben, leiden diese jedoch von vornherein unter einem schlechten Image:

• Software-Projekte kosten immer mehr, als man vereinbart.
• Software ist fehlerbehaftet, man muss mit den Fehlern leben.

Zusätzlich kommt erschwerend hinzu, dass Software allgegenwärtig ist, jeder damit in Berührung kommt und von den Software-Anbietern suggeriert wird, dass der Computer und die Software kinderleicht zu bedienen sind (wie meine Kaffeemaschine).

Da das alles so einfach und unkompliziert präsentiert wird, müssen dann scheinbar auch die Software-Projekte, die man im eigenen Unternehmen startet oder beauftragt, entsprechend einfach abzuwickeln sein. Anscheinend ist dies sehr weit im Unterbewusstsein der Entscheidungsträger und Projektverantwortlichen verbreitet, denn sonst würde nicht an so viele Software-Projekte mit einer fast naiven Unbefangenheit und Leichtigkeit herangegangen werden. Um die oft vorherrschende miserable Situation bei den Software-Projekten zukünftig zu verbessern, ist eine Bewusstseinsbildung bei den Entscheidungsträgern und Projektverantwortlichen notwendig.

Es gibt einige einfache Grundsätze, die jeder am Projekt Beteiligte wissen und anwenden sollte, um Fehleinschätzungen und Fehlschläge zu vermeiden:

• Software-Projekte sind komplex!
• Software-Projekte sind klassische Engineering-Projekt und daher auch so abzuwickeln!
• Software, die an die eigenen Bedürfnisse angepasst wird (auch wenn es sich um günstige Standard-Software handelt), kostet entsprechend viel.
• Qualitativ hochwertige Ingenieur-Leistungen benötigen entsprechende Zeit für Planung und Abwicklung.

Dipl.-Ing. Johannes Bergsmann ist Eigentümer des Unternehmens "Software Quality Lab" www.software-quality-lab.at, das Anfang 2003 gegründet wurde. Er ist seit 1996 gerichtlich beeideter Sachverständiger für Informatik und seit 1988 im IT-Bereich als Software-Entwickler, Berater, Projektleiter, technischer Leiter und Geschäftsführer tätig. Seit 2005 ist Herr Bergsmann auch staatlich geprüfter und beeideter Ziviltechniker für Informatik. Er ist Lehrbeauftragter und Gastvortragender an verschiedenen Institutionen (zum Beispiel HTL-Leonding, Universität Linz, Fachhochschule Hagenberg) sowie Vizepräsident der Österreichischen Vereinigung für Software-Qualitätsmanagement.

10 Erfolgsfaktoren des Software-Projektmanagements (aus Sicht des Auftraggebers)

• Genau und möglichst vollständig spezifizieren!

Die meisten Probleme resultieren aus einer unklaren oder unvollständigen Spezifikation. Wer hier spart, spart am falschen Platz.

• Einen realistischen Kosten- und Zeitrahmen kalkulieren!

Erfahrungsgemäß ändern sich Anforderungen im Laufe des Projekts. Faustregel: Addiere bei ungenauer Spezifikation 50-100% und bei genauer Spezifikation ca. 20% zu den Preisen und Projektzeiten der Anbieter. Nicht auf die internen Kosten vergessen!

• Auch die nicht funktionalen Anforderungen berücksichtigen!

Anforderungen hinsichtlich Qualität, Ergonomie, Sicherheit, Dokumentation, Testdurchführung u. a. werden zumeist gar nicht oder oft nur sehr ungenau spezifiziert. Dies führt dann oft am Projektende oder am Beginn des Echtbetriebs zu Konflikten zwischen Auftraggeber und Lieferant.

• Das System nicht nur aus der Sicht von heute planen, sondern die Anforderungen von morgen spezifizieren!

Es besteht die Gefahr, dass man "alten Wein in neuen Schläuchen" erhält. Innovative Wege werden dadurch oft nicht erkannt und eventuell sogar auf Jahre blockiert.

• Auf die Projekt-Verantwortung nicht vergessen - auch der Auftraggeber benötigt einen Projektleiter!

Es kommt häufig vor, dass der Lieferant nach dem Projektstart bis zum vereinbarten Realisierungstermin großteils allein gelassen wird. Dadurch verliert der Auftraggeber die Kontrolle über das Projekt. Es ist unbedingt erforderlich, dass es auf Auftraggeberseite auch einen Verantwortlichen (eventuell einen externen Projektmanager) für das Projekt gibt, der sich auch über den gesamten Projektverlauf entsprechend darum kümmert.

• Nicht zu sehr auf die Technologie konzentrieren.

Manche Projekt-Mitarbeiter (und teilweise auch Verantwortliche) sind oft technologie-verliebt und konzentrieren sich daher zu stark auf technologische Feinheiten, die eigentlich für den Projektverlauf irrelevant sind. Dadurch geht viel wertvolle Zeit verloren. Die meisten Projekte scheitern jedoch nicht an der Technologie, sondern an anderen Problemfeldern wie der Methodik, der Kommunikation, den Personen, ...

• Darauf achten, dass alle künftigen "Stakeholder" berücksichtigt und in das Projekt einbezogen werden!

Wenn die späteren Nutznießer und auch Benutzer einbezogen werden, verläuft das Projekt meist zielgerichteter und die Akzeptanz wird deutlich verbessert.

• Die Anbieter-Auswahl sorgfältig vornehmen!

Oft reicht ein Studium der Funktionsliste oder eine professionelle Verkaufs-Präsentation nicht aus, um den wahren Gehalt eines Software-Systems beurteilen zu können. Die Zeit für eine Probeinstallation, in der man sich dann natürlich auch entsprechend intensiv mit der Software auseinandersetzen sollte, ist sicherlich gut investiert. Es sollte außerdem eine detaillierte Nutzwertanalyse zur Bewertung durchgeführt werden.

• Die Balance im Spannungsfeld Funktionalität, Zeit, Kosten und Qualität halten und "ein faires Spiel spielen"!

Oft wächst die Komponente "Funktionalität" im Projektverlauf unscheinbar aber stetig aufgrund von Anforderungsänderungen des Auftraggebers. Oft ist die Qualität der einzige Parameter, der dann für den Lieferanten noch veränderbar ist. Schlechte Qualität schlägt sich zumeist langfristig in der Wartung nieder. Der Auftraggeber wird daher oft für kurzfristige, scheinbare Verhandlungserfolge langfristig zur Kasse gebeten.

• Genügend Zeit für den Test und die Abnahme der Software einplanen!

Gerade hier wird oft der Fehler gemacht, dass man nicht so genau prüft, auf einen Probebetrieb verzichtet und sich auf die Gewährleistungsfrist verlässt. Sofern eine Gewährleistungsfrist nicht ausgeschlossen wurde, muss der Lieferant natürlich nachbessern. Jedoch ist das System dann eventuell schon im Echtbetrieb und daher jede Störung um ein Vielfaches teurer als vor der Inbetriebnahme.