Testing Change on a Small Scale in the NHS: A Practical Guide

Why this topic matters

Healthcare environments are complex adaptive systems. Any change, no matter how well-intended, can have ripple effects throughout a department or entire organisation. Without careful testing, a seemingly straightforward improvement can unexpectedly disrupt workflow, increase workload elsewhere, or even compromise patient care. The 'do it once, do it right' mentality, while admirable, can be detrimental in QI if it means skipping iterative testing.

Testing on a small scale allows teams to:

• Mitigate risk: Identify potential problems and unintended consequences in a controlled environment before widespread implementation.
• Optimise the change: Refine the intervention based on real-world feedback and data, ensuring it is fit for purpose and addresses the identified problem effectively.
• Build engagement and buy-in: Involving a small group of frontline staff in the testing phase fosters ownership and generates champions for the eventual wider rollout.
• Gather data and evidence: Collect practical data on feasibility, effectiveness, and impact, providing a robust evidence base for decisions.
• Reduce waste: Avoid investing significant resources (time, money, effort) in a change that proves ineffective or impractical on a larger scale.

Practical explanation: The 'Small Scale' Principle

Testing change on a small scale is fundamentally about using Plan-Do-Study-Act (PDSA) cycles, but with a deliberate focus on starting incredibly small. It's about learning rapidly with minimal disruption. The principle is to reduce the scope of the test in three key dimensions:

1. Scale (How many?)

Start with the smallest practical number. This might mean:

• One patient: Test a new assessment tool on a single patient.
• One staff member: A single nurse trying a new documentation method for a shift.
• One specific time: Implementing a new handover process for a single morning shift.
• One location: Testing a new ward rounds structure on one ward only.

The idea is to choose a unit of testing that is manageable, allows for quick observation, and doesn't create significant risk if it doesn't go as planned.

2. Time (How long?)

Keep the initial test period very short. A common pitfall is planning a test over several weeks or months for the first cycle. Instead, aim for:

• One hour: Observe a new process for an hour.
• One shift: A new approach to managing a specific task for a single shift.
• One day: Testing a revised discharge checklist for all patients discharged on a single day.

Short test cycles allow for rapid learning and adaptation. If a change doesn't work, you've lost minimal time. If it does, you can quickly move to the next, slightly larger, test.

3. Scope (How broad?)

Narrow the focus of what you are testing. Don't try to change everything at once. Identify the most critical element of your proposed change and test that first.

• A specific part of a process: Rather than a whole new clinic pathway, test just the booking element.
• One aspect of a new form: Test only the demographic section of a new patient form, not the entire form.
• A particular type of patient: Introduce a new protocol only for patients with a specific, stable condition.

By limiting the scope, you can isolate variables and better understand what works and what doesn't.

Common pitfalls

Even with the best intentions, teams can stumble when testing changes. Awareness of these common pitfalls can help in avoiding them:

• Testing too broadly, too soon: The most frequent error. Attempting to test a change across an entire department or for all patients in the first cycle. This increases risk and makes it harder to learn.
• Lack of clear objectives for the test: Not knowing what you want to learn from the test. A test without a specific question or hypothesis is unlikely to yield useful results.
• Insufficient data collection: Failing to plan how to measure the impact of the test. Subjective feelings are useful, but hard data on specific metrics (e.g., time taken, errors made, patient satisfaction scores) is crucial.
• Ignoring negative results: Only focusing on positive outcomes. A test that reveals problems or failures is often the most valuable, as it guides refinement.
• Skipping the 'Study' phase: Rushing from 'Do' straight to 'Act' (re-planning) without properly analysing what happened, why, and what was learned.
• Lack of frontline involvement: Designing a change and testing it without input from those who will actually implement it. This often leads to impractical or unworkable solutions.
• Not planning the next step: Completing a test but not having a clear idea of what the next PDSA cycle will entail (e.g., refine, adapt, abandon, scale up).

Step-by-step approach to testing change on a small scale

This framework integrates the principles of small-scale testing within the classic PDSA cycle.

Step 1: Plan your first small test (P)

• State your aim: What problem are you trying to solve? What specific improvement do you want to achieve?
• Define your proposed change: What exactly are you going to do differently?
• Formulate your test question(s): What do you want to learn from this specific test? (e.g., "Will using this new handover template for one patient at the morning handover save 5 minutes?").
• Specify the small scale: Who, what, when, where will the test take place? Be very precise. (e.g., "Nurse Smith will use the new template for Mr. Jones's handover on Tuesday morning, 08:00-08:15, on Ward B.")
• Predict the outcome: What do you expect to happen? This helps in analysing results.
• Determine data collection: How will you measure the outcome? What data do you need? Who will collect it? (e.g., time taken, number of specific issues identified, qualitative feedback).

Step 2: Do the small test (D)

• Implement the change: Carry out the test exactly as planned, in the specified small scale.
• Collect data: Record observations, measurements, and any unexpected occurrences or feedback from those involved.
• Observe and document: Pay attention to what works, what doesn't, and why.

Step 3: Study the results (S)

• Analyse the data: Compare your actual results with your predictions. What did you find?
• Review observations: Discuss what happened with those involved in the test. What went well? What went wrong? Why?
• Identify learnings: What did you learn about the change itself, the process, the team, or the system? Were there any unintended consequences?
• Reflect and conclude: Based on the evidence, what does this tell you about the change? Is it viable? Does it need modification? Is it having the desired effect?

Step 4: Act based on learning (A)

• Decide on the next steps: Based on what you learned, what will you do next?
  • Adapt: Make modifications to the change based on the test and run another, slightly larger, PDSA cycle.
  • Adopt: If the change worked perfectly and is ready for wider implementation (unlikely after one small test), plan for broader rollout.
  • Abandon: If the change was ineffective or detrimental, stop and rethink your approach to the problem.
  • Expand: If the small test was successful, plan the next PDSA cycle with a slightly increased scale (e.g., two patients, two staff, an entire shift).
• Plan the next PDSA cycle: Use the insights from the 'Study' phase to inform the 'Plan' for your next iteration. This continuous loop of learning and refinement is key.

Example in clinical practice: Reducing delays in ED discharge

A multidisciplinary team in an NHS Emergency Department identifies a problem with patient discharge delays, particularly for those awaiting transport or medication. They decide to focus their initial QI effort on improving the efficiency of medication delivery for discharged patients.

Proposed Change:

Implementing a 'rapid discharge pharmacy pack' system for certain low-risk patients, allowing nurses to prepare discharge medications from a pre-approved stock before a pharmacist review.

Initial Small Test (PDSA Cycle 1):

• Plan (P):
  • Aim: Reduce medication-related discharge delays for low-risk patients.
  • Change: Use the 'rapid discharge pharmacy pack' for one patient.
  • Test Question: Can Nurse A successfully use the new pack to prepare discharge medications for one patient within 15 minutes of the decision to discharge?
  • Scale: One patient (Mr. Williams), one nurse (Nurse A), one shift (Tuesday afternoon), one location (Resus cubicle 4).
  • Prediction: Nurse A will be able to prepare the medications and documentation within 15 minutes.
  • Data: Time taken to prepare, nurse feedback on usability, any errors identified by pharmacist review.
• Do (D): Nurse A uses the pack for Mr. Williams. Records start/end times. Notes any difficulties. Pharmacist checks completed pack.
• Study (S):
  • Results: Time taken was 25 minutes. Nurse A found the pack incomplete for one common medication. Documentation was complex.
  • Learnings: The pack needs revision for completeness. The documentation process requires simplification. The 15-minute target was ambitious for the first use.
• Act (A): Revise the contents of the pack and simplify documentation. Plan PDSA Cycle 2 to test the revised pack with two patients and two nurses, with a new target time of 20 minutes.

This iterative process allows the team to refine the change with minimal disruption, identifying and addressing issues before a wider rollout.

How Lazomis can help

Lazomis provides a structured environment to support your small-scale testing and PDSA cycles:

• Project Planning Tools: Our QI project setup templates guide you through defining your aim, proposed change, and specific test questions for each PDSA cycle.
• Data Collection Forms: Customisable forms can be configured to capture the specific data points needed for your small-scale tests, from timings to qualitative feedback, ensuring consistent and relevant information gathering.
• Dashboards & Reporting: Visualise your test results rapidly, allowing for quick analysis of 'Study' phase data and informing your 'Act' decisions. Track progress across multiple, sequential PDSA cycles.
• Documentation & Collaboration: Centralise your PDSA cycle documentation, making it easy to share learnings with team members, track iterations, and build a comprehensive record of your improvement journey.

This resource supports, but does not replace, clinical judgement. Local policy, formulary and specialist advice should be followed.

Key takeaways

• Testing change on a small scale is essential for safe and effective quality improvement in the NHS.
• Begin with the smallest practical scope: one patient, one staff member, one shift, or one specific location.
• Utilise the Plan-Do-Study-Act (PDSA) cycle as your framework for iterative learning.
• Clearly define what you want to learn from each small test and how you will measure it.
• Embrace findings from tests that reveal problems; these are crucial opportunities for refinement.
• Document your process, observations, and learning from every test to inform the next steps.