Warum scheitern IT-Projekte?

Jedes dritte IT-Projekt scheitert oder wird nur teilweise erfolgreich abgeschlossen. Es erfüllt die Anforderungen nicht, dauert länger, kostet mehr oder liefert ein anders Ergebnis als geplant.

Warum? Vornweg: Es liegt selten an der Technik. Meistens scheitert es an fehl gesteuerten Prozessen und falschen Annahmen.

Die eierlegende Wollmilchsau gibt es auch in der IT nicht

Viele IT-Projekte wollen zu viel. Man weiss: Je kleiner und kürzer ein IT-Projekt ist, desto höher stehen die Chancen auf Erfolg. Möglichst viele Anforderungen in einem einzigen System unterzubringen, ist einer der häufigsten Fehler. Die neue Software muss nie alle bisherigen Funktionen auch noch können.

Es braucht Mut, alte Zöpfe abzuschneiden. Allgemein gilt: Je mehr Anforderungen desto mehr Beteiligte. Damit steigen die Kommunikationsschnittstellen exponentiell. Interessenskonflikte nehmen zu. Es gibt häufigere und längere Sitzungen und es gibt mehr Missverständnisse. Die Projektdauer steigt ins Unendliche.

Am Schluss hat man ein halbfertiges Produkt. Es kann irgendwie alles, ist aber komplizierter als vorher.

Zu Beginn eines erfolgreichen IT-Projektes geht es um Reduktion, denn die Komplexität ist der Feind des Projekterfolgs. Weniger ist mehr, Reduktion ist alles. Es geht also darum, die Projektanforderungen so weit wie möglich zu reduzieren, was naturgemäss nicht allen in den Kram passt.

Ein IT-Projekt ist Chefsache

Ein erfolgreiches IT-Projekt braucht eine uneingeschränkte Verpflichtung der Geschäftsleitung. Ein IT-Projekt ist immer ein Schnittstellen-Projekt. Es betrifft die unterschiedlichsten Abteilungen und somit deren Abteilungsleiter. Jeder Abteilungsleiter hat seine Wünsche und Bedürfnisse. Der Projektleiter nimmt sie auf, aber nur soweit diese dem Projektziel dienen. Wenn nicht, muss sich der Projektleiter gegenüber einem Abteilungsleiter durchzusetzen können. Und das kann er nur bei einer klaren Verpflichtung der Geschäftsleitung.

Werden die Anforderungen aus den unterschiedlichsten Abteilungen nicht sorgfältig gemanagt, wächst der Anforderungskatalog unaufhörlich. Der daraus resultierende Scope Creep (Erschleichung weiterer Anwendungsbereiche), lässt viele IT-Projekt scheitern. Ein erfolgreiches IT-Projekt ist kein Demokratieprozess. Die Stakholders reden mit, haben aber nicht das letzte Wort.

Einfache Sprache, definierte Begriffe

Sprachliche Unzulänglichkeit ist eine der grössten Fehlerquellen in IT-Projekten. Sie kommt noch vor logischen und inhaltlichen Fehlern. Missverständnisse führen zu nachträglichen Änderungen und solche sind für ein IT-Projekt Gift. Missverständnisse beginnen oft mit einer zu technischen Sprache. Mit technischen IT-Fachbegriffen will/kann ein Anwender nichts anfangen. Es braucht einfache und definierte Begriffe. Sonst entsteht ein Interpretationsspielraum. Man vertraut darauf, richtig verstanden worden zu sein und sieht in Begriffen wie Asynchron Business Driven Information Systems die gesuchte Lösung.

Auch die einfachen Begriffe müssen geklärt sein. Wenn die einen von Anlagen, die anderen von Filialen, die dritten von Standorten und die vierten von Datenlieferanten sprechen, aber alle vier dasselbe meinen, kommt es nicht gut.

Unterschiedliche Sprachen

Ein Programmierer spricht eine andere Sprache als ein Anwender. Der Satz: «Ist in zwei Wochen fertig» hat in einem IT-Projekt ganz unterschiedliche Bedeutungen, je nach dem, ob ihn der Programmierer, Productowner oder Anwender sagt. Der Projektleiter muss diese Sprachen kennen und können. Er muss neben der Technik und dem Inhalt insbesondere von den beteiligten Menschen eine Ahnung haben. Ein erfolgreicher IT-Projektleiter sagt: «Technology is easy - people are hard».

Hand-Notizen statt PowerPoint

Wie die Sprache (siehe oben) sind oft auch die Arbeitsinstrumente zu technisch. PowerPoint, Flow-Charts, Funktionsdiagramme oder Datenbankmodelle sind Technologiefallen. Computererstellte Inhalte wirken technisch und damit zu perfekt. Weil die Inhalte technisch einwandfrei daher kommen, wird ihnen mehr zugetraut. Sie werden überschätzt und dadurch weniger kritisiert.

Kritik ist elementar beim Klären der Anforderungen. Die besten Erfahrungen mache ich ohne Computer - mit Papier und Stift. Handgezeichnete Abläufe werden verstanden und als „unfertig“ angesehen. Das ebnet den Weg zur nötigen Kritik. Denn nur wenn kritisiert wird, kommen Fehler früh genug – und nicht erst beim Rollout – ans Tageslicht.

Projektmethode

Werden in einem Projekt laufend neue Ideen präsentiert, verliert man den Fokus. Damit es nicht soweit kommt, braucht es definierte Schritte, die sich voneinander abgrenzen. Zu beginn braucht es hohe Agilität in kleinen Iterationen. Bedürfnisse, Ideen, Konzepte werden laufend überprüft, überarbeitet, verworfen und neu ausformuliert. Dazu braucht es keine einzige Zeile Code. Handskizzen (siehe oben) sind mindestens so gut wie ein Prototyp am Bildschirm, wenn nicht sogar besser. Sobald die Programmierer mit ihrer Arbeit beginnen, werden ändernde Anforderungen zum Stolperstein.

Ein IT-Projekt ist wie ein Hausbau: Möchte man eine Tiefgarage nachdem bereits der zweite Stock hochgezogen ist, gibts ein Problem mit dem Budget und das Richtfest rückt in weite Ferne. Damit es nicht soweit kommt, braucht es Mut zur Reduktion, eine klare Begrifflichkeit, viele (Hand) Skizzen, und man darf nicht alles und jeden berücksichtigen.

Fazit

Die Praxis zeigt, dass Projektleiter, die den Umgang mit vielen Stakeholdern erfolgreich beherrschen, ein wichtiger Erfolgsfaktor sind. Der erste Schritt, um Komplexität zu reduzieren und beherrschbar zu machen, sind klare Ziele. Eine sorgfältige, vorausschauende Planung mit voneinander abgrenzenden Projektschritten von angepasster Agilität machen aus einem Wunschkonzert ein erfolgreiches IT-Projekt.

© Heute, IGNAZ Unternehmensinformatik