In more than two decades working inside and alongside complex technology programmes, I've seen the same patterns repeat with remarkable consistency. The specific context changes — the industry, the technology, the team — but the underlying reasons programmes struggle tend to be the same. Here are the ten I see most often.
1. The business case is approved but never revisited
Most programmes start with a business case that justifies the investment. Few organisations revisit it systematically once delivery is underway. As scope changes, timelines shift, and market conditions evolve, the original case for the programme quietly erodes — but delivery continues on autopilot. By the time someone asks whether the investment still makes sense, the answer is often uncomfortable.
2. Scope grows without consequence
Technology programmes attract additions throughout their lifecycle. A new requirement here, an expanded integration there — each individual change seems reasonable and manageable. Cumulatively, they extend timelines, stretch teams, and dilute focus. The original plan becomes unrecognisable, but the original deadline and budget remain. Something has to give, and it's usually outcomes.
3. The wrong people are accountable
Delivery accountability in large programmes is frequently misaligned. The person with formal accountability on paper is not always the person with the authority, relationships, or proximity to delivery required to actually drive outcomes. When something goes wrong, ownership is unclear — and unclear ownership means slow escalation, deferred decisions, and problems that persist far longer than they should.
4. Vendor reporting is taken at face value
Systems integrators and technology vendors are commercial partners. They have a financial interest in continued engagement and a reputational interest in reporting progress positively. Most vendor reporting reflects the story they want to tell — not necessarily the full picture of where delivery stands. Organisations that accept vendor reporting without independent challenge are, in effect, outsourcing their risk management to the party most motivated to understate it.
5. Dependencies are identified but not managed
Every complex programme has dependencies — between teams, between workstreams, between internal functions and external partners. They get logged in the plan and added to the RAID register. What happens less consistently is active management of those dependencies — naming an owner, tracking resolution, escalating when they're at risk. Unmanaged dependencies are one of the most reliable predictors of programme delay.
6. Governance reports rather than decides
Steering forums and programme boards serve an important function — but only if they're making decisions, not just receiving updates. In many programmes, governance has drifted into a reporting cadence where status is presented, noted, and filed. Difficult decisions are deferred. Risks are acknowledged but not acted on. The forum exists, but the governance function it's supposed to provide doesn't.
7. Teams are too busy delivering to surface problems
Delivery teams are under pressure to make progress. Raising a blocker or escalating a risk takes time, requires confidence that it will be received constructively, and can feel like admitting a personal failure. In cultures where the emphasis is on keeping things moving, problems stay at team level longer than they should. By the time they surface formally, they've already had weeks or months of compounding impact.
8. The plan measures activity, not outcomes
A plan that tracks workshops completed, sprints delivered, and milestones recorded as met can show consistent progress while the programme drifts away from its intended outcomes. Activity is easy to measure and easy to report positively. Outcome-based tracking — what has actually been delivered into production, what business value has been realised — is harder and less common. Programmes that measure activity rather than outcomes can look healthy right up until they don't.
9. Leadership is too far from delivery reality
The further a leader is from day-to-day delivery, the more dependent they are on filtered reporting. This is not a criticism — it's an inevitable consequence of scale. But it creates a structural gap between what leadership believes is happening and what is actually happening on the ground. That gap tends to widen over time, and it's rarely closed by adding another layer of reporting. It requires a fundamentally different kind of visibility.
10. Problems are discovered when it's too late to act cheaply
Most of the issues above are recoverable — if they're identified early enough. Scope creep can be managed. Dependencies can be resolved. Governance can be strengthened. Vendor performance can be challenged. The tragedy of most programme failures is not that the problems were unavoidable — it's that they were identified at a point when the options for intervention were limited, costly, and disruptive.
The organisations that consistently deliver better outcomes from technology programmes are not the ones that avoid these problems entirely. They're the ones that identify them early enough to act before the cost of doing so becomes prohibitive.
A note on independent visibility
The common thread running through all ten of these patterns is visibility — or rather, the lack of it. Most delivery problems are not hidden deliberately. They're invisible because the mechanisms organisations rely on to surface them are structurally limited. Independent delivery assurance exists specifically to address that limitation — providing the objective, evidence-based view that internal reporting consistently struggles to deliver.
Performance Radar provides independent delivery assurance for technology leaders running complex programmes. To discuss your situation, schedule a 15-minute introduction.