PDPC
— Process Decision Program Chart: When Your Planning Starts Accounting for
What Could Go Wrong — and You Stop Being Surprised by Crises You Could
Have Predicted
A story about how one diagram transforms your project planning
from naive optimism into strategic readiness — and why the best quality
managers don’t just plan for success, but for every possible path to
failure.
The Scenario Everyone Knows
It’s Monday morning, 6:00 AM. Your team has just kicked off the most
important project of the year — deploying a new measurement system on a
critical production line. You had a plan. You had deadlines. You had a
budget.
By Wednesday, the plan is in ruins.
The supplier is late with calibration. Two out of five operators are
on sick leave. The new system’s software isn’t compatible with your old
database. And an email just came in from the customer — the audit is
two weeks earlier than you planned.
You sit in your office staring at the Gantt chart that looked perfect
just yesterday. Every step was thought through, every milestone clearly
defined. The one thing missing was a tiny detail:
You didn’t think about what could go wrong.
And now it’s caught up with you. Every crisis you’re solving ad hoc
costs three times more time, money, and nerves than if you had
anticipated it.
What Is PDPC and Why You Need
It
Process Decision Program Chart (PDPC) is a systematic
risk planning tool that originated in Japan as part of the Quality
Management toolkit (alongside the Affinity Diagram, Tree Diagram, and
other so-called “7 Management and Planning Tools”). Its single purpose
is to answer one question:
“We have a plan. But what if something goes wrong? What exactly
will we do when it happens?”
PDPC is not another risk register. It’s not another FMEA. It’s not
another spreadsheet you fill out just to have paper for an audit.
PDPC is a living diagram that maps every step of your
project, attaches potential problems to each step, and assigns specific
countermeasures to each problem. It’s mapping the future — not the one
you wish for, but the one that could actually happen.
How PDPC Works — Step by Step
Step 1: Define Your Main Objective
Start with specifics. Not “improve quality.” But “deploy a new SPC
system on Line B by June 30, 2026, with Cpk > 1.33 on all critical
characteristics.”
Specificity is essential. A vague goal produces vague
countermeasures.
Step 2: Break the Objective
into Major Activities
Every project consists of several major blocks. For our SPC system
deployment example, these might be:
- Software selection and procurement
- Installation and configuration
- Personnel training
- Pilot testing
- Full deployment
You place these activities in the diagram as main branches — similar
to a tree diagram.
Step 3:
For Each Activity, Identify Potential Problems
This is where the real value of PDPC begins. Think about each activity
and ask:
- What could go wrong?
- What are the real risks?
- What could stop or delay this activity?
For the “Software selection and procurement” activity: – The selected
software doesn’t support your data format – The budget isn’t approved
on time – The supplier changes licensing terms
For the “Personnel training” activity: – Operators resist the new
system – The training is too technical and incomprehensible – Key
people aren’t available on the scheduled training dates
For the “Pilot testing” activity: – Measurement points don’t work
in the real production environment – Data is inconsistent – The line
must run at full capacity and there’s no time for testing
Step 4: For
Each Problem, Design Countermeasures
Now ask: What will we do if this happens?
Countermeasures must be specific, feasible, and — this is crucial —
they should be planned before the problem
appears.
| Potential Problem | Countermeasure |
|---|---|
| Software doesn’t support data format | Verify compatibility with a test dataset sample before procurement; prepare an alternative export format |
| Operators resist the system | Start with a pilot group of “ambassadors”; involve them in system selection; show them benefits using their own examples |
| Key people unavailable | Schedule two training dates; create video recordings for self-study; appoint deputies |
| Data is inconsistent | Define data checkpoints before the pilot; prepare an automatic validation script |
Step 5: Evaluate and
Prioritize Countermeasures
Not all problems are equally likely, and not all countermeasures cost
the same. Use a simple scoring system:
- Probability of occurrence (1–5)
- Impact on the project (1–5)
- Effort required for countermeasure (1–5)
Problems with high probability and high impact get priority.
Countermeasures with low effort and high effectiveness are implemented
immediately — even as prevention.
PDPC in Practice — A Real
Story from Manufacturing
Let’s say you’re a quality manager at an automotive plant planning the
transition from manual inspection to an automated visual inspection
system (Automated Optical Inspection — AOI). The project is supposed to
take 6 months and affects three production lines.
Conventional Planning (Without PDPC)
You create a project plan. You define milestones. You assign
responsibilities. At first glance — professional.
In month 3, you discover that the lighting on Line 2 creates false
defects. The system rejects 40% of good parts. Operators shut it off and
revert to manual inspection. The project grinds to a halt. You start
scrambling for a solution under pressure.
Planning With PDPC
Already in month 1, your diagram had a branch:
Activity: Setting up cameras and lighting on Line 2
→ Potential problem:environmental conditions (vibrations,
lighting, reflections) causing false detections →
Countermeasure: 1. Conduct an environmental audit of Line
2 before installation 2. Prepare a set of filters and shields for testing
3. Define acceptance criteria for false positives (< 2%) 4. Schedule
two weeks of buffer time for fine-tuning
When the problem appears, you don’t waste time figuring out what’s
happening. You have a prepared set of filters. You have defined criteria.
You have buffer time in the schedule.
The project continues. Not because you got lucky. But because
you were prepared.
PDPC vs. FMEA — What’s the
Difference?
I often get asked in training sessions: “Why do we need PDPC when
we already have FMEA?”
The answer is straightforward:
FMEA is a tool for products and
processes. It analyzes what can go wrong with your product or on
your production line. It’s operationally oriented.
PDPC is a tool for projects and
plans. It analyzes what can go wrong with your project or your
implementation. It’s execution oriented.
They are complementary. FMEA tells you what could go wrong with your
product. PDPC tells you what could go wrong with your plan to improve
that product.
Use both. But never substitute one for the other.
When to Use PDPC
PDPC is not a tool for everyday problems. It’s a tool for situations
where:
- The project is complex with many dependencies and
stakeholders - The stakes are high — failure has serious consequences
(financial, safety, reputational) - The project is new — you lack experience from
previous implementations - Time buffer is minimal — you can’t afford unexpected
delays - Multiple departments are involved — coordination is
critical
Typical scenarios in quality and manufacturing: – Deploying a new QMS
system – Preparing for a certification audit (ISO 9001, IATF 16949) –
Implementing a new production process – Changing suppliers of critical
components – Launching a new production line – Digital transformation of
quality (Quality 4.0) – Restructuring a quality team
Most Common Mistakes When Using
PDPC
1. PDPC as a Paper Formality
The biggest mistake is filling out a PDPC “on paper” and filing it
away in a drawer. PDPC is a living document. If a new risk emerges during
the project — add it. If a countermeasure doesn’t work — revise it. If
the project changes — update the diagram.
2. Too Vague Problems
“Something could go wrong” is not problem identification. Be specific.
“The calibration supplier might be 2+ weeks late” is problem
identification.
3. Too Vague Countermeasures
“We’ll deal with it when it comes” is not a countermeasure. “I have a
backup calibration supplier identified with guaranteed delivery within 5
days” is a countermeasure.
4.
Ignoring Low-Probability Risks with High Impact
People tend to ignore risks that are “unlikely.” But when a pandemic
hits, an earthquake strikes, or the entire IT system goes down — those
“unlikely” events become your reality. COVID-19 was an “unlikely” scenario
for many factories. And yet it happened.
5. Doing PDPC Alone
PDPC is a team tool. One person will never think of every possible
problem. You need the perspective of the operator, the maintenance tech,
the logistics coordinator, the purchasing agent, the IT specialist. The
more diverse the team, the more complete the diagram.
How to Start — A Practical Guide
If you’ve never used PDPC before, start simple:
- Pick one current project — not a hypothetical one,
but a real project you’re working on right now. - Assemble a team — 4–6 people from different
functions. Block out 90 minutes. - Draw the tree — on a flipchart, whiteboard, in Miro,
in PowerPoint. The tool doesn’t matter. The thinking process does. - Ask “What if?” — at every activity. Force the team to
think pessimistically. That’s hard for people accustomed to positive
planning. - Write down countermeasures — specific ones, with a
responsible person’s name and a deadline. - Review — every 2 weeks, or whenever there’s a
significant change in the project.
The Digital Age — PDPC in
the Industry 4.0 Era
In the context of Industry 4.0 and manufacturing digitalization, PDPC
takes on a new dimension. Modern project management tools (Jira, MS
Project, Asana, Miro) allow you to integrate PDPC directly into the
project workflow.
Some advanced organizations combine PDPC with predictive
analytics — analyzing historical data from previous projects and
identifying failure patterns that become inputs for a new PDPC.
AI-assisted PDPC is a reality: algorithms can suggest
potential risks and countermeasures based on project history before the
team even meets. Human judgment still makes the final call, but the
machine surfaces possibilities you wouldn’t have come up with on your
own.
Conclusion — Readiness Is Not
Paranoia
Peter Drucker once said: “Planning does not mean predicting the
future. It means being prepared for it.”
PDPC is the materialization of this principle. It’s not pessimism.
It’s not fear of failure. It’s professional discipline —
the same discipline that makes you carry a spare tire in your car, even
though you’ve never had a flat.
Because when it happens — and sooner or later, it will — you won’t be
scrambling for a solution in a panic. You’ll have one ready.
And that’s the difference between a manager who reacts and a manager
who leads.
Peter Stasko is a Quality Architect with 25+ years of experience in
automotive, manufacturing, and continuous improvement. He helps
organizations build quality systems that don’t just work — they work
intelligently. He believes the best plan is one that accounts for what
could go wrong.
