Rolling out a new system without the team reverting

The most expensive sentence in operations is “that’s the way we’ve always done it”. It is rarely said angrily. It is said politely, often by the most diligent person on the team, and it shuts down conversations that should have happened years ago.

Every internal process has at least one step that exists because somebody, at some point, needed it to exist. The need may have been real. The need may also have evaporated three reorganisations, two system migrations and a chief executive ago. The step survives because nobody has been given permission to remove it, and because removing it feels disproportionate to its individual cost.

This is how an organisation accumulates friction. Step by step, over years, each one defensible in isolation, the aggregate quietly enormous.

Where the inertia comes from

It is rarely laziness. It is usually one of these.

The original reason is long gone

The form has a column for “diocesan reference number” because in 2009, the diocese still required it on paper submissions. The paper submissions stopped in 2014. The column is still on the form, and three minutes a week goes into filling it in for a system that no longer reads it.

One person remembers it going badly last time

A spreadsheet got emailed to the wrong recipient in 2018. Since then, every spreadsheet leaves the office only after being printed, signed, scanned and re-attached. Nobody can quite articulate why — it is just the process. The original incident is forgotten. The control survives.

Nobody owns the process

The step happens in a workflow that crosses three teams. Each team thinks one of the other two owns it. Asking to change it requires getting permission from someone who is not sure they have the authority. The default is to leave it alone.

Changing it would imply somebody was wrong

The person who set up the process is still in the building. Suggesting that the process should be removed feels like criticism. It is gentler to let it stand.

The cost is too small to argue about

Each instance takes two minutes. Two minutes is not worth a meeting. So the conversation never happens, even though two minutes a day for ten people for ten years is six months of full-time work.

None of these are unreasonable on their own. They compound.

The audit that finds the wins

The single most useful exercise for a team that suspects it has accumulated drag is a process audit. Not a consultant exercise. A morning, with the team, and a whiteboard.

The format is simple. For each recurring task the team does, ask three questions:

1. Why do we do this? Not “because it is on the checklist”. The substantive reason. If nobody can answer, write “unknown”.
2. What would happen if we stopped tomorrow? Specifically. Not “something would go wrong”. Which thing, in which week, to whom.
3. Could the system do it instead? The system being the official one, not a spreadsheet next to it.

Roughly a third of the items will collapse under question one. Another third will turn out to have weaker consequences under question two than the team assumed. The remaining third are real, and the question is whether the system can take them on.

That third question is the interesting one, because it is the question most operations teams have stopped asking.

The case for customisation

Off-the-shelf software is fast to deploy and slow to fit. A SaaS product comes with a model of how the work is supposed to happen, and the team is expected to mould itself to that model. For a lot of work this is the right trade: standard problems get standard tools, the price is low, the maintenance is somebody else’s.

For the work that defines an organisation, the trade is less obvious. The cost of moulding the team to fit the tool, over the lifetime of the system, frequently exceeds the cost of building a tool that fits the team.

The reason this is not more widely understood is that the cost of moulding is invisible. It shows up as:

• Steps that exist because the tool requires them, not because the work requires them.
• Workarounds that exist because the tool does not quite fit, and the team has built a parallel routine around the gap.
• Shadow spreadsheets that hold the data the tool was supposed to hold but cannot.
• Reports that look right at first glance but contradict the operational record.

None of these have an invoice attached. They have a time tax, distributed across the team, paid every working day.

What customisation buys

The promise is not bespoke for the sake of it. The promise is the opposite of “that’s the way we’ve always done it”.

A team that is willing to invest in changing its system is also willing to ask the questions in the audit above — because asking them has consequences. The two go together. A team that has built and adjusted its own system has a fundamentally different relationship with its processes. Steps that were never questioned become questionable. The system grows or shrinks to match the work, not the other way around.

The cost of this is real. Custom systems need ongoing care — small adjustments, support work, an engineer or partner who knows the codebase. That is the price. The price is paid in money rather than in distributed time tax, and the money is, by a long margin, smaller.

The discipline that makes this work

Customisation has its own failure modes. A team that says yes to every change request ends up with a system that nobody else can support, that is shaped around the preferences of three loud people, and that requires constant maintenance to keep upright. Bespoke is not automatically good.

The discipline that makes it work is closer to editing than to building.

• Every change is also a conversation. Before a new field is added, the team asks whether an existing field should be removed.
• Most requests are declined. Not all change is good change. The best operational systems get smaller as often as they get bigger.
• The system is allowed to push back on the work. If a request would make the system materially harder to maintain, the right answer is sometimes to change how the work is done, not how the system is shaped.
• Customisation is itself periodically audited. Custom features that turned out to be unloved should be retired, just like inherited processes.

This is unglamorous work. It is also the work that separates a custom system that keeps its value over a decade from one that ossifies into a different kind of legacy.

The starting question

If your team is ever asked “why do we still do it this way?” and the honest answer is some version of “we always have”, that is a flag. Not necessarily a flag that the process is wrong. A flag that the process has not been examined in a while, and the cheapest thing to do this week is to examine it.

The audit takes a morning. The list of changes it produces is usually two pages. The first two changes from that list, made within a fortnight, repay the cost of the audit several times over — before anyone has touched a line of code.

That is the place to start. Customisation comes afterwards, when the audit has revealed what actually needs to change, and the team has the appetite to make it.

If you would like a hand running the audit, we are happy to spend a morning with the team. The first hour usually surfaces three things worth retiring; the second hour produces the short list of what the system should do instead.