I've spent more than 20 years working across technology, business transformation and building businesses. And if there's one thing I've learned, it's this:
You can't fix a business problem simply by buying better technology.
Yet that's exactly what organisations keep trying to do.
Processes are inefficient? Buy a new ERP.
Customer information is scattered everywhere? Implement a CRM.
Teams are drowning in manual work? Bring in automation.
Now it's AI. Apparently, every problem needs an AI solution.
Don't get me wrong. I'm a big believer in technology. I've built my career around it.
But I've also seen what happens when organisations confuse implementing technology with actually improving their business.
They're not the same thing. Not even close.
Going live isn't the same as getting better
Think about how most major technology projects are measured.
Was it delivered on time? Did it stay within budget? Did the system go live? Were the requirements met?
All reasonable questions.
But here's a better one.
Is the business actually better than it was before?
Because a project can tick every delivery box and still fail to achieve what it was supposed to.
I've seen how organisations can become so focused on implementing a system that the original business problem gets lost somewhere between the business case and go-live.
The project becomes about delivering the platform.
Not reducing costs. Not improving customer experience. Not making employees more productive.
Just getting the system live.
And once it's live, everyone celebrates, the project team moves on, and the business is left figuring out why things haven't improved as much as expected.
A successful implementation is worth celebrating. But it isn't the finish line.
It's the starting point for delivering the benefits.
Everyone's responsible. Which means nobody is.
Here's something that drives me mad about large transformation programs.
Everyone has a responsibility, but nobody seems to own the actual outcome.
IT owns the technology.
The project manager owns the plan.
The vendor owns the implementation.
Business units own their requirements.
And the steering committee gets a monthly PowerPoint presentation explaining why everything is amber.
Meanwhile, the underlying business problem is still sitting there.
The issue isn't necessarily that people aren't doing their jobs. Often, they're doing exactly what they've been asked to do.
The problem is that delivering individual pieces doesn't guarantee the whole thing works.
Someone needs to own the business outcome. Not just sponsor the project, attend steering committees or sign off on budgets.
Actually own it.
That means making decisions, resolving conflicts between departments and being accountable for whether the investment delivers value.
And that person needs the authority to change how the business operates.
Because if nobody can make those decisions, the technology team ends up trying to solve organisational problems with technical workarounds.
Which rarely ends well.
Stop automating rubbish processes
This one should be obvious. Yet it happens constantly.
A business has a complicated manual process.
Someone decides it needs to be automated.
The team starts gathering requirements, selecting tools and designing workflows.
But nobody stops to ask a fairly fundamental question.
Why are we doing half these steps in the first place?
Businesses accumulate processes over time.
An approval gets added because something went wrong five years ago.
A spreadsheet appears because two systems don't talk to each other.
An extra review step gets introduced because someone doesn't trust the data.
Eventually, all these workarounds become part of the official process.
Then along comes a shiny new system, and we faithfully reproduce the entire mess.
Congratulations. We've automated the inefficiency.
Possibly at considerable expense.
Before automating anything, I'd rather ask what the process is actually trying to achieve.
Which steps create value? Which exist purely because of old system limitations? Which could disappear entirely?
Sometimes the smartest technology decision is to remove a process rather than automate it.
And sometimes the best transformation project starts with a whiteboard, not a software vendor.
A project plan won't make a difficult decision for you
Technology programs love governance.
Steering committees. Working groups. Status reports. Risk registers. Decision logs.
I'm not against any of those things. They all have a purpose.
But there's a point where governance stops helping and starts becoming a substitute for leadership.
Two departments want different things.
A longstanding process needs to change.
Someone needs to give up control.
A decision will make one part of the organisation unhappy.
So what happens?
Another workshop gets scheduled.
The issue goes back to the steering committee.
More analysis is requested.
And the project team keeps moving, building around a decision nobody wants to make.
You can't project-manage your way out of a leadership problem.
At some point, someone needs to make the call.
It might not be the perfect decision. It might not make everyone happy.
But unresolved decisions create complexity, delay and cost.
And the longer they're avoided, the harder they become to fix.
One of the most valuable things a leader can do during transformation is provide clarity.
Not another status meeting. A decision.
Your employees know where the problems are
Here's an idea that shouldn't be controversial.
Before spending millions changing how people work, talk to the people actually doing the work.
Not just their managers.
The people processing orders, dealing with customers, reconciling information and finding ways around systems that don't do what they're supposed to.
They know where the problems are.
They know which steps are pointless.
They know which workarounds keep the business running.
And they often know why the process diagrams don't reflect what really happens.
Yet organisations can spend months designing a future operating model without properly understanding how things work today.
Then they're surprised when employees resist the new system.
Sometimes resistance is about people being uncomfortable with change.
But sometimes it's because the proposed solution genuinely makes their jobs harder.
That's worth listening to.
If the people who use the technology every day aren't involved in shaping it, don't be surprised when they find ways around it.
Stop measuring success by the go-live date
I understand why organisations focus on delivery milestones.
They're visible. They're measurable. They're easy to put in a report.
But going live doesn't tell you whether the investment was worthwhile.
A system can be technically excellent and commercially disappointing.
I'd much rather know:
- Are customers getting a better experience?
- Are employees spending less time on unnecessary work?
- Have costs, errors or delays actually reduced?
- Can the business respond faster?
- Are we doing things differently, or just using a different screen?
Those are the measures that matter.
And they should be agreed before the project starts, not invented afterwards to justify the investment.
If you can't explain how a technology project will make the business better, I'd question why you're doing it.
Start with the problem. Not the product.
I'm not suggesting technology is unimportant.
Quite the opposite.
The right technology can completely change what a business is capable of doing. It can remove constraints, open new opportunities and enable growth that wouldn't otherwise be possible.
But technology should be the enabler, not the starting point.
Before committing to a major transformation, I'd ask five questions:
- What business problem are we actually solving?
- Why does the business operate this way today?
- What needs to change beyond the technology?
- Who is accountable for the business outcome?
- How will we know whether things have genuinely improved?
If the answers aren't clear, I'd be very reluctant to start spending serious money on implementation.
Because the uncomfortable truth is that a new system won't fix unclear accountability, poor decisions, broken processes or ineffective leadership.
It might expose those problems.
It might make them more expensive.
But it won't magically solve them.
The best technology transformations don't start with technology.
They start with the business being willing to change.