Almost every healthcare improvement professional has heard of PDSA cycles. Many organisations use them. Many improvement projects include them. Many teams are asked to complete them. And yet, in practice, PDSA cycles often do not deliver the learning they are supposed to.
Instead of becoming a fast, practical way to test change, they can become paperwork completed after the event. A form to fill in. A requirement to satisfy. A record of what happened, rather than a tool for deciding what to do next. That is a missed opportunity.
PDSA cycles are one of the most powerful tools in healthcare improvement because they help teams test ideas, reduce risk, and learn quickly. But only when they are used for their intended purpose. The challenge is not usually that PDSA is too complicated. The challenge is that teams often misunderstand what it is for.
Structured testing through PDSA cycles is one of the defining characteristics of a high-quality improvement project. If you’re interested in the wider anatomy of successful improvement work, read our guide to What Does a Good Quality Improvement Project Look Like in Healthcare?
A PDSA cycle is a structured way to answer a simple question: Will this change actually work?
It helps teams test an idea before implementing it more widely.
The four stages are familiar:
Plan: Decide what you are going to test, what you think will happen, who will be involved, and what data or feedback you will collect.
Do: Carry out the test on a small scale.
Study: Review what happened. Compare the result with what you expected. Look at the data, feedback, and learning.
Act: Decide what to do next. Adapt the change, test it again, scale it slightly, or abandon it if it is not helpful.
At its best, PDSA is not a documentation exercise. It is a learning process. The purpose is not to prove that an idea was right. It is to learn whether the idea is useful, what needs to change, and whether it is ready to be tested again.
One of the biggest misconceptions is that PDSA happens after the team has already decided what the solution is. The thinking goes something like this: “We know what needs to happen. Now we need to complete a PDSA.”
But PDSA is not simply a way to record an implementation. It is a way to test a change before full implementation. For example, imagine a team wants to improve discharge communication by introducing a new checklist. A common approach would be to roll out the checklist across the whole ward and then review whether it worked.
A better PDSA approach would be to test the checklist:
That smaller test allows the team to learn quickly. Was the checklist easy to use? Did it contain the right information? Did it fit into the workflow? Did staff understand when and how to use it? Did it create any unintended problems?
A PDSA cycle tests an idea. It does not assume the idea is already right.
Healthcare often defaults to large-scale action. If a problem is important, it can feel natural to design a substantial intervention and roll it out widely. But in improvement work, bigger is not always better. Small tests often produce faster and safer learning.
A good first PDSA might involve:
This can feel too small at first. But small tests are powerful precisely because they are small. They reduce risk. They make it easier to observe what happens. They allow teams to adapt quickly. They also make it easier for busy frontline staff to participate without feeling overwhelmed. In healthcare settings, where teams are already under pressure, this matters.
A small test is not a lack of ambition. It is a practical way to learn before scaling. Or, put simply: Learn small before you scale big.
One of the biggest cultural barriers to effective PDSA is the fear of failure. Teams may feel that if a change did not work, the PDSA failed. But that is not how improvement works. If a test generates useful learning, the PDSA has done its job.
For example, a team might test a new handover prompt and discover that it adds time without improving clarity. That does not mean the PDSA failed. It means the team learned something important before investing more time in a wider rollout. They might then adapt the prompt, simplify it, test it with a different staff group, or decide that a different change is needed. That learning is valuable.
The real failure is not when a test does not work. The real failure is when teams implement changes without testing, learn too late, or repeat the same mistakes because learning was not captured. This links closely to how teams think about measurement.
If data is used for judgement, teams may feel exposed when results are disappointing. If data is used for learning, results become information that helps teams decide what to do next. That distinction is critical.
Every PDSA cycle should be supported by simple, meaningful measures. If measurement often feels like the hardest part of improvement work, we’ve explored practical ways to simplify it in our article Why Measurement Feels Hard in Healthcare Improvement and How to Simplify It.
PDSA documentation matters. But it is not the most important part.
In some organisations, PDSA has become associated with templates, forms, and project records. This can lead teams to focus more on completing the documentation than on designing a useful test. Good documentation should be simple.
It should capture:
That is enough.
The purpose of documentation is to make learning visible and reusable. It should help the team remember what they tried, understand why decisions were made, and build on previous tests. When PDSA cycles are stored in isolated documents or personal files, that learning can be lost. When they are captured in a shared improvement platform like Life QI, they become part of the wider project story. The team can see how each test connects to the project aim, measures, and next steps. Leaders and improvement coaches can also see where support may be needed. This is where the right infrastructure matters.
PDSA is not just about recording activity. It is about building a chain of learning.
Effective PDSA cycles tend to share a few characteristics.
They are small.
The test is limited enough to be manageable and safe.
They are fast.
The team can learn something quickly, often within days rather than weeks.
They are measured.
There is some way to understand what happened, even if the measure is simple.
They are collaborative.
The people affected by the change are involved in testing it.
They are iterative.
One cycle leads naturally to the next.
They are documented.
The team captures the prediction, result, learning, and next action.
They are shared.
Learning is visible to others who may benefit from it.
This final point is often overlooked.
In large healthcare organisations, different teams may be testing similar changes in different areas. If learning stays local, teams risk duplicating effort or missing useful insight. When PDSA learning is visible across projects and teams, improvement becomes more connected. One team’s learning can help another team move faster.
One PDSA cycle rarely gives a complete answer. The value comes from running multiple linked cycles that build on each other.
For example, a team improving discharge communication might follow a sequence like this:
Cycle 1: Test a checklist with one patient and one nurse.
Learning: The checklist is useful but too long.
Cycle 2: Test a shorter version on one bay during one shift.
Learning: Staff use it more consistently, but the timing needs adjusting.
Cycle 3: Test the checklist earlier in the discharge process.
Learning: It works better when started at morning board round.
Cycle 4: Test with a second team.
Learning: The approach is transferable but needs minor changes for local workflow.
This is how improvement builds.
Not through one perfect intervention, but through repeated cycles of testing, learning, and adapting. This is also why visibility and continuity matter. If each cycle is documented in a different place, or if learning depends on one person remembering what happened, the project becomes fragile. A shared system helps preserve the story of the work. It shows how thinking evolved, what was tested, and why the final approach looks the way it does.
If PDSA cycles are not producing useful learning, the tests may be too large.
Common warning signs include:
If these signs sound familiar, the project may not be running tests. It may be implementing changes and calling them PDSA cycles afterwards.
A useful question to ask is: What is the smallest version of this change we could test this week?
That question helps teams move from planning to learning.
PDSA is not about completing a template. It is about reducing uncertainty.
It helps teams answer practical questions:
The best improvement teams do not treat PDSA as a bureaucratic step. They treat it as a rhythm of learning. They test small. They learn quickly. They adapt. They test again. Over time, this creates confidence. It also makes improvement safer, more practical, and more likely to succeed.
Healthcare improvement is complex because healthcare itself is complex. Changes that look simple on paper often behave differently in practice. Workflows vary. Staff roles differ. Patients have different needs. Departments depend on one another in ways that are not always obvious at the outset.
That is exactly why PDSA matters. It gives teams a way to learn in the real world, with real people, in real settings. But to work well, PDSA needs to be used as intended. Not as paperwork. Not as proof that an implementation happened. Not as a one-off exercise. As a practical method for testing change.
When teams run smaller tests, measure simply, document learning, and make that learning visible, PDSA becomes one of the most useful tools in healthcare improvement. Because meaningful improvement rarely happens in one big leap. It happens through repeated, thoughtful steps.
Learn small before you scale big.
If you found this article useful, you might also like:
→ Why Quality Improvement Projects Fail in Hospitals (And How to Prevent It)
→ How to Prioritise Healthcare Improvement Projects for Maximum Impact
→ What Does a Good Quality Improvement Project Look Like in Healthcare?
→ Why Measurement Feels Hard in Healthcare Improvement and How to Simplify It