Why Programmes Slip Even When Every Process Is Followed

There is a version of this industry that looks highly organised. Gateway reviews. DFMEA processes. Supplier readiness tracking. Validation gates. Escalation pathways. Lessons learnt capture. Most large OEM programmes carry all of these and more, built up over decades of hard-won process maturity.

And yet programmes still slip. Issues still arrive late. Warranty accruals still climb. Launches still scramble.

The standard explanation is execution failure. Someone missed a milestone, a supplier underdelivered, a team did not escalate in time. Fix the accountability, tighten the process, add another review. That explanation is not wrong. But it is incomplete.

Because the deeper pattern, the one visible across programmes regardless of organisation, geography, or vehicle architecture, is not a failure of process maturity. It is a failure of execution coherence. And those two things are not the same.

The information exists. It is just not where the programme can see it.

Consider what the execution environment actually looks like on a typical vehicle programme. Multiple engineering domains. Globally distributed suppliers. Separate PLM and ERP environments. Independent validation systems, timing tools, compliance tracking, software issue platforms, manufacturing readiness systems, regulatory reporting. Each is optimised for a specific function. Very few are designed to maintain a continuously synchronised view of the whole programme.

So a direct dependency on a supplier is never visible in the execution environment unless it is captured somewhere official, in a format every relevant layer of the organisation actually monitors. In practice, that rarely happens consistently. Commitments land on email. Actions get recorded in spreadsheets or OneNote. Conversations carrying real programme implications happen in personal chats and local folders, disconnected from any live system.

The programme looks coherent from the outside, and at governance level it genuinely is. Status is reported, gates are reviewed, risks are logged. What is rarely visible in one place is the actual state of execution: the live dependency picture across engineering, suppliers, validation, and manufacturing readiness, simultaneously.

That gap, between governance coherence and execution coherence, is where programmes quietly accumulate risk. By the time the programme notices the missing signal, it is already reacting to consequence.

Coherence is built by hand, continuously

This produces the actual operating model inside large programmes, the one rarely described plainly.

Because the true state of the programme is not visible in one place, coherence is created through continuous cross-functional reconciliation. Programme managers aligning timing assumptions. Chief engineers reconciling technical trade-offs. Integration teams coordinating supplier dependencies. Validation leads connecting test outcomes back into risk decisions. A significant portion of programme execution is, in effect, coordination overhead between fragmented information environments.

You can see it in what every large programme accumulates:

• Recurring cross-functional reviews
• Dependency alignment meetings
• Escalation forums
• Supplier integration workshops
• Manual status consolidation
• Parallel reporting structures

These are not inefficiencies. They are the compensating architecture. They exist because no single system represents the live operational state of the programme, so the organisation builds a human layer to do it instead.

And that human layer works. Programmes deliver. Vehicles launch. Most teams are not wrong locally, even when the programme drifts globally, because the people holding the seams together are good at it. But it works at a cost the industry has normalised: coordination overhead, late signal interpretation, and problems that surface only once they already carry consequence.

A problem is not a problem until it surfaces. And once it surfaces, it arrives with a cost the programme has been accumulating silently for months.

Why the model is getting harder to sustain

For a long time this was manageable, for one reason above all: institutional memory filled the gaps that systems left open. Architectural patterns were stable, supplier relationships were long-standing, failure modes were understood. Experienced people had seen it before, so they knew where to look.

That foundation is eroding, and not because the people are less capable. It is eroding because the interactions that now drive programme risk increasingly cross the boundaries institutional memory was never built to span. A software timing issue affects validation sequencing. A supplier firmware dependency affects manufacturing readiness. A regulatory interpretation change alters system-level integration assumptions. None of these are exotic. Every programme manager has navigated versions of all three. But they are interactions between domains that historically had little to do with one another, and no individual's accumulated memory reliably covers them.

Automotive companies have encountered a fourfold increase in software complexity since 2010, while software development productivity has only increased by about 1 to 1.5 times. That gap is not academic. It shows up as integration delays, late-stage defects, and cross-domain dependencies no single person can hold in their head anymore.

Electrified propulsion, software-defined architectures, cross-domain feature integration, over-the-air capability, tighter regulation, compressed timelines, distributed engineering ecosystems: each of these increases the number of interactions that must stay synchronised. Together, they compound. The compensating human layer scales linearly. The complexity does not.

Documentation will not close this gap. The premise of documentation-based visibility is that documentation stays live, updated, and accessible. In multi-year programmes under execution pressure, that premise fails consistently. The information is usually inside the programme already, sitting in another functional system, inside supplier reporting, buried in local issue tracking, or simply arriving too late in the escalation chain to be addressed cleanly.

The question the industry has not asked clearly enough

Most post-programme reviews ask: where did execution fail?

The more useful question is: where did the execution environment make failure harder to see?

There is a meaningful difference between a programme that fails because people made poor decisions, and one that fails because the information architecture made it structurally difficult to make good ones in time. The industry has spent decades improving the first, through accountability frameworks, governance maturity, and process discipline, all real progress. The second has received far less structural attention.

Large automotive organisations already have processes. That has never been the gap. The gap is whether programme-level coherence can be maintained as dependency complexity scales across systems, functions, and suppliers, without relying on continuous human reconciliation to hold it together.

Today, much of that coherence is still achieved through exactly that. That model has delivered programmes for decades. But as complexity, software integration, supplier interdependence, and development speed keep rising at once, the coordination burden rises with them. At some point, holding coherence together by hand is no longer a process problem. It is a structural one.

And structural problems require structural responses.

What comes next

This is the first piece in a series on execution coherence in automotive programmes. The pieces that follow trace the problem from the inside out:

• Why programmes drift while every team reports green
• How a consequence in one domain propagates across a boundary undetected, and why the signal that never arrives is the hardest risk to see
• Why the human reconciliation that holds programmes together is infrastructure rather than overhead
• Why that infrastructure scales slower than the complexity it absorbs
• And finally, what maintaining execution coherence would actually require once holding it by hand stops being enough

The industry has built strong processes. The question now is whether those processes can see what they need to see, when they need to see it, without relying on continuous manual translation between fragmented systems.

Because the programmes that slip are not the ones without process. They are the ones where the process cannot hold the whole picture at once.