Gleich vorweg: Dieser Artikel bietet kein Patentrezept für das achte Weltwunder. Erstens macht es keinen Sinn, grundsätzlich jedes gefährdete IT Projekt zu retten: Es gibt IT Projekte, wo sich das Projektziel nicht mehr mit vertretbaren Kosten erreichen lässt. Zweitens sind die Gründe für das Scheitern von IT Projekten vielfältig, ebenso vielfältig sind die Lösungsansätze. In diesem Artikel wird folglich ein Set an praxistaugliche Methoden skizziert, mit deren Hilfe ein Lösungsweg erarbeitet werden kann.

Der Troubleshooter: Wer ist geeignet?

In einem ersten Schritt ist es erforderlich, den Status Quo in einem IT Projekt zu bestimmen: Welcher Entwicklungsfortschritt wurde erreicht, welche Features sind bereits umgesetzt? Was sind die Ursachen für die Projektkrise: Unvollständige Spezifikationen, mangelnde Expertise der Entwickler in den einschlägigen Technologien, falsche Priorisierung der Features, mangelhafte Kommunikation, überforderte Projektmanager oder Anderes? Lassen sich die Projektziele mit vertretbarem Aufwand noch erreichen, ohne den Return-on-Investment eines IT Projektes zu gefährden?

Bereits diese Frage lässt sich keineswegs pauschal beantworten. Es ist empfehlenswert, dass das Top Management (etwa: die Geschäftsführung) mit den relevanten Parteien (z.B. fachliche Leitung, technische Leitung) Gespräche führt, um zu einer groben Situationseinschätzung zu kommen. In manchen Fällen kann der Turnaround aus dem bestehenden Projektteam selbst gelingen; es gibt andererseits Indizien, die einen externen Troubleshooter erfordern: Die Kommunikation funktioniert nicht mehr, die Situation ist (emotional) vollkommen verfahren. Oder es gibt Anzeichen dafür, dass das Projektmanagement überfordert ist. Wenn die Qualität der bisherigen Entwicklungsergebnisse kritisch ist, sollte ebenfalls dringend ein externer Troubleshooter mit dem erforderlichen technischen Background hinzugezogen werden.
Sofern ein externer Troubleshooter das Spielfeld betritt (dies kann auch ein „externer“ Troubleshooter aus einem anderen Unternehmensbereich sein), dann sollte dieser vor allem folgende Eigenschaften mitbringen: Ausgeprägte Kommunikationsstärke, hohe Belastbarkeit, gute analytische Fähigkeiten und Fachwissen im einschlägigen Technologieumfeld sowie fachlichen Umfeld. Das Knowhow zu agilem und klassischem IT Projektmanagement sollte eine Selbstverständlichkeit sein. Im Hinblick auf die Akzeptanz bei den verschiedenen Parteien im Projekt sollte er eine Sachautorität mitbringen, etwa aufgrund nachweiser Erfolge im Projektmanagement.

Analyse des Projektstatus sowie der Krisenursachen

Es klingt banal, ein no-brainer, aber gerade in gefährdeten IT Projekten ist diese Frage häufig nicht so einfach zu beantworten: Wo stehen wir in dem Projekt? Welche Anforderungen sind bereits umgesetzt, getestet, einsatzfähig? Welche Features werden gegebenenfalls bereits genutzt? Welche Kosten sind bereits entstanden? Sind die Meilensteine und Aufwendungen bis zum Erreichen der initial vereinbarten Projektziele bereits definiert, mit welcher Unsicherheit sind diese behaftet?

Der Troubleshooter muss sich darüber hinaus ein Bild darüber verschaffen, wie das Projekt in die Krisensituation geraten ist. Dafür gibt es eine Vielzahl von möglichen Ursachen, nachfolgend seien einige aufgeführt (ohne Anspruch auf Vollständigkeit): Die fachliche Seite liefert falsche, unvollständige oder missverständliche funktionale Spezifikationen. Die Projektleitung oder (in einem Scrum-Projekt) der Product Owner ist überfordert und führt nicht rechtzeitig (oder überhaupt nicht) die erforderlichen Priorisierungsentscheidungen herbei. Der Technology Stack für das Projekt ist falsch gewählt und führt zu schlechter Performanz, geringer Skalierbarkeit oder funktionalen Einschränkungen (die im schlimmsten Fall die Projektziele gefährden). Es werden Bibliotheken eingesetzt, die lizenzrechtliche Probleme verursachen. Das Entwickler-Team weist eine hohe Fluktuation auf. Das Entwicklerteam bringt keine ausreichende Expertise für die eingesetzte Technologie mit. Die Endnutzer werden zu spät in den Entwicklungsprozess eingebunden (untypisch für Projekte, die agile Methoden einsetzen). Das Budget wurde von Anfang an zu niedrig angesetzt.

Für diese Statusanalyse und Krisenanalyse ist die Einarbeitung in die wesentlichen Projektunterlagen und Projektdokumentation erforderlich, ebenso wie Gespräche mit zentralen Akteuren im IT Projekt. Je nach Größe eines Projektes dauert eine solche erste Analysephase ein bis maximal drei Wochen.

Neuausrichtung, Projektstopp oder Erarbeitung alternativer Entwicklungspfade

Bei einfach strukturierten Problemursachen oder aber in kleinen bis mittelgroßen Projekten lassen sich nach der ersten Analysephase bereits klare Entscheidungen fällen: Ein Projekt wird gestoppt, weil die Projektziele außerhalb einer finanzielle oder zeitlich vertretbaren Reichweite liegen. Oder die Projektziele werden angepasst oder aber ein Entwicklerteam (eines IT Dienstleisters) wird nach Eskalation umgestaltet. Zu treffende Maßnahmen ergeben sich bei einfach strukturierten Projekten in der Regel aus den Krisenursachen.
Bei einigen IT Projekten – insbesondere bei umfangreicheren Vorhaben – benennt die erste Analysephase zwar die Krisenursachen, die Ausarbeitung von Lösungsansätzen jedoch erfordert mehr Zeit: So könnte etwa das Management vorgeben, dass ein bestimmter Zeitrahmen zwingend einzuhalten ist. Für einen solchen Fall müssten verschiedene Entwicklungsoptionen ausgearbeitet werden, dies reicht von einer Neu-Priorisierung der Anforderungen über den Einsatz neuer Technologien (oder Dritt-Parteien-Komponenten) bis hin zu einer Skalierung des Projektteams (und des Projektbudgets). Auf die Analysephase folgt in dem Fall eine (konzeptionelle) Lösungsphase, die wiederum 1 bis 3 Wochen in Anspruch nehmen kann.

Projektneustart: Erneuter Kick-Off, klare Projektvision, enges Projektcontrolling

Ist ein Projekt einmal in die Krise geraten, haben sich häufig Frustration, Ärger und/oder Motivationslosigkeit bei den Beteiligten breit gemacht. Darum ist es eminent wichtig, eine sichtbare Zäsur zu machen und das „alte“ Projekt bzw. die Vergangenheit abzuschließen. In einem Kick-Off für die Projektphase nach der Krise sollte nachvollziehbar für alle dargestellt werden, was als Krisenursachen identifiziert wurde und mit welchen Maßnahmen der Projekterfolg in (naher) Zukunft sichergestellt wird. Die Präsenz des Top Managements bei diesem Kick-Off unterstreicht diesen Neuanfang.

Hierbei ist die klare Kommunikation der Projektvision nochmals zwingend erforderlich: Warum setzen wir dieses Projekt um? Was bringt uns das IT Projekt? Warum ist das dem Top Management so wichtig? Je überzeugender diese Zielvision, desto besser kommt ein Projektteam auch einmal durch eine schwierige Phase in einem Projekt, desto höher die Motivation, die „extra Meile zu gehen“.
Und last but not least: Die Fortschrittskontrolle bzw. das Projektcontrolling hat nach einer Krise eine besondere Relevanz. Sofern ein solches IT Projektcontrolling bereits vor der Krise bestand, so ist es zumindest dahingehend zu erweitern, dass zukünftig jene Ursachen schnell sichtbar werden, die zur Krise geführt hatten.

“Ich bin nicht gescheitert – ich habe 10.000 Wege entdeckt, die nicht funktioniert haben.”
Thomas Alva Edison

Sebastian Zang
Author

Der Autor ist Manager in der Softwareindustrie mit internationaler Expertise: Prokurist bei einem der großen Beratungshäuser - Verantwortung für den Aufbau eines IT Entwicklungszentrums am Offshore-Standort Bangalore - Director M&A bei einem Softwarehaus in Berlin.