Mehr als 80 Prozent aller IT-Projekte erreichen die ursprünglich festgelegten Ziele nicht. Das ist im Markt unstrittig. Die IT-Abteilungen, die am Projekterfolg gemessen werden, stehen folglich unter Druck. Wo über Make-or-Buy-Fragen, Budgets und die Rolle der IT als Business-Innovator entschieden wird, lässt sich mit erfolgreichen Projekten sehr gut punkten.

Die Projekt-Performance ist also von existentiellem Interesse für jede IT-Organisation. Zudem entscheidet das Gelingen von Projekten auch über die Wettbewerbsfähigkeit des Unternehmens. Nicht selten führen ungünstig verlaufende Transformationsprojekte zu Unternehmenskrisen.

Das IT-Management versucht bereits seit Jahren, darauf zu reagieren. Es wurden Projekt-Management-Systeme eingeführt und Mitarbeiter auf Methoden wie PMBoK oder Prince2 trainiert. Trotzdem ist die Ausfallquote bei Projekten immer noch sehr hoch. Offenbar verpufft die Wirkung der "eingeführten" Methoden in einer mangelhaften, wenig nachhaltigen Umsetzung. Denn auch Projekt-Management-Methoden entfalten ihren Nutzen erst, wenn sie in ein Prozess-Management-System eingebettet sind.

Vollständigkeit der Methode

Erfolgreiche IT-Projekte brauchen Entwicklungsprozesse für das Lösungssystem - bestehend aus Hardware, Software und Services. Auch wenn ein externer Dienstleister einen Teil der Entwicklung übernimmt, muss die IT-Organisation ein klares Bild von ihrer Lösungserstellung haben. Nur so kann sie die Schnittstellen konsistent beschreiben und ein effektives "Build-Management" betreiben. Ansonsten wird das Unternehmen durch den Service-Provider gesteuert, anstatt ihn selbst zu managen.

Zudem lässt sich in der Praxis immer wieder feststellen, dass die Projekt-Management-Methode selbst nicht vollständig ist. Damit sind Defizite in Projekt-Reviews, Risiko-Controlling und Fortschrittskontrollen beinahe schon programmiert.

Ausreichender Umsetzungsgrad

Für IT-Projekte gilt dasselbe wie für viele andere Management-Gebiete: Machen Sie lieber weniges richtig als vieles halb. Stellen Sie sich folgende Frage: Welche Eckdaten, die im Konzept erarbeitet wurden, halten Sie in der Realisierung wirklich nach? Oft ist die Plan-Do-Check-Act-Regelschleife nicht geschlossen, und damit gibt es auch keinerlei Verbesserung. Ein übergeordnetes Prozess-Management-System (siehe Teil 1 dieser COMPUTERWOCHE-Serie) ermöglicht es, die Prozessabläufe regelmäßig auf ihren Reifegrad hin zu überprüfen.

Neben diesem inhaltlichen Aspekt ist entscheidend, wie die Kommunikation auf allen Ebenen des Projekts geführt ist. Der Projektstatus muss nach der Projektfreigabe mit der ursprünglichen Planung verglichen werden. Aber wo geht dieser Vergleich in die Regelkommunikation von Projektteams oder zwischen Team und Lenkungsausschuss ein?

Auf Teilprojektebene gelten Statusberichte oft als Last und nicht als methodische Hilfe zur Zielerreichung. Im Allgemeinen bekommen die Projektbüros etwa 60 Prozent der Statusberichte zum gesetzten Termin. Und von den tatsächlich erstellten Berichten ist nur durchschnittlich ein Drittel in Bezug auf die ursprüngliche Projektplanung aussagefähig. Hier gibt es für das Projekt-Management noch einige Überzeugungsarbeit zu leisten, bis die Teilprojektteams den Umgang mit Statusberichten als Teil ihrer Meetings akzeptieren. Selbstverständlich müssen Projekt- und IT-Leitung mit gutem Beispiel vorangehen.

Ein wichtiges Stichwort auf der Ebene des Gesamtprojekts ist die Aussagefähigkeit:

• Welche Projektbüros validieren die Status- und Meilensteinberichte inhaltlich?

• Wer weiß auf Wochenbasis, ob ein Teilprojektteam noch an seinem eigentlichen Arbeitsprogramm sitzt oder sich in Einzelheiten verloren hat und dem "Command of the Day" folgt?

• Kann jemand mit Sicherheit sagen, ob der Ergebnisstand des Projekts den aufgelaufenen Ressourcenverbrauch rechtfertigt?

• Sind die methodischen Grundlagen für solche Aussagen geschaffen worden - zum Beispiel mittels der "Earned-Value-Methode"?

• Wie sieht es mit dem Risiko-Management aus? Existieren Frühindikatoren für Risiken oder Verhaltensänderungen? Werden sie in die Regelkommunikation auf Projektebene einbezogen? Lassen sich auf dieser Grundlage proaktive Gegenmaßnahmen beschließ?

Was die Kraftfeldanalyse vermag

Die Force-Field-Analyse kann hier Klarheit verschaffen. Sie ist ein hilfreiches Visualisierungsmittel innerhalb des Projektteams, aber auch in Richtung des Lenkungsausschusses.Das Topmanagement eines Unternehmens spielt beim Umsetzungsgrad der Methode eine Schlüsselrolle. Es muss entweder selbst die Zeit und Kompetenz haben, um Projekt-Proposal, Gesamtprojektstatus oder Debriefing zu hinterfragen, oder es muss sich durch einen Berater darin unterstützen lassen.

Auf jeden Fall sollten die Mitglieder des Lenkungsausschusses diese Punkte im Rahmen ihrer Sitzungen behandeln. Zu oft ist in Lenkungsausschuss-Sitzungen eine unidirektionale Rapportsituation ohne Mehrwert schaffende Diskussion wahrzunehmen. Es werden Informationen aufgenommen, ohne Schlussfolgerungen zu ziehen und den Entscheidungsbedarf zu konkretisieren. Wozu aber der ganze Mess- und Berichtsaufwand, wenn zwar der Projektstatus transparent ist, aber die Richtung nicht korrigiert wird - jedenfalls nicht kurzfristig? Projektfortschritt lebt von einer Führung, die fordert und fördert.

Dem Gesamtprojektleiter kommt dabei besondere Bedeutung zu. Er sammelt die Einzelberichte nicht einfach zu einem Projektbericht an den Lenkungsausschuss. Seine Aufgabe ist es vielmehr, den Gesamtprojektstatus zu analysieren, zusammenzufassen und zu quantifizieren, sowie den Bericht mit klaren Entscheidungsbedarfen zu versehen. Damit schafft er erst die Grundlage dafür, dass der Lenkungsausschuss Wirkung erzielt.

Ausprägung der Standards

Ebenso wichtig wie Projekt-Management-Standards sind geeignete Entwicklungsmethoden, die es erlauben, das Produkt des Projekts in planbarer und nachvollziehbarer Qualität zu erstellen. Gängige Entwicklungsmethoden wie das V-Modell unterteilen den Produktlebenszyklus in fachlich bedingte Phasen über den zeitlichen Ablauf des Projekts.

Erst die Integration der fachlichen Phasen mit dem jeweiligen Projekt-Management-Standard komplettiert das Projektvorgehen. Häufig ist dieses Projektvorgehen zu allgemein formuliert. Die Qualität der Projektintegration hängt dann in hohem Maße von der Erfahrung des Projekt-Managers ab. Einer unserer Kunden musste das auf die harte Tour lernen. Bei der Entwicklung einer individuellen Anwendung erkannte er erst im Abnahmetest, dass die gewählte Architektur nicht den Lastanforderungen genügte. Ein teures Re-Design war damit unumgänglich - und das zu einem Zeitpunkt, als sich das Projektteam schon fast am Ziel wähnte.

Des weiteren muss das Projektvorgehen im Einklang mit dem Projektrisiko stehen. Dieses Risiko ist bei einer kompletten Eigenentwicklung wesentlich vielschichtiger und größer als beim Rollout einer erprobten Standardlösung. Das Projektvorgehen muss dieses höhere Risiko widerspiegeln - durch die Aufteilung des Vorhabens in viele kleinere Schritte, beispielsweise die Absicherung der Architektur durch Lasttests. Um den Arbeitspunkt des Projektvorgehens richtig zu setzen, sind dessen Auswahl und Anpassung durch Checklisten zu unterstützen. Diese orientieren sich an der Projekterfahrung der Organisation - im Sinne einer kontinuierlichen Verbesserung.

Dazu nun drei Beispiele aus der Praxis. In jedem der Unternehmen waren Projekt-Management-Systeme eingeführt sowie die Mitarbeiter darauf trainiert und zertifiziert worden.

Fall 1: Mangelnde Transparenz in einem großen Änderungsprojekt

In vielen Unternehmen werden Änderungsanträge unter Umständen als Projekte umgesetzt: ab einer gewissen Größenordnung, einer hohen Bedeutung für das Business oder abhängig vom Risikopotenzial. In diesen Fällen wird ein Projektträger eröffnet, und das Projektprozess-Management-System ist anzuwenden.

In einem konkreten Fall stellte sich die Situation jedoch ziemlich unklar dar:

• Die Teilprojektleiter wurden von den eigenen Plänen überrascht. Denn niemand wusste so recht, was in der Projektplanung stand und wo das Projekt in Bezug zum Plan stand.

• Die häufigste Fortschrittsmeldung war: "80 Prozent fertig" oder "Fast fertig".

• Überraschend wurde für Teilprojekte "rot" gemeldet.

• Projektberichte waren bloße Aktivitätsbeschreibungen ohne analytischen Soll-Ist-Vergleich zwischen Plan und aktueller Performance.

• Die Projektkennzahlen erlaubten keine vorwärtsgerichteten Aussagen, sondern beruhten auf subjektiver Bewertung.

Die Ursachen ließen sich auf zwei wesentliche Felder eingrenzen: Zum einen war die Methode unvollständig. Die Planung wies eine weitmaschigere Granularität auf als die Berichte (bezüglich Detaillierung und Frequenz). Dadurch wurden Kennzahlen öfter geschätzt als gemessen.

Zum anderen mangelte es am Grad der Umsetzung - und zwar in vielen Punkten. Die Projektleiter führten quasi freihändig, sie setzten sich nicht regelmäßig mit ihrem Plan auseinander. Die Risikoplanung wurde nicht aktualisiert, die Fertigstellungskriterien waren unscharf. Das führte in der Summe dazu, dass "Fast-fertig"-Meldungen ausgegeben wurden, obwohl noch großer Aufwand erforderlich war. Zudem wurden Projektpläne willkürlich geändert, ohne die Basisplanung anzupassen.

Folgende Maßnahmen wurden ergriffen:

• Das Team überarbeitete die Projektpläne entlang klarer Planungsregeln.

• Es etablierte eine rollierende Detailplanung in überschaubaren Planungsfenstern.

• "Fertig"-Meldungen wurden anhand harter Kriterien objektiviert.

• Die Qualität der Ergebnisse musste sich überprüfen lassen.

• Eine Projekt-Scorecard mit geeigneten Kennzahlen zur Fortschrittskontrolle (Ergebniskennzahlen) und Prognose (Frühindikatoren) wurde eingeführt.

Fall 2: Transitionsprojekt beim Wechsel von Outsourcing-Partnern

Der Wechsel eines Outsourcing-Partners ist vielschichtig. Die Art und Weise, wie ein solches Projekt gemanagt wird, ist allzu oft fahrlässig, wie folgendes Beispiel belegte.

• Qualitätsmängel fielen erst an der Schnittstelle zum Kunden und mit dessen Einbindung auf. Damit konnten Gegenmaßnahmen nicht mehr ergriffen werden, die Fehler zu beheben wurde maximal teuer.

• Die Leitungsebene erkannte Projektverzögerungen erst an der Kundenschnittstelle.

• Es entstanden hohe Mehrkosten sowohl für das Transitionsprojekt als auch für den Servicebetrieb.

• Der Service erfuhr häufige und lange Unterbrechungen.

• Die Kundenorganisation war überlastet, es gab Lärm und Ärger.

Wieder einmal ließen sich die Ursachen auf ein fehlendes Prozess-Management-System und die mangelnde Einbettung der Projekt-Management-Methode zurückführen. Die Lösungsentwicklungsprozesse waren im Projektplan einfach nicht umgesetzt. Der Verzicht auf die notwendigen Tests führte zu Qualitätsmängeln.

Das war offenbar weder der Projektleitung noch dem Lenkungsausschuss aufgefallen. Jedenfalls hatte keine Prüfung oder Validierung stattgefunden. Niemand hatte sich dort aktiv mit dem Vorhaben auseinandergesetzt. Der Lieferanten- und Vertrags-Management-Prozess war mangelhaft. Damit blieben die Projektverantwortlichen in Unkenntnis über die Vertragsinhalte. Die Vertrags-Governance wurde verletzt, Rollen und Verantwortlichkeiten wurden nicht gelebt, Entscheidungen ohne Mandat getroffen und umgesetzt. Die Regeln für Change-Management-Prozessregeln blieben völlig unbeachtet.

Da halfen nur noch ein interner Projekt-Review im Hinblick auf den Projektplan und der Beschluss eines ganzen Pakets notwendiger Maßnahmen. Die späte Korrektur kostete nicht nur alle Beteiligten einen empfindlichen Imageverlust. Sie musste auch mit der Aufhebung der Kostenkontrolle und der Zuführung von Ressourcen auf beiden Seiten, also beim Kunden und Lieferanten, bezahlt werden.

Fall 3: Applikationsentwicklung ohne ausreichende Validierung

Ein umfassendes Innovationsvorhaben für einen Geschäftsprozess lief lange im Zeitplan, erst gegen Ende ergaben sich häufige und wiederkehrende Zeitverschiebungen. Dies war umso schädlicher für das Image des Projektteams, als der Endkunde in dieser Projektphase bereits stark involviert war - für User-Tests und Rollout-Planungen.

Es wurden erheblich Mehraufwände notwendig: Zeitarbeitspersonal, das die Geschäftprozesse manuell abarbeiten musste, und weitere Hardware zur Beseitigung von Engpässen vor Ort. Zudem brachte die Inbetriebnahme eines instabilen Systems Datenverluste beim Kunden mit sich, Aufträge und Lieferscheine gingen nach Auslieferungen verloren. Folglich konnte der Kunde nur Teilaspekte abnehmen. Vor allem aber waren Projektleitung und Lenkungsausschuss nicht in der Lage, Entscheidungen zu treffen, da ihnen der Projektstatus und die Prognosen schleierhaft blieben.

Proposal nicht ausreichend validiert

Des Rätsels Lösung lag darin, dass der Projektvorschlag (Proposal) hinsichtlich Machbarkeit und Risiken nicht ausreichend validiert worden war. Man hatte sich für eine "Big-Bang"-Release-Strategie entschieden. Das war schon sehr waghalsig angesichts der Tatsache, dass es sich bei der Zielarchitektur um eine neue Technologie mit einer neuen Entwicklungsumgebung und einem neuen Entwicklungspartner handelte. Zu allem Überfluss betraf das Vorhaben auch noch einen äußerst sensitiven Bereich des Kundengeschäfts.

Diese Planungsfehler wurden noch durch weitere Ergebniszusagen verschlimmert, für die es keinen sauberen Change-Prozess als Grundlage für die ständigen Terminverschiebungen gab. Die Projektorganisation war in Silos ohne regelmäßige übergreifende Kommunikation, geschweige denn Abstimmung, angelegt. Die zu entwickelnde Applikation hingegen schnitt unterschiedliche Prozesse über die Bereichsgrenzen hinweg. Die Kundenabnahme war denn auch nicht klar organisiert.

Zur Korrektur wurde die Projektleitung an einen Dritten vergeben, der die Generalunternehmerverantwortung übernahm. Zudem bekam die Projektstruktur einen stärkeren Integrationsfokus. Und die Release-Planung wurde inhaltlich überarbeitet - zur Verbesserung der Qualität.

CW-Kommentar: Das ominöse Wörtchen "fast"

Auch wenn die IT im Grund aus Einsen und Nullen besteht - sie ist durchaus nicht immer und überall messbar. Zum Beispiel lässt sich der Nutzen eines Compliance-Projekts höchstens durch die Umkehrfrage ermitteln: Was bleibt uns erspart, wenn wir in diesen sauren Apfel beißen? Auch der Wert zufriedener Anwender ist schwer zu eruieren. Um wie viel besser arbeitet jemand mit einem modernen - und das heißt auch: zur Spielerei verlockenden - Werkzeug gegenüber jemandem, der widerwillig funktionstüchtige, aber veraltete Technik nutzt? Bis Langzeitstudien einen verlässlichen Wert ausweisen können, hat sich das Gadget längst in eine Commodity oder sogar in Elektroschrott verwandelt.

Zu den IT-Bereichen mit einem hohen "Vagheits-Faktor" gehört offenbar auch das Projekt-Management. Daran ändern aktuelle PM-Methoden wie Prince2 und PMBoK wenig. Vorgehensmodelle bewirken nur etwas, wenn die Prozesse nachvollziehbar sind und alle Statusmeldungen durch harte Fakten (was?), Werte (wie?) sowie Fristen (wann?) hinterlegt sind.

"Ich bin fast fertig", kann vieles heißen. Wie wir seit der Kindheit wissen, bedeutet es meist: "Lass mich bloß in Ruhe, ich habe gerade ein Problem zu lösen." Deshalb fragten unsere Eltern auch meist zurück: "Was machst du denn genau, und wann bist du damit fertig?"

Systementwickler sind den Kinderschuhen zumeist entwachsen, aber sie lassen sich genauso ungern auf etwas festlegen wie unser Nachwuchs. Eines möchte man ihnen immerhin zugutehalten: Wenn sie die Wahl zwischen Zeitverzug, Budgetüberschreitung und Qualitätsabstrichen haben, entscheiden sie sich selten für Letztere. Aber damit kommen sie nicht mehr durch - man ist versucht zu sagen: leider! Und jetzt ist dieser Kommentar fast fertig.

Karin Quack