When to Fix a Process and When to Eliminate It

When a process is causing problems, the default response is to fix it. Add a step to catch the errors. Build a check into the workflow. Assign someone to review the output before it goes further. These interventions feel productive because they address the visible symptom. But they frequently make the underlying problem worse by adding complexity to a process that should not exist in its current form, or perhaps should not exist at all. Before spending time or money on fixing or automating any process, the more useful question is whether fixing is the right response — or whether eliminating would serve better.

The cost of fixing the wrong things

Every process that exists in an organisation carries overhead: the time to execute it, the management attention to maintain it, the systems that support it, and the errors it generates when it fails. A broken process that is fixed still carries all of this overhead. It is now a less broken version of a process that might not have needed to exist. Over time, accumulated fixes on accumulated processes produce organisations that are extraordinarily complex to run, where enormous effort goes into maintaining processes whose original purpose has been overtaken by events.

This is one of the most common findings in our operational diagnostics. Businesses that have grown quickly accumulate processes the way they accumulate any resource — fast, and without always stopping to ask whether what they are adding is still serving its purpose. A process that made perfect sense at fifteen people, built around the constraints and capabilities of that moment, often remains in place at sixty people unchanged, even as the organisation has developed the scale and tools to approach the underlying need completely differently.

The elimination test

Before deciding whether to fix a process, apply an elimination test. Ask what would happen if this process simply stopped tomorrow. Would the underlying need go unmet — meaning something genuinely important would fail to happen? Or would the organisation find other ways to address it, ways that have already emerged informally and rendered the formal process redundant? Or, most revealing of all, would nothing important change at all?

The third answer appears more often than people expect. Processes persist long after the need they were built to address has changed or disappeared. They persist because stopping a process requires an active decision and no one has made one, while continuing it requires only inertia. The elimination test forces the active decision that inertia prevents.

When fixing is right

Fixing is the right response when the process addresses a real, current need, the need cannot be better addressed by a different approach, and the process is sound in design but flawed in execution. Execution flaws — steps that are inconsistently performed, checks that happen too late, handoffs that are unclear — are well served by redesign that strengthens what exists. These are the cases where investment in process improvement directly serves the underlying purpose.

Fixing is also appropriate when a process is on a trajectory of increasing importance — when the volume it must handle is growing and the current design will not scale. In this case, redesigning for scale before the breaking point is far less expensive than fixing under pressure after it. The distinction here is between a process that is temporarily inadequate and one that is fundamentally unnecessary.

When eliminating is right

Elimination is right when the process exists primarily to compensate for a different problem — when it is a workaround rather than a genuine value-creating activity. A reporting process that exists because two systems do not talk to each other disappears when the integration is built. An approval step that exists because a role lacks clear authority disappears when authority is explicitly assigned. A checking process that exists because an upstream step is unreliable disappears when the upstream step is fixed. In each of these cases, fixing the downstream process is the wrong intervention. Eliminating the cause makes the downstream process unnecessary.

Elimination is also right when the process was built for a scale or context that no longer exists. Processes designed for a fifteen-person team, a previous technology stack, or a customer base with different needs should not be carried forward merely because they were once necessary. A periodic review — at least annually, and whenever the business undergoes significant change — that asks of each major process whether it still serves its original purpose, and whether its original purpose is still relevant, keeps the operational environment from accumulating processes that have outlived their usefulness. This review is not bureaucracy reduction for its own sake. It is the discipline that keeps the organisation able to run clearly and scale without carrying the full weight of every decision it ever made about how to operate.