Problematische IT-Projekte beenden?

Ein IT-Projekt dauert viel länger als erwartet, die Kosten haben sich vervielfacht, die bisherigen Lieferungen entsprechen nicht den Erwartungen des Auftraggebers. Die bisher getroffenen Maßnahmen haben nicht ausgereicht, das Projekt wieder auf Erfolgskurs zu bringen. Was können Sie veranlassen, um eine tragfähige Entscheidung über die Zukunft des Projekts zu treffen? Ist es zielführend, die Ausrichtung oder das Management des Projektes maßgeblich zu verändern oder müssen Sie die Beendigung des Projektes empfehlen? Dazu gehören Fragen wie: Wie geht das Unternehmen am besten weiter vor? Ist das Projekt noch zu retten? Stimmt die Projektaufstellung? Funktioniert das Projektmanagement?

Häufig ist eine Eskalation schon fortgeschritten, das Management drängt auf möglichst belastbare Handlungsoptionen. Daher steht für eine erste Einschätzung nur wenig Zeit zur Verfügung, so dass ein sehr zielgerichtetes Vorgehen erforderlich ist. Als Basis für die Beantwortung der Fragen muss der Projektstatus ermittelt werden. Ich stelle dazu eine Lösung aus der Sachverständigenpraxis vor, die auf smarte Indikatoren fokussiert und mit einem überschaubaren Aufwand aussagekräftige Ergebnisse liefert. Mit der Analyse dieser Indikatoren durch die Beantwortung der zugehörigen Fragen schaffen Sie eine einleuchtende Basis für das Management, eine Entscheidung über die Zukunft des Projekts zu treffen.

Die effiziente Lösung zur Beurteilung der Projektaussichten liegt in sehr vielen Fällen nicht darin, funktionale Anforderungen der Reihe nach auf den Umsetzungsgrad zu prüfen. Das ist aufwendig und geht häufig an den eigentlichen Ursachen vorbei. Vielmehr sollten Sie Ihre Analyse bei den handwerklichen Aspekten beginnen. Das ist vergleichbar mit dem Bau eines Hauses, der nur gelingt, wenn die Statik richtig berechnet ist und die Baustoffe so ausgewählt sind, dass keine Wärmebrücken entstehen. Auch die Handwerker sollten Termine und gerade Wände schätzen.

Die fachgerechte Umsetzung von Projektmanagement und Projektaufstellung ist daher unabdingbare Voraussetzung für eine erfolgreiche Projektdurchführung. Defizite in diesen Bereichen liefern gerade bei Projekten in Schieflage aussagekräftige Anhaltspunkte für die Ursachen und die Zuordnung von Verantwortlichkeiten für derzeitige Krisensituation.

Die folgenden vier Größen haben sich in der Praxis als Indikatoren für den Projektstatus bewährt:

Change Requests
Datenübernahme
Schnittstellen und Services
Mitwirkungsleistungen

1. Change Requests

Änderungsanforderungen des Auftraggebers gibt es in nahezu jedem Projekt. Sie sind letztendlich ein Merkmal für ein lebendes Unternehmen und daher notwendige Zutaten eines Projektes. Sie verändern die umzusetzenden Anforderungen und bilden daher ein relevantes Beurteilungskriterium für den Projekterfolg.

Wesentlich in diesem Kontext ist, wie mit diesen Change Requests umgegangen wird. Zur Beurteilung bieten sich Antworten auf folgende Fragen an, die den Umsetzungsgrad eines fachgerechten Projektmanagements widerspiegeln. In agilen Projekten liefert ein Blick in den Backlog und die Sprintplanung Antworten auf die Frage, was noch im Scope des Projektes liegt.

Gibt es ein vertraglich geregeltes Verfahren zur Abarbeitung von Change Requests?

In welchem Status befinden sich die Change Requests:

Welche sind vom Auftragnehmer hinsichtlich der Auswirkungen für das Projekt (Zeit, Kosten, Risiken) bewertet worden?
Welche wurden vom Auftraggeber beantragt?
Welche wurden bisher nicht beauftragt?
Welche wurden (endgültig) abgelehnt?
In welchem Umsetzungsstadium befinden sich die beauftragten Change Requests (begonnen/in Arbeit, abgeschlossen, bereitgestellt, oder freigegeben durch Auftraggeber)?

Bei nahezu allen Projekten in einer Schieflage ist festzustellen, dass der Großteil dieser Fragen nicht ohne erheblichen Such- und Zusammenstellungsaufwand beantwortet werden konnte. Es hatten sich andere Themen in den Vordergrund geschoben; im Ergebnis gibt es damit kein abgestimmtes Kriteriengerüst zur Beurteilung des Projekterfolgs. Das betrifft Auftraggeber und Auftragnehmer gleichermaßen.

2. Datenübernahme

In vielen Projekten wird kein System auf der grünen Wiese neu eingeführt, sondern ein oder mehrere Systeme abgelöst oder eingebunden. Unterschätzt wird generell die Datenqualität in diesen Systemen. Nicht selten sind Daten gespeichert, die bereits mehrfache Systemwechsel mitgemacht haben. Zwei Fragen klären die Aufmerksamkeit, die der Übernahme von Daten zugewandt wurde:

Ist eine Analyse der Datenqualität der zu übernehmenden Daten durchgeführt worden?
Welche Schritte wurden aus den Ergebnissen abgeleitet und umgesetzt?

Wenn Daten übernommen werden müssen, ist es in einem späten Projektstadium faktisch nahezu unmöglich, eine unzureichende Datenqualität zu beseitigen. Die Problematik besteht in dem Knowhow der Datennutzung in den Altsystemen und der Expertise der Benutzer, die die Daten in diesen Systemen auf bestimmte Weise genutzt und gepflegt haben. Die Details dazu sind häufig wenig oder nicht dokumentiert. Bei Mitarbeiterwechseln und Systemänderungen geht dieses Knowhow häufig verloren und muss aufwändig neu zusammengestellt werden.

Weitere Fallstricke liegen bei der Migration der Daten. Es muss geklärt werden, welche Daten in welcher Form vom abgebenden auf das aufnehmende System übernommen (migriert) werden. Bei umfangreichen Datenbeständen kann es zur Vermeidung längerer Betriebsunterbrechungen notwendig werden, die Daten in mehreren Tranchen zu übertragen. Dazu sind folgende Punkte im Vorfeld zu klären und zu testen:

Welche Datenarten (Stammdaten, Bewegungsdaten) mit welchen Feldern werden für welche Zeiträume migriert?
Haben die zu übernehmenden Daten im neuen System die gleiche Bedeutung (Semantik)? Wie wird mit Abweichungen umgegangen?
Gibt es eine Abbildungstabelle (Mapping Table), die definiert, welche Datenfelder des abgebenden Systems in welche Datenfelder des aufnehmenden Systems übertragen werden?
Auf welche Weise erfolgt ggf. eine Umwandlung von Daten (beispielsweise Formatänderungen)?
Müssen mehrere Datenbestände zusammengeführt werden? Wie wird dabei mit Dubletten (gleichen Daten) umgegangen?

3. Schnittstellen und Services

Systeme arbeiten in der heutigen Zeit nicht mehr isoliert, sondern werden über Schnittstellen und Services mit anderen Systemen verbunden. Da es eine Reihe unterschiedlicher softwarearchitektonischer Ansätze und viele Standards gibt, muss bereits in der Konzeptions-Phase eines Projektes die Integration in eine Systemlandschaft im Einzelnen konzipiert werden. Die Analyse zeigt häufig Abhängigkeiten auf der fachlichen Ebene, die von den Realisierern (dem Auftragnehmer) nicht ohne weiteres erkannt werden können, aber massiven Einfluss auf die Realisierung haben. Unzutreffende Konzepte können leicht zu einem Neuaufsetzen wesentlicher Projektteile oder des ganzen Projektes führen.

Zur Analyse sollten folgende Fragen beantwortet werden:

Wurden die für das neue System notwendigen Services und Schnittstellen systematisch ermittelt und sind sie vollständig?
Ist für jede Schnittstelle und jeden Service klar, welche Anforderungen hinsichtlich der verbundenen Systeme, der Daten, des Antwortzeitverhaltens, der technischen Realisierung und der Nutzungsintensität bestehen?
Auf welche Weise ist die Bereitstellung der Schnittstellen und Services in die Projektplanung eingegangen?

Die Antworten belegen den zu erwartenden Konzeptionsgrad der Systemintegration. Bei Projekten in Schieflagen zeigen sich in der Regel mehrere Systemverbindungen mit einer unzureichenden Planung bzw. defizitären Umsetzungen.

4. Mitwirkungsleistungen

Der Auftraggeber stellt in vielen Fällen nicht nur Infrastruktur zur Verfügung, sondern muss auch fachliche Mitwirkungsleistungen erbringen. Hierzu gehören Antworten zur Ausgestaltung der Geschäftsprozesse, die Implementierung einzelner Funktionen oder die Organisationsstruktur des Unternehmens.

Die Mitarbeiter in Unternehmen sind in der Regel ausgelastet; besonders diejenigen, die einen Überblick der Geschäftsprozesse besitzen und Knowhow mit Informationen an einen Auftragnehmer weitergeben können. Die Mitwirkungsleistungen des Auftraggebers kommen somit in der Regel zum Tagesgeschäft hinzu, wenn dafür nicht ein entsprechender Ausgleich geschaffen wird. Ein Ersatz durch externe Mitarbeiter ist nur sehr begrenzt möglich, da diese nicht das unternehmensspezifische Knowhow mitbringen, um das es hier geht.

Ein kleines Rechenexempel: Wenn in einem Projekt 2.000 Stunden fachlich qualifizierte Mitwirkungsleistungen erbracht werden sollen und hierfür 10 Personen (beispielsweise Key User) zur Verfügung stehen, bedeutet das pro Person einen Aufwand von 200 Stunden. Diese Anzahl verteilt auf eine produktive Arbeitszeit von rund 40 Wochen bedeutet eine Mehrbelastung von 5 Stunden pro Woche durch das Projekt, was mehr als ein halber Arbeitstag ist. Hinzu kommt, dass diese Mehrbelastung nicht kontinuierlich zu erbringen ist, sondern eher sprunghaft verläuft und stark vom aktuellen Projektgeschehen abhängig ist.

Falls Mitwirkungsleistungen vertraglich begrenzt werden, muss der Auftraggeber berücksichtigen, dass der Aufwand für die Durchführung der Abnahmeprüfung gesondert anfällt und eingeplant werden muss. Der Abnahmezeitraum ist im Verhältnis zum Projektablauf vergleichsweise kurz und verlangt einen konzertierten Aufwand des Auftraggebers.

Die Antworten auf folgende Fragen liefern eine erste Indikation, in welchem Umfang der Auftraggeber seinen Beitrag zum Projekterfolg geleistet hat:

Sind Mitwirkungsleistungen vertraglich vereinbart?
Gibt es quantitative und qualitative Festlegungen zum Umfang und der Qualifikation der Mitarbeiter?
Welche Mitwirkungsleistungen sind qualitativ und quantitativ erbracht worden?
Gab es in der Vergangenheit Probleme bei nicht rechtzeitig bereitgestellten Mitwirkungsleistungen?

5. Zusammenfassung

Zur Statusermittlung eines IT-Projekts gibt es vier charakteristische Indikatoren, die Aufschluss über die Projektsituation geben. Erfahrungsgemäß ist die Bestimmung der Indikatoren effizienter als Aussagen über den Fertigstellungsgrad oder eine Aufwandsschätzung der noch zu erbringenden Restarbeiten, die immer sehr stark von (subjektiven) Einschätzungen abhängig sind und einen erheblichen zusätzlichen (Zeit-)Aufwand bedeutet.

Die smarten Indikatoren ermöglichen eine effiziente Beurteilung der Ursachen für die Schieflage und damit die Zuordnung der Verantwortung für die defizitäre Umsetzung. Damit erkennen Sie auch typische Defizite im Projektmanagement wie Moving Targets oder ausufernde Verbindungswünsche zu anderen Systemen. Auf dieser Basis können Sie Verbesserungsvorschläge für die Zukunft des Projekts (wie Projektaufstellung oder Projektmanagement) abgeben oder die Beendigung des Projekts empfehlen.

Dr. Siegfried Streitz.