Zwei Drittel der großen Technologieprogramme erreichen ihre Ziele bei Zeit, Budget und Scope nicht.1 Eine ältere, aber bis heute prägende Untersuchung von McKinsey und der University of Oxford über mehr als 5.400 IT-Projekte beziffert die durchschnittliche Budgetüberschreitung großer IT-Programme auf 45 Prozent — bei einem Wertbeitrag, der im Schnitt 56 Prozent unter Plan liegt.2 Der Standish-CHAOS-Report 2020 kommt zu einer ähnlichen Bilanz: Nur 31 Prozent der untersuchten Projekte gelten als erfolgreich, 50 Prozent als „challenged", 19 Prozent als gescheitert.3 Die Ursache liegt selten in der technischen Umsetzung. Sie liegt an den Übergängen: zwischen Anforderung und Entscheidung, zwischen Vertragsstatus und Liefersteuerung, zwischen Reporting und Maßnahme. Genau dort entsteht die operative Komplexität, die IT-Programmsteuerung adressieren muss.
Komplexität ist eine Funktion von Abhängigkeit, nicht von Größe
Ein Programm wird nicht dadurch schwierig, dass es viele Arbeitspakete enthält. Schwierig wird es, wenn Entscheidungen in einem Bereich Auswirkungen in drei anderen erzeugen — und niemand diese Wirkungskette in Echtzeit abbildet. Eine Anforderungsänderung verschiebt den Releaseplan. Der Releaseplan verschiebt Lieferantenkapazitäten. Eine offene Lizenzfrage blockiert die Migration. Ein Datenqualitätsproblem gefährdet das Testing. Wer diese Kette erst im Lenkungsausschuss sichtbar macht, steuert reaktiv. Wer sie wöchentlich in einem konsolidierten Steuerungsbild führt, entscheidet vorausschauend.
Die BCG-Untersuchung bestätigt dieses Muster aus Praxisperspektive: Mehr als 60 Prozent der befragten Programme nennen das Fehlen eines durchgängigen Master-Plans mit kritischem Pfad und klaren Abhängigkeiten als zentrale Ursache des Scheiterns. Weitere 60 Prozent verweisen auf das Fehlen eines aktiven PMO, das Wertlieferung überwacht und entstehende Risiken identifiziert.1
Reporting beschreibt. Steuerung führt.
In vielen Programmen wird Statusreporting mit Steuerung gleichgesetzt. Ein Report zeigt Ampel, Fortschritt, Risiken — das ist Pflicht, aber keine Führung. Steuerung beginnt dort, wo jede Information mit einer Konsequenz verbunden ist:
- Welcher offene Punkt blockiert den nächsten Meilenstein?
- Welche Entscheidung fehlt, und wer ist Owner?
- Welche Abhängigkeit verschiebt Zeitplan, Budget oder Qualität?
- Welches Ticket gefährdet ein Release?
- Welches Vertragsthema hat operative Auswirkung in den nächsten 14 Tagen?
Ein guter Report beantwortet nicht nur „Wo stehen wir?", sondern „Was muss bis wann von wem entschieden werden?". Erst diese Übersetzung macht aus einem Report ein Steuerungsinstrument.
Der loumiTECH Steering Quadrant
Wirksame IT-Programmsteuerung verbindet vier Perspektiven, die in den meisten Organisationen getrennt geführt werden:
Fachklarheit
Anforderungen sind verständlich, priorisiert und entscheidungsreif. Akzeptanzkriterien sind dokumentiert, offene Fachfragen haben Owner und Termin.
Operative Transparenz
Fortschritt, Risiken, Tickets, Meilensteine und Abhängigkeiten sind in einer aktuellen, entscheidungsorientierten Sicht konsolidiert — nicht in fünf parallelen Tools.
Kommerzielle Steuerung
Budget, Forecast, Vertragsstatus, Lizenzen und Lieferantenbeiträge sind direkt mit dem Lieferstatus verknüpft. Kommerzielle Themen werden als Lieferblocker behandelt, nicht als separater Workstream.
Technische Wirkungsanalyse
Migration, Schnittstellen, Datenqualität, Testing und Releasefähigkeit werden in jeder Steuerungsrunde bewertet — nicht erst in der Cutover-Phase.
Die vier Perspektiven sind in Summe nicht neu. Neu ist die Konsequenz: Sie werden in einer wöchentlichen Steuerungslogik zusammengeführt, mit einem Owner pro offenem Punkt und einer expliziten Eskalationsstufe.
PMO als Reibungsreduktion, nicht als Verwaltungsschicht
Ein PMO erzeugt Mehrwert, wenn es Reibung reduziert — nicht, wenn es zusätzliche Formate produziert. Der Maßstab ist einfach: Eine Stunde PMO-Arbeit muss mindestens eine Stunde Reibung in Fachbereich, Entwicklung, Einkauf oder Management einsparen. PMO-Arbeit, die diesen Test nicht besteht, ist Bürokratie. Konkret bedeutet das: weniger Statusfolien, mehr Entscheidungsvorlagen. Weniger Wiederholungsmeetings, mehr asynchrone Klärung. Weniger Tool-Pflicht, mehr Owner-Zuordnung.
Wenn vier Sichten kein Gesamtbild ergeben
In einem mehrjährigen S/4HANA-Rollout-Programm mit mehreren Werken und drei externen Lieferanten zeigte sich ein typisches Muster: Vertragsthemen wurden im Einkauf bearbeitet, Lieferantensteuerung im PMO, technische Risiken in der Solution Architecture, Forecasts im Controlling. Die Eskalationen erreichten den Lenkungsausschuss zu spät, weil keine der vier Sichten allein das Gesamtbild ergab. Die Einführung eines konsolidierten Steering Quadrants — ein wöchentliches Format, das offene Punkte aus allen vier Perspektiven mit Owner, Frist und kommerzieller Wirkung führte — verkürzte die durchschnittliche Klärungsdauer offener Programmthemen messbar. Wichtiger als das Format war die Disziplin, jeden offenen Punkt bis zu Entscheidung oder Abschluss konsequent weiterzuführen.
Contract Management ist Liefersteuerung
Vertrags- und Lieferantenthemen werden in IT-Programmen zu spät in die operative Steuerung integriert. Lizenzmodelle, Leistungsabgrenzungen, Change Requests und Übernahmeleistungen wirken direkt auf Zeitplan, Budget und Scope. Ein offener Lizenzpunkt ist kein Einkaufsthema — er ist ein Lieferblocker, sobald die technische Umsetzung darauf wartet. IT-Programmsteuerung muss vertragliche Themen auf der gleichen Ebene führen wie technische und fachliche.
Der entscheidende Schritt: offene Punkte abschlussfähig machen
Programme gewinnen Geschwindigkeit nicht durch zusätzliche Abstimmungen, sondern durch konsequente Weiterführung offener Themen — von der unklaren Anforderung zur Spezifikation, vom Risiko zur Maßnahme, vom Vertragspunkt zur Entscheidung, vom Defect zur Abnahme. An genau diesen Übergängen verlieren Programme Zeit. Wer sie systematisch schließt, gewinnt mehr Geschwindigkeit als jede zusätzliche Liefereinheit erzeugen kann.
Was Sie jetzt tun können
Drei konkrete nächste Schritte für die Programmsteuerung Ihrer Organisation.
- Steering Quadrant einführen. Konsolidieren Sie offene Punkte aus Fachbereich, Liefersteuerung, Vertrag und Technik in einer wöchentlichen Sicht — mit Owner, Frist und Wirkung.
- Reporting in Entscheidungen übersetzen. Jeder steuerungsrelevante Punkt erhält eine konkrete nächste Aktion, nicht nur einen Status.
- Contract Management eskalationsfähig machen. Vertrags- und Lieferantenthemen werden im gleichen Takt geführt wie technische Risiken.
Quellen
- Boston Consulting Group (2024): Most Large-Scale Tech Programs Fail — Here's How to Succeed. Studie über 1.000 Unternehmen in 59 Ländern. Verfügbar unter: bcg.com/publications/2024/most-large-scale-tech-programs-fail-how-to-succeed
- Bloch, M., Blumberg, S., Laartz, J. (2012): Delivering large-scale IT projects on time, on budget, and on value. McKinsey & Company in Zusammenarbeit mit dem BT Centre for Major Programme Management, University of Oxford. Datenbasis: 5.400 IT-Projekte. Verfügbar unter: mckinsey.com
- The Standish Group (2020): CHAOS 2020: Beyond Infinity. Letzte Ausgabe der CHAOS-Reportreihe, Datenbasis: über 50.000 IT-Projekte. The Standish Group International.
IT-Consultant mit Schwerpunkt SAP-Programmsteuerung, PMO-Aufbau, Contract Management und Finance Reporting. Unterstützt Unternehmen international bei komplexen IT- und Transformationsprojekten. Kontakt: hello@loumi.tech
Komplexes Programm,
konkreter Engpass?
Eine kurze Nachricht reicht für eine erste Einschätzung — pragmatisch, ehrlich und ohne Verkaufsdruck.
Projekt anfragen →