Avoiding a Lean Six Sigma Project Failure, part 2

Minitab Blog Editor | 24 September, 2013

Topics: Lean Six Sigma, Project Tools, Six Sigma, Data Analysis, Quality Improvement

In a previous post, I discussed how to avoid a disastrous Lean Six Sigma project failure, specifically if the reason behind the failure is that the project solution never gets implemented.

In this post, let's discuss a few other project roadblocks that our customers cited when we asked them about the challenges they come across in completing projects. I’ll also go into detail about suggestions our industry-seasoned trainers at Minitab offer to avoid these failures.

Is the project scope too large?

One common reason quality improvement projects get started on the wrong foot is that their scope is too large.

In fact, one of our customers provided us with a great example.

In this particular case, the customer's project goal was to “improve the profitability of the company’s South American Division.” In theory, this sounds like a pretty good project goal, but when they actually began work on the project, the project team needed to hone in on that broad goal in order to reach something to work on that was less vague and more specific (not to mention measurable).

To help the team drill down to a more concrete project goal, they created a CTQ (Critical To Quality) tree:

CTQ Tree in Quality Companion

This CTQ tree above was created in Minitab Engage, but you could certainly employ this tool using pen and paper, a whiteboard and a marker, etc.

How does a CTQ tree work?

The CTQ tree starts with a broad project goal, such as “increasing the profitability of the South American Division,” and works downward to identify factors “critical to” achieving this goal. In this case, the team identified that improving sales by 20% and improving the sales margin by 20% was “critical to” achieving this goal (see the green boxes).

Now they drill down even further. In order to improve sales by 20%, the team identified that it was critical to improve Internet sales by 25%. To improve Internet sales, the team determined that they needed to reduce complaints about order-to-fill time, and to do that they needed to decrease order-to-fill time by 45%.

The team could have gone on (and on …), but they decided to end here, since they now had a much more measurable project goal than they originally started with. This smaller project—decreasing the Internet order-to-fill time—supports the overall goal to improve the profitability of the entire division, but now the team has a specific goal to focus on.

Another tip for ensuring your project scope is appropriate is to limit the project to one geographical location, one measurable product/defect, and clearly define the customer up front. Another tool that can help define the project scope is a SIPOC.  Basically, a SIPOC is a high-level process map that defines the scope of a process. Check out this post for more on how to use this tool.
 

Is the project not linked to finances?

Another reason customers say quality improvement projects have been unsuccessful is a failure to link the project to finances. One of our trainers gave me the following example from his years working as Six Sigma project leader.

One quality improvement team from a manufacturing company had a goal to reduce the number of press shutdowns caused by mold in equipment from 37 to less than or equal to 14 per month. Even though everyone in the facility understood the importance of reducing the number of shutdowns, when it came time to implement the team's solution, questions began to arise about the large costs involved.

The team now faced a challenge—they needed to prove that the expensive solution was actually a good idea to implement over the long term.

Here’s what they did: They calculated that just one shutdown would cost the company $8,000. They also calculated that once implemented, the solution would reduce shutdowns from 37 to 14 per month (23 fewer per month), thus saving them over $2 million dollars per year. So was the solution worth implementing?  Yes!

The company decided that the high cost to implement the solution wasn’t really so bad after all, and the project team was given the OK to make it happen.

This example project illustrates the importance of having a demonstrated financial “link” throughout your project, and being able to answer the following questions: 

  • How much money do you expect to save overall?
  • How much money will it cost to implement your project solution?
  • What is the time frame for realizing the expected financial benefits?

How can these questions be answered? Carry out a financial analysis of your project. There are many ways to do this. If you're using Engage, the software includes a form (in both transactional and manufacturing versions) you can utilize to help guide your project financial analysis:

Project Financial Analysis

To help you provide the “linkage” between your project and bottom-line impacts on the organization—which is an important component in obtaining full support from management and project stakeholders—a project financial analysis is the way to go.

What other tips have helped you to carry out successful projects?