Process Decision Program Chart

Turn a preferred plan into a resilient operating path by preparing for plausible problems before they become surprises.

In one minute

A Process Decision Program Chart (PDPC) extends a plan with two questions:

1. What could go wrong at this step?
2. What will we do if the warning condition appears?

The chart typically connects:

Objective → planned activity → possible problem → countermeasure → trigger and owner

PDPC is not a catalogue of every imaginable failure. It focuses attention on plausible disruptions that could materially prevent the plan from achieving its objective.

Best for: new implementations, migrations, AI pilots and cross-functional plans with consequential exception paths.
Avoid when: the team needs to diagnose an incident, quantify a broad risk portfolio or replace emergency response procedures.

The problem it addresses

Plans are usually drawn as a happy path. Problems are handled informally after launch, so teams improvise under time pressure and users encounter inconsistent recovery.

PDPC makes contingency thinking part of the plan. It links warning signals, preventive actions, response actions and ownership to the exact activity where a problem may arise.

When to use it

Use PDPC when:

• a decision has been made and implementation needs stress-testing;
• an AI agent will cross a data, approval or action boundary;
• the plan depends on several teams or suppliers;
• rollback, fallback or escalation must be ready before launch;
• unusual cases could stop progress or cause harm;
• a pilot needs explicit go, hold and stop triggers.

Start with the planned path; otherwise the contingency tree has no stable reference.

When not to use it

Do not use PDPC:

• as a substitute for FMEA across an entire product or process;
• to investigate why a past failure occurred;
• to record risks without executable countermeasures;
• when a countermeasure has no trigger or owner;
• to create an unreadable tree of remote possibilities;
• to bypass formal safety, security or incident-response requirements.

Use Root Cause Analysis for causal investigation and FMEA for systematic prospective failure analysis.

Inputs required

• a chosen objective and implementation boundary;
• the planned activities and dependencies;
• people who perform and receive the work;
• relevant incident, exception and near-miss evidence;
• mandatory controls and authority limits;
• warning signals and monitoring capability;
• owners able to execute countermeasures;
• rollback, escalation and communication channels.

Step-by-step process

1. Define the objective and success conditions

State what the plan should accomplish and which quality, safety or customer conditions must remain true.

2. Draw the planned activity path

Show the major sequence from preparation through completion. Keep activities at a consistent level and include hand-offs or decisions that create meaningful exposure.

3. Identify plausible problems

For each activity, ask what could prevent, delay or corrupt the intended result. Use evidence, analogous experience and structured challenge. Write a specific observable problem rather than “system issue.”

4. Select material problems

Focus on problems with credible likelihood, serious consequence or difficult recovery. Mark unknowns that require a test before launch.

5. Design preventive countermeasures

Where practical, change the plan so the problem is less likely: validate inputs, sequence work differently, restrict permissions, rehearse migration or reduce scope.

6. Design response countermeasures

Define what happens when prevention fails. Include hold, fallback, manual route, rollback, escalation, user communication and recovery evidence.

7. Attach triggers and owners

Every countermeasure needs an observable trigger, monitoring source, authorised owner and response time. “Watch closely” is not operational.

8. Test the branches

Run tabletop scenarios or controlled simulations. Verify that people can detect the trigger, access the fallback, exercise authority and restore a trustworthy state.

9. Integrate with the operating plan

Move approved countermeasures into procedures, monitoring, launch criteria and ownership records. The PDPC should not remain a workshop-only image.

10. Review during implementation

Record which branches occurred, whether countermeasures worked and what new problems appeared. Update the chart for the next stage or rollout.

AI automation lens

For an AI agent, map the complete action chain:

• receive request;
• retrieve permitted evidence;
• generate or classify;
• validate required conditions;
• request approval when necessary;
• execute a bounded action;
• record outcome and monitor exceptions.

Possible problems include missing retrieval evidence, prompt injection, low-confidence output, tool unavailability, duplicate action, permission mismatch, reviewer overload and inability to reverse.

Countermeasures should be enforced in the surrounding workflow where possible: allowlists, read-only defaults, schema validation, idempotency, abstention, human escalation, audit and rollback. Prompt wording alone is not a reliable contingency plan.

Visual model

Text alternative: an implementation objective branches into prepare, pilot and scale activities. Each activity has a possible-problem branch connected to prevention, trigger, owner and response countermeasure. The AI path includes abstention, manual fallback and rollback before scale.

Interactive example

Scenario

A company plans to let an AI assistant update CRM opportunity stages after sales calls. The happy path is: transcribe → extract evidence → propose stage → manager approves → CRM updates.

Known concerns include missing call consent, ambiguous customer intent, duplicate updates after timeout and managers approving without reading the evidence.

Your move

Add problem branches, triggers and countermeasures to the plan.

Worked answer

• Problem: consent is missing. Trigger: no valid consent record. Countermeasure: stop transcription and route the call for manual notes.
• Problem: evidence does not support one stage. Trigger: conflicting signals or missing cited passage. Countermeasure: abstain and keep the current stage.
• Problem: update request times out. Trigger: no confirmed transaction ID. Countermeasure: query status using an idempotency key before any retry.
• Problem: approval becomes superficial. Trigger: correction or reversal rate exceeds the pilot limit. Countermeasure: pause live updates, return to proposal-only mode and review interface evidence.

The operations owner can pause the pilot. Technology owns rollback, and sales managers own case correction within one business day.

Facilitation notes

• Begin from a real plan and objective.
• Keep problem statements specific and observable.
• Use operators and affected teams to challenge the happy path.
• Separate prevention from response.
• Require a trigger, owner and response time.
• Test at least one uncomfortable branch before launch.
• Move accepted countermeasures into the operating system.

Expected output

A sound application produces:

• a defined objective and activity path;
• material possible-problem branches;
• preventive and response countermeasures;
• observable triggers and monitoring sources;
• authorised owners and response times;
• tested fallback and rollback routes;
• an updated implementation plan.

Common mistakes

1. Mapping only the happy path. The chart adds no resilience.
2. Listing generic risks. “AI error” cannot trigger a specific response.
3. Designing countermeasures without owners. Response depends on improvisation.
4. Using warnings instead of controls. The failure opportunity remains unchanged.
5. Ignoring recovery. The workflow can stop but cannot restore service.
6. Treating prompt text as enforcement. Permissions and fallback remain unprotected.
7. Keeping PDPC outside the launch plan. Useful decisions never reach operations.

Quality checklist

• The objective and success conditions are explicit.
• Major activities and dependencies are visible.
• Problems are plausible, specific and observable.
• Material branches are prioritised.
• Prevention and response are distinguished.
• Every response has a trigger and monitoring source.
• Owners have authority and response-time expectations.
• AI fallback and rollback are executable outside the prompt.
• Branches are tested and integrated into the plan.

Template

Objective and success conditions:

Stop and rollback authority:

Branches to simulate before launch:

Knowledge check

A team writes “monitor AI quality closely” as a countermeasure. What is missing?

A. A more colourful diagram.
B. An observable trigger, monitoring source, authorised owner and executable response.
C. A larger model.
D. A promise that no errors will occur.

Answer: B. A contingency becomes operational only when the signal and response are explicit.

Related tools

• Follows: Kepner-Tregoe Decision Analysis, Vroom-Yetton-Jago Decision Model
• Risk input from: FMEA, Mistake Proofing
• Test through: PDCA/PDSA Cycle
• Not to be confused with: a process map, decision tree, risk register or incident runbook

References

1. American Society for Quality. “Seven Management and Planning Tools.” Authoritative overview (opens in a new tab).
2. Mizuno, S., ed. Management for Quality Improvement: The Seven New QC Tools. Productivity Press, 1988.
3. Brassard, M. The Memory Jogger Plus+: Featuring the Seven Management and Planning Tools. GOAL/QPC, 1989.
4. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, 2023. Official publication (opens in a new tab).
5. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1, 2024. Official publication (opens in a new tab).

Sources reviewed 12 August 2026.