More activity doesn't mean more progress.
There is a particular moment in a project when everybody starts feeling better. The workshops have happened.The walls are covered in Post-its.
Research has been conducted. Stakeholders have been consulted. Teams have been interviewed. Someone has created a Miro board large enough to require its own postcode.
And now there is a deck. A very large deck.Everyone has been extremely busy.
The uncomfortable question is:
What do we understand now that we didn't understand before? Because activity and progress are remarkably easy to confuse.
Busy has a reassuring quality.
Activity is visible. You can schedule it. Count it. Photograph it. Put it into a project plan.
12 stakeholder interviews.
4 workshops.
387 survey responses.
63 slides.
1 final report.
It looks substantial. And all of those things can be incredibly useful. But they're inputs not outcomes.
Twelve interviews don't automatically produce twelve interviews' worth of insight. A workshop isn't successful because twenty people attended it. Research isn't valuable because there is a lot of it. And a 100-page strategy isn't more strategic than a ten-page one simply because it's heavier.
The value is in what became clearer because we did the work.
We'd rather leave something out than do it for theatre.
This can set us apart from the rest. If we don't think a workshop is necessary, we'd rather not run one.
If six interviews have revealed something worth investigating, we don't automatically conduct another fourteen because the proposal said twenty.
If a question has already been answered, we'd rather move to the next one. And if a 15-page document can make the decision clearer than a 70-page report, we'd prefer the 15 pages.
That's not about doing less work. It's about making sure the work does something. There is enough performative busyness inside organisations already and we don't need to add more.
Sometimes progress means stopping.
This is the part that doesn't fit particularly neatly into a Gantt chart. A project starts with a proposed solution. Everyone assumes the job is to work out how to deliver it.
Then something in the evidence changes the picture. Maybe customers don't actually want the thing being designed. Maybe staff have already invented a better workaround. Maybe the process everyone wants to optimise exists only because of a decision made six years ago that nobody has questioned since. Maybe three teams are doing slightly different versions of the same thing. Or perhaps the problem simply isn't where everyone thought it was.
At that point, progress might mean saying:
Stop.
Not because the project has failed. Because it has learned something.
That's progress too.
The question matters more than the machinery around it.
We like methods.
Research matters. Workshops can be brilliant. Journey maps can expose things that were previously invisible. Prototypes let people encounter an idea instead of discussing it endlessly. Data can challenge assumptions. Good facilitation can completely change a conversation.
A method is useful because of what it helps us see, decide or change. Not because it appears on a consultancy methodology diagram. That's why we don't want every project we undertake to look the same.
One problem might need three weeks of research. Another might need three conversations and access to the right data. One might require a room full of people. Another might require somebody to sit quietly and watch what actually happens.
The problem gets to decide. Not the process.
And sometimes the deliverable isn't the point either.
This is perhaps the easiest trap of all. The report gets delivered. The presentation goes well. Everyone agrees with the recommendations.
The invoice gets paid. The PDF joins the other PDFs.
And six months later, remarkably little is different. Technically, the project was completed, but was anything actually accomplished? We think there's a useful distinction between finishing the work and changing something. The document matters if it helps someone make a decision. The research matters if it changes what the organisation understands. The workshop matters if something happens afterwards that wouldn't otherwise have happened. The strategy matters if it changes where people put their attention, money or effort.
Otherwise, we've simply produced evidence that a project took place.
So what does progress look like?
Sometimes it's something big.
A redesigned service.
A different strategy.
A simpler customer journey.
But often it's quieter than that. A decision that can finally be made and something complicated becoming understandable.
Two teams realising they're solving the same problem separately.
A process losing four unnecessary steps. A question nobody had thought to ask or an assumption everybody held turning out not to be true. Or most importantly, an organisation deciding not to do something it had been preparing to spend a great deal of money doing. Those things don't always produce impressive photographs.
They can produce impressive consequences. And that's the distinction we're interested in.
Because at the end of a project, we'd rather be able to answer a much harder question: