Was in Projekten warum schiefgehen kann

16.09.2011
Zu viele IT-Projekte sind nicht erfolgreich. Woran liegt es, dass die meisten Vorhaben anders laufen als gedacht? Und was ist dagegen zu tun?

Manchmal ist einfach der Wurm drin: Erst verzögert sich die Programmierung einer wichtigen Schnittstelle. Dann ist ein für die Hardware zuständiger Mitarbeiter im Urlaub. Plötzlich muss der ursprüngliche Go-Live-Termin um einen Monat verschoben werden.

So oder ähnlich trägt es sich in vielen Unternehmen zu. Nach einer Studie der Standish Group sind im Jahr 2010 insgesamt 24 Prozent aller IT-Projekte gescheitert oder abgebrochen worden. Lediglich 32 Prozent waren rundum erfolgreich.

Zwischen diesen beiden Extremen finden sich Vorhaben, die in erheblichem Maße die vorgegebenen Kosten überschritten sowie Zeit- und Qualitätsziele verfehlt haben. Woran liegt das und wie lassen sich mögliche Fehlverläufe verhindern?

Planung, Durchführung, Abschluss

Alle Projekte unterteilen sich grob in drei Phasen: die Planung, die Durchführung und den Abschluss. In jeder dieser Phasen können sich Fehler einschleichen und verhindern, dass das Vorhaben erfolgreich zu Ende gebracht wird.

Die Planung: erst das Fundament, dann das Haus

Die Planungsphase bildet die Basis für ein erfolgreiches Projekt. Werden hier wichtige Bausteine außer Acht gelassen, so sind sie im späteren Verlauf schwer einzubauen.

Das fängt bei der Auftragsklärung an. Sie sollte möglichst genau sein und die Projektziele definieren. Was will der Auftraggeber eigentlich? So lautet die Hauptfrage in dieser Phase. Und gerade weil die Antwort so selbstverständlich erscheint, überspringen viele Projekte diesen Schritt.

Dazu ein Beispiel: Ein IT-Projekt hatte zum Ziel, SAP-Systeme verschiedener Geschäftsbereiche eines Versicherungskonzerns zu konsolidieren. Es war auf drei bis vier Jahre Laufzeit angelegt. Allerdings wurden die Anforderungen an das zu erstellende System nicht sorgfältig definiert. Im Laufe des Projekts versuchte dann jeder Geschäftsbereich, seine eigenen Funktionen durchzusetzen. Dadurch erweiterte sich der Umfang des Systems mehr und mehr. Der zeitliche Rahmen und das Budget drohten, den vorgegebenen Rahmen zu sprengen.

Nur durch Aufsetzen eines Änderungs-Management-Prozesses ließen sich katas-trophale Folgen im Nachhinein abfangen. Das Projekt verteuerte sich trotzdem um 25 Prozent gegenüber den ursprünglich veranschlagten Kosten.

Fachkompetenz allein reicht nicht

Kaum ein Projekt scheitert an der Technik. Die beteiligten Menschen sind für das Gelingen maßgeblich. Aus diesem Grund sollte von Anfang an auf die bestmögliche Zusammensetzung des Teams geachtet werden. Fachkompetenz ist dabei nur ein Auswahlkriterium unter vielen. Eine ausgeprägte Sozialkompetenz ist die Voraussetzung für ein erfolgreiches Projektteam.

Sobald die Mitarbeiter zusammengestellt sind, ist eine gemeinsame Projektkultur aufzubauen und zu fördern. Dazu gehören beispielsweise klare Regeln für Kommunikation und gemeinsames Arbeiten.

Sonst ergeht es dem Projekt wie in diesem Beispiel: Es galt, ein Content-Management-System einzuführen. Der technikbegeisterte Projektleiter setzte sich mit allen Details der anzuschaffenden Software auseinander. Er punktete in stundenlangen Diskussionen mit den Entwicklern durch seine Fachkenntnisse. Darüber vernachlässigte er die Teamführung. Schwelende Konflikte unter den Beteiligten blieben völlig unbemerkt und führten allmählich zu Demotivation. Die frustrierten Teammitglieder kündigten schließlich oder ließen sich versetzen. Projektrelevantes Know-how ging verloren.

Schlecht Informierte sperren sich

Auch von außerhalb des Teams sollten die Betroffenen und Interessierten ins Boot geholt werden. Das aktive Management von Stakeholdern bringt unmittelbaren Nutzen: Ein Projekt, dem die Organisation positiv gegenübersteht, verläuft eher erfolgreich als eines, das kritisch gesehen wird.

Diese positive Grundeinstellung gilt es durch Kommunikation zu fördern. Denn oft verweigern Menschen einem Projekt die Unterstützung, weil sie sich schlecht informiert fühlen. Gegenüber dem unbekannten Neuen nehmen sie dann quasi automatisch eine Abwehrhaltung ein. Nur selten sind es die tatsächlichen Projektziele, die ihnen missfallen.

Dazu wieder ein Beispiel: In einem Logis-tikkonzern, der seine komplette Systemlandschaft umstellen wollte, gab es kaum Kommunikation zwischen den Fachbereichen und der IT. Anstatt als Teamplayer an einem Strang zu ziehen, wurden die Teammitarbeiter regelrecht zu Gegnern. Das Projekt zog sich über Jahre hin, mehrere Projektleiter scheiterten. Ein mittlerer Millionenbetrag war ausgegeben, ohne dass ein Ergebnis vorgelegen hätte - bis schließlich ein externer Moderator die Projektplanung mit allen Stakeholdern konsolidierte.

Vertrags- und Claim-Management

Ein weiteres Projektrisiko, das selten im Bewusstsein der Teammitglieder verankert ist, liegt im Vertrags- und Claim-Management. Gerade in Projekten mit starker Beteiligung externer Partner und Dienstleister ist eine gute Planung unverzichtbar. Jemand muss alle vertraglichen Vereinbarungen mit externen Dienstleistern im Blick behalten. Das sorgt unter anderem dafür, dass auslaufende Verträge verlängert und bei Vertragsverletzungen Pönalen eingefordert werden.

Ein großer Automobilkonzern ließ ein Projekt umsetzen, in dem das zentrale IT-System zur Lagerlogistik entwickelt werden sollte. Währenddessen lief der Vertrag mit einem externen Dienstleister aus. Dieser verplante daraufhin seine Ressourcen anderweitig. So drohte das ausschließlich bei dieser Firma vorhandene Know-how für das Projekt verloren zu gehen.

Um dieses Problem zu lösen, waren umfangreiche Workshops zur Priorisierung von Aufgaben notwendig. Mit der Modifikation der ursprünglichen Planung wurden zweitrangige Funktionen in einen späteren Zeitraum verschoben. Nur so ließ sich der Go-Live-Termin des Systems sicherstellen.

Die Durchführung: Wer navigiert, muss seine Position kennen

Während der Durchführungsphase ist kontinuierlich zu prüfen, ob sich das Projekt eigentlich noch auf dem geplanten Weg befindet. Die zentralen Fragen, die hier gestellt werden müssen, sind folgende: Stimmen die Kosten? Liegen die Ergebnisse im Zeitplan? Sind gegebenenfalls Anpassungen notwendig?

Nur wer weiß, wo sein IT-Projekt aktuell steht, kann effizient steuern und mögliche Fehlentwicklungen vermeiden. Aus diesem Grund sollte das Unternehmen ein Reporting installieren, das auf die Bedürfnisse der unterschiedlichen Adressaten wie Top-Management, Projektleiter und Teilprojektleiter abgestimmt ist. Erst damit rücken zeitnahe Informationen über den Projektfortschritt in den Bereich des Möglichen.

Wichtig ist es, die richtigen Kennzahlen zu wählen und die relevanten Größen zu erfassen: Sollen Zeit, Kosten oder Qualität überwacht werden? Beziehungsweise wo liegt der Schwerpunkt?

Ein zu geringes Budget rächt sich

Für das Projekt-Management planen die Verantwortlichen oft ein zu geringes Budget ein. Diese vermeintlichen Einsparungen entpuppen sich im späteren Verlauf des Projekts häufig als wahrer Kostenfresser: Das Vorhaben treibt intransparent vor sich hin und ist aufgrund der schlechten Datenbasis kaum zu steuern. Zehn bis 15 Prozent der Gesamtkosten sollten für das Projekt-Management einkalkuliert werden.

Selbst ein gut aufgesetztes Reporting muss vom Projektleiter immer wieder kritisch hinterfragt werden. Gefahr droht auch dann, wenn das Projekt laut Bericht rund läuft und die Mitarbeiter "Status grün" melden. Häufig berichten die Mitarbeiter Probleme ja nicht direkt, weil sie per se von einer kurzfristigen Lösung ausgehen. Stellt sich diese Annahme als Trugschluss heraus, so kann aus einem "Grün" urplötzlich ein "Rot" werden - und die Zeitplanung gerät aus den Fugen.

Ganz oder gar nicht

Berücksichtigt werden sollte auch das 90-Prozent-Syndrom. Viele Menschen neigen dazu, den Fertigstellungsgrad ihrer Aufgaben mit 90 Prozent anzugeben, auch wenn noch wesentlich mehr zu tun ist. Abhilfe schaffen lässt sich hier, indem man sich auf Ergebnisse oder Meilensteine konzentriert. "Ganz oder gar nicht" könnte der Ansatz heißen.

Entweder ein Ergebnis (Konzeptpapier, Dokumentation etc.) liegt vor, und der Meilenstein wurde erreicht - oder eben nicht. Zwischenschritte sind kein Ergebnis.

Moving Targets kontrollieren

Kein Projekt verläuft exakt so, wie es ursprünglich geplant war. In den meisten Fällen sind Änderungen notwendig. Diese "Moving Targets" sind grundsätzlich unproblematisch, allerdings müssen sie kontrolliert ablaufen. Dafür sollte ein Change-Management installiert werden, das unter anderem regelt, wer "Change Requests" (CR) einreichen darf, wer sie bewertet und freigibt. Bleibt dieser Punkt unberücksichtigt, kann es laufen wie in dem folgenden Beispiel.

Ein Product-Lifecycle-Management-Sys-tem wurde eingeführt. Das Projektteam erstickte förmlich unter den Änderungswünschen und war kaum noch arbeitsfähig. Der Entscheidungsprozess kostete einfach zu viel Zeit. Auf der einen Seite stand die Ablehnung der CRs bei Inkaufnahme sinkender Kundenzufriedenheit, auf der anderen deren Akzeptanz mit der Folge höherer Kosten sowie einer längeren Projektlaufzeit.

Letztendlich wählten die Verantwortlichen einen Mittelweg, um dem Dilemma zu entkommen: Die CRs wurden nach Aufwand bewertet und je nach Wichtigkeit mit "must", "should",oder "nice-to-have" priorisiert. Nur CRs, bei denen das Verhältnis Aufwand zu Dringlichkeit beziehungsweise Wichtigkeit stimmte, wurden zur Umsetzung freigegeben.

Der Abschluss: aus Fehlern für die Zukunft lernen

Ein großes Versicherungsunternehmen hatte sich bereits mehrere Jahre an einem Projekt abgemüht. Es fehlte an einer validen Planung, und daher war auch der Fortschritt intransparent. Ein externer Projektdienstleister wurde beauftragt, der erstmals eine Zeit- und Kostenplanung vorlegte. Sie offenbarte das wahre Ausmaß des Aufwands. Daraufhin entschied der CIO des Unternehmens, die Reißleine zu ziehen. Das Projekt wurde gestoppt.

Manchmal zieht sich ein Projekt über Jahre hin, ohne dass brauchbare Ergebnisse vorzuweisen sind. Der Abbruch eines Vorhabens scheidet aber als Option aus - er ist in den Köpfen der Verantwortlichen nicht vorgesehen oder wird verdrängt. Dadurch können längerfristig hohe Kosten entstehen. Scheitern als Chance? Als Ultima Ratio muss ein Abbruch möglich sein.

Nach einem erfolgreich verlaufenen Projekt sollte das Ende gebührend gefeiert werden. Doch Vorsicht: Auch wenn alle Beteiligten zufrieden sind, ist das Projekt noch nicht abgeschlossen. Das Ziel sollte sein, aus jedem Projekt zu lernen, damit das nächste noch besser gelingt und etwaige Fehler in der Zukunft vermieden werden. Ein "Lessons-Learned-Workshop" ist daher obligatorisch einzuplanen. In dessen Rahmen kann offen über den Projektverlauf gesprochen werden: Was lief gut? Was lief schlecht?

Eine maßgeschneiderte Methode

Am Ende sollten die Ergebnisse, im besten Fall unternehmensweit, gesammelt und bereitgestellt werden. So lässt sich kontinuierlich und pragmatisch eine eigene Projekt-Management-Methodik aufbauen, die zum Unternehmen passt und ständig weiterentwickelt wird. Davon profitiert jedes nachfolgende IT-Projekt. (qua)

Nicolaus von Gersdorff ist Geschäftsführer der Assure Consulting GmbH in Wehrheim.

Die zehn größten Fehler und die möglichen Lösungen

• Projektziele unklar: Verfassen Sie einen Projektauftrag, in dem die Ziele des Projekts schriftlich fixiert sind. Sprechen Sie diesen mit Ihrem Auftraggeber durch, und lassen Sie ihn unterschreiben. Unklarheiten sollten sofort beseitigt werden.

• Zeitvorgaben unrealistisch: Oft macht das Management großen Druck, das Projekt in einem viel zu eng bemessenen Zeitraum durchzupeitschen. Zeigen Sie Alternativen auf, mit denen sich wirklich Zeit einsparen lässt, zum Beispiel durch Verzicht auf weniger wichtige Features. Machen Sie keine Zusagen, wenn der vorgegebene Termin absehbar nicht zu halten ist.

• Mangelnde Abstimmung: Wer ist interessiert, betroffen und beteiligt? Wenn Sie diese Frage im Hinterkopf behalten, haben Sie schon alle Personen versammelt, die Sie im Rahmen Ihres Stakeholder-Managements berücksichtigen müssen. Stimmen Sie sich frühzeitig ab, informieren Sie offensiv über Ihr Vorhaben.

• Fehlerhafte Kommunikation: Kommunizieren Sie zielgruppengerecht. Nicht jeder muss alles immer sofort wissen. Berücksichtigen Sie die verschiedenen Medien, und prüfen Sie, wie Sie die andere Person am wirkungsvollsten erreichen - per E-Mail, Telefon oder am besten immer noch in einem persönlichen Gespräch.

• Überlasteter Projektleiter: Delegieren Sie als Projektleiter Ihre Aufgaben. Geben Sie Verantwortung an andere Teammitglieder ab und konzentrieren Sie sich auf die wesentlichen Führungsaufgaben. Das schafft Freiräume und stärkt die Motivation Ihrer Kollegen. Wenn es das Projektbudget zulässt, führen Sie ein Projekt-Management-Office ein.

• Unrealistisscher Budgetrahmen: Ähnlich wie die Zeit ist auch das Geld häufig ein knappes Gut. Entwickeln Sie frühzeitig Szenarien, mit denen der Budgetrahmen gehalten werden kann, und vermeiden Sie es, Ihren Auftraggeber mit monatlich wiederkehrenden Forderungen nach Budgeterhöhungen zu frustrieren.

• Schlampige Feinplanung: Phasen- und Meilensteinplanung sind ein guter Start, aber eine effiziente Planung hört damit noch nicht auf. Beschreiben Sie einzelne Arbeitspakete, und ordnen Sie ihnen Verantwortliche zu. Formulieren Sie alle Tätigkeiten aus, die innerhalb der Arbeitspakete zu erledigen sind.

• Unterschätzte Komplexität: Sprechen Sie rechtzeitig mit Experten und anderen Projektleitern, die Ihnen bei der Einschätzung des Projektumfangs helfen können. Planen Sie Pufferzeiten ein, um nicht beim ersten Problem den Zeitplan anpassen zu müssen. Je genauer die Planung, desto exakter können Sie die Komplexität bestimmen.

• Holpriges Berichtswesen: Halten Sie den Aufwand für das Reporting gering, um Ihre Mitarbeiter nicht mit dem Schreiben von Statusberichten zu nerven. Fragen Sie nur die wirklich wichtigen Daten ab, und entnehmen Sie so viele Steuerungsinformationen wie möglich aus bestehenden IT-Systemen wie SAP oder Projektplänen.

• Fehlende PM-Methodik: Sorgen Sie für eine sauber aufgesetzte Methodik, wie Sie Ihr Projekt planen und steuern. Damit haben Sie schon viel gewonnen. Das Wissen können Sie in Kursen, beispielsweise bei der GPM (Deutsche Gesellschaft für Projektmanagement), erwerben - oder mit einem externen Dienstleister einkaufen.