Neue methodische Vorgehensweisen

Projektrisiken rechtzeitig orten

02.06.2004 von Riem Sarsam
Langsam gibt es wieder Luft für neue Projekte. Angesichts der nach wie vor hohen Fehlerrate von IT-Projekten sind CIOs gut beraten, sich mehr mit methodisch strukturierten Vorgehensweisen auseinander zu setzen. In den vergangenen Jahren haben sich einige Modelle am Markt bewährt, neue kommen hinzu.

15 Prozent der IT-Projekte scheitern auf der ganzen Linie, gut die Hälfte erreicht längst nicht all die Ziele, die vorgegeben waren, und gerade mal ein gutes Drittel schließt mit dem erwünschten Erfolg ab. Zu diesem ernüchternden Ergebnis kam die Standish Group im vergangenen Jahr. Die Analysten von AMR Research bescheinigen immerhin 55 von 100 Vorhaben einen gelungenen Abschluss. Im Durchschnitt. In einigen Bereichen sieht es wesentlich düsterer aus: Gerade mal 16 Prozent der CRM-Projekte führten zum Erfolg, so die Experten. Der Rest werde abgebrochen oder nur in Teilen zu Ende geführt, wobei sich weder ein positiver Effekt auf das Geschäft noch die saubere Eingliederung in die Unternehmensprozesse feststellen ließ.

"Über gescheiterte Projekte redet niemand gerne", sagt Manfred Broy, Professor für Informatik an der Technischen Universität München. Da werde lieber weggeschaut, bis das Kind in den Brunnen gefallen ist. "Die Aufmerksamkeit richtet sich leider erst auf die Probleme, wenn sie eskaliert sind. Dann ist es meist zu spät."

Fehlendes Bewusstsein

Gründe, warum es nicht klappt, gibt es reichlich. Schlechte Kommunikation oder überzogene Erwartungen spielen ebenso eine Rolle wie eine unzureichende Vorarbeit, die zu einer mangelhaften Umsetzung führt. Von einer gründlichen Nachbearbeitung ganz zu schweigen. Was noch schlimmer ist: Oft ist den Verantwortlichen nicht einmal bewusst, dass ein Projekt gescheitert ist. Denn viele Unternehmen haben bislang keine Mechanismen etabliert, um Teilergebnisse oder das Endresultat überhaupt zu überprüfen.

Den Zeitrahmen und das Budget im Griff zu haben ist dabei nur ein Teil der Kunst. Die anderen Kriterien für den Erfolg eines Projektes sind Qualität und Quantität der Ergebnisses. "Quantität bedeutet, messbare Resultate zu haben, beispielsweise bei SCM die Verkürzung der Durchlaufzeiten oder schnellere Rechnungstellung und damit schnellere Bezahlung", erklärt Rüdiger Spieß, Analyst der Meta Group Deutschland. Sich alleine auf eine Berechnung des Return on Investment (RoI) zu berufen, wie es in den vergangenen Jahren Usus geworden ist, greift seiner Meinung nach zu kurz, ist zu oberflächlich. Um tatsächlich einen spürbaren Erfolg beurteilen zu können, braucht es einen längeren Atem. Für ERP-Projekte haben die Analysten der Meta Group beispielsweise eine weitere Größe namens "Time to Benefit" (TtB) eingeführt. Damit soll die Zeit gemessen werden, bis sich der "echte" Erfolg der Systemeinführung zeigt. In der Praxis heißt das, bis die ersten Nachwehen der Implementierung überwunden, Schulungen gelaufen sind und das System stabil läuft. Teil dieser Analyse ist etwa auch die Befragung der Anwender. Herausgestellt hat sich, dass die TtB von mittleren und großen ERP-Projekten im Durchschnitt bei rund 36 Monaten liegt, berichtet Meta-Group-Mann Spieß.

Um den Erfolg seiner IT-Projekte messen zu können, ist ein CIO nicht zwingend auf den Sachverstand der Berater angewiesen. Wesentlich für eine verlässliches Ergebnis ist ein festgelegtes strukturiertes Vorgehen. "Mit gesundem Menschenverstand lassen sich zumindest in kleineren Projekten bereits viele entscheidende Punkte selber identifizieren", sagt Broy. Nicht möglich ist hingegen, im Nachhinein ein Projekt in Schieflage in eines ohne Probleme zu verwandeln. Die Hausaufgaben müssen bereits im Vorfeld erledigt werden. "Gute Erfahrungen zur Qualitätsmessung haben wir beispielsweise mit einer einfachen Checkliste gemacht, mit der man die verschiedenen Rollen durchgeht", berichtet Professor Broy. "Damit lässt sich in wenigen Stunden ein grober Überblick schaffen." Solch eine selbst erstellte Checkliste, in der der CIO die Schlüsselfaktoren aufführt, lässt sich sowohl am Anfang als auch in der Mitte oder in einer späteren Entwicklungsphase des Projektes einsetzen.

Wer sich auf die Bewertungserfahrung einer standardisierten Methode stützen will, greift am ehesten zu Modellen, die aus der Softwareentwicklung stammen. Als Ansatzpunkt, um ein methodisches Vorgehen zu etablieren, dient die so genannte Reifegradmessung. Weit verbreitet hat sich das Anfang der neunziger-Jahre entwickelte Capability Maturity Model (CMM), das Praktiken und Prozesse beschreibt, analysiert und anhand von fünf Stufen den Reifegrad misst. Andere zertifizierte Methoden sind beispielsweise Bootstrap, CMMI, Cobit oder Spice (siehe Kästen).

Ein Ansatz, der noch einen Schritt weitergehen soll und eine Bewertung dessen erlaubt, was IT zum Geschäft beiträgt, ist das jüngst vom Fraunhofer-Institut für Software und Systemtechnik entwickelte Modell ITEM (IT Evaluation Management). "Den Geschäftswert der IT zu bestimmen, darzustellen, zu kontrollieren und zu steuern", fasst Michael Stemmer, Assistent des Leiters des Fraunhofer ISST, die Ziele von ITEM zusammen. Diese Fähigkeiten sind seiner Meinung nach die Schlüsselqualifikationen für das IT-Management. Bislang verwendete Instrumentarien greifen dafür zu kurz: Während das IT-Controlling zu finanzlastig und eher vergangenheitsorientiert sei, kennen CMM oder Spice keine Verfahren, den Wert für das Geschäft qualitativ und quantitativ aufzuzeigen. Stemmer: "Es besteht die Gefahr, den Nutzen für das Ganze aus den Augen zu verlieren."

Gegenstand von ITEM kann ein Produkt, ein Prozess, ein Projekt oder die gesamte IT-Funktion gleichermaßen sein. Der "Trick", auf den die Forscher dabei aufbauen: Anhand der strukturierten Darstellung der Wirkungszusammenhänge zwischen IT- und Unternehmensebene kann der Geschäftswert der IT für das jeweilige Geschäft aufgezeigt werden. Dieser Wert kann als funktionale Größe, also als Nutzwert, oder auch als Geldwert dargestellt werden.

Erkenntnisse müssen gelebt werden

Für welches der Modelle sich ein CIO entscheidet, hängt von seinen speziellen Bedürfnissen ab. Entscheidend ist, dass er sich überhaupt dazu durchringt, eine durchgängige Struktur aufzusetzen. Erst dann wird er Ergebnisse messen und auch vermitteln können. Letztlich kann jedoch jede Methode nur das Grundgerüst für die Projektarbeit sein, die von den Mitarbeitern mit Leben erfüllt werden muss. "Es ist in den meisten Fällen weniger die Erkenntnis, an der es hakt, sondern die Umsetzung", beobachtet Stemmer. Würde ein Großteil der bekannten Praktiken auch gelebt, dürften gescheiterte Projekte eher die Ausnahme denn die Regel sein.

CMM: Stufe für Stufe zum Erfolg

Das in den neunziger Jahren vom Software Engineering Institute (SEI) in den USA entwickelte Capability Maturity Model (CMM) gilt als Vorreiter unter den zertifizierten Messmethoden. Das Ziel lautete seinerzeit, die mangelhafte Qualität von Softwareprojekten in den Griff zu bekommen. In fünf Reifegrad-(Maturity-)Level werden die Fähigkeiten einer Organisation bei der Softwareentwicklung bewertet.

Nach den SEI-Vorgaben sind Unternehmen mit dem niedrigsten CMM-Level 1 chaotisch organisiert, Prozesse sind nicht erkennbar. Die Auszeichnung Level 5 erhält, wer klar definierte Abläufe und Qualitätssicherungsverfahren etabliert hat. Mit steigendem Reifgegrad verbindet sich die Erwartung, dass die Vorhersagbarkeit von Terminen, Kosten und Qualitätszielen zunimmt. CMM gilt als stark organisationsorientiert und beinhaltet zahlreiche Elemente, um Verbesserungen in der Organisation dauerhaft zu verankern. www.sei.cmu.edu