Welcome, I'm Stephen Halliday, and I'm going to take you through this define phase of Lean Six Sigma. Define in Lean Six Sigma is where we ask, "What is the problem or the issue?" In this module, we will talk about choosing a Lean Six Sigma project, defining the problem and its goals and understanding who is the customer and what are their needs.

A good Lean Six Sigma project is one where we have a problem or an issue for which we do not know what the best solution is. If you know what the solution is, then just go ahead and do it; do not bring it into Lean Six Sigma. However, if you think you know what the solution is, but you're not sure that it's the best, then by all means go through, define, measure, analyze, bring your idea into improve and compare it with other ideas, and then decide whether or not you're going to still use it.

Experience shows that very often, what people thought was a good solution at the beginning of a Lean Six Sigma project is not what they do at improve. Though for a Yellow Belt, what sort of project should you do? I would suggest that a Yellow Belt should be looking at their day-to-day work, and identifying if there's anything that causes them frustration or irritation and stop them from doing the work they think they're being paid to do.

In that case, get together with others in that department, and work out ways of stopping those things occurring. Alternatively, a lot of Yellow Belts look at what they do on a day-to-day basis and try to identify areas of waste and then working with others to try to reduce or remove them.

You may also want to consider is there any way of improving the customer experience? That also could be a good opportunity for a Yellow Belt project. Or are there any other areas of the department that need improving? All these things can form part of Yellow Belt improvements?

The problem statements and goal are often part of a one-page summary known as the project charter. The project charter will show the issue or concern or problem in the form of a problem statement or problem description. It will identify the objectives or goal of the project. It will show the scope and the boundaries to the project. What will be part of the project, what will be excluded from the project? It will also talk about who are the customers. Who else has an interest in this process? That is the stakeholders. It will also show who's leading, who's sponsoring or championing the project.

It is important on the project charter that no solutions are written. How do we define a problem? If someone is asked to describe the problem, very often they will answer by saying something like, well what we need to do is this, that does not describe the problem, it describes the solution. So a problem is something that causes pain to its customers or stakeholders. 

It is almost inevitable that any problems within an organization will be incurring large costs for that organization. Defining the problem clearly will improve the focus of the later work that's done in Lean Six Sigma.

So, how do we write a good problem description? A good problem description describes what is wrong with what. What is the pain for the customer? It should talk about what happens? When does it happen? How big is it? Or how bad is it? And what is the impact on the customer and/or the organization? It's also worth thinking, would the customer be happy if they knew we were working on this issue?

Let's have a look at some possible problem statements. The first one we'll look at says the business is not making enough profit. Whilst this may be true, it is not a good problem statement as described previously. It does not describe what happens, when does it happen, how big is it, or the impact.

For the second one during the last 12 months, 20% of our deliveries were late. This is better than the first one but it's still, it doesn't describe in detail what happens.

The third one is better: over the last two months, 15% of requests to our London office have been delayed, resulting in a 10% increase in customer complaints and a 12% loss in customer base. This tells us what happens, when it happens, how big it is, and what the impact on the customer and the organization is.

Notice though, it still does not tell us what the solution is going to be. When writing a problem statement, it's important we don't confuse it with a solution statement. In healthcare, a solution statement might read like, we don't provide nurses with the ability to capture and share patient information electronically.

Although this might sound like a problem, in fact, it's hinting at the solution which is to provide the nurses with the ability to share this information electronically. A better problem statement for healthcare might look like: we systematically exceed the four hour SLA for treating minor injuries and we have to pay penalties when this happens.

Although not perfect, it could be improved. And it could be improved by asking how often do they exceed the four hour SLA? How big a penalty and how often do they have to pay it? And so in define it's important we get to a situation where we can describe the problem that we are starting with.

Alongside the problem statement, we need to write a goal statement. A goal describes the anticipated improvement from this project. The goal itself will describe the metric which we are trying to improve. It must be consistent with the problem statement.

When describing a goal, it should start with a verb such as eliminate, increase, decrease. Goals should be measurable, and like the problem statement, it should not include a solution. If you're used to project management, you will be familiar with the goal acronym SMART. SMART stands for Specific, Measurable, Achievable, Relevant, and Time-bound. Writing a goal that fits this acronym should be a good goal.

For instance, reduce the delays in on-time delivery for stock items from 35% to no more than 10% by June the 30th. This is a good goal and that is the end of part one, define.

In part two, we'll be looking at the voice of the customer.