The Hole in the Boat: Why Six Sigma Leaders Refuse to Normalize Process Problems
The Hole in the Boat: Why Six Sigma Leaders Refuse to Normalize Process Problems
By Better Operations Hub
In many organizations, operational problems do not remain visible because they are difficult to solve. They remain because people gradually learn how to work around them.
A recurring defect becomes “normal.” An inefficient step becomes “the way we have always done it.” A quality issue becomes acceptable because production is still moving. A safety concern is tolerated because nothing serious has happened yet.
The image of a team sitting in a leaking boat provides a powerful metaphor for this situation. One person identifies the obvious problem: there is a hole in the boat. Others respond with familiar explanations:
It has always been there. We have succeeded before despite it. Other boats are in worse condition. If you do not like it, you can leave.
Meanwhile, the water continues entering the boat.
This is exactly the type of organizational thinking that Lean Six Sigma and Continuous Improvement are designed to challenge.
Six Sigma is not simply a collection of statistical tools. It is a disciplined approach to understanding variation, identifying root causes, improving processes, and sustaining better performance. The American Society for Quality describes DMAIC—Define, Measure, Analyze, Improve, and Control—as a data-driven method for improving existing processes that are not meeting expected performance or customer requirements.
The lesson for leaders is straightforward:
A problem does not become acceptable simply because an organization has learned how to operate around it.
When Problems Become Part of the Culture
One of the greatest risks in operations is the normalization of abnormal conditions.
Imagine a distribution center where a conveyor repeatedly stops several times during every shift. At first, the downtime receives attention. Technicians respond, leaders investigate, and employees report every interruption.
After several months, however, people adjust.
Team members begin manually moving product when the conveyor stops. Supervisors build additional labor into the staffing plan. Production targets are adjusted to compensate for expected downtime.
Eventually, someone says:
“That conveyor always does that.”
At that moment, the organization has moved from solving the problem to managing around the problem.
The workaround may keep operations moving, but it creates hidden costs:
- additional labor,
- lost productivity,
- increased cycle time,
- employee frustration,
- additional equipment handling,
- greater opportunity for defects,
- unpredictable capacity.
The operation may still hit its daily goal, but achieving the goal does not prove the process is healthy.
This distinction is critical.
Results can sometimes hide process weakness.
A team can meet production expectations despite inefficient processes because employees are working harder, supervisors are constantly intervening, or additional resources are being added.
Six Sigma encourages leaders to look beyond the final result and examine the process producing that result.
“We’ve Always Done It This Way” Is Not a Root Cause
Consider another example.
A warehouse experiences frequent inventory discrepancies between physical inventory and the inventory management system.
The traditional response might be:
“Inventory discrepancies are normal in warehouses.”
That statement may be technically true—no complex operation will eliminate every error—but it does not explain why the discrepancies are occurring.
A Six Sigma team would move the conversation from acceptance to investigation.
Instead of asking:
“How do we manage these discrepancies?”
the team asks:
“What process conditions are creating them?”
Possible contributors might include:
- incorrect receiving transactions,
- mislabeled inventory,
- incorrect put-away locations,
- scanning errors,
- damaged or unreadable barcodes,
- inconsistent standard work,
- system latency,
- incorrect unit-of-measure configuration,
- insufficient training,
- inaccurate adjustments.
The difference is significant.
The first mindset manages symptoms.
The second investigates causes.
Lean thinking similarly emphasizes that problem solving should be based on observable facts rather than assumptions and should continue even after an improvement is implemented. The Lean Enterprise Institute describes continuous problem solving as an ongoing effort to understand the gap between the current condition and the desired condition.
Using DMAIC to Fix the Hole Instead of Managing the Water
The leaking boat metaphor can be translated directly into the five phases of DMAIC.
- Define: What Exactly Is the Hole?
The first mistake many organizations make is beginning with a solution before clearly defining the problem.
Suppose a fulfillment operation is experiencing late orders.
A weak problem statement would be:
“Employees need to work faster.”
That statement already assumes the workforce is the cause.
A stronger problem statement would be:
“During the past eight weeks, 14% of outbound orders missed the internal processing target of four hours, compared with the expected performance level of 5% or less.”
Now the problem has:
- a measurable gap,
- a defined process,
- a timeframe,
- a target,
- and a current condition.
This changes the conversation from blame to investigation.
The Define phase establishes what problem the organization is actually trying to solve, who is affected, why it matters, and what success should look like. ASQ identifies problem definition, project goals, customers, requirements, scope, and metrics as important elements of the DMAIC framework.
In the boat analogy, Define means stopping long enough to say:
There is water entering the boat, and that condition threatens our ability to reach the destination.
Not:
Everyone needs to bail water faster.
- Measure: How Serious Is the Problem?
Once the problem is defined, leaders need reliable data.
Consider the earlier conveyor example.
Instead of relying on comments such as:
“The conveyor stops all the time,”
the team could measure:
- number of stoppages per shift,
- average duration of each stoppage,
- total downtime,
- location of each stoppage,
- product type being processed,
- operating speed,
- staffing levels,
- equipment alarms,
- maintenance history.
After collecting the data, the team might discover something unexpected.
Perhaps the conveyor is not failing randomly.
Maybe 70% of the stoppages occur at one transfer point when a specific container type is introduced.
Now the problem is considerably more focused.
Without measurement, the organization might replace motors, increase maintenance staffing, or blame operators.
With measurement, the team can investigate the actual pattern.
This illustrates one of the most important principles of process improvement:
Data transforms opinions into testable questions.
- Analyze: Find the Root Cause
The Analyze phase is where organizations must resist the temptation to stop at the first reasonable explanation.
Suppose employees frequently scan the wrong barcode during receiving.
Management might immediately conclude:
“Employees need more training.”
Training is one of the most common countermeasures in operations—and sometimes it is appropriate.
But suppose further analysis shows that each workstation contains five similar barcodes positioned close together, with small labels and poor visual distinction.
The issue may not primarily be employee knowledge.
The process design itself may be creating opportunities for mistakes.
A root-cause investigation might use tools such as:
5 Whys
- Why was the wrong transaction selected?
- Why was the wrong barcode scanned?
- Why were they difficult to distinguish?
- Why was similar formatting used?
- Why was there no standard?
Because the wrong barcode was scanned.
Because several barcodes were located next to each other.
Because the labels used similar formatting.
Because there was no visual-management standard.
Because the workstation developed over time without a formal design review.
The deeper issue is therefore not simply:
“Operator error.”
It may be:
“Workstation design allows multiple similar transaction barcodes to be easily confused.”
This changes the solution completely.
Potential improvements might include:
- increasing barcode size,
- increasing spacing,
- grouping barcodes by function,
- using clear visual headers,
- removing obsolete codes,
- repositioning high-frequency transactions,
- mistake-proofing the sequence.
This is the difference between correcting people and improving systems.
- Improve: Repair the Process, Not Just the Symptom
Once root causes have been validated, improvement should focus on changing the conditions producing the problem.
Return to the leaking boat.
A symptom-based strategy would be:
- give everyone larger buckets,
- assign more employees to remove water,
- increase the speed of water removal,
- reward the fastest bailer.
Those actions might temporarily improve performance.
But none of them repair the boat.
Operations frequently make the same mistake.
Example: Picking Productivity
Suppose employees average 55 units per hour, while the desired performance is 65 units per hour.
The immediate reaction might be:
“Push the team harder.”
But process observation might reveal that employees spend significant time walking to obtain empty containers.
A time study could show:
- 40 minutes per shift walking for supplies,
- 20 minutes waiting for replenishment,
- 15 minutes resolving location problems.
That is 75 minutes of potential lost productive time.
The improvement opportunity may therefore involve:
- changing supply locations,
- improving replenishment routes,
- redesigning workstation layout,
- balancing feeder coverage,
- adjusting inventory placement.
The productivity problem may not be primarily an employee-speed problem.
It may be a process-flow problem.
Six Sigma helps separate those possibilities.
- Control: Make Sure the Hole Does Not Return
One of the weakest parts of many improvement initiatives is sustainability.
A problem is solved.
Everyone celebrates.
Three months later, the old process returns.
That is why Control is essential.
ASQ describes the Control phase as establishing long-term measurement, mistake-proofing, reaction plans, standard operating procedures, and mechanisms for sustaining process capability.
For example, after redesigning a receiving workstation, a control plan might include:
- standardized workstation layouts,
- visual job aids,
- weekly compliance audits,
- barcode scan-error tracking,
- new-employee training,
- change-control procedures,
- ownership assigned to a specific leader.
The organization should also define a reaction plan.
For example:
If scan errors exceed 1.5% for two consecutive days, the area leader reviews the workstation, error categories, training status, and system behavior before the next shift.
Now the organization is not waiting for the process to fail dramatically.
It is monitoring early indicators.
The Danger of Comparing Yourself to Worse Performers
One of the statements in the image is particularly important:
“Other boats are in worse shape.”
Organizations frequently use comparison as justification for avoiding improvement.
Examples include:
“Our defect rate is better than the other building.”
“Our productivity is higher than the regional average.”
“Our customer complaints are lower than last year.”
Those comparisons can provide useful context.
But they do not answer the most important question:
Is the process performing at the level it is capable of achieving?
Imagine two facilities:
Facility A has an error rate of 4%.
Facility B has an error rate of 7%.
Facility A is clearly performing better.
But if a properly controlled process should operate at 1%, Facility A still has a significant improvement opportunity.
Being better than another operation does not automatically mean the process is optimized.
Benchmarking should provide perspective—not permission for complacency.
The Cost of Workarounds
Workarounds are especially dangerous because they often look like solutions.
Consider a manufacturing operation where one machine frequently produces misaligned components.
Instead of repairing the underlying issue, an inspector is assigned after the machine to identify defective parts.
Initially, this appears effective.
Defective products no longer reach customers.
But the defect still exists.
The organization has simply added another process to detect it.
Now the business pays for:
- producing the defective product,
- inspecting the product,
- separating the defective product,
- reworking or scrapping it,
- investigating customer risk,
- maintaining additional inspection labor.
A better question is:
Why is the machine creating the defect in the first place?
Inspection is sometimes necessary.
But inspection should not become a permanent substitute for process capability.
Psychological Safety Matters in Continuous Improvement
The employee who points out a problem is sometimes treated as difficult.
That response can be extremely damaging to an improvement culture.
If employees repeatedly hear:
“Stop complaining.”
“That’s how the process works.”
“Just make it work.”
they eventually stop reporting problems.
Management may interpret the silence as improvement.
But the problems may still exist.
The organization has simply lost visibility.
A strong Continuous Improvement culture encourages employees to identify abnormalities because frontline employees often experience process failures before dashboards show them.
Leaders should therefore respond to concerns with questions such as:
What did you observe?
How often does it happen?
Where does it occur?
What is the impact?
Can we observe the process together?
What data would help us understand it?
This shifts the interaction from complaint management to structured problem solving.
Example: Applying the Boat Analogy in Warehouse Operations
Consider a hypothetical distribution center experiencing recurring congestion around five processing lines.
Employees complain that material feeders cannot replenish stations quickly enough.
Management has heard the concern for months.
The accepted explanation becomes:
“That area is always busy.”
That statement is the equivalent of saying:
“The boat has always leaked.”
A Six Sigma team might approach the situation differently.
Define
Stations experience material shortages during peak processing periods, contributing to idle time and reduced throughput.
Measure
Collect:
- replenishment requests per hour,
- feeder travel distance,
- station wait time,
- units processed,
- number of active stations,
- replenishment cycle time.
Analyze
A spaghetti diagram may reveal excessive feeder travel.
A Pareto analysis may show that most delays occur on two lines.
Time studies may demonstrate that feeders spend more time walking than replenishing.
Improve
Potential countermeasures could include:
- repositioning material staging areas,
- redesigning feeder routes,
- assigning feeder zones,
- changing replenishment triggers,
- balancing staffing according to workload,
- creating visual replenishment signals.
Control
Track:
- station starvation time,
- feeder cycle time,
- travel distance,
- units per labor hour,
- replenishment response time.
Now the conversation has changed.
Instead of:
“Feeders need to move faster.”
the organization asks:
“How can we design the process so less unnecessary movement is required?”
That is Continuous Improvement thinking.
Six Sigma Is Ultimately a Leadership Discipline
Six Sigma tools are valuable, but tools alone do not create an improvement culture.
Control charts, Pareto charts, process maps, fishbone diagrams, hypothesis testing, capability analysis, and regression can help organizations understand processes.
But leadership determines whether those tools lead to meaningful change.
ASQ notes that Six Sigma commonly involves structured projects, statistical thinking, DMAIC, and a management environment that supports improvement as a business strategy.
Leaders therefore have an important responsibility.
When someone identifies the organizational equivalent of a hole in the boat, leaders should avoid immediately defending the current process.
Instead, they should become curious.
Ask:
Is this really the standard we want?
What evidence shows the process is stable?
How much is this problem costing us?
What workarounds have we created?
What is the root cause?
What would the process look like if this problem did not exist?
Those questions create improvement.
From Firefighting to Problem Solving
Organizations often praise employees who repeatedly rescue failing processes.
And those employees deserve recognition.
But leaders should also ask why the rescue was necessary.
If the same emergency happens every day, it is no longer an emergency.
It is a process condition.
Imagine an operation where one experienced employee constantly resolves inventory problems.
Everyone says:
“We don’t know what we would do without them.”
That employee may be extremely valuable.
But from a process perspective, the situation represents risk.
The organization should ask:
- Why does the process depend on one person’s knowledge?
- Why are the problems recurring?
- Is the knowledge standardized?
- Can the process prevent those errors?
- Can the solution be built into standard work?
Continuous Improvement converts individual heroics into organizational capability.
The goal should not be to create better firefighters.
The goal should be to reduce the number of fires.
The Most Important Question: Why Are We Accepting This?
Every operation has constraints.
Every warehouse will experience variation.
Every manufacturing facility will encounter defects.
Every service organization will encounter delays and errors.
Six Sigma does not suggest perfection is effortless.
Instead, it provides a disciplined method for distinguishing unavoidable variation from correctable process weakness.
That makes one leadership question particularly powerful:
“Are we managing this problem because it is truly unavoidable, or because we have become accustomed to it?”
Sometimes the answer will reveal that the organization has spent years building increasingly sophisticated ways to manage a problem that should have been eliminated.
Final Thought
The picture of people sitting in a leaking boat is humorous because the problem is obvious.
Real operational problems are rarely that visible.
They appear as:
- five extra minutes of cycle time,
- repeated inventory adjustments,
- unnecessary walking,
- recurring rework,
- excessive handoffs,
- duplicated data entry,
- damaged products,
- customer complaints,
- machine downtime,
- missed scans,
- repeated escalation.
Over time, organizations can become remarkably good at living with these conditions.
Lean Six Sigma challenges that acceptance.
Do not measure success by how effectively your organization can operate around a broken process.
Measure success by how consistently your organization can:
identify the problem, understand the data, find the root cause, improve the process, and sustain the improvement.
Because when there is a hole in the boat, the long-term strategy should never be to become better at removing the water.
The strategy should be to repair the boat.