If you have worked with me in a large program, you have probably heard me say: “We need to do more conceptual work.”

What I mean is that we need to understand how the work will actually happen before we start trying to execute it. Not just what the deliverables are, but how the teams will work together, where the dependencies are, who is responsible for what, and what we will do when something goes wrong.

After reading How Big Things Get Done, I realised that what I have been calling conceptual work is really a form of planning.

Most people think planning means building a project schedule. I think the real planning happens before that. It is the work of mentally executing the program before anyone starts doing the work—playing through who will do what, where the handoffs are, what happens when dependencies fail, and where the gaps might emerge.

This kind of planning is especially important in complex programs because alignment is not automatic. Different teams often have different assumptions about scope, sequencing, ownership, quality, risk, and progress. If those assumptions are not surfaced early, they show up later as delays, rework, escalation, or confusion.

What this planning really creates is a shared mental model. Everyone leaves the room understanding not just the plan, but how the program is expected to behave when reality starts pushing back. That shared understanding allows teams to make good decisions independently instead of constantly waiting for coordination.

A couple of years ago, we delivered a large data centre exit. We were working to immovable deadlines. The bulldozers were already scheduled to demolish the building. We spent weeks repeatedly redesigning how we were going to deliver the migration before we touched production. How should we bundle the applications? What testing did we need to perform? How would we get sign-off to migrate?

We went through painful brainstorming to think about what could go wrong. We dug into the tooling to understand what processes it enabled, and where it did not help us. We found problems, misunderstandings, and gaps before they became execution issues.

Were we perfect in execution? No. There were long nights and weekends, unforeseen problems, COVID-19, last-minute rescues, and even some rollbacks.

We succeeded not because execution was flawless, but because we had already thought through most of the difficult decisions before execution pressure arrived. Once everyone agrees how the work will happen, another benefit appears almost immediately: you can finally measure progress properly.

That experience reinforced two things for me: first, alignment has to happen before execution pressure arrives; second, progress has to be measured in units that actually mean something.

The first practical output of good planning is meaningful progress measurement.

“Percentage complete” does not mean much unless the pieces underneath the calculation are meaningful. A team can be 80% complete for weeks if the remaining 20% contains the hard decisions, unresolved dependencies, or untested assumptions.

Better measures are tied to real units of progress: work packages completed, process steps agreed, phases exited, software modules built, features tested, decisions made, or risks retired. The point is not to create reporting for its own sake. The point is to understand whether the program is actually moving.

Another important part of upfront planning is looking for ways to decouple work and retain optionality.

It is tempting to combine things to reduce retesting, reviews, or governance effort. Sometimes that is the right answer. But every time we couple pieces of work together, we also increase risk. A delay in one area can block another. A missed dependency can suddenly become a program-level issue.

Good planning creates options. Poor planning leaves you trapped by unnecessary dependencies.

Thinking through options early allows us to identify off-ramps. What can move independently? What can be sequenced differently? What can be recombined if a dependency does not come through? What decisions do we need to keep open for longer?

Something will invariably go wrong in a complex program. The goal is not to create a perfect plan that assumes nothing changes. The goal is to create enough shared understanding and enough optionality that the program can adapt when things do change. That is why upfront alignment matters. It isn’t bureaucracy; it’s how complex programs remain executable when reality inevitably refuses to follow the plan.