Sales are falling, so the marketing budget is increased. Projects are delayed, so another project management tool is introduced. Employees seem overloaded, so more people are hired. Customer complaints are rising, so a new customer service system is purchased. These actions can look logical because they create movement, activity and the impression that something is being fixed. But in many cases, the organisation is not solving the real problem at all. It is solving the symptom.
The Difference Between a Symptom and a Root Cause
A symptom is what the business can see. A root cause is what is actually creating the problem. Falling sales, for example, are a symptom. The real cause could be poor pricing, slow response times, weak product positioning, a confusing buying process, inconsistent service or a lack of understanding of the target customer. Low productivity works in the same way. It may be caused by duplicated work, unclear responsibilities, excessive approvals, poor systems or employees spending hours manually transferring information between tools.
The visible problem is therefore usually only the starting point. Good business analysis asks: Why is this happening? And then often asks again: Why is that happening? That is where the real investigation begins.
Why Businesses Often Solve the Wrong Problem
One reason is that symptoms are easier to recognise than causes. If sales fall, the sales numbers are visible immediately. If a workflow is badly designed, however, the problem may be spread across several departments, systems and employees, meaning no single person sees the entire process.
Another reason is pressure to act quickly. Managers are expected to provide solutions, so saying, “We need to investigate the process first,” can feel slower than buying software, hiring staff or launching another marketing campaign. Yet acting quickly on the wrong problem can become far more expensive. A company might spend £30,000 on a new system only to discover that the real issue was not the software but unclear ownership of the process. Another organisation may hire more employees because the team appears overloaded, while the real problem is that staff are repeating the same manual tasks every day. The company increases capacity without fixing the reason why so much capacity was needed.
A Simple Example
Imagine a business where customers are complaining about slow service. The immediate conclusion might be: “We need more customer service staff.” But before hiring anyone, the business maps the process and discovers that enquiries arrive through three different channels, employees manually copy information into another system, and some enquiries require approval from a manager before a response can be sent.
The manager is often unavailable, so requests sit waiting. The real problem may therefore be duplicated data entry, fragmented communication, unnecessary approvals, unclear decision-making authority or poor workflow design. Hiring more people may reduce pressure temporarily, but the inefficient process remains. A better solution could be to redesign the workflow, connect systems and allow staff to resolve certain enquiries without managerial approval. The business may then discover that additional employees were never necessary.
The Cost of Treating Symptoms
Treating symptoms instead of causes creates several problems. First, the same issue often returns. A temporary solution may reduce the visible problem for a few months, but if the root cause remains, the symptoms usually reappear.
Second, organisations become more complicated. Each new problem can result in another tool, another approval stage, another report or another member of staff. Over time, complexity grows. Third, poor diagnosis wastes money. The business invests in solutions that were never designed to address the real issue, and the cost is rarely limited to the initial purchase. Training, implementation, subscriptions, maintenance and disruption to employees all add to the final cost.
Start With the Process
One of the most useful ways to investigate a business problem is to look at how work actually happens, not how the process is supposed to work. Map the process from beginning to end and examine who starts it, what information is required, which systems are used, where work waits, where information is entered more than once, which approvals are necessary, which tasks remain manual, where mistakes occur and who owns each stage.
This often reveals issues that are invisible in reports. A delay that appears to be caused by one department may actually originate much earlier in the process. A productivity problem may have little to do with employee performance and much more to do with the systems, approvals or workflows employees are expected to use.
Data Can Help — But Only If You Ask the Right Question
Business data is extremely useful, but numbers alone do not automatically explain what is happening. A dashboard may show that conversion rates are falling, which tells the business what is happening, but it does not necessarily explain why. The next step may involve examining customer behaviour, response times, pricing changes, competitor activity, website performance or the sales process.
The same principle applies internally. A report may show that one department takes longer to complete tasks, but before assuming poor performance, the organisation should determine whether that team is receiving incomplete information, waiting for approvals or dealing with more complex cases. Data should support investigation, not replace it.
Ask “Why?” More Than Once
A useful technique is to keep questioning the initial explanation. Projects are delayed. Why? Because approvals take too long. Why? Because every project requires approval from three senior managers. Why? Because the process was designed years ago when the company was much smaller.
At that point, the organisation is much closer to the root cause. The solution may not be new project management software at all. It may simply be redesigning the approval structure.
The Best Solution May Be Simpler Than Expected
Businesses often assume that improvement requires major transformation. Sometimes it does, but many problems can be improved through relatively simple changes. Removing one unnecessary approval stage can save hundreds of hours. Connecting two systems can eliminate repeated data entry. Clarifying ownership can prevent work from sitting unfinished. Changing one reporting process can reduce administrative workload across an entire team.
The objective of business analysis is not to make every problem complicated. It is to understand the problem well enough to avoid implementing an unnecessarily complicated solution.
Before You Invest, Diagnose
Before buying software, hiring more people, increasing marketing spend or introducing another management initiative, businesses should ask:
Are we solving the problem — or only reacting to the symptom?
That question can prevent unnecessary spending, reduce complexity and lead to much stronger decisions. The most effective business improvements often begin before any solution is chosen. They begin with understanding what is actually happening, because if the wrong problem is being solved, even an excellent solution can still produce the wrong result.
Category: Business Analysis
