Six Sigma Project Selection: Don't Pan for Gold in Your Hot Tub!

I saw a post on isixsigma.com by a gentleman named Gary A. Gack about Six Sigma project selection in Software Development. I wanted to exapand on this (and contract a bit) on How to Select a Generic Six Sigma Project. I used some of Gary's excellent concepts.

Gary post can be found on isixsigma.com at: (http://www.isixsigma.com/index.php?option=com_k2&view=item&id=758&Itemid=1&Itemid=1)


One of the most frequent questions asked by students new to Six Sigma is something like, "What types of problems should we address with Six Sigma?" While there is no one-size-fits-all answer to this sort of question, there are criteria that are universally applicable and provide a project selection framework that covers general top-level considerations.

The first rule is, "Don't pan for gold in your hot tub!" Go where the money is. Six Sigma is about significant step changes in organizational effectiveness, and those changes can happen only if the methodology is applied to significant problems that consume an important share of organizational resources.
Considerations for Project Selection

Other considerations that should strongly influence Six Sigma project selection in software include:

Replication Potential – “Don’t Boil the Ocean”! Ideal are small and manageable projects that can be used to prove an approach or solution concept in a limited pilot area and then rolled out to a much larger population to multiply the benefits.

Example: Instead of taking on a project to fix the effectiveness of the Finance department (which can be a futile effort), use data and prioritization tools like Pareto Analysis to determine a more finite scope (“The Biggest Bang for the Buck”) within finance like the Billing/Invoicing process … and even this can be scoped down depending on the size of your company.

Measurability - Consider projects in which it is feasible and affordable to use or create and/or investigate measurement data that can quantitatively demonstrate the business case. This means selecting areas where baseline data can be collected to enable pre- and post-improvement comparison.

Example: The invoicing process currently has a baseline of 2,300 (average) defective (need to be reworked) out of 150,000. This can be further equated into a dollar value.

Employee Acceptance - Ease of use and efficiency considerations play an important part in Change Management. Working in a cooperative setting can be critical to success. Mandating Six Sigma is often ineffective; look for interested volunteers, and think about incentives.

The role of a Six Sigma practitioner is not to “Push Change” but to be a Facilitator of Change using the process owners (what we call the “Subject Matter Experts”) as the leaders of change in their area by feeding us experiential data as well as pointing us in the direction of quantifiable data. In a Six Sigma team effort the SME is always “the most important person in the room” … if you remember this then Change will be Accepted.

Realistic Resource Allocation - Rarely is it possible to realize meaningful improvement without some investment. Hence team is going to work on a Six Sigma project, it must be given time to do so. If a team cannot be given some "slack," either by assigning additional resources or reducing delivery expectations, it is unlikely the team can successfully execute a Six Sigma project. In general, a Six Sigma team working on a significant project will require 20 percent of a Green Belts time and 10 percent of one or more Yellow Belts time. While these figures are based on experience, they, of course, can vary by project.

Appropriate Scope - Many problems are not appropriate targets for Six Sigma - not every project is a Six Sigma project. If the problem is local and can be resolved by assigning a skilled resource (e.g., improve response time of a specific system), it is not a Six Sigma project, it is a Lean or a “Just do it” project. Problems appropriate for Six Sigma are: recurring, important to the organization, those for which the solution is not obvious, and those that are capable of being scoped to enable demonstration (pilot) of a solution in a four- to six-month time frame.

There is a Problem (or Opportunity) with an Existing Process – Six Sigma’s DMAIC process is about addressing existing deficiencies within a process at any scale. DMAIC is not for assessing a new process design. This assessment of a new process design is reserved for a methodology called DFSS (Design for Six Sigma).

Credits:

Parts of this White Paper is summarized from a post on isixsigma.com by Gary A. Gack. The post can be found at: (http://www.isixsigma.com/index.php?option=com_k2&view=item&id=758&Itemid=1&Itemid=1)

Additional Comments by:
Kevin Clay, Instructor and Consultant for SixSigma.us
kevin.clay@6sigma.us

Project Closure and Y=f(x1,x2,x3...xN) ....

Have you ever head the saying that the "the Cobbler's children have no shoes"? Sometimes you get so caught up in teaching the Lean and Six Sigma methodology that you forget that the methodology can improve the outcome of what you teach. It is no myth that the most difficult "output" of any Lean and Six Sigma Implementation is actual consistent project closure. We tend to "get the train going" with the training of new Green Belts, Black Belts, and Champions and then let them loose to "Slay Dragon's" ... often times with weapons that they don't know how to use.

As MBB's, we teach the methodology and help to implement, but we often fall into the trap that many college professors fall into ... WE have a deep intimate knowledge of what we are teaching, and we expect (often subconciously) our budding belts to fill in the blanks. We expect the potential belts to ask questions, but alot of times they get so much information that they don't even know how to formulate the questions. This "input" leads to students that go back to work and either consistently communicate with me or SSDSI's other MBB's to "fill in the blanks" and complete the projects ... or they go back to work and revert back to their "reactive" modes and the project is pushed off indefinitely. Thus, project closure becomes an issue.

Being a Lean and Six Sigma practitioner, I have developed an informal Six Sigma project from this "opportunity". My "Y" is project closure rate. My "X's" include many aspects of each belt curriculum, tools, and project structure information. What i have found so far is really a "no brainer" ... Belt students want education but need structure. I took the Voine of the Customer, and they said "we need help getting started". I have added that structure into my RESOURCES page in the form of a Six Sigma Green Belt Project Progression (Flow Chart) and Tollgate Reveiws for each of the DMAIC process. The flow chart helps the student to undertand the basic flow of a project. The Tollgate reviews are the "rubrics" by which each of the phases are assessed before moving on to the next phase. This structure ("input") has led to a marked increase in project closure ("output").

If you want to learn more, contact me at kclay@sixsigmadsi.com or call 479-739-4940. Check out my other blogs at http://www.sixsigmadsi.com/.