How to: Quality

Welcome to the series of How To:Quality. Your 3 min guide on how Quality Professionals address various business needs to drive Improvement and Governance.

Quality Professionals, regardless of the sector they work in, strive to help businesses achieve their strategic objectives. They do this in various ways: be it deploying governance frameworks, implementing improvement strategies, or delivering assurance programmes.

In this post I talk about how Quality Professionals can help businesses investigate a problem or an issue operational to rectify it and build improvements.

How to: Investigate an Operational Problem or an Issue

Operations in any business (small, medium or large) is not free from challenges, problems and issues that hinder productivity and the customer experience. In this How-to post I explain a simple three steps approach to investigating an operational problem which will help you arrive to suitable remedial actions. The three steps are:

Understand what happened
Understand what should have happened
Identify the gap between the two

To simplify the outcome for all stakeholders, I find it very useful when I work with predefined categorisations of potential errors. I generally work with thee categories:

Is this a human error?
Is this a system error?
Is this a policy / procedure error?

1. Understanding what happened

When an operational issue is flagged internally, in most times getting things right immediately is the natural human urge. While this is a great sign that the workforce care about the work they do, Quality professionals are able to help the team consider all potential implications to the resolution before pressing the green light. It is their ability to break down an incident into small bite sizes.

Personally, I tend to follow a chronological approach as I conduct this step. When an issue occurs and I want to understand what happened, I conduct interviews and where possible, review the evidence of what has occurred, step-by-step, or click-by-click. And I document my understanding in the same way – chronological order.

2. Understanding what should have happened

In this step of the investigation, it is essential to understand what should have happened i.e. the correct behaviour of the process. This is the sky is blue scenario. Understanding the correct behaviour of a process should take place as it is normally the baseline. Do not get stuck with terminology. For instance, if a process does not exist documentation wise, it is not a problem. Carry on with the investigation to understand what usually happens when there are no issues. Remember, this is aimed to give you the baseline to measure the issue against.

It is worth noting that step 1 and step 2 could be interchangeable. It depends on your own preference and style, you can decide to start with step 2 and then step 1.

Why I do conduct step 1, then step 2? Because when people identify an error, they tend to want to explain what happened. It is the best way to let them speak everything they have as you document. Treat it as the safe space where they let it off their chest, and then go back to the logical steps.

3. Identify the gap between (step 1 and step 2)

Now that you have information from the first 2 steps, you can map them against each other and identify where the issue occurred. Having the details clearly written (norm vs issue) makes it easier to conclude how best to fix the issue. To ensure this step is bringing added value to the business and simplifies the internal communication, I work with three categorisations of errors:

Category 1: Human Error: This is when the operational error was simply done due to a human mistake. This is usually the case when the guidance is clear, the system are functions but a human oversight happened due to unforeseen reasons.
Category 2: System Error: This category is used when there is a problem with the system – such as an outage, or a bug that caused the system to fail. If a system was coded incorrectly, I would also map such errors to system errors.
Category 3: Policy and Procedure: This category is used when the operational error happened due to an oversight from all internal stakeholders. The operational governance as a whole has not accounted for such processes or instances.

When investigating an operational errors, be mindful not to fall into two traps:

⛔️ Common Mistake: It is easy to quickly jump into changing the process altogether in light of this issue. I would avoid this approach until full analysis is conducted.

⛔️Common Mistake: The focus can shift to future preventative measures rather than fixing the one issue that occurred. This could have a negative impact operationally on all your internal stakeholders and could potentially result in forgetting that a fix to the issue here and now is required.

Check out this case study from Process Management International on how one team changed they way they worked to provide customer delight by adopting the mindset of Plan-Do-Study-Act.

If you enjoyed this How To scenario, why not follow me for other scenarios dropping straight into your inbox 👇

If you would like to see a particular topic covered in this series, please get in touch and let me know the topic or scenario, and I will do my best to help. You can get in touch on your preferred platform 👇