Defining The Problem Tutorial

3.1 Module 3 Defining the Problem

In the previous module, we used certain elements of the SIPOC to identify the stakeholders in the process. On the next slide, we’ll explore how to build a complete SIPOC in the define phase of a project.
Let us begin with the first topic of this lesson.

3.2 Topic 1 How To Build a SIPOC

The acronym SIPOC stands for Suppliers, Inputs, Process, Outputs, and Customers.
The SIPOC is very useful to gain an understanding of a process, who it impacts, and what it involves.
Oftentimes, the process of developing the SIPOC actually helps the project leader and his team identify potential causes of the problem they are setting out to fix.
Building a SIPOC begins with the process steps. Some teams prefer to start with the SIPOC framework and build the process as they go while others prefer to start with the process map and then build out the SIPOC. There is no right answer, it’s just a question of following the method that works best for you.
For this course, we’ll start with the process map first, and then build out the other SIPOC elements from there.

3.3 Topic 2 Choosing a Project Team

In the next topic, we’ll discuss some considerations the project leader should have when choosing his team.

3.4 Topic 3 Crafting a Problem Statement

The problem statement serves to communicate exactly what the project team is working to resolve. It has to be very clear, specific, concise, and leave no room for confusion.
The problem statement should not be more than one or two sentences.
Firstly, the problem statement should illustrate the current performance of the process. In other words, the problem has to be quantified.
Here are some considerations to help formulate the first part of an effective problem statement:
What exactly is the problem?
When does it happen?
Where does it happen?
Who does it affect?
Why does it affect them?
For example, the problem can be expressed in terms of defects, or performance levels, or costs, or cycle time, or non-value added.
“The Urology clinic currently reschedules 15% of its consult appointments…”
This is important as the improvements will then be compared to this baseline performance.
The second part of the problem statement is the goal.
A common mistake committed by non-lean six sigma practitioners is to immediately jump to a solution, or a “How” to resolve the problem. The “how” will come later. The purpose of the problem statement is now the “how” but rather the “what”.
What is it that has to be achieved to resolve the problem? For example, the goal may be to reduce appointment reschedules by 50%, not “how” this is going to be achieved.
Let us discuss more about goal in the next slide.

3.5 Topic 4 Understanding the Impact

We’ve already explained how expressing the benefits is important to obtain stakeholder support for the project. It also follows that those benefits are most likely linked to an impact if nothing is done at all.
For example, in the Urology clinic, one of the benefits of the project was that less reschedules will result in more procedures being done and therefore higher revenues.
On the flipside of that we find the impact; a high frequency of reschedules results in less procedure being done and consequently, lower revenues.
Like a problem statement, impacts and benefits should be expressed in measurable terms as much as possible. The reason being that stakeholders will want to know whether or not the project actually made a difference.
If an impact is not measurable, or not easily measured, it’s usually wiser to not mention it at all.

3.6 Topic 5 Flushing Out the Causes

Unless existing data already reveals potential causes of the problem, one of the first tasks the project team will face is to use their first-hand knowledge of the process to help narrow down the vital few causes from the trivial many.
This is an important step because it helps the team to focus on specific avenues as opposed to trying to investigate every single potential cause.

3.7 Topic 6 Case Study

As you may recall from the last module, John (a new employee at Mercy West regional hospital) was tasked to figure out a way to improve the overflowing ED.
After completing an overall review, John realized there were many potential problems to be tackled but since this issue had to do with capacity and flow, John knew that working on downstream processes first would be more beneficial.
Consequently, John focused on the discharge process first. The SIPOC revealed that there were many stakeholders in the discharge process ranging from most clinical departments (depending on which were involved with the patient) to finance, and just about everything in between as well. Not to mention external stakeholders like rehab, home care providers and long term care facilities.
The discharge process at Mercy West varies in complexity (and duration) depending on the state of the patient being discharged and where they are discharged to. Despite this, the team agreed that the administrative and financial aspects of the discharge were probably a large (and controllable) cause of delays.
Looking at the brainstorm results of potential causes of delays in the discharge process, the team suspected that waiting for a vacancy in an outside facility was a major factor. Another factor was actually getting all the internal coordination done quickly enough so that a patient could leave without having to wait for all the administrative formalities to be completed. The team decided that this would be the factor that should be investigated in the Measure phase of the project.
Hence, the team crafted this problem statement:
“All discharges from Mercy West require administrative and financial transactions which account for 30% of the process cycle time. The goal is to reduce this portion of the discharge cycle time by 50% by the end of the quarter.”

3.8 Quiz

You will now attempt a quiz to test what you’ve learned so far.

3.9 Summary

In this module we discussed some of the important elements of the Define phase of an improvement project.
First we saw how to build a SIPOC. Then, we looked at choosing a project team, crafting a powerful problem statement and understanding its impact. From there, we learned how to flush out the few vital causes from the trivial many.
We concluded the module with a case study in a hospital setting that served to illustrate how these elements all fit together in a practical setting.