When delivery gets harder, don't add more process

When delivery starts to feel harder, the instinct is often to add something. Another meeting, another checklist, another approval or another status update.

Sometimes that is exactly what is needed. But often, the problem is not that there isn't enough process. It is that something in the system around the work is not working as well as it should.

People might be unclear on why they are doing something, decisions might not have a clear owner, or teams affected by a change might be brought in too late. Information can be spread across too many places, or everyone might already be stretched, leaving little room to respond when something does not go to plan.

Adding more process can make these problems worse. It can add another layer without addressing the reason the work is getting stuck in the first place.

Look at the system around the work

Good delivery is rarely just about whether a team can execute. The work sits inside a wider system of people, decisions, dependencies, processes and expectations, and when something is not working, the problem can sit anywhere within that system.

That is why I have become increasingly interested in the conditions around delivery. Before asking, how do we make this process better?, I think it is often more useful to ask, what is making this harder than it needs to be?

That question tends to lead somewhere more useful. It might reveal that a team does not have enough clarity to make good decisions, that a downstream team is being asked to prepare for something they had no involvement in shaping, or that the organisation has taken on more change than it currently has capacity to absorb.

These are not always problems that need another process. They need a better understanding of what is actually getting in the way.

I have built three tools that each look at a different part of this system. They are designed to be used in sequence, though not every piece of work needs all three.

01: Start with clarity

One of the biggest sources of delivery friction is not knowing what we are trying to achieve. Teams can be busy, plans can be detailed and work can be well organised, yet people can still be unclear about the problem they are solving, the outcome they are aiming for or how decisions should be made along the way.

This creates a particular kind of uncertainty. People start filling in the gaps themselves, different teams make different assumptions, decisions get revisited and priorities shift without everyone understanding why. Progress becomes harder to judge because there is no shared reference point for what good looks like.

Clarity does not remove uncertainty. It gives people enough context to navigate it.

➡️ This is why I have built the Delivery Clarity Check. It is designed to help identify where a piece of work lacks the clarity needed to move forward confidently. The aim is not to produce another score, but to identify where a conversation needs to happen.

02: Know what you are dealing with

Clarity tells you whether a piece of work is defined enough to move on. It does not tell you how much coordination that work actually needs.

There is another trap that appears as organisations grow. We start to create processes to protect against the things that have gone wrong before. A release caused an unexpected problem, so we add another approval. A team missed an important stakeholder, so we add another meeting. Something went wrong after launch, so we create a longer checklist.

Over time, the process grows.

The problem is that not every piece of work carries the same level of risk, complexity or organisational impact. A small change and a significant strategic launch should not necessarily move through the same pathway, and good operating systems should help people understand the difference.

➡️ This is why I have built the Release Impact Classifier. It is designed to help teams determine how much coordination a release actually needs, rather than automatically applying the same level of governance to everything.

03: Check whether you are ready

Knowing how much coordination a release needs is still only part of the picture. A change can be well defined and well scoped, and still struggle because the organisation around it is not ready.

This is particularly easy to miss when we focus on the change itself. We ask whether the scope is right, whether the communication is ready and whether the plan is complete, but have we asked whether the people who will actually live with the change have had a chance to prepare?

Is there someone clearly accountable? Do people understand what is changing and what it means for them? Is it clear who can make a decision when something needs to shift? Have downstream teams been involved early enough? And if the change does not land as expected, does anyone actually have the capacity to respond?

➡️ This is the thinking behind the Change Readiness Check. The goal is simple: is your organisation ready for what is coming, or is the way you work the risk? These are organisational questions, and not just project tasks.

How the three fit together

Each of these questions builds on the last. The Clarity Check asks whether the work is defined enough to move on. The Release Impact Classifier asks how much coordination it actually needs. The Change Readiness Check asks whether the organisation around it is ready to absorb it.

Not everything needs all three. A small clarification might only need the first. A significant release might move through all of them, in that order, before it ever ships.

The point is not to have less process

I am not against process. Good process should make expectations clearer, reduce cognitive load, protect important decisions and help teams work consistently.

The problem is process that exists without a clear purpose. Process should make things easier. It should help people know what matters, who needs to be involved, what decisions need to be made and what happens next. If it is consistently creating more work than value, it is worth asking why it exists.

The solution shouldn't always be to remove it. Sometimes it needs to be simplified, or moved earlier or later. Sometimes the problem is not the process at all, but the missing clarity or ownership around it.

This is why I think good operating systems are less about designing the perfect process and more about understanding where people are experiencing friction.

Diagnose before you design

I'm not interested in adding process for the sake of looking organised. I am much more interested in understanding what is actually happening and where the system around the work is making things harder than they need to be.

That is the approach I am trying to build into the tools I create. They are not more frameworks for the sake of having frameworks. They are practical ways to pause, understand what is happening and make a better decision about what the situation actually needs.

You can find all three, and the thinking behind them here.

For me, that is the point of good delivery systems. They should create enough clarity and structure for people to move confidently, without creating unnecessary work around the work.