Project scope issues are probably one of the top failure modes for LSS projects. If the scope is too narrow, leadership doesn’t view the effort as important and doesn’t support it. Too broad, and the improvements are either never implemented, or aren’t sustained due to poor implementation and control.

Often out of necessity, projects are chartered and scoped with imperfect data and understanding of the problem. (After all, if the solution was known, launching a project would be unnecessary). By design, DMAIC leads the team through a discovery process that can affect the scope or drive the effort in a new direction entirely.

Systems thinking, on the other hand, challenges us to understand the interconnectedness of all things. Such thinking also shows that seemingly discrete processes usually begin and end beyond the defined scope of a LSS project, beyond the boundaries of the department, or even the organization. Firms like Toyota, Rathyeon, Pratt Whitney and others get this – they work with their customers, suppliers, their suppliers suppliers, and so on to achieve more process stability, efficiency, and quality of inputs and outputs.

On many projects, particularly early on in a deployment, it’s not long before the project team starts to see opportunities everywhere - problems their department causes for others, problems they deal with caused by others. Things can quickly snowball until a well- scoped green belt project turns into solving global warming. Then there’s the individual that tries to bolt on their particular hobby horse issue to another project, often only peripherally affecting the problem at hand.

It takes discipline on the part of the champion, the project leader, and the process owner to maintain the scope of an improvement effort, and stay realistic about what can be accomplished within the timeframe and resource availability of a green belt project.

So how do you, LSS practitioners, balance the need to manage scope creep, while keeping attuned to the broader context in which the projects are taking place? Please reply using the comments section.

Every Six Sigma project is (or should be) built around improving a primary process metric: the Big Y. From there, we drill down into the critical factors, as measured by the “little y’s” – if we can improve the right factors, the primary metric will improve, and we can all declare victory and move on.

One frequent frustration of green and black belts is that getting resources and priority on their improvement projects is difficult, leading to long project cycle times and a sense of disappointment and anti-climax when the control phase comes to an end. It doesn’t need to be this way.

Which brings me to the title of this piece: Cash. Recently I read a post on a Lean discussion board in response to a question about what metrics to use in valuing lean projects. An astute poster replied: cashflow. Reduced inventory and defects, more efficient use of materials and labor, and increased throughput will all find their way to the bottom line. The cash levels of the company are one of the best ways to measure health. Conversely, if the cash situation is not improving, that should prompt an evaluation of current projects, especially if expense reduction as an explicit or implicit goal of Lean Six Sigma at the company.

The financial piece of Lean Six Sigma projects is often viewed as a necessary evil by Green and Black belts – for many, the language of accounting and finance is as engaging as the finer details of two-way ANOVA with replication and blocking. Many companies don’t have activity based costing for manufacturing processes, let alone transactional ones, and the process of establishing the financial opportunity for a Lean Six Sigma effort can seem like non-value-added activity.

Let me suggest that Black Belts and Master Black Belts would be wise to spend time with a CFO or Controller, to understand what the business leaders are looking at to run the business. Take the time to understand the difference between the Balance Sheet and the Income Statement, Net Present Value and Internal Rate of Return, EBITDA and Cashflow. Your business leaders may in fact be paying far closer attention to these metrics than process metrics. And the next time you have to explain how your projects affect the company, you can speak the language of business – cash.

"Innovation comes from the producer - not from the customer." - W Edwards Deming

In the course of teaching Kano Analysis to green belts and others, I frequently talk about the difficulty in uncovering delighters or excitement needs, as the customer often cannot articulate these at an actionable level. Or in other words, “The iPod didn’t come from a focus group”. (For the real scoop on where it did come from, click here.)

While it may be true that no customers conceived of the iPod, or a host of other innovative inventions, it is no longer true that innovation is the sole purview of producers. Take the iPhone as an example – originally designed to work only on one wireless network, it was only a matter of weeks before a team created a way to unlock the iPhone to work on other networks – clearly a desirable feature for customers which Apple decided not to include.

There is now a variety of websites devoted to various hacks for the iPhone to overcome shortcomings in the original product and software design, or enable entirely new functions. While it’s likely that customers who would be interested in hacking their iPhones represent a small subset of Apple’s customer base, this is a highly innovative group.

Will Apple take advantage of these efforts? After all, what better way to build future releases with killer features than to allow your customers to run wild and create them on their own? Time will tell. It is intriguing that despite being one of the most innovative companies in the world, Apple’s customers can still find ways to better Apple’s products.

Your company probably knows more about what is possible than most of your customers; but the lesson I take away from the Apple example is this: some of our customers know a lot more than we do, and we ignore them at our peril.

The concept of customer innovation is not exactly new – Harvard Business Review published an article on it in 2002 – but it does seem to be garnering more attention these days. But how many firms are still relying on the “tried and true” methods of developing products, or worse, adopting a “we know best” position and internally designing products and services with little to no input from actual customers?

I think Deming said it best in this line: “It is not necessary to change. Survival is not mandatory.”

In the transactional environment, we frequently run projects around reducing cycle times. More often than not, cycle time distributions are not normal, owing to the fact that there is a hard stop at 0 – negative cycle times to complete transactions rarely seen.

Despite the fact that most statistical analysis is built on the assumption of a normal distribution, hypothesis tests are generally robust enough to handle non-normal data (see Robin Barnwell’s post for more details on this.)

Whenever I study a process, I always want to know two things: what is the pattern of variation over time, and what is the process’ current capability of meeting its specification. This is where data transformation can come into play, quite usefully.

It should be said that transforming data can be risky – after all, we are taking true data, with all of its idiosyncrasies, and making it “more normal” to ease our analysis. Moreover, trying to explain transformed data in business contexts poses its own challenges. (If you do need to transform, and then explain this in a business context, try the square root option – far easier to get into than logarithmic numbers).

Capability studies in Minitab can be run with or without transformation on non-normal data; the main nuance being the expected process performance (based on the distribution) vs. the actual process performance (based on actual data). Often the difference in capability results is small, and actual process performance is sufficient in many applications.

Control charts can also be run with transformation, and this is perhaps its most useful application. Consider these control charts for a transactional process:

Without transformation, a process owner or project leader would be led to investigate the four out of control points on this chart, to discover the special cause present. Not only could valuable time and effort be wasted on such inquiries, but process adjustments made on the basis of these datapoints could in fact upset a properly functioning process. By correctly calculating the control limits, no process intervention would be required.

So readers, what process situations have you encountered which required decisions concerning transforming data? Please post your comments below.

I opened this morning’s USA Today while on the road, and was struck by this story. It details how a simple clerial error on the part of a pharmacy technician resulted in wrong dosage instructions - "As Needed" rather than "4 pills, 2 times per day" - and a fatal overdose for a Florida man.

The man took 22 pain pills in a 36 hour period.

Clearly there are numerous points of failure in this story, as well as the entire drug dispensing process. The article does go into many of the process factors at play in the incident, as well as the various error-proofing techniques pharmacies are now using to prevent errors from happening.

But what continues to trouble me is the recurring theme that the workers involved didn’t care enough. I have no reason to believe that the pharmacist and pharmacy tech did not give their "best efforts" - but as Deming tells us, something more is needed. (Interestingly, the commentors on the story cite problems throughout the process, not just the pharmacy tech’s mistake.)

So readers, what more is needed? Post your thoughts in the comments section.

Effectiveness = Quality * Acceptance * Execution

I originally learned this equation during Green Belt training as Effectiveness (of Solution) = Quality * Acceptance, and it immediately resonated with me. In order to produce the most effective solution to a given problem, the solution had to be of high quality, and it had to be bought in to by the stakeholders. Lean Six Sigma gives all the tools one needs to generate high quality solutions. Change management and team building tools help achieve the acceptance needed. Seems simple enough.

Until the solution is correctly and fully implemented, and brought into control, the entire effort can be for naught. The consequences of poor solution execution can range from frustration and resentment on the part of the project team, to actually worsening the problem the project was intended to fix, to spelling demise for an entire Lean Six Sigma deployment.

So the new equation is Effectiveness = Quality * Acceptance * Execution. Weakness in any of these aspects will harm the overall effectiveness of the solution.

Knowing this is half the battle. The other half is actually executing properly. Many green belts find themselves leading their first project of any kind, let alone one involving all of the new tools and methods that Lean Six Sigma offers. Coaches, here is where your belts may need your guidance the most.

As those of us who have managed projects know, there are many details involved in rolling out a new change, and missteps on any of them can be damaging. Comprehensive roll-out plans are critical to successful execution.

Questions I always consider include:

- Who needs to be notified that the process is changing?

- Does anyone need training on the new process?

- What documentation needs to be updated or created?

- Are any of our audit controls affected or changing with the new process?

- What dashboards or other reports are needed to help the process owner manage the new process?

Simple tools like Gantt charts and project plans (complete with detailed tasks, due dates and accountable resources) along with cheerful yet persistent follow-up on the part of the project leader can go along way towards a successful implementation.

So readers, what experiences have you had with executing your teams solutions, especially in transactional environments? Share your stories in the comments section.

Think about this: when was the last time you told someone about an experience that met your expectations. Perhaps it was an adequate dinner while on the road, or a satisfactory hotel stay. Now think about the last time your expectations either weren’t met at all, or were wildly exceeded. How many people did you tell then? One, ten, twenty?

Why is it then that organizations spend time, money and focus on something no one apparently cares about: Customer Satisfaction?

Consider this model:

Based on this model then, merely satisfying our customers buys us very little; perhaps we can keep them until another firm comes along to delight them. Then we’re left to wonder what happened - Weren’t our customers satisfied? Where’s the loyalty?

Naturally, this doesn’t always apply. If you’re fortunate enough to be a monopoly, or the government, mere appeasement of the customer may suffice. But for the rest of us, working in highly competitive industries, moving beyond satisfying customers may be what keeps the company in business.

A few parting lessons from this concept:

- Customers are not monolithic - what delights one may not matter to another. Finding out is a difficult, but necessary effort. (Your customer often doesn’t even know what it would take to delight - a focus group probably didn’t come up with the iPod.)

- Net Promoter Score is a useful measure, but only if the survey can shed light on why the customer would or would not recommend your firm

- Exceptional value can mitigate price sensitivity; failing to meet expectations leaves customers feeling cheated and much more price sensitive

- If your firm can’t yet delight customers, start by not disappointing them

So let me ask you, dear readers, how do your firms address Customer Satisfaction especially for your transactional projects? Please post your experiences, suggestions and/or horror stories in the comments section.

Special thanks to Bill Bellows of UTC Pratt Whitney Rocketdyne for the above model.

Many organizations are awash in data, generating enormous and plentiful reports with a variety of statistics. Others have little data to work with, often going by gut feel and experience when decisions are to be made. Most are somewhere in between. In the transactional world, many process measurement systems are manual, comprised of spreadsheets, Access databases, and, yes, even clipboards with tick sheets.

Let’s assume for the moment that you are working in an organization that actually has decent process-metric data to work with. The next question invariably is, "can we trust this data?" or, "are we even measuring the right things?"

To keep this entry brief, let’s assume that the right things are being measured. We may even have operational definitions, and a process by which process measurements are taken. (Naturally, in the absence of these things, I recommend starting with a CT Flowdown to identify the big Y’s, then process map to identify key process variables, create operational definitions for them, and then document and implement a new measurement system for our process.)

Some Master Black Belts insist that a full Gage R&R Study is required for all measurement systems, in order to validate the reliability of the data the project is based on. Is this always necessary for a Green Belt, or even possible?

In an MBB class I took last year, our instructor suggested that there are three options when it comes to validating our data: MSA, A&V, and H&P. MSA, is fairly self-explanatory. A&V refers to Audit and Verify: take a sample of your data and audit for accuracy with your process personnel. Does it pass the laugh test? If so, it’s probably reliable enough to move forward with. If not, you know this needs work before moving ahead. The last option, H&P is the least desirable: Hope and Pray, and is our default position if the MSA and A&V options are skipped. Try this one at your next tollgate meeting before the Champion - let us know how that turns out.

So when should we MSA, and when is an A&V sufficient? Like most things, it depends. In an effort to keep DMAIC project work lean, I tend to start with A&V before determining whether a full-blown MSA is needed. If a high degree of precision is needed in the measurement system, or measurement variation poses a large risk, absolutely run an MSA. MSA is also very useful where humans are making attribute or quality determinations, as in an inspection step or categorizing an input for further processing, or if each operator has "their own way" of doing things. Often, the Attribute MSA is the only way to illustrate the deficiencies in that measurement system. In the case of a destructive MSA situation, where repeatability is not possible, the study can still point out where reproducibility is a problem, as well as agreement with the standard.

So let me ask you, dear readers, how do you handle Measurement System Analysis, especially for your transactional projects? Please post your experiences, suggestions and/or horror stories in the comments section.

Special thanks to BMG Instructor George Rommal for introducing the A&V and H&P concepts.

James Considine is Quality Programs Leader and Lean Black Belt with a global energy products and services corporation. Previously, he was Regional Manager, Continuous Improvement with Vertis Communications, a $1.8 Billion marketing services firm. In this role he deployed Lean and Six Sigma to a $125 million division of the company, leading complex projects and facilitating numerous Kaizen and Workout events, which produced over $2 million in savings and revenue growth. He trained and mentored over 25 green belts in a variety of transactional process improvement projects.

Prior to joining Vertis, James was a Black Belt with New York Independent System Operator, which operates the $12 Billion electric power commodity market in New York. As part of the initial Lean Six Sigma deployment team, he led and mentored a variety of transactional projects, from IT to HR, creating over $1.5 Million in benefits in the process. Prior to entering the Lean and Six Sigma world, he spent 10 years as a project and product manager in both the technology and marketing fields.

James is a graduate of the University at Albany, with a BA in Philosophy and an MBA in Finance. He is a certified Lean Six Sigma Black Belt (BMG), and a Certified Continuous Quality Improvement Facilitator (Juran Institute).