The spreadsheet graveyard

Nobody sets out to run a CI programme on spreadsheets. It happens by accretion. I have seen many times how organisations start with one tracker for the first project, a separate log because ideas needed somewhere to land and another tab because the first one got too crowded…

None of this is a bad decision within the moment because each piece does its job perfectly well. The problem only shows up later, once all of it has become the record-keeping system for the whole programme.

It's an easy trap to miss from the inside, because at no point does it feel like a decision. Nobody within an organisations sits down and chooses to run a multi-site improvement programme out of three spreadsheets and an inbox. It arrives one tracker at a time, each one a perfectly sensible fix for a problem in front of someone that week, until the sum of all those fixes is the infrastructure the whole thing depends on.

In the second episode of Diary of a CI Leader, Chris Dando, Founder of OpX describes exactly this pattern from a conversation last week with someone leading CI across a few thousand people and fourteen sites.

A spreadsheet, a log for ideas, and nothing joining them up

Chris Dando explained how her first site had gone well. The plan was the sensible one: prove it in a small space, evidence the results to senior leadership, then replicate. What she could see, and what Chris zeroed in on, was what that first success had actually been built on.

“The challenges here lie in only having a small number of experts to facilitate the scaling. They lie in the way that the experts have deployed improvement — fragmented tools. There's a spreadsheet, there's a log for ideas over there, and it's all very disparate and unconnected.”
— Chris Dando

None of those tools is the problem on its own, especially as a spreadsheet is a good way to track one project and a log is a fine way to catch ideas. What's missing is anything connecting them, so the picture of what's actually happening across the programme exists only in the heads of the small number of people holding it together by hand.

The hidden work of holding it together

That's the part that doesn't show up on a tracker: the manual reconciling. When a spreadsheet is used, the CI lead has to check the ideas log against the spreadsheet, or chase an update that lives in someone's inbox. They then have to rebuild the same view of progress every time somebody senior asks for it. It works, but only because a handful of people are quietly doing that stitching-together every single week, which is exactly why it was never going to survive being asked to run at five sites instead of one.

“She's got the foresight to realise that this is just going to break as soon as she goes to site two, site three, site five. It's going to fall over.”
— Chris Dando

Break is the right word here because fragmented tools don't get gradually harder to manage as a programme grows. They typically hold, right up until the moment the manual reconciliation that was quietly propping them up can no longer keep pace, and then they fail all at once.

What it costs when it breaks

The cost isn't just the rework, but it is instead what happens to everyone watching. A programme that visibly stumbles when it tries to grow doesn't just lose a quarter to firefighting but loses the very thing that got it this far in the first place.

“If it breaks, what does that mean? Well, it means people at all layers lose confidence. And if they lose confidence, they distance themselves from it. So you can forget scaling CI — it's actually going to shrink.”
— Chris Dando

That's the sting in the tail because a fragile spreadsheet setup doesn't just fail to scale. When mishandled, it actively reverses the momentum a good first site built. Leadership who backed the pilot start to wonder if the wobble at site two says something about the method, rather than about the tooling underneath it. The practitioners on the ground, who did the hard work of making site one succeed, watch site two struggle and quietly conclude that this doesn't travel. Neither conclusion is really true. But both are entirely reasonable reactions to watching a spreadsheet-and-inbox system buckle under more weight than it was ever built to carry.

See how OpX replaces the spreadsheet graveyard with one system

Using a spreadsheet versus running improvement through spreadsheets

That's the actual distinction worth making. Using a spreadsheet to track a project is fine and it's what spreadsheets can be used for, but running an entire improvement programme through a spreadsheet, a separate ideas log, and whatever else has quietly filled the gaps between them, is a different thing altogether, and it's rarely a decision anyone consciously makes.

Every other function in the business settled this question a long time ago. Nobody runs finance out of a shared spreadsheet, or sales out of an inbox. Improvement is often still the exception and not because spreadsheets are the wrong tool, but because nobody ever decided they'd become the infrastructure for the whole programme. They just did.

This is not an argument for banning spreadsheets, and it isn't a criticism of the people relying on them as they're usually the ones who built something work by sheer effort, with nothing better on offer. It's an argument for noticing the moment a personal workaround has quietly turned into organisational infrastructure, and treating that as the actual milestone it is. That's usually somewhere around the first successful pilot and exactly the point at which the conversation turns to replicating it elsewhere.

A spreadsheet and a log for ideas can carry one team a long way. What they can't do is become the system of record for a whole organisation without someone paying for it in hidden hours and eventually, in a rollout that quietly falls over at site two. That's the gap OpX was built to close.

Start with myOpX