Why PDCA Works
Plan, Do, Check, Act. Four words you know. Four steps everyone understands. And yet this simple method is one of the most powerful improvement tools in modern manufacturing.
The PDCA cycle – sometimes called the Deming or Shewhart cycle – is not academic theory. It is a proven way to systematically solve problems and improve processes. It works just as well at Toyota as it does in a small forge shop.
What makes PDCA effective? Discipline. It forces us to:
- Think systematically instead of fighting fires
- Make decisions based on data, not gut feelings
- Verify results instead of hoping for the best
- Sustain improvements instead of letting them fade away
In a world where "fix it fast and move on" is the norm, PDCA says: "Stop. Think. Verify. Sustain."
A Bit of History
Walter Shewhart developed the predecessor of PDCA in the 1920s at Bell Labs. Dr. W. Edwards Deming then expanded it and introduced it in Japan after World War II as the "PDSA cycle" (Plan-Do-Study-Act). The Japanese adapted it to "PDCA" and used it as the foundation of their quality revolution.
Why a "cycle"? Because it is not a linear process with a beginning and an end. It is an endless loop. After the Act phase, you return to Plan for the next improvement. Over and over again. You are never "done" with improvement.
Today PDCA is the foundation of many modern methods – Six Sigma, Kaizen, A3 problem solving. Anyone who understands PDCA understands the essence of all these approaches.
PLAN - The Foundation of Success
The first step is often rushed or skipped. "We know what's wrong, so let's just fix it!" But poor planning kills most improvements before they even start.
1. Clearly define the problem
Wrong: "Part quality is terrible."
Right: "The defect rate on line 3 for part XYZ has increased from 2% to 5% over the past four weeks."
The problem must be measurable, specific, and bounded. Without a clear definition, you will never know when it has been solved.
2. Find the root cause
What is actually causing the problem? Not the symptom, but the underlying cause.
Practical example using the 5 Whys method:
- Symptom: High defect rate
- First why: Material is contaminated
- Second why: Cleaning is not effective
- Third why: We changed the cleaning agent, which is not effective on the composition declared by the supplier
- Fourth why: The supplier changed the composition without notification
- Fifth why: We have no written agreement on changes
- Root cause: Missing supplier change control system
If you only fix the symptom (more inspection, sorting), the problem will return. If you fix the root cause (implement a change management system), you solve the problem permanently.
Useful tools:
- 5 Whys
- Ishikawa diagram (fishbone)
- Pareto analysis
- Production data analysis
3. Set a clear goal
"Reduce the defect rate on line 3 back to 2% within two weeks."
The goal must be specific, measurable, and time-bound. You need to know exactly what you want to achieve.
4. Design a solution
First, come up with multiple options. What could you try?
Then evaluate each option:
- Is it technically feasible?
- How much will it cost?
- How long will it take?
- What are the risks?
Choose the most promising solution – a combination of effectiveness, feasibility, and cost.
5. Create an action plan
A concrete plan means:
- Who is exactly responsible for what
- What will be done
- When it will be completed
- What resources you need
- What metrics you will track
Not a vague intention like "we'll improve it," but a clear plan with deadlines and responsibilities.
Most common planning mistakes:
❌ Jumping straight to a solution without understanding the cause
❌ Vague goals ("improve quality")
❌ Not considering multiple options
❌ Lack of clear accountability
❌ Planning in too much detail before trying anything
Good advice: Planning typically takes 20–40% of total time. Don't rush. The investment pays off.
DO - Execution with Sense
The second step sounds simple – just do what you planned. But this is exactly where success and failure part ways.
1. Start with a pilot test
Don't roll out the solution everywhere at once! Test it on a small scale first:
- One machine
- One shift
- One line
A pilot allows you to learn and fine-tune at low risk. If something fails, the impact is limited. Success in the pilot then builds confidence for others.
2. Stick to the plan
Resist the temptation to improvise. The plan was carefully prepared – give it a fair chance.
If during implementation you find that a change is needed, that's fine. But decide consciously, document the change, and explain why.
3. Collect data
This is not just about doing – it's about documenting:
- Measurements before and after
- Observation notes
- Problem records
- Photos, videos
Data are critical for the next step. Without them, you only have impressions and opinions instead of facts.
4. Involve people
Those affected by the change must understand:
- Why it is happening
- What is expected of them
- How it will help them
Resistance often stems from misunderstanding or the feeling that something is being imposed. Involvement builds support.
5. Record deviations
Did something go differently than planned? Write it down. Perhaps:
- You encountered an unexpected obstacle
- You discovered a better way
- You found that an assumption was wrong
Deviations are not failures – they are learning opportunities. But only if you capture them.
Practical example:
Problem: Long changeover time between production batches
Plan: Introduce quick-change fixtures
Do: Pilot on one machine for one week. Operator receives training. Every changeover is measured. All problems are recorded.
Finding: Fixtures work, but the bolts are too long. Adjust.
Most common mistakes:
❌ Skipping the pilot, going full deployment immediately (risky)
❌ Changing the plan without documenting it (makes evaluation impossible)
❌ Insufficient data collection
❌ Insufficient training of people
❌ Premature declaration of success
Good advice: Execution typically takes 30–40% of total time. Rushing ruins everything.
CHECK - Verification Based on Facts
This is where discipline often breaks down. People are eager to see success, so they declare it – without proper verification.
1. Compare results against the goal
What did you want to achieve? What did you achieve? Quantitatively, not in the manner of "I think it's better."
Example:
- Goal: Reduce defect rate to 2%
- Result: 2.5%
- Assessment: Partial success – improvement, but goal not reached
2. Analyze why the results occurred
If successful:
- Why did it work?
- Was the solution as effective as expected?
- Were there other factors involved?
Understanding success is just as important as understanding failure.
If it didn't work:
- Why not?
- Was the solution wrong?
- Was the implementation poor?
- Were there unexpected complications?
3. Monitor side effects
Sometimes a solution fixes one problem but creates another:
- Did defects decrease, but cycle time increase?
- Did quality improve, but costs become unsustainable?
- Was the problem solved on one line but created on another?
Evaluate the overall impact, not just one indicator.
4. Verify statistically
Question: Is the improvement real, or just chance?
Example: Defect rate dropped from 2.0% to 1.8%. That sounds good. But:
- If the normal process variability is ±0.5%, it may just be noise
- If the normal variability is ±0.1%, it is a real improvement
Control charts and basic statistics will help you distinguish signal from noise.
5. Get feedback from people
What do operators, setup technicians, and engineers think? Their qualitative perspective complements quantitative data.
Sometimes the numbers look good, but people report hidden problems. Sometimes the numbers are average, but people see major practical improvements.
Most common mistakes:
❌ Superficial evaluation – "looks better, let's move on"
❌ Selecting only the data that fits
❌ Ignoring negative side effects
❌ Too short a testing period
❌ Mistaking chance for real improvement
Good advice: Evaluation takes 15–25% of time. Don't rush it – wrong conclusions lead to wrong decisions.
ACT - Closing the Loop
The final step completes the cycle. Based on the Check results, you decide what comes next.
If it is a success:
1. Standardize
Document the improved method. Update:
- Work instructions
- Process sheets
- Training materials
- Control plans
Critical: Without standardization, improvements gradually disappear. People revert to old habits or new employees have no idea about the change.
2. Expand
Can the improvement be applied elsewhere?
- Similar processes
- Other lines
- Other departments
3. Celebrate
Recognize the people who were involved. Share the success across the whole company. It builds momentum for further improvement.
4. Sustain
Improvements are easy to lose. Check regularly:
- Control charts
- Periodic audits
- Visible metrics
If it is a partial success:
Refine
- What worked? What didn't?
- Can the solution be fine-tuned?
- Start a new PDCA cycle built on the lessons learned
Often the second or third iteration achieves the full goal.
If it failed:
1. Learn
- Why didn't it work?
- What did you learn?
- Unsuccessful experiments are not failures – they are learning
2. Try differently
Based on the insights, formulate a new hypothesis and solution. Start a new PDCA cycle with a different approach.
Perseverance decides. The first attempt rarely achieves a perfect result. Successful companies iterate until the problem is solved.
Most common mistakes:
❌ Declaring success without standardization (everything reverts)
❌ Giving up after the first failure
❌ Not sharing lessons from failures
❌ Moving on to the next problem without ensuring sustainability
❌ No verification that Act is actually working
Good advice: Act takes 10–20% of time, but determines whether the improvement is temporary or permanent.
PDCA in Manufacturing Practice
Everyday problems (minutes to hours)
Fast cycles for common operational issues.
Example:
- Plan: Machine making a strange noise → check lubrication
- Do: Inspect, top up oil
- Check: Did the noise disappear?
- Act: Log in the maintenance book; if not → escalate
Improvement projects (weeks to months)
Formal projects for chronic problems.
Example – reducing changeover time:
- Plan (2 weeks): Detailed current-state analysis, waste identification, design of quick-change solutions
- Do (3 weeks): Piloting on one machine, measurement, adjustments
- Check (1 week): Comparing times, data analysis, feedback
- Act (1 week): Standardizing the procedure, training all shifts, expanding to other machines
Strategic initiatives (months to years)
Large organizational changes.
Example – implementing TPM:
- Plan: Months of preparation, analysis, training
- Do: Gradual rollout by area
- Check: Measuring OEE, breakdowns, costs
- Act: System optimization, expansion
Different time scales, same logic. PDCA scales from micro to macro.
PDCA vs. PDSA – Which Is Correct?
Some people use "PDSA" – Plan-Do-Study-Act.
The difference:
- Check = simple verification (did it work?)
- Study = deeper analysis (why did it work? what did we learn?)
In practice, the two are used interchangeably. The essence is the same – verify results and learn from them.
Why PDCA Often Fails
Despite its simplicity, many PDCA attempts fail. The most common reasons:
1. Insufficient planning
We jump straight to the solution without understanding the cause. We treat symptoms, not the disease.
2. No proper verification
We implement the solution and move on without checking results. Common when people are pushed to "fix it and forget it."
3. Missing standardization
The improvement works, but it is not documented or trained. It fades over time.
4. Giving up after the first attempt
The first attempt is not fully successful, so we give up. There is a lack of understanding that iteration is the key.
5. Too complicated
We turn a simple PDCA into a bureaucratic monster with piles of paperwork and approvals. We kill agility.
6. We start, we don't finish
We launch ten PDCA cycles, complete two. We dilute our effort.
Success requires: The discipline to complete the full cycle, the willingness to iterate, and cultural support.
How to Make PDCA a Habit
At the individual level
Encourage everyone to apply PDCA thinking in their daily work. Small personal improvements.
At the team level
Team meetings structured around PDCA. A regular rhythm – weekly or monthly.
At the company level
PDCA embedded in how the organization operates. Large projects explicitly structured around PDCA. Managers ask: "What PDCA phase are you in?" instead of just "What's the status?"
Visualization
A PDCA board showing current cycles:
- What phase each project is in
- Who the owner is
- What the status is
- Deadlines
Makes the process visible and creates accountability.
Training
- Everyone trained in PDCA basics
- Facilitators trained in deeper skills
- PDCA as a common language
Recognition
Celebrate completed PDCA cycles – especially those requiring perseverance. Not just success, but disciplined approach.
What This Brings to the Company
Investment:
- PDCA training: 4–8 hours per person (one-time)
- Time for application: Depends on problem complexity
- Facilitator support: ~0.5 FTE per 200 employees
Returns:
- Higher solution success rate: 60–80% vs. 20–40% with a chaotic approach
- Lasting solutions: Problems don't come back
- Organizational learning: Knowledge accumulates
- Less waste: Right the first time
- Cultural shift: From reactive to proactive
Conclusion
The elegance of PDCA lies in its simplicity. It is neither complex nor intimidating. Four steps anyone can master.
But disciplined application of these four steps transforms companies from chaotic firefighting to systematic improvement.
Master PDCA and you master the foundation of excellence.
Practical Tips to Close
✅ Start with small problems – build success
✅ Document your first cycles – templates help
✅ Visualize progress – boards, workflows
✅ Don't wait for perfection – iteration is normal
✅ Standardize successes – otherwise they disappear
✅ Share learnings – even from failures
✅ Be persistent – the first attempt rarely lands perfectly
PDCA is not about complex tools. It's about disciplined thinking and a systematic approach. Start today with the first small problem.
