John Christopher

From Programme Planning To Delivery Control

During my recent programme delivery work, one thing became very clear to me.

The challenge was not a lack of planning information. We had estimates, capacity information, delivery plans, dependencies and PI commitments.

The challenge was bringing all of this together into a view that people could actually use.

Different teams were looking at planning from different perspectives. Some were working at a monthly level, delivery teams were working through sprints, and programme planning was focused on PI commitments and longer-term delivery.

All of these views were useful, but they were not always connected.

That made me think about programme planning differently.

For me, good programme planning is not about creating another project plan or another report. It is about creating a connected view of capacity, demand, delivery, dependencies and timing.

That is where planning starts to become delivery control.

Connecting The Planning View

The approach I worked with was based around four connected stages:

The first step was understanding the capacity available across the programme.

Then came the delivery demand. What work are we expecting to deliver, how much effort is involved, and when does it need to happen?

The integrated plan then brought these views together with sequencing, dependencies, releases and forecast dates.

From there, the information could be taken into the level of detail needed by delivery teams.

This sounds straightforward, but keeping these views connected is where most of the effort goes.

A capacity number on its own does not tell you what you can deliver. Equally, a delivery plan does not tell you whether you actually have enough capacity to support it.

You need to look at both together.

Connecting Quarterly, Monthly, Weekly, Sprint And PI Planning

Another area I focused on was connecting the different planning horizons.

The intention was not to create five different plans.

It was to make sure that the different levels of planning were connected and that the information remained consistent as you moved from the programme level down into execution.

At the higher level, leadership needs to understand capacity, demand and forecast delivery.

At the delivery level, teams need to understand what needs to happen next.

The difficulty is keeping those two views connected.

If the numbers change between them without a clear reason, confidence in the plan starts to disappear.

Building The Integrated Programme Plan

As part of this work, I developed an integrated Microsoft Project view to bring the different elements of programme delivery together.

It included the delivery lifecycle, estimated effort, sequencing, dependencies, resource demand, capacity, release planning and forecast delivery dates.

The intention was not to create another day-to-day delivery tracker.

It was to provide a programme-level view that could help answer some fairly basic but important questions.

• What are we trying to deliver?
• How much effort is involved?
• Do we have the capacity to support it?
• Where are the constraints?
• What dependencies could affect the timeline?
• What does the current demand mean for the delivery forecast?

Having this information together made it easier to look at the programme as a whole rather than looking at individual pieces of the plan in isolation.

PI Planning Is More Than Story Points

PI planning can sometimes become heavily focused on velocity and story points.

They are useful measures, but they are only one part of the delivery picture.

From a programme perspective, I also need to understand the relationship between available capacity and expected demand.

Even where a team appears to have enough capacity, delivery can still be affected by dependencies, sequencing, external teams or platform readiness.

That is why I see PI planning as both a delivery planning activity and a capacity management activity.

The question is not simply how much work we can commit to.

It is whether the planned work can realistically be delivered within the capacity and constraints that exist.

The Planning Model Is Only As Good As The Data

One of the things I learned through this work is that building the planning model is only part of the job.

The more difficult part is making sure the information behind it is reliable.

• Who owns the estimate?
• Who validates the capacity?
• Who owns the dependency?
• Who confirms the change?
• How often is the information updated?
• What is the source of truth?

These questions become increasingly important as the programme grows.

Without clear ownership, planning can quickly become an exercise in chasing information and reconciling different versions of the same story.

That is where governance becomes important.

Not governance for the sake of governance, but enough structure to make sure people know what they are responsible for and that the information being used for decisions can be trusted.

Reusable Planning And Process Artefacts

Another part of the work was creating reusable planning and process artefacts.

This included a PI calendar, capacity planning model, planning views connecting monthly, weekly, sprint and PI planning, as well as reusable process documentation templates.

The reason for doing this was simple.

I did not want the programme to depend on one person recreating the same information every time.

A common structure makes it easier for teams to understand how planning works and gives future teams something they can build on.

For me, that is one of the practical benefits of good programme delivery. When you solve a problem once, try to turn the solution into something that can be reused.

What I Learned

The biggest lesson for me was that creating the plan was actually the easy part.

The harder part was keeping the information connected, current and trusted.

A useful programme planning model needs good data, clear ownership and regular review. It also needs to stay close enough to actual delivery that changes in the real world are reflected in the plan.

A programme plan should not become something that is created once and then protected.

It needs to change as the programme changes.

That does not mean constantly changing the target.

It means having an honest view of where delivery is today and understanding what needs to change when the reality is different from the original assumption.

What I Would Do Differently

If I were starting the same exercise again, I would establish ownership and definitions much earlier.

I would agree upfront what we mean by capacity, demand, effort, dependency and forecast.

I would also establish the relationship between the different planning horizons from the beginning rather than allowing each level of planning to develop independently.

Most importantly, I would make the assumptions behind the plan visible.

Forecasts are always based on assumptions. Making those assumptions clear makes it much easier to have the right conversations when something changes.

From Planning To Delivery Control

For me, this is the real difference between programme planning and delivery control.

Planning gives you a view of what you expect to happen.

Capacity planning tells you whether you have the ability to support it.

Integrated planning connects the work, people, dependencies and timelines.

Delivery tracking tells you what is actually happening.

Delivery control brings those views together so that you can see where the programme is and make informed decisions when things change.

That is ultimately what I want programme planning to achieve.

Not another report.

Not another spreadsheet.

Not another status meeting.

A reliable view of where we are, where we are going, what could affect the outcome and what decisions need to be made.

After working across complex technology and transformation programmes, I have come to see programme planning as much more than a planning activity.