„GEFAHRENZONE IT-PROJEKTE“

Die Realisierung großer IT‐Vorhaben stellt die verantwortlichen Manager und Aufsichtsräte vor eine gewaltige Herausforderung. Interne und externe Anbieter investieren viel Aufwand und ihre besten Verkäufer, um IT‐Budget‐Verantwortliche davon zu überzeugen, dass sie auf ihre Erfahrung mit der Durchführung solcher Projekte vertrauen können. Die Ergebnisse einer Umfrage der Standish Group (CIO.com, 18. Juni 2009), an der 400 Unternehmen teilnahmen, zeigen jedoch eine ernüchternde Realität. Nur 32% aller IT‐Projekte sind bezüglich der Einhaltung ihres Zeitplans, Budgets und ihrer Anforderungen erfolgreich. Ca. 24% werden als gescheitert betrachtet, werden komplett eingestellt oder nach Abschluss nicht genutzt. 44% stehen in ihrem Verlauf vor Schwierigkeiten unterschiedlicher Komplexität. IT‐Projekte können am Ende ein Vielfaches dessen kosten, was ursprünglich veranschlagt war. Auch kann der materielle Schaden und Imageverlust als Folge von Verzögerungen, Funktionsstörungen oder dem möglichen Verlust  vertraulicher Daten in den Augen von Kunden und der Öffentlichkeit um ein Vielfaches höher sein als die sichtbaren Budgets und Kostenüberschreitungen.

Es scheint allerdings eine Toleranz für schlechte Nachrichten bei IT‐Projekten zu geben, die in anderen Branchen absolut unvorstellbar wäre. Wo sonst kann man sich eine Ersterfolgsquote von einem Drittel noch leisten? Vielleicht gehen Manager, CEOs und Aufsichtsräte davon aus, dass diese Vorhaben so komplex sind, dass schlechte Projektleistung unvermeidbar ist und es einfach zu schwierig ist, aus einer Distanz zum Projekt den Korrekturbedarf frühzeitig zu erkennen? Diese Sicht wird zunehmend riskant angesichts der jüngsten Veränderungen im gesetzlichen Umfeld (Stichwort: BilMoG) sowie der wachsenden strategischen Bedeutung von IT‐Projekten. Solche Vorhaben internen Managern und externen Anbietern zu überlassen, reicht heute nicht mehr aus (vgl. Kagermann & Schilling, FAZ, 6.4.2010, S.12). Sowohl Geschäftsführung als auch Aufsichtsrat müssen sich aktiv um den Verlauf großer IT‐Projekte kümmern. Dieser Artikel soll zeigen, wie Gestaltung und Fortschritt eines IT‐Projekts während sämtlicher Projektphasen mit bewährten Best‐Practice‐Methoden überwacht werden kann, ohne sich auf optimistische Prognosen von Projektleitern und Anbietern verlassen zu müssen.

Viele Projekte werden gleich mit Konstruktionsfehlern aufgesetzt, während andere erst allmählich außer Kontrolle geraten. Stark unterschätzt werden die typischen Projektgestaltungsfehler, zum Beispiel unklare Projektziele, unvollständige Anforderungen, vage Abnahmekriterien, überhöhte Komplexität, Grauzonen bei Verantwortlichkeiten, Stakeholder‐Konflikte, die Fehlbesetzung von Schlüsselrollen oder ein Bestand an ungelösten Themen, z.B., ob Risiken über sog. „Back‐to‐Back“‐ Vereinbarungen weitergereicht werden, oder die Frage, wer als Generalunternehmer die Koordination verschiedener Anbieter oder Arbeitsergebnisse sicherstellt. Ein weiteres, weit verbreitetes Problemfeld stellen unrealistische Zeit‐ und Budgetplanungen dar. Unter hohem Druck werden auch unrealistische Zusagen gemacht. Eine einfache Top‐down‐Anforderung wie „Kunden müssen nach dem Merger ihre alten Kontonummern behalten“ kann einen Quantensprung bei Projektkosten, Zeit und Komplexität verursachen. Wenn zu viele Variablen gleichzeitig verändert werden, kann die Umsetzung eines Projekts unmöglich werden. Die Plausibilität des sogenannten Projektmodells sollte daher unbedingt frühzeitig einem Review unterzogen werden. Ein wichtiger Faktor zu Planungszwecken ist dabei die Referenzierung auf historische Leistungsdaten. Jeder Anbieter, der etwas auf sich hält, sollte entsprechende Datenarchive vorhalten, und Angaben zur Genauigkeit früherer Schätzungen machen können. Wenn es keine solchen Aufzeichnungen gibt, dann ist es sinnvoll, eine zweite Meinung von unabhängigen Experten einzuholen. Was kann neben der frühzeitigen Prüfung der „Governance“, Struktur Komplexität und Plausibilität eines Projektvorgehens noch getan werden, um potenzielle Probleme im Projektverlauf zeitnahe zu entdecken?

Das klassische Projektüberwachung basiert auf drei Parametern: Zeit, Kosten und Qualität. Diese Parameter sind notwendig, aber nicht ausreichend, um den Projektfortschritt transparent zu machen, besonders da der Begriff „Qualität“ viel Spielraum für Interpretation lässt. Mit den klassischen Parametern lässt sich relativ einfach ein positives Bild des Projektfortschritts zeichnen – mit „grünen Ampeln“ und vorsichtig formulierten, positiv klingenden Erläuterungen. Der große Knall kommt kurz vor Abschluss des Projekts, wenn man Glück hat während der Integrationstests und wenn man Pech hat während der Übergabe und dem Go‐live. Es gibt Anbieter, die den Zeitplan und das Budget einhalten, weil sie an allen Stellen sparen, die nicht Teil des Monitoring sind. Pläne und verbleibende Aufwände werden im Hintergrund geändert, Anforderungen werden weggelassen, Größe und Kompetenz‐ profile von Teams werden reduziert, Reviews und Tests werden abgespeckt, Arbeit wird an kostengünstige Standorte übertragen, um nur einige der Tricks zu nennen, die hier angewendet werden können. Der Druck von oberen Führungskräften, nur positive Nachrichten zu liefern, ist unter Umständen so hoch, dass negative Nach‐ richten so lange wie möglich unter den Teppich gekehrt werden.

Die moderne Überwachung von IT‐Projekten muss acht und nicht drei Parameter umfassen: Zeitplan und Budget sind gesetzt, doch die Entwicklung der Anforderungen, Teamprofile, Fehlererkennung, Nacharbeit, Risiken und Stimmung im Projekt sind zusätzlich zu überwachen. Zur großen Erleichterung vieler Anbieter sind in der Regel nur wenige dieser Parameter in den vereinbarten Berichten enthalten. Selbst wenn, dann ist der Abstraktionsgrad so hoch, dass Abweichungen auf Ebene der Arbeitspakete nicht mehr analysiert werden können. Doch als Kunde, Manager oder Aufsichtsrat mit Verantwortung für große IT‐Projekte muss man in die Lage versetzt werden, Probleme präzise und zeitnahe zu erkennen. Wir nennen die Lösung hierfür das Theron‐Modell für Transparenz und Professionalität in IT‐ Projekten. Vorbildliche Anbieter, die sich zu internationale Standards bekennen und über die entsprechenden Werkzeuge verfügen, können diese Daten liefern, mittelmäßige und schlechte Anbieter können das nicht. Die Kernelemente sind nachfolgend erklärt:

Termintreue: Alle Projekte überwachen ihre Meilensteine, meist nachden vertraglich vereinbarten Arbeitsergebnissen und Projektphasen.. Verzögerungen bei der Erfüllung von Meilensteinen werden gewöhnlich in Tagen berechnet, gemessen an dem aktuellen Plan, und zu einem Gesamtbericht mit Ampeln zusammengefasst. Das Theron‐Modell verlangt, dass auch alle Planänderungen im Hintergrund dieser Soll‐Ist‐Vergleiche transparent gemacht werden. Zusätzlich muss jedes Arbeitspaket mit dem Plan abgeglichen werden, sodass die Varianzen der Abweichungen im Ver‐ lauf des Projekts gemessen werden können. Die Wechselwirkungen von Abwei‐ chungen im Terminplan auf das Budget oder die Erfüllung von Anforderungen müssen ebenfalls nachvollziehbar und die Treiber solcher Abweichungen müssen eindeutig identifizierbar sein. 

Budget: Alle Projekte messen ihre angefallenen Kosten. In der Regel werden sie mit der geplanten „Burn Rate“ für jede Projektphase verglichen. Solange es keine Überschreitung des Gesamtbudgets gibt, steht die Ampel auf „grün“. Aufwandsüber‐ schreitungen im Hinblick auf Stunden und Kosten können durch Einsparungen an anderen Stellen kompensiert werden. Das Theron‐Modell verlangt, dass alle Veränderungen des Budgets, in Cash oder Zeit transparent sein müssen. Ferner muss jedes Arbeitspaket mit aktuellen und früheren Plänen abgeglichen werden, damit die Varianz ermittelt werden kann. Auch hier muss es möglich sein, die Treiber der Veränderung zu identifizieren. Gab es Abweichungen bei Budgets als Folge von geänderten Anforderungen, verzögerten Zeitplänen, Fehlschätzungen Nacharbeit, oder traten erwartete‐ bzw. unerwartete Risiken auf? Legt jemand vielleicht sogar ungeplante Kosten aus einem anderen Bereich um, nur weil in diesem Projekt noch Reserven im Budget vorhanden sind?

Anforderungen: Projekte haben einen Zweck. So wie man ein Haus baut, um darin zu leben, werden Projekte initiiert, um bestimmten geschäftlichen Anforderungen zu begegnen. Sie sind die inhaltliche Dimension des Projekts. Beispiele für Anforderungen wären bei einem Haus, zu duschen, zu kochen, zu baden, zu heizen, Steck‐ dosen, Wasserhähne, das Telefon und die Toilette zu benutzen. Bei IT‐Projekten ist das Nachhalten funktionaler und nicht funktionaler Kundenanforderungen von ent‐ scheidender Bedeutung und muss so mit den Budgets und Zeitplänen verknüpft werden, dass die Auswirkung von Veränderungen eines der drei Parameter zu den anderen zwei Parametern zurückverfolgt werden kann. Verändern sich vereinbarte Anforderungen im Verlauf des Projekts? Werden dadurch Budgets und Zeitpläne gefährdet? Werden Anforderungen innerhalb des Gesamtplans unauffällig verschoben? Wurde die Arbeit nicht wie geplant begonnen bzw. beendet? Werden Tests wie geplant durchgeführt? Durch das Theron‐Modell werden die Anforderungen zu einem wesentlichen Bestandteil der Projektüberwachung. 

Teamprofile: Wenn Elektriker und Klempner häufig auf der Baustelle sind, heißt das nicht automatisch, dass alles in Ordnung ist. Wenn sie aber nicht da sind wenn sie es laut Plan eigentlich sein sollten, dann stimmt etwas nicht. Außerdem werden Gewerke und Arbeitspakete mit Bezug auf Kompetenzen und Erfahrung geplant. Die Auswirkung von Erfahrung und Motivation auf die Produktivität ist enorm, aber selten im Fokus des Managements. Zu Unrecht. Es muss streng überwacht werden,ob Teammitglieder über angemessene Erfahrung und die nötigen Kompetenzen verfügen. Außerdem muss ihre ausreichende Verfügbarkeit gesichert sein. Am besten eignet sich ein Akkreditierungssystem, um mitzubestimmen, wer an kritischen Projekten arbeitet. Die Herabstufung von eingesetzten Profilen ist weit verbreitet. Dies spart Geld oder kann in Unternehmen, die paranoid bezüglich hoher Produktivität sind, dazu verwendet werden, die Stunden, die bei einem gegebenen Budget allokiert werden, zu erhöhen. Engpässe bestimmter Profile oder die restriktive Handhabung von fremden Ressourcen müssen erkennbar sein. Deshalb verlangt das Theron‐Modell, dass unvollständige Teams oder Teams mit einer größeren Anzahl unerfahrener Mitglieder als geplant proaktiv gemeldet werden.

Fehlererkennung: Ein sehr wichtiger Qualitätsindikator während aller Phasen eines IT‐Projekts ist das Erkennen von Fehlern. Im Gegensatz zu dem, was vielleicht intuitiv erwartet wird, ist eine geringe Anzahl an Fehlern häufig ein Zeichen von Nachlässigkeit und nicht von Qualität. Viele Unternehmen erfassen keine historischen Daten zu ihren Fehlern und können daher auch keine Angaben zur Fehlerdichte machen, die in ihren Projekten zu erwarten ist. Es geht weniger darum, ob Fehler gemacht werden, sondern ob und wann sie entdeckt werden. Gute Unternehmen entdecken Fehler kurz nachdem sie gemacht wurden, schlechte Unternehmen viel später oder gar nicht. Sie überlassen es vielleicht sogar den Kunden, sie zu melden. Das Theron‐Modell verlangt, dass die Anzahl Fehler, ihre Dichte und die Verzögerung in der Fehlererkennung über den Verlauf des Projekts gemessen und berichtet werden. Dies muss mit einem historischen oder erwarteten Richtwert des Anbieters abgeglichen werden. Wenn ein Arbeitspaket durch einen Fehler betroffen ist, müssen die Auswirkungen der Behebung des Fehlers auf den kritischen Pfad, die Anforderungen und auf andere Arbeitspakete in zwei Richtungen nachvollziehbar sein: einerseits für die Aufgaben, die noch anstehen, und andererseits für die Aufgaben, die bereits erledigt wurden.

Nacharbeit: Viele Unternehmen halten sich gerne mit Aussagen bedeckt, wie viele Arbeitsstunden und Prozent des Aufwands, durch Nacharbeit entstehen. Das ist nichts, was die Kunden unbedingt allzu genau wissen sollten. Um die Ursachen von Überschreitungen auf Ebene der Arbeitspakete transparent zu machen, sind diese Informationen allerdings unabdingbar: Haben veränderte Anforderungen, eingetretene Risiken, Schätzfehler oder Nacharbeit die entdeckten Überschreitungen verursacht? Die zielorientierte Diskussion der Ursachen für Überschreitungen wird häufig von fehlenden Informationen bezüglich der Nacharbeit behindert. Probleme im Bereich Nacharbeit verlangen beispielsweise andere Lösungen als Probleme bei der Genauigkeit von Schätzungen. Das Theron‐Modell verlangt daher eine transparente Aufzeichnung aller Stunden und Ausgaben, die während aller Projektphasen für Nacharbeit aufgewendet werden.

Risikomanagement: Reserven für Risiken sind ein normaler Bestandteil der Projektplanung und werden gewöhnlich durch spezifische Risikoannahmen und Wahrscheinlichkeitsbetrachtungen unterstützt. In den meisten Fällen beobachten Projektmanager zwar aufmerksam die identifizierten Risiken, doch sie tendieren zu der Annahme, dass sie diese Reserven aufbrauchen können egal ob die Risiken eintreten oder nicht. Schlimmer noch, die Annahmen zur Eintrittswahrscheinlichkeitkönnen manipuliert werden, z.B. wenn das Management Druck ausübt, um Rückstellungen für Überschreitungen im Projektgeschäft zu reduzieren. Man reduziert die Bewertung der Wahrscheinlichkeit einfach unter die Schwelle, ab der Rückstellungen  gebildet werden müssen und belässt sie dort so lange wie möglich. Um ein derartige Verhaltensmuster zu erkennen, verlangt das Theron‐Modell, dass alle identifizierten Risiken, ihre angenommene Wahrscheinlichkeit, Veränderungen der Wahrscheinlichkeit sowie unerwartete Risiken, die Auswirkungen auf das Projekt haben, regelmäßig und transparent berichtet werden.

Stimmungsbarometer: Egal welch positives Bild Projektberichte auch zeichnen, es wird immer Beteiligte im Projekt geben, die genau wissen, wenn etwas schief läuft. Warum also nicht diese Gruppe anonym befragen? Die Stakeholder‐Analyse ist ein elementarer Bestandteil jedes professionellen Projektmanagements. Alles was noch zusätzlich notwendig ist, ist ein sinnvoller „Pulse Check”, um die Stimmung & Einschätzungen des Projektteams, der betroffenen Kunden und Anbieter zu erfassen. Einige Unternehmen haben sogar damit begonnen, Prognosebörsen einzuführen, um die Wahrscheinlichkeit  der Termingerechten Fertigstellung wichtiger Softwareprojekte zu ermitteln. Dies basiert auf der wissenschaftlichen Erkenntnis, dass Teilnehmer und Beobachter, als Gruppe genommen, eine bemerkenswert große Prognosegenauigkeit erreichen (vgl. New York Times, 25. Juni 2009 bzw. Hackhausen, wiwo.de vom 26.11.2006).

Wird der hier beschriebene Ansatz verfolgt, müssen interne bzw. externe Anbieter wesentlich mehr Transparenz bieten als dies heute üblich ist. Was, wenn ein Anbieter sich weigert? Das hängt von der Art des Projekts und den Standards des Anbieters ab. Für „Time & Material“‐Projekte oder für kleine Projekte mit geringer strategischer Relevanz mag der Aufwand zu hoch im Verhältnis zu dem Nutzen sein. Wenn das Projekt allerdings für den Erfolg des Unternehmens entscheidend ist, dann gibt es keinen vernünftigen Grund, von dem Theron‐Modell abzuweichen. Widerstand von Seiten des Anbieters spiegelt in solchen Fällen vermutlich eher seine inadäquaten Projektstandards wider.

Das Theron‐Modell kann die Anbieterauswahl für strategische Großprojekte erleichtern. Professionelle IT‐Anbieter entwickeln über Jahre hinweg, verlässliche Vorgehensmodelle für ihre Projektarbeit, Datenarchive und Leistungsindikatoren. Sie messen Fehler, ihre Häufigkeit und den Zeitversatz zwischen ihrem Auftreten und ihrer Entdeckung, genauso wie sie die Genauigkeit ihrer Budget‐ und Zeitschätzungen verfolgen. Sie kennen das Niveau und die Bandbreiten, in denen sie typischerweise agieren, aber auch die Verbesserungen, die sie realistisch pro Jahr erreichen können. Sie greifen ein, wenn definierte Schwellenwerte überschritten werden und stellen sicher, dass Ihre Mitarbeiter fit für ihren Einsatz sind. Die Dar‐ stellung von Kennzahlen und Wechselwirkungen ist kein Problem, denn sie vernetzten Anforderungen, Zeitpläne und Budgets. Sie können bei Störungen die Auswirkungen auf das Restprojekt und das bisherige Projekt darstellen, zum Beispiel, welche bereits erfolgreich absolvierten Tests dadurch gegebenenfalls wiederholt werden müssen. Sie werden bereitwillig Demos geben, wie sie das im Tagesgeschäft machen und mit welchen Tools sie sicherstellen, dass die “Best Practices” in den Projekten zur Anwendung gebracht werden. Es sind die IT‐Anbieter, die es mit den Standards nicht so genau nehmen, die hier nicht Aussagefähig sind. Entsprechend groß sollte auch der Bogen sein, der bei wichtigen Projekten um solche Anbieter gemacht wird.

Durch die Anwendung des Theron‐Modells können die Herausforderungen, die mit der Umsetzung großer IT‐Projekte zwangsläufig entstehen, wesentlich besser gesteuert werden, weil acht wichtige Dimensionen transparent überwacht und weil negative Entwicklungen viel früher entdeckt werden. Es ist allerdings kein Patentrezept gegen Konstruktionsfehler in Projekten, unrealistische Erwartungen oder eine schlechte Anbieterauswahl. Doch auch hier gilt: Konstruktions‐, Erwartungs‐  und Anbieterprobleme werden sich schon in sehr frühen Projektphasen unübersehbar manifestieren, sodass Manager und ihre Aufsichtrsräte, frühzeitig und zielsicher Maßnahmen ergreifen können, um das Projekt wieder in die Erfolgsspur zu führen.

Köln, im April 2012

 

Ansprechpartner