There’s a point in most change programmes where the focus turns to delivery. And that’s usually when the pressure starts to build around getting everything ready for day one.

It’s well intentioned. People want things to land properly. No one wants gaps or issues at launch. But trying to get everything over the line at once often creates more risk, not less.

What’s actually going on

When I hear that push to “get everything ready”, it’s rarely at the start of a programme. It tends to come later, when the work is closer to being real. 

This is usually the point where a programme moves into what I tend to think of as the ‘messy middle’. You’re far enough in that things are starting to overlap, but not far enough through that anything has properly settled.

Workstreams that felt quite separate at the start begin to connect up, and earlier decisions start to carry a bit more weight because you can see where they lead, not just what they solve. 

It’s also the stage where people are being pulled in a few directions at once. They’re still doing their day jobs, but they’re also being asked to contribute to decisions that feel more visible and, in some cases, are a bit harder to make quickly.

From the outside, it can look like things are slowing down, but when you’re in it, it usually feels more like everything is happening at once.

Why pushing for more doesn’t always help 

At this stage, the pressure often isn’t about adding more. It’s about getting everything to a point where it feels “ready”. The closer you get to launch, the more visible the gaps become. Small issues stand out more, and there’s a natural instinct to try to resolve as much as possible before day one.

That’s where the push for completeness can start to work against delivery.

Teams focus on closing every gap, even when some of those gaps don’t need to be resolved immediately. Work that could have been phased gets pulled forward. Time that was needed to stabilise what’s already in place gets spread more thinly.

The result is often a series of late-stage pushes to get things finished, rather than making sure what’s already there is working as it should.

It can mean going live with a lot in place, but not all of it as robust as it needs to be.

What tends to work better

In my experience, it’s more useful to pause briefly and focus on what actually needs to be true at launch.

  • What needs to be in place for the programme to work on day one?
  • What can be phased in shortly after?
  • What are we trying to complete now that doesn’t materially affect go-live?

Being clear on those points makes it easier to prioritise properly. It also creates space to acknowledge where things won’t be finished at launch, rather than relying on last-minute effort to get everything over the line.

In practice, the programmes that land well are usually the ones that focus on getting the core elements working as they should, rather than trying to complete everything at once. None of this reduces momentum; it actually makes it more sustainable.

A different way to think about readiness

There’s often an assumption that success means everything being fully complete at launch. In reality, it’s more useful to be clear about what “ready” actually means.

Early in a programme, that definition can feel quite broad. But as delivery gets closer, it becomes more important to focus on what needs to work on day one, rather than what could be included.

Without that clarity, it’s easy for teams to keep pushing towards a version of “ready” that includes everything, and that’s usually where programmes start to feel under pressure towards the end.

The risk isn’t just the extra effort; it’s that time and attention get pulled away from making sure the core elements are working properly.

The programmes that hold up best are usually the ones that are clear about their priorities, and willing to draw a line. They focus on what needs to be stable at launch, and plan for the rest to follow. That doesn’t lower the standard, it protects it.

In most cases, trying to achieve perfection for day one doesn’t improve delivery. It usually creates more problems than it solves.