Steering requirements, contracts, tickets and forecasts separately loses speed long before the first release exists.

Two thirds of large technology programmes do not achieve their goals for time, budget and scope.1 An older but still widely cited study by McKinsey and the University of Oxford of more than 5,400 IT projects puts the average budget overrun of large IT programmes at 45 percent. The value contribution is on average 56 percent below plan.2 In our own observation, the cause rarely lies in technical delivery. Time is lost above all at the transitions, that is between requirement and decision, between contract status and delivery steering and between reporting and measure. That is where the operational complexity arises that IT programme steering has to deal with.

Key points
  • In our own observation, IT programmes lose speed above all at the interfaces between business, contract, technology and finance and less in individual delivery units.
  • Classic status reporting describes the past. Steering begins where information turns into a decision with an owner and a deadline.
  • Contract management belongs in operational programme steering. Topics around licences, suppliers and changes block delivery and are therefore not a back-office task.

Complexity arises from dependencies, not from size

A programme does not become difficult because it contains many work packages. It becomes difficult when a decision in one area has consequences in three others and nobody maps this chain continuously. A changed requirement shifts the release plan. The release plan shifts the suppliers’ capacities. An open licensing question blocks the migration. A data quality problem puts testing at risk. Making this chain visible only in the steering committee means steering reactively. Keeping it in a shared steering view every week makes it possible to decide with foresight.

The BCG study fits this pattern. More than 60 percent 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. Another 60 percent point to the absence of an active PMO that monitors value delivery and identifies emerging risks.1

Reporting describes. Steering leads.

In many programmes, status reporting is equated with steering. A report with traffic lights, progress and risks is mandatory, but not yet leadership. Steering begins where every piece of information is connected to a consequence. For that, the report has to answer the following questions.

  • 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 puts a release at risk?
  • Which contract topic has an operational impact in the next 14 days?

A good report therefore does not only answer the question of where the programme stands. It also shows what has to be decided by whom and by when. Only with this translation does a report become a steering instrument.

The Steering Quadrant

Effective IT programme steering connects four perspectives that are managed separately in most organisations.

  • Functional clarity: Requirements are understandable, prioritised and ready for decision. Acceptance criteria are documented, and open functional questions have an owner and a deadline.
  • Operational transparency: Progress, risks, tickets, milestones and dependencies are brought together in a current view geared towards decisions. They are not spread across five parallel tools.
  • Commercial steering: Budget, forecast, contract status, licences and supplier contributions are linked directly to delivery status. Commercial topics count as delivery blockers and do not run alongside in a separate workstream.
  • Technical impact analysis: Migration, interfaces, data quality, testing and release readiness are assessed in every steering round and not only in the cutover phase.

Each of the four perspectives is known on its own. The working model proposes bringing them together in a weekly steering round, with an owner for every open item and a defined escalation level.

PMO as friction reduction, not as an administrative layer

A PMO creates value when it reduces friction. Additional formats alone do not create value. The yardstick is simple. One hour of PMO work has to save at least one hour of friction in the business, in development, in procurement or in management. PMO work that does not pass this test is bureaucracy. In practice, this means fewer status slides and more decision papers, fewer recurring meetings and more asynchronous clarification, and fewer obligations in tools and more clearly assigned owners.

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

SAP S/4HANA rollout. In a multi-year S/4HANA rollout with several plants and three external suppliers, a typical pattern emerged. Contract topics were handled by procurement, supplier steering lay with the PMO, technical risks with solution architecture and forecasts with controlling. Escalations reached the steering committee too late because none of the four views alone showed the whole picture. A shared steering quadrant was therefore introduced. In this weekly format, open items from all four perspectives were tracked with owner, deadline and commercial impact. In our own assessment, open programme topics were clarified faster as a result. More important than the format was the discipline of following every open item through consistently to a decision or closure.

Contract management is delivery steering

Contract and supplier topics are often taken into operational steering too late in IT programmes. Licence models, scope definitions, change requests and transition services have a direct effect on schedule, budget and scope. An open licence item becomes a delivery blocker as soon as technical delivery is waiting for it. From that moment, it is no longer purely a procurement topic. IT programme steering therefore has to manage contractual topics on the same level as technical and functional ones.

Bringing open items to closure

Programmes do not become faster through additional alignment meetings. They become faster when open topics are consistently followed through. The unclear requirement becomes a specification, the risk a measure, the contract item a decision and the defect an acceptance. These are exactly the transitions at which programmes lose time. In our own experience, closing them systematically gains more speed than additional delivery units.

Limits

The steering quadrant is our own working model from practice and not an empirically validated instrument. The studies cited show how often programmes miss their goals. They do not show that this format works. Not every programme needs all four perspectives in the same depth. With few dependencies and no suppliers, leaner steering can be enough. Moreover, the format does not work on its own. It needs the discipline to follow every open item through to a decision or closure. Otherwise the quadrant also becomes just another status format.

What can be derived from this

Three concrete next steps follow for programme steering.

  • Introducing the steering quadrant: Open items from business, delivery steering, contract and technology are brought together in a weekly view with owner, deadline and impact.
  • Translating reporting into decisions: Every item relevant for steering receives a specific next action and not just a status.
  • Making contract management escalation-ready: Contract and supplier topics are managed at the same cadence as technical risks.