The Mirror Trap: Why New Software Doesn’t Fix Old Drift

When your organisation decides it needs new software, the first thing most teams do is document what they currently do. They map the processes. They capture the workflows. They list the reports they run every month. Then they hand that document to a vendor and ask: Can your system do this?

It feels thorough. It feels responsible. It is, quietly, the first mistake.

You are not selecting software. You are selecting a mirror.

When requirements are built from current practice, you are not designing for what your organisation needs. You are photographing what it has become — habits, workarounds, and all. The software that wins the selection is the one that most faithfully reflects your existing constraints back at you.

And then you go live. And the constraints come with you. Repackaged. Faster. More expensive to change.

How the drift works

No organisation deliberately designs bad processes. Drift doesn’t announce itself.

A local council adopts a manual approval step because, years ago, a project went over budget and someone got burned. The step made sense then. Over time, the person who added it leaves. The reason is forgotten. The step remains. New staff learn it as how we do things here. It becomes invisible — not because it’s hidden, but because it’s normal.

When the time comes to select a new system, the team documents the approval step. The vendor accommodates it. The system is configured around it. The software goes live. The unnecessary step, now embedded in code, will cost $15,000 to change.

This is how organisations buy software that automates their dysfunction.

The lens problem

What makes this hard is not ignorance. It’s proximity.

The people who know your systems best — the ones doing the day-to-day work — cannot easily see the drift. They are inside it. Their expertise is in navigating the current constraints, not questioning whether those constraints should exist. They see the world through the lens of what your organisation currently does, which means they don’t always see why it does those things, or whether those reasons still hold.

This is not a criticism of operational staff. It is a structural reality. Day-to-day visibility and executive-level visibility are not the same thing. One sees how the work moves. The other needs to see whether the work is moving in the right direction.

When software selection is handed entirely to the operational layer, you get operational-layer requirements. Legitimate. Detailed. And often anchored to problems that could have been solved before the system was selected.

What the selection process should be asking

The question is not: Can this system do what we currently do?

The question is: What does this organisation need to be capable of — and is what we currently do actually the right path to get there?

That distinction requires someone to pause before the requirements are written. To ask why the current process exists. To surface the constraints that were once real and are now just habit. To separate the work that creates value from the work that exists because no one has stopped to question it.

This is not a technology conversation. It is a leadership conversation. And it needs to happen before the vendor briefing, not after.

The cost of skipping it

Organisations that go into selection without this clarity don’t necessarily choose bad software. They often choose perfectly adequate software. The failure is subtler: the new system is configured to preserve what should have been redesigned. Two years post-go-live, the complaints begin. The system is slow. Inflexible. Doesn’t do what they need. The vendor gets blamed.

But the vendor built what they were asked to build.

The problem was upstream. It was in the requirements. It was in the assumption that documenting current practice was the same as understanding genuine need.

What this means for you

Before your organisation writes a single requirement, before you invite a vendor to demonstrate, ask your executive team one question: Are we selecting software for the organisation we are, or the organisation we need to become?

If you can’t answer that with confidence, the selection process hasn’t started yet.

The technology decision is the last decision. The first decision is what you actually need — and why what you’re currently doing isn’t already delivering it.

That clarity is worth more than any software feature list.

SP Singh is an independent ERP advisor based in Perth, WA. He works with executives in local government and mid-sized organisations to provide oversight and direction on technology programs — before, during, and after go-live. bhaniconsulting.com