Defining the Problem in Quality Improvement Projects

Why this topic matters

In the complex environment of the NHS, issues can appear multifaceted and overwhelming. Jumping straight to solutions without adequately defining the problem often leads to solutions that don't address the root cause, or worse, introduce new problems. For example, if a ward has long discharge times, simply adding more administrative staff might not be effective if the underlying issue is delayed consultant reviews or a lack of transport availability.

A clear problem definition:

• Focuses effort: It directs the team's energy towards a specific area for improvement.
• Guides data collection: It clarifies what data needs to be collected to understand the problem's scope and impact.
• Prevents 'solutionising': It encourages a deeper dive into causes before jumping to potential fixes.
• Engages stakeholders: A well-articulated problem is easier to communicate and gain buy-in for from colleagues and management.
• Enables measurement: It allows the team to establish baseline data and measure the impact of interventions.

Practical explanation: What makes a good problem statement?

A robust problem statement isn't just a general observation; it's a concise, evidence-backed description of an issue that needs to be resolved. It should clearly state:

1. What the problem is.
2. Where it is occurring (specific ward, clinic, service).
3. When it is occurring (frequency, timeframe).
4. Who is affected (patients, staff, specific demographic).
5. How much/many (quantification of the problem, e.g., X% of patients, Y delays per week).
6. The impact of the problem (e.g., patient harm, staff dissatisfaction, financial cost, inefficiency).

Consider the SMART criteria when formulating your problem statement:

• Specific: Clearly defined, not vague.
• Measurable: Quantifiable or verifiable.
• Achievable: Realistic to address within the project scope.
• Relevant: Aligned with organisational priorities and impactful to patient care or service delivery.
• Time-bound: Often includes a timeframe for the occurrence of the problem you are describing.

Moving from observation to specificity

Many QI projects start with a general observation, such as "Discharges are slow." While this flags an issue, it's not specific enough for a QI project. The process involves drilling down through questioning and data.

• Initial Observation: "Discharges are slow."
• Questioning: Which discharges? How slow? Why are they slow? When and where is this most common? Who is affected?
• Information Gathering: Speak to staff, review patient pathways, look at routine data (e.g., time from 'medically fit for discharge' to actual discharge). Collect qualitative data through interviews or experience-based design methods.

Common pitfalls

Several common traps can hinder effective problem definition:

• Jumping to solutions: Immediately suggesting a fix (e.g., "We need more staff") without understanding the problem's root causes. This bypasses the critical diagnostic phase.
• Being too broad or vague: A statement like "Improve patient care" is too amorphous to guide specific actions or measurement. It needs narrowing to a particular aspect of care or patient group.
• Lack of data/evidence: Basing the problem statement on anecdotes or assumptions rather than hard data. While anecdotes can highlight an issue, quantification is essential for QI.
• Focusing on a symptom, not the root cause: For instance, identifying "frequent complaints" as the problem, rather than investigating why those complaints arise (e.g., poor communication, delayed treatment).
• Absence of impact: Not articulating why the problem matters. What are the consequences for patients, staff, or the organisation?

Step-by-step approach to defining your problem

Step 1: Identify an area of concern

Start with a broad area that you or your team believe needs improvement. This could come from personal experience, patient feedback, incident reports, audit findings, or national guidance (e.g., GIRFT reports, NICE guidelines). Use brainstorming or affinity diagramming with your team.

Step 2: Gather initial qualitative information

Talk to people affected by the problem – patients, carers, and staff. Understand their perspectives and experiences. This helps to triangulate the issue and uncover potential contributing factors. Tools like 'Five Whys' can be helpful in initial probing, though a more formal root cause analysis will come later.

Step 3: Collect preliminary quantitative data

Seek out existing data. This might include:

• Hospital Episode Statistics (HES).
• Local audit data.
• Patient experience surveys (e.g., Friends and Family Test).
• Incident reporting systems (e.g., Datix).
• Local waiting list data or pathway times.

This data helps to quantify the scale and frequency of the problem. If specific data isn't readily available, consider a short, focused data collection effort (e.g., retrospective notes review for a few weeks).

Step 4: Refine the problem statement using the '5Ws and H' and SMART criteria

Synthesise your qualitative and quantitative findings into a concise problem statement. Ask:

• What specifically is the issue?
• Where does it happen?
• When does it happen or has it been observed?
• Who is impacted?
• How much is it happening (quantify it)?
• What is the impact (Why does it matter)?

Step 5: Validate the problem with stakeholders

Share your refined problem statement with key stakeholders – your team, clinical leads, managers, and potentially patient representatives. Ensure it resonates, accurately reflects the issue, and is considered important to address. This validation step is crucial for gaining support and permission for your project.

Example in clinical practice

Let's apply this to a common NHS scenario:

Initial Observation: "Patients are waiting too long in Emergency Department (ED) for a medical review."

Step 1: Area of concern: Long waits for medical assessment in ED.

Step 2: Initial qualitative information: Speaking to ED nurses, patients, and junior doctors reveals frustration. Nurses report patients becoming agitated; junior doctors feel overwhelmed by the volume; patients express anxiety over delays. The 'Five Whys' suggests delays in senior medical decision-making for complex patients.

Step 3: Preliminary quantitative data: A review of ED patient flow data for the last month shows that, on average, patients referred to the medical take wait 4.5 hours from triage to first medical review. For patients over 75, this average wait increases to 6 hours. National targets aim for much shorter waits.

Step 4: Refine problem statement: "In our Emergency Department, patients referred to the medical take currently wait, on average, 4.5 hours from triage to first medical review, with patients over 75 years old experiencing an average wait of 6 hours. This delay affects approximately 30% of ED attendees and contributes to ED overcrowding, increased patient anxiety, and a poorer patient experience, particularly for vulnerable older adults."

• What: Long wait times for medical review.
• Where: Emergency Department, specifically for patients referred to the medical take.
• When: Currently/On average (based on last month's data).
• Who: Patients referred to medical take, particularly those over 75.
• How much: Average 4.5 hours (6 hours for >75s), affecting ~30% of ED attendees.
• Impact: ED overcrowding, increased patient anxiety, poorer patient experience.

Step 5: Validate: This problem statement is presented to the ED consultant lead, medical registrar, and matron. They agree it accurately reflects a critical operational and patient safety issue that aligns with Trust priorities. The project gets the green light.

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

How Lazomis can help

Lazomis provides structured templates and frameworks within its QI project setup module, guiding you through the problem definition phase. Our tools prompt you to consider the '5Ws and H' and to quantify your problem with data before moving on. You can easily record your initial observations, gather stakeholder input, and track your preliminary data, ensuring a clear and robust problem statement for your project. The platform also facilitates sharing your problem statement with team members and sponsors for validation and feedback, streamlining the initial project setup phase.

Key takeaways