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).
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