The Decision That Looked Perfectly Reasonable

The Finance Manager needed a better system for managing accounts. MYOB Acumatica made sense. The decision was scoped, justified, approved. Perfectly reasonable.

A few months later, the Marketing Manager needed a CRM. Salesforce made sense. Scoped, justified, approved. Also perfectly reasonable.

HR had its own problem — a disjointed system that wasn’t working. Employment Hero solved it. Scoped, justified, approved. Still perfectly reasonable.

The IT team noticed gaps where none of the systems quite covered what people needed. So they built custom apps to fill them. Reasonable. Practical, even.

Each decision, on the day it was made, looked like good management. A problem identified. A solution found. Budget approved. Done.

Then the bill arrived.

Not a single invoice. Something slower and more expensive.

No system talks to any other. Data gets entered twice, sometimes three times. Staff can’t get clean answers because the answer lives in three places — and none of them agree. Workarounds multiply. The custom apps that were built to fill gaps now create new ones. New staff join and can’t understand why the organisation runs on so much manual effort.

The complexity, as one operations manager put it to me recently, is unreal.

Nobody made a bad decision. Every decision made sense at the time. And yet the organisation is carrying a technology debt it didn’t budget for, can’t easily quantify, and has no clear path out of.

Here’s what actually happened.

Software selection got treated as a departmental problem. Finance had a finance problem. Marketing had a marketing problem. HR had an HR problem.

But software selection is never just a departmental problem. It is an architecture decision — one that determines how data flows, where truth lives, what integrations are required, and what the organisation will be managing for the next decade.

When we let departments solve their own technology problems independently, we aren’t being agile. We are outsourcing architecture to whoever has the budget and the loudest pain this quarter.

The organisation doesn’t feel this immediately. It feels it slowly — in the form of double-handling, in staff working around systems instead of through them, in reports that require three exports and a spreadsheet to produce a number that should be a single click.

The patterns I see repeatedly:

A new system gets selected because it solves today’s problem well. Nobody asks what it does to tomorrow’s integration landscape.

Implementation gets declared complete when go-live happens. Nobody asks whether the organisation has actually changed how it works — or whether staff are just working around the new system the way they worked around the old one.

Post-go-live governance gets dropped. The steering committee dissolves. The project team moves on. And six months later, the system is drifting away from how it was designed to operate — quietly, without anyone formally declaring it.

Change gets treated as an event. It isn’t. Change is a process that takes time, sustained effort, and deliberate resourcing to stick.

The cost of these patterns is not abstract.

It shows up in technology budgets that keep growing without a commensurate improvement in capability. It shows up in staff frustration. It shows up in executive decisions made on incomplete or unreliable data. It shows up in the next system selection — where the organisation is starting from a messier baseline than it should be.

None of this is caused by bad intent. It is caused by decisions that were each evaluated in isolation, when they should have been evaluated as parts of a whole.

The Finance Manager wasn’t wrong to want a better accounting system. But the question was never just: does this system solve Finance’s problem?

The question should have been: where does this sit in the organisation’s architecture? What does it connect to? Who governs it after go-live? What does success look like in two years, not two months?

Software selection is a collective architecture decision.

Project assurance during implementation is not optional.

Post-go-live governance and stewardship is not optional.

And change — real change, the kind that actually alters how an organisation operates — takes time, effort, and ongoing attention to stick.

These aren’t consulting talking points. They are the patterns visible in every organisation that skipped them and is now paying the compounding cost.

SP Singh is the founder of Bhani Consulting. He provides independent ERP oversight and advisory to executives in WA local government and Aboriginal corporations — helping them see what’s drifting in their technology programs before the cost of correction becomes too high. bhaniconsulting.com