Testing change: PDSA and iterative learning

• Explain why PDSA is a method for learning from small tests rather than a label for completed change.
• Design a PDSA cycle with an explicit prediction, operational plan, measures and learning question.
• Choose an appropriate initial scale and sequence tests across different conditions.
• Distinguish testing, implementation and spread, and recognise when a change is not ready for wider adoption.
• Use failed or neutral tests constructively and document learning transparently.

Plan-Do-Study-Act is often reduced to four words on a slide. Used properly, it is a disciplined way of learning how a proposed change behaves in a real system. The purpose of an early cycle is usually not to prove that an intervention “works”, but to reduce uncertainty: Can the test be delivered? What happens to workflow? What do patients and staff notice? What data can be collected reliably? What assumptions were wrong?

A useful PDSA therefore begins with a question and a prediction. “Will a pre-discharge medicines check reduce omitted discharge medicines?” is a learning question. “We will introduce a checklist” is only an action. The first wording makes the team specify what it expects and what it will observe. This is important because improvement teams are vulnerable to confirmation bias: when people have invested time in a change, they can interpret almost any outcome as success.

IHI describes PDSA as action-oriented scientific learning. The cycle should be repeated, with each test informed by the previous one. A sequence of linked cycles is stronger than a single large launch because the team learns about reliability, unintended consequences and contextual differences before hardwiring the change.

Do not start a PDSA simply because the team has an idea. First connect the test to the project aim and to a plausible theory of how the change could influence the outcome. A driver diagram, process map or cause analysis can make that logic visible. If the aim is to reduce delayed antibiotic administration, a change aimed at discharge documentation may be useful work but is not a coherent test of the stated theory.

For each test, define the smallest set of measures needed to learn. This often includes a process measure close to the intervention, a relevant outcome measure if it can change quickly enough, and a balancing measure for foreseeable harm or burden. Qualitative observations are often essential: a technically successful test may still be unacceptable to staff or patients.

The team should also decide what result would lead to adoption, adaptation or abandonment. This avoids post-hoc rationalisation. A prediction can be modest and explicit, for example: “On one morning ward round, using the prompt sheet for five patients will increase documented escalation-plan discussion from the current 40% to at least 80%, without adding more than five minutes to the round.”

A strong Plan phase states who will do what, where, when and for whom. It names the test population, duration, data source, prediction and learning question. It also anticipates practical failure: absence, shift handover, equipment, digital access, competing priorities and the possibility that the eligible patient is unavailable.

Scale should usually be deliberately small at first. A “one patient, one clinician, one shift” test can be entirely appropriate when uncertainty or risk is high. Small tests are not timid; they are a method of containing risk while increasing knowledge. The test can then expand across staff, days, settings and patient groups.

Safety and governance still apply. PDSA is not a route around medication policy, data protection, consent, research governance or professional standards. If the proposed change creates material clinical risk or falls outside normal authority, the team must obtain the appropriate approval before testing.

During the Do phase, record deviations from the plan rather than editing them out of the story. If the nurse who was meant to use the tool was redeployed, the electronic form failed, or the patient declined, those events are data about the system. A PDSA record should distinguish “not done as planned” from “the change was ineffective”.

Keep data collection proportionate. For a tiny test, the most useful evidence may be five observations, completion times, brief staff comments and a count of successful steps. Improvement measurement seeks learning in context; it does not require every test to resemble a research study.

One team member should own the PDSA record. Retrospective reconstruction weeks later is unreliable and commonly produces a tidy narrative that loses the practical detail needed for the next cycle.

Study means more than asking whether the team liked the change. Compare the observed data with the prediction. Look for mechanisms: Why did the change produce this result? Did compliance vary by shift or professional group? Was the outcome influenced by a concurrent change? Did the data reveal a new problem?

For short tests, simple annotated run charts, counts, percentages and qualitative notes may be enough. Avoid overinterpreting random variation. A single improved day does not demonstrate sustained improvement. Equally, a poor result may be caused by an implementation defect rather than a flawed change concept.

Write the learning in plain language. For example: “The prompt worked when the consultant initiated it, but was missed when the round changed leader. We need a cue built into the electronic list rather than relying on memory.” That statement is more useful than “PDSA completed successfully.”

The Act decision converts learning into the next test. Adopt means the change is sufficiently promising to continue in essentially the same form. Adapt means the underlying idea remains plausible but needs modification. Abandon means the specific change should stop; this is not project failure if the test prevented a poor idea from being widely implemented.

Teams often skip directly from a promising first test to implementation. Instead, vary the conditions deliberately: weekday/weekend, experienced/new staff, different clinical areas, high/low workload, digital downtime or patient subgroups. Testing under adverse conditions is particularly useful because reliability problems frequently appear only when the system is stressed.

A good PDSA sequence has a visible learning chain. Cycle 2 should exist because of something discovered in Cycle 1, not simply because the project template asks for another cycle.

Testing asks “does this change appear useful here, and what must we learn?” Implementation makes the change part of routine work. Spread deliberately transfers an implemented change to additional settings or populations. Confusing these stages creates avoidable failure.

Implementation requires more than telling everyone about a successful pilot. It may require standard operating procedures, electronic defaults, training, induction, role clarity, supply chains, monitoring and withdrawal of the old process. IHI emphasises that implementation is a permanent change in how work is done.

Spread is a new improvement problem, not a photocopying exercise. A tool that succeeds on one ward may require adaptation for a community service, pharmacy, laboratory or theatre. Fidelity to the change’s essential function matters more than identical form.

A rehabilitation team finds that referrals for patients with new mobility decline are often made a day late. The aim is to reduce the median time from identification to referral from 18 hours to under 6 hours within eight weeks. A process map suggests that clinicians wait until after the ward round to enter referrals.

PDSA 1 tests a paper prompt on one bay during one ward round. Prediction: at least four of five eligible patients will have the referral entered before the team leaves the bay. Result: four were entered; one was missed because the computer-on-wheels was unavailable. PDSA 2 uses a second device and tests with a different doctor. PDSA 3 replaces the paper prompt with an electronic patient-list cue. PDSA 4 tests the cue during a high-workload Monday round.

The team does not declare success after PDSA 1. It builds confidence that the mechanism is reliable, measures time to referral on a run chart, checks that inappropriate referrals do not increase, and then moves to implementation.

Common failures include cycles that are too large, no explicit prediction, no measurement, retrospective documentation, repeating the same test without learning, and calling full implementation a PDSA. Another failure is “PDSA theatre”: the project already decided what it will do, and the cycles are written afterwards to satisfy a portfolio or governance requirement.

A second problem is testing only in favourable conditions. A change led by its most enthusiastic champion may appear reliable until that person is absent. Deliberately testing with ordinary users and difficult conditions produces more credible learning.

Finally, teams may use PDSA to avoid addressing structural barriers. If staffing, procurement or policy is the true constraint, repeated micro-tests cannot substitute for escalation and system redesign.

Take one change idea from your project. Write a single-sentence learning question and prediction. Define the smallest safe test that could reduce uncertainty within the next seven days. Specify the people, place, time, data and balancing observation. Then state in advance what would make you adopt, adapt or abandon the change.

After the test, write three sentences only: what happened, what you learned and what you will test next. If you cannot identify a meaningful next test, ask whether the project has moved into implementation or whether the change theory needs to be revisited.

Use the Stage 4 PDSA Learning Record to retain the sequence of tests. The record is portfolio evidence because it demonstrates reasoning and learning, not merely activity.

• Writing the PDSA after the intervention has already been implemented.
• Using “staff liked it” as the only evidence.
• Making the first test too large to learn safely.
• Treating a failed test as a reason to hide the cycle rather than a source of learning.
• Spreading a change before testing under varied conditions.

1. Institute for Healthcare Improvement (IHI): Model for Improvement; Testing Changes; Establishing Measures; Implementing Changes. https://www.ihi.org/library/model-for-improvement
2. NHS England: How to improve care-related processes in general practice; Model for Improvement and change principles. https://www.england.nhs.uk/long-read/how-to-improve-care-related-processes-in-general-practice/

Educational reference. Verify current local governance requirements before starting a project.