IT-Programmsteuerung: Warum komplexe Projekte an den Übergängen Zeit verlieren.

Wer Anforderungen, Verträge, Tickets und Forecasts getrennt steuert, verliert Geschwindigkeit, lange bevor das erste Release entsteht.

Zwei Drittel der großen Technologieprogramme erreichen ihre Ziele bei Zeit, Budget und Scope nicht.¹ Eine ältere, aber bis heute viel zitierte Untersuchung von McKinsey und der University of Oxford mit mehr als 5.400 IT-Projekten beziffert die durchschnittliche Budgetüberschreitung großer IT-Programme auf 45 Prozent. Der Wertbeitrag liegt dabei im Schnitt 56 Prozent unter Plan.² Nach eigener Beobachtung liegt die Ursache selten in der technischen Umsetzung. Zeit geht vor allem an den Übergängen verloren, also zwischen Anforderung und Entscheidung, zwischen Vertragsstatus und Liefersteuerung und zwischen Reporting und Maßnahme. Dort entsteht die operative Komplexität, mit der sich IT-Programmsteuerung befassen muss.

Komplexität entsteht durch Abhängigkeiten und nicht durch Größe

Ein Programm wird nicht dadurch schwierig, dass es viele Arbeitspakete enthält. Schwierig wird es, wenn eine Entscheidung in einem Bereich Folgen in drei anderen hat und niemand diese Kette laufend abbildet. Eine geänderte Anforderung verschiebt den Releaseplan. Der Releaseplan verschiebt die Kapazitäten der Lieferanten. Eine offene Lizenzfrage blockiert die Migration. Ein Problem mit der Datenqualität gefährdet das Testing. Wer diese Kette erst im Lenkungsausschuss sichtbar macht, steuert reaktiv. Wer sie wöchentlich in einem gemeinsamen Steuerungsbild führt, kann vorausschauend entscheiden.

Die BCG-Untersuchung passt zu diesem Muster. 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. Ebenfalls 60 Prozent verweisen auf das Fehlen eines aktiven PMO, das die Wertlieferung überwacht und entstehende Risiken erkennt.¹

Reporting beschreibt. Steuerung führt.

In vielen Programmen wird Statusreporting mit Steuerung gleichgesetzt. Ein Report mit Ampel, Fortschritt und Risiken ist Pflicht, aber noch keine Führung. Steuerung beginnt dort, wo jede Information mit einer Konsequenz verbunden ist. Dafür muss der Report die folgenden Fragen beantworten.

• 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 also nicht nur die Frage, wo das Programm steht. Er zeigt auch, was bis wann von wem entschieden werden muss. Erst mit dieser Übersetzung wird ein Report zum Steuerungsinstrument.

Der Steering Quadrant

Wirksame IT-Programmsteuerung verbindet vier Perspektiven, die in den meisten Organisationen getrennt geführt werden.

• Fachklarheit: Anforderungen sind verständlich, priorisiert und bereit für die Entscheidung. Akzeptanzkriterien sind dokumentiert, und offene fachliche Fragen haben einen Owner und einen Termin.
• Operative Transparenz: Fortschritt, Risiken, Tickets, Meilensteine und Abhängigkeiten sind in einer aktuellen Sicht zusammengeführt, die auf Entscheidungen ausgerichtet ist. Sie sind nicht auf fünf parallele Tools verteilt.
• Kommerzielle Steuerung: Budget, Forecast, Vertragsstatus, Lizenzen und Beiträge der Lieferanten sind direkt mit dem Lieferstatus verknüpft. Kommerzielle Themen gelten als Blocker der Lieferung und laufen nicht in einem eigenen Workstream nebenher.
• Technische Wirkungsanalyse: Migration, Schnittstellen, Datenqualität, Testing und Releasefähigkeit werden in jeder Steuerungsrunde bewertet und nicht erst in der Cutover-Phase.

Jede der vier Perspektiven ist für sich bekannt. Das Arbeitsmodell schlägt vor, sie in einer wöchentlichen Steuerungsrunde zusammenzuführen, mit einem Owner für jeden offenen Punkt und einer festgelegten Eskalationsstufe.

PMO als Reibungsreduktion, nicht als Verwaltungsschicht

Ein PMO schafft Mehrwert, wenn es Reibung verringert. Zusätzliche Formate allein schaffen keinen Mehrwert. Der Maßstab ist einfach. Eine Stunde Arbeit im PMO muss mindestens eine Stunde Reibung im Fachbereich, in der Entwicklung, im Einkauf oder im Management einsparen. PMO-Arbeit, die diesen Test nicht besteht, ist Bürokratie. In der Praxis bedeutet das weniger Statusfolien und mehr Entscheidungsvorlagen, weniger wiederkehrende Meetings und mehr asynchrone Klärung sowie weniger Pflichten in Tools und mehr klar zugeordnete Owner.

Praxisvignette: Wenn vier Sichten kein Gesamtbild ergeben

SAP S/4HANA-Rollout. In einem mehrjährigen S/4HANA-Rollout mit mehreren Werken und drei externen Lieferanten zeigte sich ein typisches Muster. Vertragsthemen bearbeitete der Einkauf, die Steuerung der Lieferanten lag beim PMO, technische Risiken bei der Solution Architecture und die Forecasts beim Controlling. Eskalationen erreichten den Lenkungsausschuss zu spät, weil keine der vier Sichten allein das Gesamtbild zeigte. Eingeführt wurde deshalb ein gemeinsamer Steering Quadrant. In diesem wöchentlichen Format wurden offene Punkte aus allen vier Perspektiven mit Owner, Frist und kommerzieller Wirkung geführt. Nach eigener Einschätzung wurden offene Programmthemen dadurch schneller geklärt. Wichtiger als das Format war die Disziplin, jeden offenen Punkt konsequent bis zur Entscheidung oder zum Abschluss weiterzuverfolgen.

Contract Management ist Liefersteuerung

Vertrags- und Lieferantenthemen werden in IT-Programmen oft zu spät in die operative Steuerung aufgenommen. Lizenzmodelle, Leistungsabgrenzungen, Change Requests und Übernahmeleistungen wirken direkt auf Zeitplan, Budget und Scope. Ein offener Lizenzpunkt wird zum Blocker für die Lieferung, sobald die technische Umsetzung auf ihn wartet. Ab diesem Moment ist er kein reines Thema des Einkaufs mehr. IT-Programmsteuerung muss vertragliche Themen deshalb auf derselben Ebene führen wie technische und fachliche.

Offene Punkte zum Abschluss bringen

Programme werden nicht durch zusätzliche Abstimmungen schneller. Sie werden schneller, wenn offene Themen konsequent weitergeführt werden. Aus der unklaren Anforderung wird eine Spezifikation, aus dem Risiko eine Maßnahme, aus dem Vertragspunkt eine Entscheidung und aus dem Defect eine Abnahme. Genau an diesen Übergängen verlieren Programme Zeit. Wer sie systematisch schließt, gewinnt nach eigener Erfahrung mehr Geschwindigkeit als durch zusätzliche Liefereinheiten.

Grenzen

Der Steering Quadrant ist ein eigenes Arbeitsmodell aus der Praxis und kein empirisch validiertes Instrument. Die zitierten Studien belegen, wie häufig Programme ihre Ziele verfehlen. Sie belegen nicht, dass dieses Format wirkt. Nicht jedes Programm braucht alle vier Perspektiven in gleicher Tiefe. Bei wenigen Abhängigkeiten und ohne Lieferanten kann eine schlankere Steuerung genügen. Außerdem wirkt das Format nicht von allein. Es braucht die Disziplin, jeden offenen Punkt bis zur Entscheidung oder zum Abschluss weiterzuführen. Sonst wird auch der Quadrant nur ein weiteres Statusformat.

Was sich daraus ableiten lässt

Für die Programmsteuerung ergeben sich drei konkrete nächste Schritte.

• Steering Quadrant einführen: Offene Punkte aus Fachbereich, Liefersteuerung, Vertrag und Technik werden in einer wöchentlichen Sicht mit Owner, Frist und Wirkung zusammengeführt.
• Reporting in Entscheidungen übersetzen: Jeder Punkt, der für die Steuerung relevant ist, erhält eine konkrete nächste Aktion und nicht nur einen Status.
• Contract Management eskalationsfähig machen: Vertrags- und Lieferantenthemen werden im selben Takt geführt wie technische Risiken.