A PDSA cycle is a structured way to test a change and learn from it: Plan the test, Do it, Study what happened and Act on the learning. In healthcare quality improvement, start with a small, practical test and use the results to decide what to try next before committing to wider implementation.
This guide is part of our series on running a successful QI project. It focuses on designing useful tests, recording learning and linking successive cycles to your project aim.
A useful cycle answers a specific question. It includes a prediction made before the test, a clear description of what will happen, observations that answer the question and a decision about the next step.
The Institute for Healthcare Improvement describes PDSA as a method for learning how a change works in the local setting. Successive tests help a team refine the idea and understand how it performs under different conditions.
Completing an activity is not the same as completing a learning cycle. “We introduced a checklist” describes an action. “We tested whether one colleague could use the checklist before the first appointment, compared the result with our prediction and revised an unclear item” describes a test and its learning.
Choose a change idea that addresses a plausible cause of the problem. Agree why you expect it to help, involve the people who do the work and check that the test is appropriate for the setting.
Your project’s measurement plan tracks the overall outcome, process and balancing measures. An individual PDSA may also need a few focused observations, such as how long a task takes or whether an instruction is understood.
Keep the first question narrow enough to answer. You can learn whether a preparation step is workable in one session; you cannot establish sustained improvement across a service from that session alone.
Write down the change, the people involved, where and when the test will happen, the information you will collect and when you will review it. State what you expect to happen and why. Agree what would make you stop the test or seek help.
Record what actually happened, including departures from the plan, practical difficulties and unexpected effects. Capture observations while they are fresh. If the test could not run, document the reason; that may reveal a dependency to resolve before trying again.
Review the observations with the people involved. What matched your prediction, what differed and what might explain the difference? Consider workload and experience as well as the intended result. Separate what the test showed from what remains uncertain.
Record whether you will adapt the idea, retain it for further testing or abandon it, and explain why. Give the next test an owner and a date. The decision should follow from the learning rather than a desire to show progress.
The following is a hypothetical teaching example, including the observations. It is not a customer case study or evidence of achieved improvement.
A team aims to reduce waiting in adult Tuesday morning general outpatient clinics. It suspects that missing equipment and unclear preparation responsibilities contribute to late starts. Its change idea is a short room-readiness checklist with a named owner.
In this imagined test, the check takes five minutes. One item, “room ready”, is interpreted differently by the colleague and project lead. The checklist also identifies missing equipment, but nobody is clearly responsible for obtaining it.
The prediction was not met. The test suggests that the checklist needs clearer wording and an escalation route. It does not yet tell the team whether patient waits will fall.
The team replaces “room ready” with specific checks and agrees who to contact when an item is missing. It tests the revised version in one room with a different colleague. The next prediction focuses on whether that person can follow the instructions without help.
Once the method is workable, later cycles could involve more rooms, a busier session and cover staff. The team continues reviewing waiting times and balancing measures across sessions to assess the wider effect.
Retain the change when the evidence supports it in the conditions tested. After an early cycle, adoption may mean keeping that version for the next test. Full implementation needs broader evidence and a plan for routine use.
Modify a promising change when the test reveals a practical problem or an assumption that needs revising. State precisely what will change. Repeating the same test without using the learning is unlikely to answer a new question.
Stop pursuing a change when it is inappropriate, creates unacceptable problems or does not offer a credible route to the aim. You do not need to repeat an unsafe or clearly unsuitable test just to complete a set number of cycles. Record the learning so another team does not repeat the same mistake.
Match the observations to the question. A usability test may need timings and comments; a test of a process step may need a count of eligible opportunities and completed actions. Use the agreed data collection method so observations remain interpretable.
Keep the project’s measures visible alongside the test record. Time-series charts can help the team review patterns across the project, but a statistical process control chart is not a requirement for every tiny test. One or two observations cannot establish a sustained shift.
Record other changes happening at the same time. If several ideas are introduced together, it becomes harder to understand which part contributed to the result.
Use these headings for each cycle: project aim; change idea; cycle number; question; prediction and rationale; test scope; owner and date; observations; what happened; comparison with prediction; learning; decision; next test.
Download the PDSA worksheet and healthcare example for an editable Word worksheet to help you plan, record and review your next test.
Long enough to answer the test question and review the observations. An early workflow test might take one session, while other questions require longer. Avoid an arbitrary duration that delays learning or ends before useful observations are available.
There is no fixed number. Continue while important questions remain about how the change works, its effect and its reliability under relevant conditions. The amount of evidence needed depends on the change and the consequences of getting it wrong.
No. An unexpected result can expose an assumption and improve the next test. The value comes from recording and using that learning.
Explore Simana’s PDSA tools to organise cycles and their learning. Continue with maintaining QI project momentum, then use our guide to implementing and sustaining changes when the evidence supports routine use.