In a recent discussion over workplace projects, someone mentioned that their teammates came to their session without knowing what “DMAIC” was. Since I’m they aren’t alone in that, I thought it worth taking a moment to review the model.
DMAIC is a staged approach to project management. Here’s a short overview of the stages,what they mean, and what you should be doing in each of them:
Define Stage: What’s the problem here?
The first stage is Define. In short, this is where you define the issue you are trying to address and what success will look like. If you don’t get this right, you’ll have a hard time keeping the project on track and you may never know when you are done.
In the Define stage you should have your project charter built, know who your team leader and team members will be, know your project champion and your project sponsor. Yes, those are all different jobs. No, we won’t be talking about them today. Yes, we will talk about them another time. Soon, I promise.
In many cases it is helpful to build a high level process map as well. At this point you aren’t looking for details, but for a general understanding of who does what and where the problem (or defect) can be found.
Measure Stage: What’s really going on?
Measure is all about data gathering and analysis. In my experience, this is the stage where most projects get derailed, especially in HR. Why? Lack of information. HR can usually produce basic metrics (headcount, time to hire, budget, etc.) but often lack the more granular data that can be helpful for projects. If you want to fix a problem, you need to know everything about it. When does it happen? What else is happening at the same time? How are they related? Is this a new problem? What was it like a year ago? What is different now? Is it a new process? Is it a temporary problem? And (this is the big one) what is the problem costing us?
If you don’t know that one, it will be tough to get the resources you may need to complete the project. Projects cost money. If it was easy and free, it wouldn’t be a project. It would be done. When you are asking for resourced to fix a problem, you are going to need to show someone, usually in Finance, the problem, the cost and the benefit. You want to know this as early as possible. You can’t leave the Measure Stage without it. Don’t even try.
Outputs of this step often include Pareto diagrams and detailed process maps.
Analyze Stage: How did that happen?
This stage is about understanding all that data you collected in the Measure Stage and figuring out what is really causing the problem. Here you will clearly state a theory or problem statement, evaluate the information with one or many different analysis tools, determine potential causes of the problem, collect extra data as needed, and make your best determination of the root cause of the problem.
There are a ton of tools you can use here. Some we’ve covered, like the Y to X tree. Others, like fishbone diagrams and scatter diagrams, are for another day.
Improve Stage: How do we fix it?
This is your testing stage. Once you know the root cause, you’ll likely come up with lots of things that might fix the problem. Ask lots of questions, try lots of things. Test, test, test. Measure the results until you are confident that you have the answer. Be ready to show data that “proves” the defect is eliminated based on your proposed changes. Then implement those changes. You will also continue to watch data after implementation to make sure it is working as expected.
As a quick aside, one of the tenants of Six Sigma is that it isn’t a real project if you already know the answer. If you know you have a leaky faucet, you don’t need to run a project to reduce water usage. Fix the faucet already.
Control Stage: When can I stop caring about this?
All projects end. It is one of the defining traits of a project. At some point, you won’t be working on this anymore. The Control Stage prepares you to move the project into “business as usual.”
The key activities here include documenting your process and the change, training the users and stakeholders of the process, if they haven’t already been part of the training, and setting up a monitor of some kind. You need to have a way of making sure the change is permanent. Personally, I’ve always believed that a change should make life better for the users so they won’t want to go back to the old way. But that isn’t always the perception, so you will want to find a way to monitor the new process, at least for a while.
As part of your project closeout, you will also want to do a postmortem to review lessons learned and recommendations for the future. While not critical to your current project, they can help set you up for long term success.
What the L?
Yes, sometimes there is another stage: Leverage. If you are fixing a problem in an isolated area, you may need to plan out how to widen the impact of the change. It isn’t part of the “official” DMAIC model, but some companies (and consultants) like to include is as their “stamp” on the model. But if you are running your project correctly, this can be included in the Improve and Control stages. If the potential scope is really wide, you may need to treat the larger implementation as a separate project. What works in one location may not work everywhere.
So there you go. Five stages that run in a cycle. The outcome of your Control discussions can lead you right back to the Define stage of the next project. The real value of all of this is to give you a systematic, staged approach to improvement, not to make it more complex than it needs to be. Don’t get hung up on the tools, the names, or the minutiae that sometimes scare people away from DMAIC. It’s just a tool and an approach. Use it as a guide, but remember that the tool is only as good as the craftsman holding it.