Use a PDSA cycle to test one process change: predict what will happen, try it within a limited scope, study the result against the prediction, and decide what to do next. Before starting, name the owner, the evidence you need, the conditions that stop the test and the fallback for unfinished work.
“We’ll try it this week” sounds temporary. Three weeks later, the team may still be doing it, with nobody able to say whether it helped. A PDSA cycle gives that experiment an end point and a decision.
The change does not need software. It might alter when an internal review happens, remove a redundant step or change the order of two existing tasks.
Quick answer: how does a PDSA cycle work?
PDSA means Plan, Do, Study, Act. For process improvement, each stage should leave something the next stage can use.
| Stage | What happens | What you retain |
|---|---|---|
| Plan | State the prediction, scope, evidence and protection before changing work | An authorized, time-limited test charter |
| Do | Run the agreed change and capture what actually happens | Case observations, deviations and any rescue effort |
| Study | Compare observations with the prediction and examine surprises | A scoped finding, including what remains unknown |
| Act | Choose repeat, revise, stop or expand | A named decision and, if continuing, the next bounded test |
The W. Edwards Deming Institute explains in PDSA Cycle that Deming emphasized predicting results, studying actual results and comparing them to potentially revise the theory. That learning emphasis matters: completing the planned activities does not establish that the idea worked. The charter below applies the method to everyday business work; it is not a validated performance benchmark.
This guide assumes one improvement has already been selected. If several changes still compete for time, use How to Prioritize Process Improvements. Software construction and rollout belong in How to Automate a Business Process; this test can run without changing any system.
What should you write before starting a PDSA test?
Write a short charter that makes the prediction testable and the exposure finite. Someone outside the experiment should be able to tell what changed, which work it touches and who can end it.
A useful prediction has this shape:
If we change this part of the process for these cases, we expect this observable result, because of this explanation. We also expect these other conditions to remain acceptable.
“Improve turnaround” is an aim. “An earlier review window will reduce waiting without extra chasing” is a theory you can test, once waiting and chasing have agreed definitions.
The baseline must use comparable work and the same definitions as the test. If those do not exist, establish them with How to Measure a Business Process rather than reconstructing a favorable before-picture afterward.
| Charter field | What the owner must settle before starting |
|---|---|
| Question and change | What uncertainty are we testing, and what single change will we make? |
| Prediction | What result do we expect, by when, and why? What finding would contradict it? |
| Eligible work | Which cases, people and location are included? Which cases remain on the existing path? |
| Exposure limit | Maximum cases, start and end dates, and any time or cost limit; specify which limit ends entry first |
| Comparison and evidence | Baseline reference, unchanged definitions, case log, collector and observation end date |
| Guardrails | What must not worsen, what triggers a pause, and who checks while work is live? |
| Ownership and fallback | Who authorizes and runs the test, who can stop it, and who takes unfinished cases back to a safe path? |
| Review and next decision | Named reviewer, actual review date, and conditions for repeat, revise, stop or expand |
Keep this beside the existing work record. A test does not need its own reporting system.
Permission to experiment is still permission with limits. Required safety, security, financial or legal controls stay in force. A low case count does not make an irreversible consequence safe; high-consequence changes need the responsible specialist’s authorization and a suitable testing environment.
Plan: an example with a limited review window
Consider an invented example, not a client result. A service team has selected a small change to its internal completed-job-pack review: add an 11 a.m. review to the existing 3 p.m. review. The required checks and release authority will not change.
The proposed explanation is that one daily batch leaves otherwise-ready packs waiting. Adding a review window may shorten that wait. It may also interrupt the reviewer twice without helping enough to justify it.
Their charter could say:
Question: Does the additional review window reduce waiting without needing coordinator reminders?
Prediction: Among eight eligible packs, no more than two will wait over four business hours from readiness to completed review, compared with four of the previous eight comparable packs. No reminders will be needed. Added reviewer effort will stay within twenty minutes across the test.
Scope and limit: One coordinator, one reviewer and routine internal packs only. Enroll from Monday morning until the eighth pack or Thursday noon, whichever comes first. Urgent, incomplete and nonstandard packs stay on their existing authorized paths.
Evidence: The coordinator logs each eligible pack’s readiness and review times, reminders, rework and status. The reviewer records added effort and any effect on other commitments. Follow enrolled packs through Friday noon, retaining unfinished cases.
Guardrails and stop: Required checks remain unchanged. A bypassed check, threatened existing commitment or effort beyond the twenty-minute cap pauses the test immediately. Either participant can pause it and notify the operations lead.
Fallback: The coordinator identifies every open test pack; the reviewer resumes the prior 3 p.m. routine, with the operations lead resolving any case that cannot safely wait. Nobody repeats a completed review just because the schedule reverted.
Decision: The operations lead reviews the record on Friday afternoon and authorizes any next test. No continuation by silence.
The numbers are local illustrative choices, not recommended sample sizes or industry targets. In a real charter, replace role labels and weekday shorthand with names and calendar dates. The participants also need to agree what “business hours,” “ready,” “completed review” and “added effort” mean before using the comparison.
This plan changes review timing only. It does not also rewrite the checklist, move the records and reassign the reviewer. If several things change together, the team will have a harder time explaining the result.
Do: keep the awkward cases in the record
Before the first case enters, the runner checks that participants understand the boundary and can use the fallback. A backup person must be named if the runner or reviewer will be absent. If no authorized cover exists, new test entry pauses.
During the test, the log can remain small:
| Case reference | What was actually done | Observed result | Deviation, rescue or side effect |
|---|---|---|---|
| Existing authorized record ID | Test method followed, changed or bypassed | Agreed measures and current status | Extra reminder, interruption, correction, stop or fallback |
Customer details can stay in their authorized system. The test log needs traceable references, not copied sensitive records.
Record help that makes the change look successful. If the founder personally chases a review, that effort belongs beside the result. Otherwise, the experiment measures the founder’s intervention rather than the proposed process.
An unexpected deviation may be useful learning, but it is not permission to quietly change the method. The runner notes what happened and checks whether the charter still permits continuation. A material change to the test needs a revised prediction and boundary before more cases enter.
On reaching the entry limit, stop adding cases. Existing work still needs an owner and safe completion. The observation window may continue after enrollment closes; that is why the charter distinguishes the two dates.
Study: compare the prediction with what happened
The study starts with the original prediction, not with a fresh definition of success. Put expected and observed results side by side, then ask what could explain the difference.
Suppose all eight packs in the invented test complete review by the observation deadline. The record shows:
| Prediction | Illustrative observation | What it permits you to say |
|---|---|---|
| No more than two packs wait over four business hours | Two exceed that threshold | The local waiting condition was met in these cases |
| No coordinator reminders | Three packs require a reminder | The prediction of an unprompted review routine was not met |
| No more than twenty added reviewer minutes | Eighteen added minutes | Recorded reviewer burden stayed within the cap |
| Required checks and existing commitments remain protected | No breach recorded during these cases | No observed breach in this limited exposure; not proof of universal safety |
The result is mixed. Waiting improved in the observed comparison, but the test still needed chasing. Expanding it unchanged would carry that unresolved dependency into more work.
The operations lead should ask whether the earlier window occurred as planned, whether pack complexity differed and whether the reminders explain the apparent gain. A short before-and-after comparison does not, by itself, establish causation. It can still reveal enough to decide what to test next.
Missing evidence must remain visible. If only three eligible packs arrived, say three, not eight. If two remain open, keep their status and elapsed waiting in the record rather than reporting only the completed cases. When a relevant condition never occurred, the test has not answered that part of the question.
Act: choose repeat, revise, stop or expand
The decision should follow what the test taught you, including evidence that weakened the original explanation. These four dispositions keep “continue” from meaning several different things.
| Verdict | When it fits | What must happen next |
|---|---|---|
| Repeat | The method remains plausible, but exposure or evidence was insufficient | Name the missing observation, renew the limits and set another review date |
| Revise | A specific part of the method or prediction needs changing | Explain the revision and start a new, bounded cycle |
| Stop | Harm, burden, impracticality or contradictory evidence makes this approach unsuitable | Activate the fallback, account for open work and retain the learning |
| Expand | The prediction and guardrails hold within the observed scope, and wider learning is justified | Authorize one wider dimension with new limits and a new prediction |
For the review-window example, revise is the defensible next step. The lead might agree an explicit responsibility for checking the ready queue at the added window, then test whether it happens without reminders. That is a proposed next experiment, not evidence that the revised method will work.
Expansion is not automatic adoption. Another team, a larger volume or a different case type introduces conditions the first cycle did not examine. Wider rollout and permanent standard changes require their own authorization. How to Standardize a Business Process covers the default path and permitted variation; this charter only records what the test supports.
Close the cycle with a short note: original prediction, actual exposure, findings, chosen verdict, unresolved question, responsible person and next date. Confirm where open cases went and which working instruction now applies. The team should not have to guess whether the experiment is still running.
If the test exposes broader unclear ownership, repeated rescues or conflicting records, Download the Operational Drag Diagnostic Kit. The charter above remains usable on its own.
Frequently asked questions
How long should a PDSA cycle last?
Long enough to observe the condition you intend to learn about, within an acceptable exposure limit. A daily activity and a monthly exception need different windows. Set the review date in advance; insufficient cases should produce an explicit decision, not an indefinite extension.
Is one successful cycle enough?
It may support a narrow next step, but it does not establish performance across untested people, workloads or case types. Record the conditions observed and the uncertainty that remains before increasing exposure.
Is PDSA the same as PDCA?
They are related four-stage improvement cycles. The Deming Institute distinguishes PDSA by its emphasis on studying actual results against predictions and revising the underlying theory. For this test, preserve that learning step rather than treating “Study” as a task-completion check.
Can a failed prediction still produce a useful cycle?
Yes. Discovering that a change requires constant rescue, shifts burden elsewhere or fails under an ordinary condition can prevent a poor rollout. Preserve the evidence and change the next decision accordingly. A useful lesson does not make a harmful result acceptable.
When a test crosses teams and nobody can authorize its limits or own the fallback, Book a SYSIPHANY discovery call. Bring the proposed change and the unresolved responsibility. Resolve that boundary before exposing more work.