Choose a healthcare quality improvement (QI) project by finding a problem that matters to patients and staff, checking the evidence, and narrowing it to a process your team can influence. The best starting point is a meaningful, manageable problem with a clear owner and a practical way to measure progress.
This article covers the first step in the setup stage of our guide to running a successful QI project. Use the checklist and project brief below to move from a list of ideas to a project your team is ready to start.
A good QI project idea identifies a gap between the care or service people receive and the care or service you want to provide. It names who is affected, where the problem occurs and why it deserves attention. It also leaves room to learn which changes will help.
For example, “patients wait too long between arrival and consultation in our outpatient clinic” describes a problem to investigate. “Introduce a new booking system” names a solution before the team has established what causes the delays.
Keep these three decisions separate:
The Institute for Healthcare Improvement’s Model for Improvement connects aims, measures and change ideas with testing and learning. Plan–Do–Study–Act (PDSA) cycles help you test changes; they do not replace the work of deciding which problem needs attention.
Start with the experiences of people who use and deliver your service. Ask patients, carers and colleagues where they encounter delays, confusion, repeated work or unreliable processes. Compare these accounts with available information, such as patient feedback, incident themes, audit findings, waiting-time data and staff observations.
Look for recurring problems rather than assuming that a single difficult day represents the whole service. Check your organisation’s priorities and existing improvement work, too. Another team may already be tackling the same issue or have learning you can use.
Write a short statement that identifies the people affected, the setting, the process and the evidence you have. Separate what you know from what you suspect. If staff believe late room preparation causes clinic delays, record it as a possible explanation to investigate, rather than an established cause.
A useful starting format is: “In [setting], [people] experience [problem] during [process]. We know this from [evidence]. It matters because [impact].” If evidence is limited, make gathering a small baseline sample your next action.
Choose an initial scope that is small enough to understand and influence. Define one service, patient group or part of a pathway, and state what is outside the project. “Improve access across the hospital” is much harder to act on than “reduce delays between referral receipt and triage in one outpatient service”.
Small scope does not mean low importance. It gives a team a manageable place to learn before considering wider adoption. Confirm that the people responsible for the process can participate and that someone can help resolve barriers beyond the team’s authority.
Before committing, identify how you could tell whether the situation is improving. Check what data already exists, how consistently it is recorded and how much effort additional collection would require.
For a waiting-time project, you might track time from arrival to consultation alongside patient feedback. You would also consider unintended effects, such as increased staff workload or a longer wait elsewhere in the pathway. You do not need a complete measurement plan yet, but you do need a feasible starting point.
Discuss a shortlist with staff who know the process and people affected by it. Use the same criteria for each idea, make uncertainties visible and record why you chose one project over another. Confirm a project lead, the people needed to get started and the first action before leaving the discussion.
Use these six questions to compare your shortlist. For each idea, record clear evidence, needs checking or not yet feasible, with a short explanation. This is a discussion aid, not a validated scoring tool.
Do not let an easy-to-measure project automatically outweigh a more important problem. If a worthwhile idea is not ready, record what would make it feasible: a smaller scope, access to data, a partner team or sponsor support. Urgent safety concerns should follow the organisation’s escalation process rather than wait for project selection.
This is an illustrative scenario, not a reported project or a claim of results.
An outpatient team is considering three ideas: redesign booking across the hospital, reduce arrival-to-consultation waits in one clinic, or improve appointment information. Patients have raised concerns about waiting, and staff report variation in how clinic sessions start.
The team selects arrival-to-consultation waits for an initial investigation because it addresses a concern patients have raised, has a clear process boundary and involves colleagues who can influence the work. Before confirming the project, they check whether arrival and consultation times are recorded reliably.
The team has chosen a problem to investigate, not committed to a new booking system or another solution. Once it understands the starting point, it can define an aim and develop changes to test.
Copy these prompts into your project document and complete them with your team. Keep the first version short, and mark anything you still need to confirm.
To keep the brief, responsibilities and project updates together, explore Simana’s project management tools.
A good first project addresses a real local problem, involves a process your team can influence and has a manageable scope. Choose work that matters to the people affected and can be measured with the time and resources available.
You need enough evidence to justify investigating the problem and a practical way to understand current performance. Complete baseline data may come later, but agreeing a numerical target without checking the starting point can lead to an unrealistic aim.
Choose and understand the problem first. Keep suggested solutions as hypotheses, then investigate causes and test appropriate changes. Starting with a preferred solution can obscure what patients and staff actually need.
It may be too broad if you cannot name a clear process owner, define who is included or gather useful data within your capacity. Narrow it to one setting, group or process step, while considering how that step affects the wider pathway.
Once you have selected a project, agree the people and support needed to take it forward. Continue with how to assemble an improvement team, then use the evidence you gather to write a clear QI aim statement.
Return to the QI project guide for the full journey through setup, planning, evidence and close-out.