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.
Es liegt selten an der Technik. Meist scheitert es an fehl gesteuerten Prozessen und falschen Annahmen.
So erkärte es der Kunde
So verstand es der Software-Verkäufer
So verstand des der Projektleiter
So beschrieb es die Marketing-Abteilung
So wurde es technisch spezifiziert
So wurde es programmiert
So wurde es dokumentiert
So wurde der Kunde eingeführt
So wurde es korrigiert
Das wurde vom Kunden erwartet
Das bräuchte der Kunde
Dafür hätte das Geld gereicht
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.
Wie die Sprache 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 zu viel zugetraut. Sie werden überschätzt und dadurch zu wenig 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 offen kritisiert wird, kommen Fehler früh genug – und nicht erst beim Rollout – ans Tageslicht.
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».
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 neben den neuen Funktionen nicht auch alles bisherhige weiterhin 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 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.
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. Am Anfang 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.
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.