Schiffbruch vermeiden

Der Autor hat an der Universität St. Gallen in Betriebswirtschaft promoviert, ist diplomierter Ingenieur der ETH Zürich und verfügt über mehr als 20 Jahre Beratererfahrung, vorwiegend in der Finanzbranche. Für Trivadis ist er als Senior Consultant für Business Intelligence tätig. Viel zu viele IT-Grossprojekte laufen aus dem Ruder. Eine von McKinsey und der Universität Oxford durchgeführte Untersuchung von mehr als 5400 IT-Projekten aus dem Jahr 2012 macht dies einmal mehr deutlich. Demnach weisen grosse Projekte (mit einem Budget von über 15 Millionen US-Dollar) im Durchschnitt Mehrkosten von 45 Prozent sowie Verzögerungen von 7 Prozent auf und erbringen einen um 56 Prozent geringeren Nutzen als erwartet. Grosse Software-Projekte schneiden dabei in den ersten beiden Punkten besonders schlecht ab: 66 Prozent Mehrkosten, 33 Prozent Verzögerungen, allerdings nur 17 Prozent weniger Nutzen als erwartet. Ursachen für das Versagen von IT-Projekten nennt die Studie mehrere: unklare Zielsetzungen und fehlenden geschäftlichen Fokus, unrealistische Terminplanung und reaktive Planung sowie wechselnde Anforderungen und technische Komplexität. Angesichts der aufsehenerregenden Zahlen stellt sich die Frage: Wie können die Erfolgsaussichten von IT-Projekten verbessert werden?

Als gescheitert gilt ein Projekt, wenn eine inakzeptable Abweichung zwischen den erwarteten und den erreichten Projektresultaten besteht. Gescheiterte IT-Projekte sind beispielsweise solche, die abgebrochen, mit Mehrkosten, verspätet oder mit ungenügender Funktionalität enden. Begünstigt werden Misserfolge durch die oftmals vielseitigen und widersprüchlichen technischen wie fachlichen Anforderungen. Ein weiterer Faktor ist die ungleiche Verteilung von Aufgaben zwischen den Projekt-Stakeholdern: Auftrag­geber, Projektmanager, Entwickler und Nutzer. Denn IT-Projekte, welche die Zusammenarbeit Dutzender Spezialisten erfordern, sind keine Ausnahme, sondern die Regel. Offshoring und Outsourcing von IT-Aufgaben erfordern zusätzlichen Kommuni­kations-, Koordinations- und Kontrollaufwand. Wie wichtig gerade die Kommunikation für den Erfolg bzw. Miss­erfolg eines Projekts ist, zeigt der Fall der Weltraumsonde Mars Climate Orbiter. Die NASA-Sonde ging 1999 nur deshalb verloren, weil zwei Projektteams unterschiedliche Masseinheiten benutzten: das metrische SI-System mit Kilogramm, Meter und Zentimeter sowie das angloamerikanische mit Pfund, Fuss und Zoll. Lesen Sie auf der nächsten Seite: Gegenmassnahmen

Fallstudien und statistische Unter­suchungen nennen übereinstimmend vier Haupt­­ursachen für das Misslingen von IT-Projekten: unklare Anforderungen, zu optimistische Planung, fehlende Kontrolle sowie mangelhafte Kommunikation. Daraus abgeleitet, sind folgende Gegenmassnahmen zu empfehlen: Business Case: Der geschäftliche Nutzen eines IT-Projekts muss aufgrund eines realistischen Business Cases nachgewiesen werden. Dieser enthält Simulationen von Trendszenarien sowie positive und negative Extremszenarien. Eckdaten wie die Amortisationsdauer und der interne Zinsfuss erleichtern die Evaluation der Projektrentabilität. Nutzenmanagement: Ein Nutzenmanagementsystem bezweckt die zielgerichtete Planung und Steuerung des erwarteten geschäft­lichen Projektnutzens. Hier ist zu beachten, dass der Projektaufwand grösstenteils in der IT-Abteilung entsteht, während der Ertrag den Fachabteilungen in Form von Kostensenkungen oder Umsatzsteigerungen zugutekommt. Ein Nut­zen-Review hilft, detaillierte Einsichten über Entstehung und Zusammensetzung des Nutzens zu gewinnen. Bei einer schrittweisen Einführung ist der Nutzen das Kriterium für die Priorisierung. Klare Anforderungen: Ein detailliertes Pflichtenheft dient der Fokussierung von knappen Ressourcen auf konkrete Projektergebnisse und erleichtert das Messen der Zielerreichung. Pragmatische Planung: Budgetüberschreitungen und Verzögerungen infolge zu optimistischer Erwartungen sind zu vermeiden. Deshalb nehmen die für die Umsetzung Verantwortlichen an der Bottom-up-Schätzung von Aufwänden und Terminen teil, die auf Erfahrungswerten und realistischen Annahmen basiert. Reserven für Unvorhergesehenes helfen, Spielraum für den Umgang mit internen und externen Projektrisiken zu erhalten. Verkleinerung des Projektumfangs: Grosse Projekte versagen überproportional oft. Bei langjährigen Projekten besteht die Gefahr, dass sich bei Projektende die Rahmenbedingungen stark verändert haben. Deshalb werden grosse Projekte in kleine (maximal 6 Monate) unterteilt und im Sinne eines Projektportfolios realisiert. Schrittweise Einführung: Für die Einführung von umfangreichen, unternehmensweiten Systemen ist ein schrittweises Vorgehen sinnvoll (etappenweise Erweiterung der Funktionalität durch verschiedene Releases). Das Roll-out findet am besten stufenweise statt, zum Beispiel von einer Tochtergesellschaft zur anderen. Stösst das Projektteam an einer Stelle auf Prob­leme, kann es deren Lösung lokal suchen, ohne bisher Erreichtes zu gefährden. Meilensteine und Kontrollpunkte: In regelmässigen Zeitabständen durchgeführte Kont­rollen helfen, Zielabweichungen zu prognostizieren und frühzeitig Korrekturmassnahmen zu ergreifen. Zudem eignen sich die Kontrollen gut, um getroffene Annahmen zu revidieren, veränderte Rahmenbedingungen zu berücksichtigen und die Zuverlässigkeit der Planung zu erhöhen. Kommunikation: Ein regelmässiger Austausch zwischen den Projektbeteiligten, insbesondere unter Teilnahme der zukünftigen Systembenutzer, fördert eine Realisierung mit der erwarteten Funktionalität. Change Request Management: Die kon­sequente Dokumentation, Genehmigung und Überwachung von beantragten Änderungen der ursprünglichen Anforderungen verhindern das unkontrollierte Anwachsen des Projektumfangs. Testmanagement: Quantitative Zielsetzungen (Metriken) für die Testresultate sowie eine systematische Planung und Durchführung der Tests helfen, das spezifizierte Qualitätsniveau vor dem Release zu erreichen. Prototypen und Pilotprojekte: Für innovative oder komplexe Vorhaben empfiehlt es sich, das Realisierungsrisiko mit Prototypen oder Pilotprojekten zu beschränken. Erste Erfahrungen, die in einem kontrollierten Umfeld gesammelt werden, können die Machbarkeit bestätigen. Projekt-Reviews: Das Projektteam führt diese während der gesamten Projektdauer durch. Ziel ist es, fachliche und technische Probleme gemeinsam und möglichst früh anzugehen. Peer-Reviews: Bei komplexen oder umfangreichen Vorhaben überprüft eine unabhängige Person stichpro­benweise die erreichten Resultate, in
Analogie zu einem Prüfingenieur für Brückenbauprojekte. Monitoring: Die Echtzeitüber­wachung des Verhaltens von ungewöhnlichen oder innovativen Systemen während der Entwicklung und dem Betrieb liefert Erkenntnisse für zukünftige Vorhaben. Die Benutzerfreundlichkeit von Onlineshops wird beispielsweise durch eine automatisierte Beobachtung der Antwortzeiten und des Navigationsverhaltens der Nutzer gesichert. Wissen: Die Teilnahme an Fachkonferenzen, die Mitgliedschaft in Fachvereinen, das Studium von Fachzeitschriften sowie Gespräche mit Experten tragen dazu bei, den Wissensstand der Projektteilnehmer zu erhöhen. Lesen Sie auf der nächsten Seite: Schlussfolgerungen

Das Scheitern jedes einzelnen IT-Projekts enthält Informationen, um das Versagen weiterer Projekte zu vermeiden. Daraus können konkrete Massnahmen (siehe oben) abgeleitet werden. Diese Massnahmen, beispielsweise der Gebrauch von Pflichtenheften, sind für Gross- und Kleinprojekte relevant, wie folgender, nicht allzu seltene Fall zeigt: Unternehmen aller Grössen treffen manchmal den Entscheid, selbstent­wickelte Applikationen neu zu programmieren, um sie mit beinahe gleicher Funktionalität in einer moderneren IT-Plattform zu betreiben. Mit der Begründung, die vorhandene und die neue Applikation seien funktionsmässig deckungsgleich, unterlassen sie es, die Anforderungen in einem Pflichtenheft festzuhalten. Die vorhandene Applikation übernimmt dann die Rolle des Pflichtenhefts. Nun stellt sich nachträglich heraus, dass die auf den ersten Blick einfach erscheinende bestehende Applikation, unerwartet umfassend und komplex ist. Der tatsäch­liche Entwicklungsaufwand übersteigt den geplanten um das Mehrfache. Das Gleiche gilt für die Entwicklungsdauer bei stark reduzierter Funktionalität. Nach hohen Verlusten bricht das Unternehmen das Projekt ab und sucht nach weiteren Alternativen, beispielsweise Standard-Software. Das Fallbeispiel zeigt, dass einfache Massnahmen einen entscheidenden Beitrag zum Erfolg von IT-Projekten leisten können.