Vage Gründe für das Scheitern
Warum IT-Projekte unberechenbarer sind als andere Vorhaben, mag auch Laartz nicht eindeutig begründen. Möglicherweise kämen hier verstärkt die beiden am weitesten verbreiteten Ursachen für Fehleinschätzungen zum Tragen. Die seien:
-
Übertriebener Optimismus aufgrund einer interessengeleiteten Darstellung des Projekts ("Optimism Bias"); dieser Fehler lässt sich durch die Nutzung einer unabhängigen Risikoeinschätzung korrigieren, wie sie beispielsweise das "Reference Class Forecasting" darstellt.
-
Mangelnder Fokus auf die strategischen Ziele ("Strategic Misrepresentation"); das führt dazu, dass im Projektverlauf Änderungen vorgenommen werden, die den Nutzen des Vorhabens schmälern, wenn nicht verhindern.
Weitere Besonderheiten von IT-Projekten liegen auf der technischen Seite. Dazu gehören beispielsweise Unwägbarkeiten in der Implementierungsphase. Wie Laartz einräumt, ist die Untersuchung in diesem Punkt noch nicht abgeschlossen: "Wir können nur etwa jeden zweiten Fall auf seine Ursachen zurückführen."
Das macht die Suche nach einem Gegengift umso schwieriger. Nicht einmal die Betrachtung der Best-in-class-Projekte hilft hier sehr viel weiter: Auch von den IT-Vorhaben, in denen fast alles richtig gemacht wurde, endete jedes zehnte im "schwarzen" Bereich.
Size doesn't matter that much
Seit den 90er Jahren beschäftigen sich die Berater und Analysten mit der Frage, was signifikante Budgetüberschreitungen verursacht und wie sie sich vermeiden lassen. Zum Ende des vergangenen Jahrhunderts galt die von Capers Jones aufgestellte These, dass die Wahrscheinlichkeit der finanziellen Bruchlandung mit der Größe des Projekts wachse. Zu einem ähnlichen Ergebnis kam die Standish Group später in ihrem "Chaos Report".
McKinsey ist jedoch anderer Ansicht: "Es gibt keine Korrelation von Misserfolg und Projektgröße", konstatiert Laartz - "jedenfalls heute nicht mehr". Die Unternehmen hätten mittlerweile gelernt, umfangreiche Projekte zu modularisieren: "In der Folge haben sich die Risikoprofile von großen und mittleren Projekten angenähert."
Allerdings tun sich Analysten und Wissenschaftler auch schwer, andere Zusammenhänge zu finden. Fest steht allerdings, dass die finanziellen Exzesse auch mit exorbitanten Zeitüberschreitungen einhergehen. Dass Projekte mehr als anderthalb mal so lange dauern wie geplant, ist dabei sogar noch an der Tagesordnung. Die Vorhaben, die ihre Plankosten um mehr als 200 Prozent überschreiten, brauchen noch mehr Zeit: Im Durchschnitt überziehen sie den Zeitplan um 68 Prozent. Das veranlasst Laartz zu der Feststellung: "Je länger ein Projekt dauert, desto höher das Risiko eines Cost Overrun." Also ist nicht der Projektmfang, sondern die benötigte Zeit der Hauptrisikofaktor.
- Spielregeln für das Projekt-Team
Diese Spielregeln sorgen für eine offene Kommunikation und bieten auch im Konfliktfall eine Orientierung. - Projektauftrag klar definieren
Der Projektauftrag ist das A und O der Projektdurchführung. Er bildet die Grundlage für die Abnahme der Projektergebnisse und damit den Projekterfolg! - Projekt in steuerbare Arbeitspakete schneiden
In jeder Phase des Projekts den Überblick bewahren. - Betroffene zu Beteiligten machen
Ein offenes Ohr für die Projektbeteiligten erhöht die Akzeptanz der zukünftigen Nutzer. - Projekt(kern)team klein halten
Auch bei der Durchführung eines Projektes gilt: Zu viele Köche verderben den Brei. - Umgang mit Change Requests definieren
Hinterfragen Sie Änderungswünsche während der Projektdurchführung kritisch und prüfen Sie sie auf ihre Sinnhaftigkeit. - Abnahme-Prozess formalisieren
Keine Kritik ohne Verbesserungsvorschlag: Ein Feedback-Formular mit Pflichtfeld "Verbesserungsvorschlag" sorgt für Konstruktivität im Feedback-Prozess. - Projektmanagement leben
Kommunikation, Kommunikation und nochmal Kommunikation! - Management of Change: „Hypercare“ einplanen
Ein speziell hierfür ernannter Ansprechpartner hilft über Probleme und Sorgen in den ersten Tagen nach der Systemeinführung hinweg. - Übergabe in den Betrieb sicherstellen
Eine geregelte Übergabe ermöglicht den reibungslosen Betrieb des IT-Systems. - Lessons Learned
Die Erfahrungen sollten am Ende eines Projekts zusammengetragen werden, um für die nächsten Projekte zu lernen.