Avoiding a Lean Six Sigma Project Failure

Minitab Blog Editor 11 September, 2013

FailureFailure. Just saying the word makes me cringe. And if you’re human, you’ve probably had at least a couple failures in both your work and home life (that you've hopefully been able to overcome).

But when it comes to Lean Six Sigma projects, there’s really nothing worse than having your entire project fail. Sometimes these projects can last months, involve a large project team, and cost companies a lot of money to carry out, so it can be very upsetting for all involved to know that the project failed (for whatever reason).

At Minitab, we’re always talking to our customers and practitioners in the field to better understand how they’re structuring and completing their projects, what tools they’re using, and the challenges and roadblocks they come across. One common reason practitioners have told us their projects weren’t successful is because the solution recommended at project completion was never even implemented.

Understanding why project solutions were never implemented

When we pried a little further, we got some interesting feedback and heard three different reasons why this outcome occurred. The most common reason was that the process owner was not involved in the project from the start.

If you consider the way that many quality improvement initiatives are structured—with a separate quality improvement team or department responsible for completing and actually “owning” projects taking place all over the company—it’s easy to see how a process owner could be left out of a project from time to time. Maybe the process owner is extremely busy doing his day job, and has little time to devote to the project team. Or maybe for various reasons the process owner is never actually interested in the project. Maybe the process owner wants to take charge of the process and find a solution on his own, or maybe the project team responsible for making the process more efficient could streamline the process so much that the process owner could lose his job? These could all be reasons why the process owner never implemented the solution.

Other feedback suggested that maybe solutions were never implemented because the project team followed the DMAIC methodology, but only completed the define, measure, and analyze phases, and never actually made it to the improve or control phases. In other words, they handed off the project after completing the “DMA” of DMAIC, and expected the process owner to take care of the “I” and “C.”

Other practitioners told us that project solutions were not implemented because after the project team did all the work and designed the new process, they shared it with upper-level managers who said something along the lines of, “This is not what we expected.” Management might nix a project solution if it’s too complex, expensive, or simply because it’s not the solution they would have come up with themselves.

How can you keep this from happening to you and your Six Sigma project team?

It might seem pretty simple, but one thing you can do is create a thorough project charter at the outset of each project. What is a project charter? It’s a document, usually completed during the define phase, that answers these basic questions about your project:

  • Why is this project important?
  • Who is responsible for the success of this project?
  • What are the expected benefits of this project?
  • When should the expected benefits begin to accrue, and for how long?
  • Where are improvement efforts being focused?

The information in a project charter is critical for obtaining leadership commitment to provide the necessary resources for completion of the project. Sometimes it can even serve as your “approval” from management to move forward with the project. This tool is one of the principle communication tools for all project stakeholders, so it’s important that you have it filled out clearly and concisely, as well as updating it with changes that may occur as the project progresses.

Here’s an example of the project charter available in Companion by Minitab:

Project Charter in Quality Companion

Note that some forms, such as the project charter, share certain data throughout the project. When data is shared, the information you enter in one form automatically populates in other forms where it appears. For example, when you add the project name, status, and start date in Project Today, they also appear in the Project Charter:

data-sharing example

If you do a thorough job on your project charter, you should be able to avoid some of the issues above, and be on your way to completing a successful project!

What are your tips for avoiding a failed project?