What is the “Define” stage of DMAIC?
The DMAIC methodology continues to be a popular approach for solving problems within existing service and manufacturing processes.
DMAIC provides a logical sequence of steps for teams to follow as they endeavour to improve process performance.
I have summarised the five steps Define-Measure-Analyse-Improve-Control in another blog but here I want to describe the first step, “Define”, in a little more detail.
The first Step of DMAIC
DMAIC projects should start by defining the problem to be addressed. It’s critical to get this first step right as it sets the direction for the follow-on work about to be done. The aim of the “Define” stage is to give everyone involved a clear understanding of this direction.
Developing the definition for an improvement project might sound easy, but often it is not straight forward. If the problem is a simple fix with clear boundaries then a workable definition may be achieved in minutes.
However, if the problem is cross-functional or if there are multiple variables at play, finalising a project definition might take significant effort and include much debate and discussion.
Teams who fail to invest sufficient energy at the definition stage are likely to run into problems as the project progresses. These include solving the wrong problem, failing to deliver the best solution, or falling short of management expectations.
So how do we avoid these issues? Here are some simple steps a team can take that lead to a clear problem definition.
1. Define the Customers.
Even simple projects can have multiple customers. First there is the person or group sponsoring the improvement. Then there are the people who will be responsible for operating the new methods or working with the improved product that your project delivers. We would refer to the above groups as Internal Customers as they are part of our organisation.
Our External Customers would be those outside our organisation who receive or purchase our product or service.
It’s important when defining our customers that we identify those closest to the work and avoid naming lots of “customers” who are only vaguely connected to the situation.
2. Gain Customer Input.
This is often referred to as the “Voice of the Customer”. Here we are gathering both the positive and negative impressions and information that customers have about the current process / situation. Customers may well have positive suggestions about how that situation could be improved. This customer input will define why we should be motivated to work on the problem in the first place.
Depending on the situation, gaining customer inputs could take the form of:
- Sampling from a wide customer base
- Process observations
- Mystery shopper
3. What’s Critical To Quality?
If in seeking Voice of the Customer information, we gain some numerical input, in the form of targets, then that’s good, because it gives us something quantitative, we can work with.
However, often we don’t get this level of input from customers, particularly external customers. Their expressed requirements can often seem unclear or even woolly.
For example: “When I hold the tennis racket, it has to feel light yet solid.”
What does this mean for us, producing the tennis racket?
So, we need to convert these qualitative insights, into quantitative measures, that we will use to show improvement through our project.
We would call this translation of inputs, as defining our Critical to Quality criteria – or CTQs for short. Often a single CTQ is enough and helps to focus the effort of the team. The actual values and targets for CTQs can be developed during the Measure stage of DMAIC.
4. Define Project Scope.
It is imperative that we define and document the scope of the problem including what’s to be addressed and, just as important, what is not. Defining and communicating what’s out of scope will avoid awkward surprises for our management and customers at later stages of the project.
5. Summarise all of the above into a Problem Statement.
This can be a single sentence or a few paragraphs or even a list of bullet points. The key thing is that it summarises the problem to be addressed in a way that everyone involved understands.
If data is available it should be incorporated into the problem statement in summary fashion. If a target or known objective exists include this as well. The biggest pitfall to avoid at this stage is to write a solution into your problem statement. DMAIC projects never start with solutions.
It is important that the above five steps are documented and communicated to all project stakeholders.
There are many more tools and techniques that can be used at the “Define” stage, but even using the steps above should help to get your improvement project off to a good start.
In his book “Seven Habits of Successful People”, Steven Covey describes how we should ensure our ladder is placed against the right wall before we start climbing it. In the context of DMAIC, this is exactly what we mean by “Define”.