In diesem Video geht es um ein Muster, das ich in letzter Zeit in der IT-Branche immer wieder beobachte. Es ist ein Anti-Pattern — eine Denkfalle, die ich „dieser Schuss muss sitzen“ nennen möchte. Oder anders gesagt: Dieses Projekt muss ein Erfolg werden.
Trotz allem, was wir über große und komplexe IT-Programme wissen, werden sie immer wieder aufgesetzt. Wir wissen, dass sie ein hohes Scheitern-Risiko tragen, dass sie sich verzögern, ihre Budgets sprengen und Kunden am Ende oft unzufrieden sind. Ich war selbst Mitglied in einigen dieser Death Marches — ich weiß, wovon ich spreche.
Aber warum greifen Unternehmen immer noch zu diesen großen und komplexen IT-Projekten? Trotz des Wissens um ihre Umsetzungsrisiken. Trotz des Wissens, dass die Erfolgschancen steigen, wenn man zum Beispiel die Batch-Größe reduziert — also große Initiativen in mehrere dünne Scheiben schneidet.
Seien wir ehrlich: Es gibt Programme, die von Natur aus groß und komplex sind. Denk an den Bau einer großen Brücke oder einer Bahnstrecke zwischen zwei Städten. Ein agiler Ansatz — schnell Wert liefern, Initiativen aufteilen, mit MVPs experimentieren — funktioniert dort nicht wirklich. Zumindest nach meiner Kenntnis. Wenn du Gegenbeispiele kennst, freue ich mich über Kommentare — das interessiert mich wirklich. Manche Herausforderungen lassen sich eben nicht in Größe, Komplexität, Risiko und Zeitrahmen verkleinern. Und als kleiner Vorgeschmack: Das Cynefin-Framework hilft zu verstehen, warum manche Herausforderungen grundlegend anders sind als andere.
Zurück zu den heutigen IT-Programmen. Vor einigen Tagen moderierte ich einen Runden Tisch zum Thema Portfolio-Management. Eine Teilnehmerin sagte, die Ära der großen und komplexen Programme sei vorbei. Ich dachte: Sie hat recht — aber das entspricht nicht dem, was ich draußen sehe. Immer wieder stoße ich auf große und komplexe IT-Programme, die mit unrealistischen Zeitplänen, unklaren Ergebnissen und hohen Risiken aufgesetzt werden. Ich höre IT-Manager sagen: „Dieses Projekt muss ein Winner werden.“ „Diesmal müssen wir es wirklich richtig machen.“ „Wir setzen alles auf eine Karte.“ Oder sogar: „Die Zukunft unseres Unternehmens hängt von dieser strategischen Chance ab.“
Dann denke ich: Die sollten es besser wissen. Sie sollten die Risiken großer und komplexer IT-Programme kennen. Sie sollten die Möglichkeit sehen, dünne Scheiben zu schneiden, mit MVPs zu starten. Oder Methoden wie R.A.T. (Riskiest Assumptions Tested) zu nutzen. Warum kommen sie nicht dahinter? Es liegt alles auf dem Tisch — die Evidenz auf der einen Seite, die Prinzipien, Techniken und Tools auf der anderen. Und ja, ich höre Klagen von Managern, die selbst in diesen Death Marches stecken. Was passiert da also?
Ich bin zu der Überzeugung gelangt, dass es nicht der Wunsch einzelner Personen nach großen und komplexen IT-Programmen ist, der dieses Anti-Pattern erzeugt. Das Problem ist systemischer Natur. Die Ursache liegt in dem, was aus reifen Unternehmen über die Zeit geworden ist. Und es sind genau diese reifen Unternehmen, bei denen ich dieses Anti-Pattern beobachte. Es liegt in der Management-Hierarchie, die reife Unternehmen über Jahre des Wachstums aufgebaut haben. Diese Hierarchie kennst du. Sie ist die vorherrschende Organisationsstruktur in entwickelten, reifen Unternehmen.
Kurz gesagt: Wenn Unternehmen wachsen und reifen, nutzen sie Skaleneffekte, um einst differenzierte Leistungen zu günstigeren Preisen anzubieten — weil die Konkurrenz aufholt. Das müssen sie, um im Wettbewerb zu überleben. Und dabei entstehen Silos. Diese Silos können ein Unternehmen effizienter machen, gleichzeitig aber auch weniger flexibel und anpassungsfähig.
Also: Management-Hierarchie und Silos.
Schauen wir uns an, wie Entscheidungen in dieser Hierarchie getroffen werden.
Entscheidungen wandern in der Hierarchie nach oben. Sie blubbern hoch. Manager delegieren Entscheidungen in der Regel nicht nach unten — an die Teams oder die betroffenen Personen. Ein Grund dafür: Teams haben meistens keine End-to-end-Verantwortung für die Produkte oder Services, die sie entwickeln. Sie sind in der Regel nicht autonom. Sie sind auf Input und Abstimmung mit anderen Teams angewiesen. Das ist eine direkte Konsequenz der Silo-Struktur. Vergessen wir nicht, warum diese Silos überhaupt existieren. Innerhalb von ihnen können sich Menschen spezialisieren, tieferes Wissen und Fähigkeiten aufbauen — gemeinsam mit Kolleginnen und Kollegen, die an ähnlichen Problemen arbeiten. Sie sammeln mehr Aufgaben desselben Typs und können so automatisieren und Pooling nutzen, um effizienter zu werden.
Nehmen wir an, ein Team möchte eine bestimmte Fähigkeit implementieren oder eine Änderung vornehmen. Da das Team nicht autonom ist, braucht es Unterstützung von einem oder mehreren anderen Teams oder Kolleginnen und Kollegen aus anderen Abteilungen. Aus einer Teamarbeit wird eine koordinierte Initiative über mehrere Teams hinweg. Der Scope wächst. Und durch die notwendige Abstimmung und die Übergaben steigt auch die Dauer. Die Entscheidung liegt nicht mehr bei einem einzelnen Team — sie wandert in der Hierarchie nach oben. Und sie wächst in Scope und Wirkung, je mehr Teams betroffen sind. Veränderungen und die damit verbundenen Entscheidungen werden immer komplexer — und damit auch riskanter. Das Management erkennt das. Es schickt Teams zurück, um die geplante Änderung weiter zu analysieren und das Risiko zu reduzieren. Diese gut gemeinte Aufgabe verlangsamt die Umsetzung zusätzlich. Ich habe selbst mehrere dieser Analysen und Machbarkeitsstudien erlebt, deren Ergebnisse ordentlich aufbereitet wurden — und die dann NIEMAND, wirklich niemand, sich angeschaut hat. Weil inzwischen dringendere Fragen aufgetaucht waren. Das ist eine enorme Quelle von Verschwendung. Und natürlich verlieren die Menschen, die diese mühsame Analysearbeit leisten, mit der Zeit ihre Motivation.
Da Veränderungen in reifen Unternehmen länger dauern, verpasst man auch die Chance, die Wirkung von Initiativen schnell zu sehen und daraus zu lernen. Statt auf konkreten Ergebnissen aufzubauen, muss man sich auf Business Cases und Management-Narrative verlassen.
Vor diesem Hintergrund mache ich keine einzelne Person dafür verantwortlich, ein großes und komplexes Programm zu starten — oder zu sagen: „Dieser Schuss muss sitzen.“ Es ist die Organisationsstruktur reifer Unternehmen, die große und komplexe IT-Projekte hervorbringt. Es ist das System. Und solange wir nicht beginnen, die Struktur der Organisation zu verändern, werden digitale Transformationen weiterhin scheitern. Und wir werden weiterhin große und komplexe Projekte sehen — von denen viele scheitern werden.
Was können wir also tun? Ehrlich gesagt: Ich bin nicht sicher. Digitale Transformationen sind schwierig. Aber wenn man das agile Prinzip ernst nimmt, klein anzufangen, ist der erste Schritt: Bewusstsein schaffen. Die Auswirkungen der Management-Hierarchie und der Silos verstehen. Sehen, wie es anders gehen kann. Wirklich agile Unternehmen beobachten. Erleben, wie autonome Teams arbeiten. Aber Vorsicht vor Faux-Agile und Cargo-Cult-Agile. Fahr also ins Valley — oder fang hier in Berlin an. Und das gilt nicht nur für die Entwicklungsteams. Gerade Manager sollten über die Konsequenzen von Silos und Management-Hierarchie nachdenken. Lies über die Evidenz. Lies über Conway’s Law. Wenn du VP oder Director bist, überleg es dir zweimal, bevor du das nächste Mal eine Machbarkeitsstudie anforderst. Warum nicht stattdessen nach einem MVP fragen und vom Nutzer-Feedback lernen? Wenn du Program Manager bist, überleg es dir zweimal — und sei ehrlich mit dir selbst: Willst du wirklich 18 Monate warten, um erste Ergebnisse zu sehen? Die Wahrheit ist: Du bekommst diese Ergebnisse vielleicht nicht mal in 18 Monaten — es könnte länger dauern, und du bekommst vielleicht nicht das, was du dir erhofft hattest. Hör genau hin, wenn dir das nächste Mal jemand sagt, dieses Projekt muss ein Winner werden. Frag danach, wie eine dünne Scheibe aussehen könnte. Das ist nicht einfach — zugegeben. Aber diese großen und komplexen Programme und Death Marches auch nicht.
