Viele IT-Projekte starten mit unrealistischen Annahmen – Interview mit Dr. Gerhard Friedrich

Hallo Herr Dr. Gerhard Friedrich: Seit über 30 Jahren leiten Sie Projekte an der Schnittstelle von Fach- und IT-Seiten. Wie haben sich die Initiativen über die Zeit gewandelt?

Es gibt zwei fundamentale Änderungen. Erstens: Es gibt keine grünen Wiesen mehr. IT-Projekte müssen einen immer größeren Anteil ihres Aufwandes in Integration und in Schnittstellen investieren.

Zweitens: Der Ansatz, einem großen IT-Unternehmen ein Lastenheft zu übergeben, am Pflichtenheft mitzuarbeiten und dann auf das Ergebnis der Umsetzung zu warten, funktioniert nicht mehr.

Warum? Weil kein externer Dienstleister in der Lage ist, die Chancen und Risiken einer IT-Investition ohne intensive Mitwirkung des Kunden, und dort sowohl IT als auch Business, zu erkennen und umzusetzen. Womit wir wieder beim ersten Punkt wären.

In Ihrem Buch 12 Halbwahrheiten über IT-Projekte nehmen Sie bekannte Glaubenssätze von Technologie-Vorhaben auseinander. Auf welche Halbwahrheit sollte ich als angehender Projektleiter besonders achten?

Angehende Projektleiter klammern sich gerne an Standards. Es ist natürlich gut, das Rad nicht neu erfinden zu wollen. Es ist gut, Erfahrungen zu nutzen, die andere schon gemacht haben. Und es ist auch gut, sich an Standards zu orientieren, sonst herrscht babylonische Sprachverwirrung.

Die erste Halbwahrheit meines Buches lautet daher: „Projektmanagement-Standards unterstützen die Projektarbeit“. 

Was ist daran nicht richtig? Es kommt auf die Handhabung an! Wenn man das eigenständige Denken, den aufmerksamen Blick auf die Einmaligkeit des Projektes zugunsten der strikten Befolgung eines Standards vernachlässigt, gilt Mephistos Aussage in Goethes Faust: „Vernunft wird Unsinn, Wohltat Plage“.

Daher gilt: Intensive Auseinandersetzung mit verschiedenen Standards, dann erkennt man schon einmal, dass es nicht den einen, richtigen Weg gibt, wie man Projekte managt. Und auf dieser Grundlage die Augen und den Geist offen halten für die Spezifika des Projekte und aus dem Fundus des Wissens das hervorholen und einsetzen, was hier und jetzt sinnvoll und wirksam ist.

Je besser man die Standards kennt, umso leichter fällt es einem, kreativ und effektiv auf Herausforderungen zu reagieren.

Aus Ihrer Sicht: Weshalb schlagen IT-Projekte fehl, überschreiten Zeit bzw. Budget oder liefern nur mittelmäßige Ergebnisse?

Viele IT-Projekte starten mit unrealistischen Annahmen. Eine der gefährlichsten ist, dass die Anforderungen bekannt seien und sich im Verlaufe des Projektes nur marginal ändern würden und dürfen. Wenn dann im Projekt neue, im ursprünglichen Scope nicht berücksichtigte Anforderungen auftauchen, beginnt ein heftiger Kampf gegen Change-Requests, der viel Zeit, Energie und auch Budget kostet.

Damit kommt das gesamte Setup des Projektes ins Rutschen und es braucht Anpassungen des Scope, des Budgets und der Terminleiste. Das wiederum verunsichert die Auftraggeber und Sponsoren des Projektes. Es werden Controller und Berater darauf angesetzt, die Ursachen dieser Entwicklung zu identifizieren und die ursprüngliche Ordnung wieder herzustellen. Einige Monate und sehr viele Euros später erkennt man, dass die Änderungen doch nicht nur Gold-Plating waren und passt den Projektplan zähneknirschend an.

Das alles hat viel an Good-Will der Leistungsträger im Projekt gekostet und die Effizienz der Projektarbeit nimmt weiter ab. Und allzu oft beginnt dieses Spiel bald wieder von vorne.

Dass es so läuft, hat mit einer Reihe von vermeintlichen Wahrheiten zu tun, die ich in meinem Buch analysiere. Ich zeige dabei auf, was daran sinnvoll und hilfreich ist und was gefährlich werden kann, wenn man sich unkritisch daran orientiert. Einige davon: „Eine detaillierte Anforderungsdefinition erlaubt eine zuverlässige Aufwandsschätzung“, „Zuerst die Geschäftsprozesse optimieren, dann erst die Anforderungen an die IT definieren“, „Die IT ist ein Dienstleister“ und „Wasserdichte Verträge schützen vor Mehrkosten“.

Nicht nur in der IT scheitern zunächst viele Projekte, entpuppen sich aber über die Jahre als erfolgreich. Wird zu schnell ein Fazit gezogen?

„Kein Plan übersteht die erste Feindberührung““sagte Generalfeldmarschall Moltke sehr treffend. Der Feind des Projektes ist die Realität. Wie erfolgreich ein IT-Projekt verläuft, kann während der Laufzeit des Projektes tatsächlich nur sehr schwer beurteilt werden.

Nehmen wir ein allseits bekanntes Beispiel: Der schiefe Turm von Pisa war als Bauprojekt ein Desaster, aus wirtschaftlicher Sicht ein enormer Erfolg für die Stadt Pisa. Das ist kein Freibrief für sorglose Planung und Umsetzung von Projekten, es soll nur zeigen, dass der Projekterfolg nicht so klar definiert werden kann.

Die Standish-Group analysiert in ihrem Chaos-Report regelmäßig die Erfolgsrate von IT-Projekten. Es ist kein Zufall, dass sie die langjährigen Erfolgskriterien OnBudget, OnTime und OnTarget ersetzt hat durch Valuable, OnGoal und Satifsfactory. Damit soll vermieden werden, dass Projekte negativ bewertet werden, deren Zielsetzung sich im Verlauf des Projektes weiter entwickelt hat. Das ist bei allen IT-Projekten regelmäßig der Fall.

Entscheidend ist der finale Wertbeitrag des Projektes, nicht die Übereinstimmung mit anfangs definierten Planwerten, die ohne fundiertes Wissen zustande kamen.

Letzte Frage: Wenn Sie ein Buch für modernes IT-Projektmanagement neben dem Ihren empfehlen würden: Welches sollte es sein?

Ich würde gerne 100 Bücher empfehlen, aber ich versuche Ihrem Wunsch weitgehend zu folgen und beschränke mich auf zwei. Ein Klassiker, der sehr ernüchternd zeigt, wie und warum IT-Projekte zum Scheitern gebracht werden können: Death March von Edward Yourdon. Und ein aktuelles Buch, das zeigt, wie man es richtig machen kann: Specification by Example von Gojko Adzic.

Das Interview mit Dr. Gerhard Friedrich führte Christopher Schulz per E-Mail am 27. September 2022.

Zur Person Dr. Gerhard Friedrich