Problem solving in management consulting is a disciplined process for turning an unclear concern into a decision that leaders can act on. The consultant does not begin with a preferred solution. The work starts by defining the decision, separating symptoms from causes and agreeing what evidence would change the conclusion.

Define the problem and the decision needed

“Performance is weak” does not specify what needs fixing. Describe the gap between current and required results, the process, period and affected group. Is the problem delivery speed, quality or cost? Who has authority to change the work? Agree scope, constraints, resources and timing before expanding the analysis.

For example: “60 of 200 orders due during a month were delivered late, and we want to reduce the late-delivery rate to 15% or less.” This statement can be tested, unlike a claim that employees are uncooperative. These figures are illustrative; in actual work, verify their source and define late delivery precisely.

Root-cause analysis in management consulting
A conceptual view of uncovering root causes beneath business symptoms.

Separate symptoms from causes

Late delivery is an observable symptom, but it does not explain why it occurred. Possible causes include material shortages, waiting for approval or incomplete order information. Map work from receipt to delivery and locate waiting and rework. Listen to staff and customers, but treat explanations as hypotheses requiring evidence.

Do not assume that every problem has one cause. A factor can be a symptom at one level and a cause at another: a stock shortage may cause delay while itself resulting from weak purchasing planning. Finding root causes means identifying interventions that prevent recurrence, not finding someone to blame.

Break down the question and test hypotheses

An issue tree breaks a large question into smaller questions. For delivery delays, branches might cover order readiness, material availability, operating capacity and delivery. Make branches clear, reduce overlap and check for important omissions. The tree maps what needs investigation; it is not a drawing designed to prove a preferred explanation.

For each hypothesis, record expected supporting evidence and what could disprove it. If approval delays are suspected, compare submission and authorization times and examine both late and on-time orders. Prioritize hypotheses by potential impact and testability. Do not collect every available dataset without a clear question.

Collect evidence and check its quality

Combine order records, stage timings, interviews and direct observation, then compare sources. Check whether dates are complete and whether promised-date definitions or order types changed during the period. Define the numerator and denominator before calculating a rate, and record data limitations instead of hiding them.

Do not sample complaints alone. Examine successful cases to understand what differs. Separate facts, estimates and opinions and investigate cases that contradict your explanation. Use only necessary information and protect confidential data. An opinion repeated in several interviews may reveal a shared perception without establishing the cause.

Test the explanation before choosing a solution

Root cause analysis connects evidence with how a problem occurs. Repeated “why” questions or a diagram of potential causes can help, but every answer needs verification. Do not stop at “human error”: examine instructions, tools, authority, workload and how the error was detected.

Correlation does not establish causation. More delays on busy days do not prove volume alone is responsible; order complexity or supplier availability may also have changed. Look for timing, a plausible mechanism and evidence that supports or challenges the explanation. Where uncertainty remains, test a limited intervention while monitoring other factors and state that the conclusion is provisional.

Compare options and their trade-offs

Options may include checking order completeness before acceptance, changing approval authority, adding capacity or maintaining current arrangements with monitoring. Compare each against criteria set in advance: expected impact, cost, time, risk, operating capability and reversibility. Identify which judgments are estimates and which are supported by data.

Do not select a new system because its demonstration is impressive when the problem is missing information. Nor should the cheapest option be chosen if it shifts burdens to customers or weakens quality. Explain what will be gained, what may be lost and which changed assumption would alter the choice.

Turn the recommendation into an accountable decision

Present the problem, evidence, alternatives, recommendation and confidence limits in a clear decision brief. The client retains decision accountability while the consultant explains the reasoning and unresolved questions. Name the process owner, implementers and reviewers and give each role appropriate resources and authority.

Set decision gates: review points at which continuation, modification or stopping is decided. Agree acceptance and stop criteria before the pilot and define escalation when people disagree. Starting implementation is not an open-ended authorization to expand scope or cost.

Pilot the solution and verify lasting improvement

Use Plan–Do–Check–Act (PDCA): plan the change and measures, implement within a suitable scope, compare results with the baseline, then standardize what works or adjust what does not. Track an early indicator such as complete order information and an outcome measure such as the late-delivery rate, alongside cost, complaints and quality.

Fewer late deliveries are not enough if achieved by extending promised dates or rejecting difficult orders. Check that measurement remains consistent and examine changes in volume and order mix, then review performance after stabilization. Update procedures, training and authority, record exceptions and lessons, and stop or redesign the solution if it fails to deliver acceptable value.

Worked example: from late orders to an improvement pilot

Entirely hypothetical example: A company has 200 orders due during a month, of which 60 are late: 30%. The operations manager leads the review and asks for an explanation before approving additional staff. The team checks records, interviews staff and follows orders through the process.

To avoid double counting, the team assigns one principal delay factor to each late order: 36 involved incomplete information that held up processing, 14 material shortages and 10 approval waiting. Other contributing factors may overlap, so these counts alone do not prove root causes. Timing records confirm that requests for missing information preceded the delays, while observation shows that the intake form allows orders to proceed without required fields.

The team compares extra staffing with revising the intake form and checking completeness. It selects the latter for a month-long pilot in a comparable scope. In advance, it sets a late-delivery target of no more than 15%, no increase in the complaint rate against baseline and no extension of promised dates. The intake owner checks information and the operations manager reviews results weekly.

In the next hypothetical period, 24 of 200 orders are late: 12%. This is a reduction of 18 percentage points, equivalent to a 60% relative reduction from the original 30% rate. The complaint rate does not increase and promised dates are not extended. The team also examines changes in order mix and material availability before attributing the improvement to the intervention.

The result supports gradual expansion with another month of monitoring, not a conclusion that all delay causes have disappeared. Material shortages and approvals remain under investigation, and the intervention is retested if operating conditions change. The decision is therefore tied to reviewable evidence rather than a large purchase based on an initial impression.

Checks before closing the problem

Confirm that the problem is measurable, causes are supported by evidence rather than opinion alone, and options have been compared against stated criteria. The decision should identify the outcome owner, resources and success and stop criteria. Follow-up should demonstrate sustained improvement without material harm elsewhere. Closing the consulting engagement and handing over a report do not automatically mean the problem is resolved.

Problem-solving funnel from symptoms to an actionable decision
A visual model for narrowing symptoms and evidence into evidence-supported causes and a decision.

For the consultant’s role and engagement boundaries, read the foundational guide to management consulting. ISO 20700 is included below as general guidance for consultancy services; the worked example and explanatory steps in this article are not text from the standard.

Next step

Start with a defined problem and evidence that can test it, then select an intervention whose effects can be measured. If your organization needs independent analysis or help comparing alternatives, contact ATMACSS to define the engagement scope and deliverables.