Six Sigma Project Selection

I spent the afternoon with the North West Quality Forum (NWQF). Today’s meeting took place on the Microsoft campus in Redmond, Washington, just North East of Seattle. It was my first time to Redmond, besides my house-hunting trip to the Seattle area a couple of years ago.

The NWQF is a group of Seattle-based deployment leaders that get together every other month to discuss their Six Sigma and Lean initiatives. Today’s session was focused on project selection. Boeing, Washington Mutual, InfoSpace and iSixSigma presented their project selection processes. (iSixSigma presented the IDX process from the March/April 2005 issue of iSixSigma Magazine.)

Although the project selection processes varied in scope and detail, most of the presentations included the following key points:

  1. Start with and understand your business strategy
  2. Determine areas of the business that drive the strategy (the big Ys)
  3. Scope potential projects in written form, quantifying the opportunity
  4. Prioritize the list of approved projects

Comments 1

  1. Mike Carnell


    The issue lies between step 2 and 3. There is a huge amount of work, drill down and understanding that need to take place between those steps. A Y defined at the Corporate strategy level and the Y for a project are typically several levels apart. The issue really becomes ambiguous when the direction given is "select a Six Sigma project." People immediately believe it is something they have never done before so they begin to look at things that are not neccessarily in alignment. That results in projects that are meaningless in the context of the Corporate Strategy.

    There usually something already on their plate that qualifies and is in alignment but there is typically some contrived definition of what a project is so they infrequently look at what they already have planned to work on. Assuming there is alignment, any issue where the solution is unknow is a good candidate. It helps if data already exists.

    The other issue is that is projects are derived from accounting data you will typically end up with Cost reduction programs (your pet peeve) because that is what accounting tracks traditionally and where improvement typically occurs.

    The entire area has been mystified and it should actually be simplified.

    Just my opinion.

Leave a Reply