Are we still solving the right problem?

Somewhere between identifying a problem and delivering a solution, it's surprisingly easy to lose sight of what we were trying to achieve in the first place.

Most business improvement initiatives begin with a straightforward problem. Customers are waiting too long for answers. Employees spend hours doing something that could be automated. Management struggles to get reliable information. Or perhaps a business has simply outgrown the processes and systems that once served it well.

Someone identifies the problem, a few conversations take place, and eventually a decision is made to do something about it. Then the project begins.

Requirements are gathered, stakeholders are consulted, technologies are evaluated, and project plans are developed. Teams are assembled, responsibilities are assigned, and everyone gets to work. All perfectly reasonable.

But as the project grows, something can gradually change. The conversation starts moving away from the problem that prompted the initiative and towards the increasingly complicated business of delivering a solution. Before long, more time is spent discussing functionality, architecture, deadlines and deliverables than the actual improvement everyone originally wanted.

The project becomes an objective. And that raises an interesting question: are we still solving the right problem?

When the solution becomes the focus

Consider a business that wants to improve the efficiency of its supplier payment process. Invoices take too long to process, employees spend considerable time capturing information manually, and suppliers regularly follow up on outstanding payments. Automating the process seems like a sensible solution.

The business evaluates different technologies, selects a platform and launches an implementation project. Months later, the new system goes live. Invoices are captured automatically, workflows have been configured, and the project is declared a success.

But what happens if suppliers are still waiting just as long to be paid?

Perhaps the delays were never primarily caused by manual data capture. Maybe invoices spend most of their time sitting in approval queues, or perhaps responsibilities between departments were never particularly clear. The technology may have eliminated hours of manual work without making much difference to the problem that originally prompted the investment.

From a project delivery perspective, everything may have gone according to plan. From a business perspective, however, the improvement may be far less significant than anticipated.

This isn't necessarily a failure of the technology or the people implementing it. It's often the result of gradually allowing the solution to become more important than the problem it was intended to address. And it happens more easily than we might think.

Activity and progress aren't always the same thing

Business projects have an enormous capacity to keep people busy. There are meetings to attend, documents to review, decisions to make, issues to resolve and milestones to achieve. Progress is measured, reported and presented. Everyone can see that work is being done.

But the amount of activity taking place doesn't always tell us much about the value being created.

A team might spend weeks developing a complicated new reporting capability when the real issue is that nobody trusts the underlying data. A business might invest heavily in automation when the process being automated probably shouldn't exist in its current form. Or an organisation might introduce artificial intelligence into a workflow without first establishing whether the workflow itself makes sense.

None of these are necessarily bad ideas. The technology might work exceptionally well. The difficulty arises when we become so focused on what we're building that we stop questioning why we're building it.

And once considerable time, money and effort have been invested, questioning the direction becomes even harder. Nobody particularly enjoys being told that something they've worked on for six months might not be necessary. It's understandable. We're human, after all. But continuing with an approach simply because we've already invested in it doesn't make the outcome any more valuable.

The importance of asking simple questions

There's a tendency, particularly in complex organisations, to assume that difficult problems require complicated solutions. Sometimes they do. Large businesses operate within complicated environments, and there are good reasons for many of the controls, systems and processes that exist.

But complexity isn't inherently a sign of quality. A solution doesn't become more valuable because it uses the latest technology, involves multiple platforms or requires an elaborate implementation programme. Its value comes from what it actually improves.

This is why some of the simplest questions can be the most useful ones to ask throughout a project.

What problem are we trying to solve? Who benefits from this change? Will it make someone's work easier, improve a decision or reduce a genuine business risk? If we removed this feature or activity, would the outcome be any worse?

These questions don't replace good project management, technical expertise or proper governance. They help ensure that all those things are being applied for the right reasons. They also create room for an important possibility: perhaps the best solution isn't the one we originally imagined.

Sometimes the answer is a new system. Sometimes it's a better process, clearer accountability or simply making existing information more accessible. Being willing to recognise the difference can save a business a great deal of time and money.

Knowing when to reconsider

One of the more difficult aspects of any project is knowing when to challenge an approach that everyone has already agreed upon. There will always be reasons to keep going. Budgets have been approved. Commitments have been made. People have put considerable effort into getting things to where they are. And changing direction can feel like admitting that something has gone wrong.

But projects are ultimately exercises in solving problems, not exercises in proving that our original assumptions were correct. As we learn more, we should expect our understanding of the problem to improve. Sometimes that means refining the solution. Sometimes it means removing unnecessary complexity. Occasionally, it means reconsidering the approach entirely.

None of those outcomes should automatically be seen as a failure. In fact, recognising that something needs to change before investing even more resources can be one of the most valuable contributions a project team makes.

The important thing is to create an environment where people feel comfortable raising those concerns. A project benefits enormously from having people who are prepared to ask whether an activity still makes sense, even when the answer might be inconvenient.

What does success look like?

Perhaps the most useful exercise during any business improvement initiative is to revisit the original problem periodically. Put the project plan aside for a moment. Forget about the number of requirements completed, the percentage of functionality delivered or how closely expenditure is tracking the budget.

Instead, consider what has actually changed. Are customers receiving better service? Are employees spending less time on unnecessary administration? Is management making better decisions? Has the business become more efficient, more resilient or better equipped to grow?

These are the outcomes that justified the investment in the first place. Of course, budgets, timelines and technical deliverables still matter. A project that ignores them is unlikely to be successful. But delivering a solution on time and within budget is only part of the story.

The real measure of success is whether the business is better off because of the work that was done. And every so often, it's worth reminding ourselves of that before getting caught up in the next meeting, milestone or exciting new piece of technology.