IT programme steering: Why complex projects fail at the transitions — not at delivery.

Anyone who steers requirements, contracts, tickets and forecasts separately loses speed long before the first release emerges.

Two-thirds of large technology programmes fail to reach their goals for time, budget and scope.¹ An older, but to this day formative study by McKinsey and the University of Oxford covering more than 5,400 IT projects puts the average budget overrun of large IT programmes at 45 per cent — with a value contribution that is, on average, 56 per cent below plan.² The Standish CHAOS Report 2020 reaches a similar conclusion: only 31 per cent of the projects examined are deemed successful, 50 per cent "challenged", 19 per cent failed.³ The cause rarely lies in the technical delivery. It lies at the transitions: between requirement and decision, between contract status and delivery steering, between reporting and action. It is precisely there that the operational complexity arises which IT programme steering must address.

Complexity is a function of dependency, not of size

A programme does not become difficult because it contains many work packages. It becomes difficult when decisions in one area produce effects in three others — and no one maps this chain of effects in real time. A requirement change shifts the release plan. The release plan shifts supplier capacities. An open licence question blocks the migration. A data-quality problem jeopardises testing. Anyone who only makes this chain visible in the steering committee steers reactively. Anyone who runs it weekly in a consolidated steering picture decides ahead of time.

The BCG study confirms this pattern from a practical perspective: more than 60 per cent of the programmes surveyed name the absence of an end-to-end master plan with a critical path and clear dependencies as a central cause of failure. A further 60 per cent point to the absence of an active PMO that monitors value delivery and identifies emerging risks.¹

Reporting describes. Steering leads.

In many programmes, status reporting is equated with steering. A report shows a traffic light, progress, risks — that is mandatory, but not leadership. Steering begins where every piece of information is connected to a consequence:

• Which open item is blocking the next milestone?
• Which decision is missing, and who is the owner?
• Which dependency shifts schedule, budget or quality?
• Which ticket jeopardises a release?
• Which contract topic has an operational effect in the next 14 days?

A good report answers not only "Where do we stand?", but "What must be decided by when and by whom?". Only this translation turns a report into a steering instrument.

The loumiTECH Steering Quadrant

Effective IT programme steering connects four perspectives that are run separately in most organisations:

1. Functional clarity. Requirements are understandable, prioritised and ready for decision. Acceptance criteria are documented, open functional questions have an owner and a deadline.
2. Operational transparency. Progress, risks, tickets, milestones and dependencies are consolidated in a current, decision-oriented view — not in five parallel tools.
3. Commercial steering. Budget, forecast, contract status, licences and supplier contributions are linked directly to delivery status. Commercial topics are treated as delivery blockers, not as a separate workstream.
4. Technical impact analysis. Migration, interfaces, data quality, testing and release readiness are assessed in every steering round — not only in the cutover phase.

The four perspectives are, in sum, not new. What is new is the rigour: they are brought together in a weekly steering logic, with one owner per open item and an explicit escalation level.

PMO as friction reduction, not as an administrative layer

A PMO creates value when it reduces friction — not when it produces additional formats. The yardstick is simple: one hour of PMO work must save at least one hour of friction in business, development, procurement or management. PMO work that does not pass this test is bureaucracy. Concretely, this means: fewer status slides, more decision papers. Fewer repeat meetings, more asynchronous clarification. Less tool obligation, more owner assignment.

Practice vignette: When four views do not add up to a whole picture

SAP S/4HANA rollout. In a multi-year S/4HANA rollout programme with several plants and three external suppliers, a typical pattern emerged: contract topics were handled in procurement, supplier steering in the PMO, technical risks in the solution architecture, forecasts in controlling. Escalations reached the steering committee too late, because none of the four views alone produced the whole picture. The introduction of a consolidated Steering Quadrant — a weekly format that ran open items from all four perspectives with owner, deadline and commercial effect — measurably shortened the average clarification time for open programme topics. More important than the format was the discipline of consistently carrying every open item through to decision or closure.

Contract management is delivery steering

Contract and supplier topics are integrated into operational steering too late in IT programmes. Licence models, scope demarcations, change requests and handover services act directly on schedule, budget and scope. An open licence item is not a procurement topic — it is a delivery blocker as soon as the technical implementation waits on it. IT programme steering must run contractual topics at the same level as technical and functional ones.

The decisive step: making open items ready for closure

Programmes gain speed not through additional coordination, but through the consistent progression of open topics — from the unclear requirement to the specification, from the risk to the action, from the contract item to the decision, from the defect to acceptance. It is precisely at these transitions that programmes lose time. Anyone who closes them systematically gains more speed than any additional delivery unit can generate.

Limitations

The Steering Quadrant is our own working model from practice, not an empirically validated instrument; the cited studies evidence the frequency of missed programme goals, not causally the effect of this format. Not every programme needs all four perspectives in equal depth — with low dependency and no supplier involvement, leaner steering may suffice. And the format alone has no effect: what is decisive is the discipline of carrying every open item through to decision or closure — otherwise the quadrant, too, becomes just another status format.

What you can do now

Three concrete next steps for your organisation's programme steering:

1. Introduce the Steering Quadrant. Consolidate open items from business, delivery steering, contract and technology in a weekly view — with owner, deadline and effect.
2. Translate reporting into decisions. Every steering-relevant item is given a concrete next action, not just a status.
3. Make contract management escalation-ready. Contract and supplier topics are run at the same cadence as technical risks.