Making Lean Six Sigma Lean Again

Effective Charters

Despite record profits in many industries, uncertainty in the economy is creating an environment where service reductions, streamlined operations and cost cutting have become more important for success than innovation.Lean has, and continues to have a strong foothold in manufacturing and production environments where waste impacts COGS.  Six Sigma still is strong in fields where defects may have catastrophic consequences.

But lets face it; most environments in this information economy don’t fit that mold and without strong incentives to put improvement methodologies in place they go by the wayside.There are a wide variety of reasons that the Lean Six Sigma movement struggles in an environment where it should flourish; the largest reason in my opinion is the perception that LSS adds overhead to process improvement projects that is unnecessary and unneeded.  Those not anointed see excessive training requirements, specialization in an economy that can’t afford it and time commitments that they don’t feel they can keep.

One of the things we learn as leaders in the process improvement movement is that a certain amount of overhead is needed to ensure that the improvements we facilitate are the correct improvements, properly delivered and sustained over time.The key however is to minimize overhead and facilitate quick delivery of the improvements you are going after.

The best way to ensure that a project doesn’t get away from you is to start with a really good project charter.Project charters need to capture essential information that identifies the project, team members, milestones and other elements.  But the most important element of a good project charter is a well-crafted problem statement.

Good problem statements show that the team has a firm grasp over what problem the team needs to address, where and how often the problem occurs and the impact of the defect.It is important that the validated charter that is the result of the Define Phase does not contain biases of the Champion, Sponsor or even the Belt running the project.  It is also important to understand that discoveries are made throughout the DMAIC lifecycle that may impact the problem statement.

Although it is acceptable to tweak the problem statement as new facts are discovered, substantial changes should be reviewed critically to determine if the problem size or scope continues to warrant substantial improvement efforts.One of my first projects involved reducing the cycle time to provide service on password changes by the IT Helpdesk.The problem statement read something like this:

“The password reset cycle time is currently 48 hours; the customer’s expectation is that password reset tickets must be resolved within 2 hours.  Passwords are changed every 60 days and occur 10,000 times per year”.This is a well written problem statement.  The problem is defined as the password change process, it takes 48 hours to resolve when it should take 12 hours or less, the potential for missing the service level happens every 60 days and happens 10,000 times per year.

There should be no question that this problem needs to be resolved.  It is easy to take this statement and with simple math come up with estimated benefits for completing the project. In this particular project, we discovered during the Define Phase that the current phone selections on the call tree didn’t have a Password Reset option and that little change brought down the cycle time to less than the service level requirement.  This wasn’t a simple tweak of the Problem Statement, it was no longer a problem and therefore the project was closed.

The second important element is establishing project goals.  Project goals need to answer “How will we know the project is successful”? Goals need to start with a verb and need to be time bound.In our example above, the goal would be to reduce password change cycle time to 12 hours or less to meet customer requirements by December 31, 20XX. If your problem statement is complete and you know your expected result (your goal) as long as you have your labor costs known, you should be able to estimate the benefit for completing the project.

Lastly the project scope needs to be established for a complete project charter.  The scope includes a high level map of your existing process and what elements of the process is included and excluded from addressing during the project.LSS projects are best implemented when you are not trying to “boil the ocean”.  If you have a 20 step process of which not everything is under the control of the team or the Sponsor, you may need to exclude those things that can’t be changed.  This keeps the team focused on controllable root causes later in the project.There are many other elements to running a successful LSS project, but a well written charter sets the stage for the entire project.