The Right Answer to the Wrong Problem

The Right Answer to the Wrong Problem

Or Why Establishing the Current Condition Matters

Consider a hypothetical situation.

A warehouse is struggling with late deliveries.

Management believes the problem is picking productivity. Operators walk long distances, orders take too much time to prepare, and overtime has become routine.

The explanation seems reasonable.

A project is launched.

Storage locations are reorganized. Picking routes are optimized. Performance indicators are introduced.

Within a few weeks, picking productivity improves by 35%.

The project is declared a success.

Except for one small detail.

Customers are still receiving their orders late.

What happened?

The improvements were real. Operators were walking less, and the warehouse could prepare more orders per hour.

But a closer examination reveals something nobody had investigated before launching the project.

Many orders were waiting for missing items. Others were held because of incomplete information. Some required authorization from another department before they could be released.

Picking productivity was an opportunity for improvement.

It was not the principal reason customers were receiving their orders late.

The solution worked. The assumption didn’t.

The problem we think we have

This is one of the most dangerous traps in problem-solving.

Not because the proposed solutions are necessarily bad, but because they can be perfectly reasonable responses to an incomplete understanding of reality.

We observe an undesirable result.

We recognize something that might explain it.

And, almost without noticing, we begin treating that explanation as a fact.

“Deliveries are late because picking is too slow.”

Notice what happened.

An observation became an explanation.

An explanation became a diagnosis.

And a diagnosis became a project.

All without verifying whether the assumed relationship was true.

The organization did not fail to execute its solution.

It failed to establish what was actually happening.

Establishing the current condition

In TPS, establishing the current condition is not simply collecting performance indicators or documenting how a process is supposed to work.

It means understanding how the work actually happens.

Where does an order spend its time?

When is work progressing, and when is it waiting?

What interrupts the flow?

Which conditions repeatedly require people to intervene?

And, perhaps most importantly, what evidence supports our explanation of the problem?

These questions require us to observe the process rather than rely exclusively on reports, assumptions, or familiar explanations.

A dashboard may tell us that deliveries are late.

It cannot necessarily tell us why.

A procedure may describe how orders should move through the system.

It does not prove that they actually move that way.

And an experienced manager may recognize a pattern from previous situations.

But recognizing a pattern is not the same as verifying that it applies here.

Intuition tells us where to look. Reality tells us what is there.

Improving something is not necessarily solving the problem

There is another distinction worth making.

An organization can improve an individual process without improving the outcome that matters to the customer.

In our hypothetical warehouse, reducing unnecessary walking was valuable. It may have made the work easier, safer, and more efficient.

That achievement should not be dismissed.

But it should not be confused with solving the delivery problem.

Different departments may also see different symptoms of the same situation: overtime, low productivity, changing priorities, or customer complaints.

Each perspective can be useful, provided we do not mistake a local measure for the purpose of the entire system.

Every department can hit its target while the system misses its purpose.

The question is not whether we found something worth improving.

It is whether we understood what needed to change to achieve the result we were seeking.

Experience should improve our questions

Experience helps us recognize patterns.

After years of encountering similar situations, we often develop a sense of where problems might originate.

That ability is valuable.

But experience can also make us dangerously confident.

We have seen this before.

We know what usually causes it.

We already have a solution.

And sometimes, that confidence allows us to skip the very observations that could prove us wrong.

Experience should help us ask better questions, not just find answers faster.

The point is not to distrust experience.

It is to use experience as a starting point for investigation, rather than as a substitute for it.

Nor does establishing the current condition mean we must understand every detail before taking action.

We need enough understanding to distinguish observations from assumptions, formulate a reasonable hypothesis, and recognize what evidence would confirm or challenge it.

Then we can act, observe the results, and learn.

Understanding and improvement are not separate activities. They should reinforce each other.

Before we celebrate the answer

Organizations are often very good at celebrating completed projects.

A target was reached.

A solution was implemented.

An indicator improved.

Those accomplishments deserve recognition.

But before declaring victory, there is one more question worth asking:

Did we actually improve what we set out to improve?

If the answer is no, the effort may still have produced something valuable.

But we should be willing to recognize what it did not accomplish.

And perhaps revisit the assumptions that led us there.

Because the quality of a solution cannot be judged only by how well it was executed.

It must also be judged by whether it addressed the problem that mattered.

The right answer to the wrong problem is still the wrong answer.