Technology Isn't the Problem. The People Making the Decisions Are.

I've lost count of how many times I've heard someone tell me their business needs a new IT system.

Their current software is rubbish, employees aren't using it properly, information is difficult to find or the business has grown and the technology apparently hasn't kept up.

Sometimes they're absolutely right. The software is outdated, poorly supported or no longer capable of doing what the business needs.

But sometimes, when you start asking a few questions, you discover the system itself isn't the real problem.

No one has agreed on how the business should operate. Different departments have developed their own ways of doing things, managers have different expectations and employees have been left to work around processes that don't make sense.

Yet somehow, the proposed solution is to spend a considerable amount of money on another piece of software.

I've worked in technology for long enough to recognise how attractive that idea can be. Buying something new feels like progress. There's a project to announce, a supplier to appoint and a date when everything is supposed to be better.

It's far less exciting to admit the business might need to change how it works, especially when the people running it have created or tolerated some of the problems.

But I've become convinced that a surprising number of technology problems are actually management problems that somebody hopes a computer will solve.

Until businesses become more comfortable recognising that distinction, they'll keep spending money fixing the wrong things.

We've got very good at buying solutions before understanding the problem

One of the first things I want to understand when a business approaches me about changing its technology is what it's actually trying to achieve.

Not which software it wants to buy or which supplier has given the most impressive demonstration. I want to know what isn't working today and what the business expects to be different afterwards.

That sounds obvious, but it's surprising how quickly conversations move towards products rather than outcomes.

Someone has seen another company use a particular system, attended an event where a supplier demonstrated something impressive or read that artificial intelligence will transform an industry. Suddenly, the business has decided it needs that technology too.

Exploring new ideas is fine. Some of the best improvements come from recognising that another organisation has found a better way of doing something.

The difficulty starts when the decision to buy is made before anyone has established whether there's a problem worth solving.

Take a business struggling to manage customer enquiries. Messages get missed, customers chase updates and staff complain they're constantly interrupted.

Sure, a new CRM system might help you fix all this if the current setup doesn't give people visibility into outstanding work.

But I'd want to understand why enquiries are being missed in the first place. Is there a clearly defined process for dealing with them? Does somebody own each enquiry? Are employees expected to respond while also handling other responsibilities? Does management know what a reasonable response time should be?

If nobody can answer those questions, buying a new system might be a more expensive way to lose track of the same enquiries.

The same applies to businesses looking to improve communication. They might invest in Microsoft Teams, a new project management platform or another collaboration tool, but if managers don't communicate decisions clearly and nobody knows who's responsible for what, software won't magically create clarity.

It might make the confusion considerably easier to distribute.

I've always believed technology should serve how a business needs to operate, not become something the business has to organise itself around simply because somebody liked a demonstration.

Of course, introducing better technology can be an opportunity to change outdated working practices. Sometimes that's precisely why a business should invest in it.

But those changes need to be intentional. They shouldn't come as an unpleasant surprise once everyone has been given a login.

A successful installation isn't necessarily a successful project

This is one distinction I wish more business owners understood.

From a technical perspective, a project can be completed successfully. The software is installed, employees can access it, information has been migrated and the supplier has delivered everything specified in the contract.

Yet six months later, the business may be no better off.

Staff still maintain separate spreadsheets, managers keep asking for information by email and someone has invented a workaround because the new system doesn't reflect how their work actually happens.

The technology might be functioning perfectly. That doesn't mean the investment has delivered what the business wanted.

I've managed technology from inside organisations and now advise businesses from the other side of that relationship. Those experiences have taught me to judge a project by what the business was trying to achieve, not simply whether the technical work was completed.

If the objective was to reduce the time employees spend processing information, measure whether that time has actually reduced.

If the business wanted fewer errors, establish what those errors looked like before the change and whether they're happening less frequently afterwards.

If a new system was supposed to make information easier to access, ask the people who use it whether their jobs have genuinely become easier.

I'd also want to know whether the improvement has come at the expense of something else. Saving ten minutes in one department isn't particularly impressive if you've created an additional twenty minutes of work for somebody further along the process.

It's easy to concentrate on the part of a project that's visible and measurable. Licences have been purchased, devices deployed, training sessions delivered and the system gone live.

Those are milestones, but they don't necessarily prove success.

A new system should meaningfully change how the organisation operates. Otherwise, what exactly have you achieved beyond spending the money?

The people doing the work often know what management doesn't

When I want to understand why a business process isn't working, I find it useful to speak to the people who deal with it every day.

They usually have a very different perspective from the people who approved the system.

Management might believe employees are following a particular process because that's how it was documented. Employees know the process doesn't account for certain situations, takes longer than expected or requires information they don't always have.

So they've adapted.

They maintain their own spreadsheets, save information somewhere more convenient or ask a colleague to do something outside the agreed process because that's the only way to finish the job.

From management's perspective, those workarounds can look like employees refusing to use the systems they've been given.

Sometimes that is exactly what's happening, and businesses shouldn't automatically accept people ignoring established processes just because they prefer doing things their own way.

But I think managers have a responsibility to understand why people are working differently before deciding the answer is more training or a stricter policy.

A workaround can signal poor discipline, but it can also show the process itself doesn't work.

That's a distinction worth investigating.

I've worked in environments where technology has to support people doing very different jobs, from office-based staff to employees working on operational sites. What looks perfectly sensible when you're designing a process at a desk can be far less practical when someone tries to use it in the middle of a busy workday.

That's why I'd involve employees before choosing a replacement system, rather than asking for feedback after the contract is signed.

I'd want to understand which tasks take too long, where information gets duplicated, what regularly goes wrong and which parts of the current arrangements people have stopped using altogether.

Some of their suggestions might be impractical. Others might challenge assumptions management has held for years.

That's precisely why the conversations are worth having.

If you're going to spend money changing how people work, you should probably understand how they're working in the first place.

Sometimes the software is being blamed for decisions nobody wants to own

There's another part of this that businesses don't always like discussing.

Technology is a convenient thing to blame.

When something goes wrong, it's often easier to say the computer system isn't working than to explain why a process was badly designed, why nobody followed it or why management didn't address a known problem.

I've seen how quickly conversations can shift to what the software supposedly can't do, even when the real issue is that the business hasn't decided how to handle it.

Consider a company where different managers approve purchases in different ways. Some want every request to come through them, others let employees make purchases below an informal limit and another department has its own approval arrangements.

The business then introduces software to manage purchasing and expects the process to become consistent.

But consistent with what?

If management hasn't agreed on who can authorise spending, what the limits should be or how exceptions are handled, the software can't decide that on its own.

It can enforce rules once the business has decided what those rules are. It cannot resolve a disagreement that management has chosen to avoid.

The same issue appears in document management, staff onboarding, customer service and countless other business functions.

I've seen businesses invest in new systems expecting them to improve reporting, accountability or consistency, only to discover they're still dealing with exactly the same problems. But if management can't agree on what information it needs, who's responsible for what or how things should be done, I'm not sure what it expects the software to achieve.

That doesn't mean suppliers should be let off the hook when their products don't work properly or fail to deliver what was promised. But a supplier can only do so much when the business itself hasn't got its act together, and spending more money on technology won't fix that.

Employees don't resist every change. They resist changes that make their jobs worse

Whenever a technology project struggles, someone will eventually suggest employees resist change.

I've always found that explanation a little too convenient.

People can certainly get comfortable with familiar systems, and some will resist changing how they work even when there's a good reason to. I've encountered that throughout my career.

But I've also seen how easily businesses label perfectly reasonable concerns as resistance.

When employees say the new system is making their jobs harder, perhaps management should listen rather than accuse them of resisting change. If something that used to take five minutes now takes fifteen and nobody can explain what the benefit is, I'd say that's a perfectly reasonable thing to question.

Telling people to embrace change instead of addressing their concerns isn't good management. It's avoiding the problem.

If you ask someone to abandon a process they know and use a different one, they deserve to understand why. More importantly, the new arrangements should have been properly considered before they're expected to rely on them.

That doesn't mean every employee gets to veto a business decision. Sometimes a change is necessary even when it's unpopular, and management has to make that call.

But there's a difference between making a difficult decision and dismissing legitimate feedback because it challenges the project.

I also think businesses underestimate how much people worry about their ability to do their jobs when technology changes.

An experienced employee might be excellent at their work but less confident with unfamiliar software. If the new system is introduced badly, that person can suddenly feel as though years of experience count for very little.

A few training sessions aren't always enough, especially when someone is expected to keep up their normal workload while learning something completely different.

If managers struggle with the system themselves, employees notice.

Good change management means explaining what's happening, giving people enough time to learn and being ready to listen when something isn't working.

It's not particularly complicated in principle, but it requires leadership to stay involved after the launch announcement.

Why buying the cheapest option can become expensive

I've never believed that the most expensive technology is automatically the best choice.

Some businesses pay for sophisticated systems when a simpler product would meet their needs just as well. Equally, I've seen organisations try to save money on technology without fully considering the operational consequences.

The problem is rarely the price itself. It's the way the decision is evaluated.

A supplier quotes a monthly fee, management compares it with another proposal and the cheaper option looks attractive.

But what about the time required to implement it? Will existing information need to be transferred manually? Does the system work with the software the business already uses? How much training will employees need, and what happens if something goes wrong?

Can the business get its information out again if it decides to leave?

Those questions don't always appear neatly in the supplier's pricing table, but they can make an enormous difference to the real cost.

Businesses also need to consider the cost of doing nothing.

An ageing system might still function, but perhaps employees spend hours each month working around its limitations. It may rely on one person who understands how it operates, or the supplier may no longer provide the level of support the business needs.

Continuing to use that system isn't necessarily cheaper just because there's no new invoice to approve.

The sensible decision comes from understanding the total cost and the value the business expects to receive, not choosing whichever number looks most appealing at the bottom of a proposal.

And sometimes the right answer is to keep what you've already got.

I've never seen much sense in replacing technology purely because something newer has become available. If the existing system is secure, supported and meets the organisation's needs, you need a convincing reason to change it.

The money might deliver far more value elsewhere.

AI is giving businesses another opportunity to make exactly the same mistakes

We're seeing a new version of this problem with artificial intelligence.

Businesses are under pressure to show they're adopting AI, suppliers are adding AI capabilities to products, and employees are experimenting with tools that promise to save time.

There are genuinely impressive opportunities here, and I spend considerable time exploring how organisations can use AI sensibly.

But I've noticed how easily the conversation can begin with the technology rather than the problem.

A business wants to introduce AI because it believes competitors already are. Someone has watched a demonstration showing how quickly a task can be completed, and management starts calculating how much employee time it might save.

Those savings might be achievable, but I'd want to understand what's actually involved before treating them as a reason to invest.

If somebody uses AI to produce a report in five minutes instead of thirty, that sounds like a considerable improvement. But what happens next? Does another employee need to spend twenty minutes checking the report? Has the AI actually reduced the work, or just moved it somewhere less visible?

And if the report wasn't particularly useful in the first place, why are we celebrating how much faster we can produce it?

The same applies to AI meeting summaries, automated customer responses and systems that promise to make decisions on employees' behalf.

Before measuring how quickly the technology can complete a task, I'd establish whether the task needs doing, whether the result is good enough and what happens when the technology gets something wrong.

There are also obvious questions about information security, confidentiality and whether employees should be putting particular business or customer information into AI services.

But those considerations need to be part of a wider discussion about how the technology is supposed to improve the business.

I've delivered AI training and helped organisations think through acceptable use, and I try to avoid treating adoption itself as an achievement.

An employee using AI for ten tasks isn't necessarily more productive than somebody using it carefully for two.

I'd rather see a business identify one worthwhile application, introduce it properly and understand the results than announce an ambitious AI strategy without being able to explain what it's supposed to improve.

The technology is new. Buying a solution before understanding the problem certainly isn't new.

Leadership doesn't end when the contract is signed

One of the most frustrating things about technology projects is how quickly senior management can lose interest once they've made the initial decision.

There's considerable enthusiasm while suppliers are evaluated, demonstrations are held and budgets are approved.

Then the project moves into implementation, responsibility shifts to someone else, and the people who originally wanted the change become increasingly distant from it.

When problems emerge, it's treated as an IT issue.

But if the project requires departments to change how they work, managers to agree new responsibilities or employees to follow different processes, the IT team can't make those decisions independently.

They require somebody with the authority to change the business.

I've been an internal IT manager, managed infrastructure and support across different organisations and worked with businesses as an external technology adviser. The environments have changed, but the importance of having someone own the business outcome hasn't.

The technical team can explain what's possible, identify risks and implement the agreed solution. A good adviser should also challenge a proposal when it doesn't make sense.

But someone on the business side needs to decide what success looks like, resolve disagreements and ensure the organisation is prepared for the change.

Without that involvement, technology projects can become exercises in delivering whatever was originally requested, even when it becomes obvious that the original request wasn't quite right.

And I think managers need to be prepared to acknowledge that sometimes they made the wrong decision.

Nobody gets every technology investment right. Requirements change, products develop in unexpected ways, and organisations learn during implementation things they couldn't reasonably have known beforehand.

What matters is how the business responds.

If a pilot demonstrates that a proposed system isn't appropriate, changing direction isn't necessarily a failure. Continuing with an unsuitable project because too much money has already been spent is considerably harder to justify.

I've always thought it takes more confidence to admit something isn't working and correct it than to keep defending a decision simply because your name is attached to it.

What I'd want to know before approving the next technology investment

If a business owner asked me whether they should spend money on a new system, I'd want to have a proper conversation about what the organisation expects to achieve.

I'd ask them to explain the problem in ordinary language, without starting with the name of the product they've already decided they want.

I'd want to understand who experiences the problem, how often it happens and what it costs the business in time, money, customer satisfaction or unnecessary risk.

Then I'd speak to the people actually doing the work.

I'd ask what they think needs improving, what arrangements already work well and what they're worried about losing if the business makes the change.

From there, I'd look at the possible solutions. That might involve replacing the existing system, improving its configuration, introducing a different process or providing employees with better training.

Sometimes, the answer is that the technology is perfectly adequate and the business just needs to manage it properly.

I wouldn't rule that possibility out just because it doesn't require a new purchase.

I'd also want someone to agree on how the business will measure whether the change worked.

That doesn't need to involve a complicated reporting system. If the objective is to reduce the time it takes to process an order, establish how long it takes now and measure it again after the change.

If the aim is to reduce mistakes, identify which mistakes matter and how often they happen.

If management believes employees will benefit, ask employees whether that's actually true.

The UK government's Digital, Data and Technology Playbook makes a similar point when discussing technology projects: organisations should focus on user needs and the problem they're trying to solve rather than beginning with a specific solution.

It's guidance intended for public sector technology programmes, but the underlying thinking is just as relevant to a small business considering its next software investment.

I'd also be prepared to test the idea before committing to a full rollout. A small pilot can reveal process, data or employee-expectation problems that are much easier to fix before the whole organisation depends on the system.

Throughout that work, I'd want management to stay involved. There's little point agreeing the objectives at the beginning if nobody responsible for the business checks whether they're being achieved.

Sometimes the best technology decision is to stop buying technology

I enjoy technology. I've built my career around it, and I wouldn't be doing what I do today if I didn't believe it could make an enormous difference to how businesses operate.

I've seen the benefits of replacing outdated systems, improving infrastructure and introducing tools that make people's jobs easier.

But I also know that an impressive demonstration doesn't guarantee a useful result, and spending more money doesn't necessarily mean a business is moving forward.

Technology is often the easiest part of a difficult business decision because you can compare specifications, arrange demonstrations and get a quotation.

It's much harder to challenge the assumptions behind a process, tell managers they need to work differently or acknowledge that a problem has existed for years because nobody wanted to deal with it.

Those conversations don't come with a shiny new product attached, but they often matter most.

The next time somebody tells you the business needs a new IT system, ask them to explain exactly what isn't working before discussing what they want to buy.

And if the answer comes back to unclear responsibilities, inconsistent processes, poor communication or decisions nobody wants to make, the first thing that needs changing may not be the technology.

Because you can buy better software, faster computers and more sophisticated systems.

You can't buy your way out of bad management.

And if the people making the decisions aren't prepared to address that, the next system is going to inherit an awful lot of the problems you thought you were paying to get rid of.