Typische Projektmanagement-Handbücher – unabhängig davon, ob für traditionelle Wasserfall- oder agile Methoden – decken nicht alle Aspekte der Projektarbeit ab. Sie enthalten "weisse Flecken", die in der "Pyramide des Scheiterns" immer wieder für Probleme in IT-Grossprojekten sorgen oder diese sogar zum Scheitern bringen können.

Beim derzeitigen Hype um agile Entwicklungsmethoden wie Scrum, Kanban und weitere, teilweise hybride Varianten müsste man eigentlich annehmen, dass die Anzahl gescheiterter IT-Projekte abnimmt. Dem ist allerdings nicht so, wie die seit 1994 in regelmässig veröffentlichte "CHAOS-"Studie der US-Beratungsfirma The Standish Group zeigt (s. Abbildung unten). Die Studie basiert auf einer Datenbank mit mehr als 50'000 detaillierten Projektprofilen.

Wie aus der Abbildung ersichtlich wird, bewegt sich die relative Anzahl der sogenannten failed projects (abgebrochene Projekte) seit Jahren konstant bei rund 20%. Auch die challenged projects, also solche mit Termin- und/oder Kostenüberschreitung respektive reduzierter Funktionalität, bleiben mit wenigen Abweichungen ziemlich konstant bei rund 50%.

Woran kann das liegen?

In meinem Buch "Projektmanagement für Profis" habe ich den Untersuchungsbericht des vor 10 Jahren mit 116 Millionen Franken spektakulär gescheiterten Megaprojektes Insiemeder Eidgenössischen Steuerverwaltung (ESTV) analysiert. Die darin enthaltenen Befunde habe ich mit meinen eigenen Erfahrungen als IT- und Businessprojektleiter im Finanzwesen abgeglichen.

Auf dieser Basis und gestützt auf weitere Recherchen habe ich die unten dargestellte "Pyramide des Scheiterns" entwickelt. Sie zeigt die wichtigsten, in Methodenhandbüchern aber leider nur stiefmütterlich – wenn überhaupt – behandelten vier Problembereiche grosser IT-Projekte: Projektleitung, Aufsicht und Kontrolle, Komplexität sowie Governance.

In meinen über 40 Berufsjahren als Business Analyst und Projektleiter habe ich kein einziges Projekt gesehen, das an technischen Schwierigkeiten gescheitert ist. Die Ursachen sämtlicher von mir beobachteten und analysierten IT-Flops hatten mit Menschen und/oder Strukturen zu tun. Unzweckmässige Strukturen ziehen sich dabei wie ein roter Faden durch alle mir bekannten IT-Flops.

Meine erste Kolumne widmet sich deshalb einem der meistunterschätzten Aspekte grosser IT-Vorhaben: der Projektorganisation.

Gemeint ist damit in erster Linie das Organigramm für die Projektleiterin und ihr Team. Die Probleme übergeordneter Governance-Strukturen mit möglichen Interessenkonflikten und Machtkonzentrationen beim Auftraggeber und dem Projektausschuss werde ich in einem der nächsten Beiträge thematisieren.

Für die tägliche Projektarbeit ist das Thema wichtig, weil nur sorgfältig aufgesetzte Strukturen dafür sorgen, dass kein Sand ins (Projekt-)Getriebe gerät. Mit einer klaren Aufbauorganisation werden die Weisungsbefugnisse und Verantwortlichkeiten zugeordnet und so eindeutig wie möglich voneinander abgegrenzt. Die tägliche Arbeit eines Projektteams verläuft deutlich reibungsärmer, wenn es nicht zu Streitigkeiten um Kompetenzen oder Doppelspurigkeiten kommt. Deshalb ist die Gestaltung einer effizienten Teamstruktur eine der wichtigsten Aufgaben der Projektleitung gleich zu Beginn des Vorhabens.

Wegen ihrer grossen Bedeutung für den Projekterfolg habe ich mir angewöhnt, bei jedem Einsatz als Troubleshooter zuerst die Organisationsstruktur einer eingehenden Prüfung zu unterziehen. Dabei achte ich speziell auf die folgenden 6 Qualitätskriterien:

Die beiden folgenden Praxisbeispiele zeigen, wie in diesen Projekten gleich mehrere der genannten Qualitätskriterien verletzt wurden.

Im ersten Beispiel werden die Kriterien 1 und 6 verletzt. Ich wurde damals als Troubleshooter von einer Schweizer Grossbank eingesetzt, weil das Projekt in akute Schieflage geraten war.

Bereits beim Blick auf das Organigramm stellte ich fest: Die operative Führungsebene war sowohl funktional (Verification etc.) wie auch objektorientiert (IT-Tool) aufgesetzt. Zudem liessen sich auf der Governance-Ebene entweder das Steering Committee oder das Project Committee ersatzlos streichen. In Absprache mit dem Auftraggeber wurde eine Ebene entfernt und die operative Führung klarer funktional ausgerichtet. Nachdem wir das Projekt nach ein paar Monaten stabilisiert hatten, konnte ich es einem internen, ambitionierten Junior-Projektleiter übergeben.

Im zweiten Beispiel sind die Kriterien 3 und 4 nicht erfüllt. Mit diesem Projekt (ebenfalls in einer Schweizer Grossbank) sollte das eingekaufte Private Banking Modul einer Gesamtbank-Software implementiert werden.

Die beiden Delivery Teams – eines davon unter meiner Leitung – waren personell zwar gut dotiert, standen allerdings 12 (!) Einheiten mit Querschnitts- oder Supportfunktionen gegenüber. Unschwer sich vorzustellen, wie in den Führungsmeetings die Gesprächsanteile bemessen waren und weshalb der Fokus auf den Projekterfolg verloren ging. Ich habe deswegen und angesichts der schwindenden Erfolgsaussichten das Projekt verlassen. Ein paar Monate später wurde es zuerst redimensioniert und danach ganz abgebrochen.

Während auf der Governance-Ebene die Linienvorgesetzten und Aufsichtsorgane gegen unzweckmässige Strukturen intervenieren müssen, geht es bei der Teamorganisation darum,

Eine gut aufgesetzte Teamorganisation ist zwar noch kein Garant für Erfolg, aber zumindest lassen sich damit ein paar der gröbsten Fehler in der Projektarbeit vermeiden.