My colleagues and I have often discussed which type of change manager gets more results, especially which type gets more results in our particular organization. We have a lot of pitbulls, who adopt a fairly confrontational stance when dealing with those who need to make a change. They sink their teeth into the data, make a bulletproof metric, and then proceed to beat their adversaries over the head until the metric moves. Performance is segmented and presented by person, not process. One group goes so far as to designate one general manager “Top Dog” and one “in the doghouse” (complete with a photo of the manager in a doghouse) on their metrics reporting portal each week.

Seriously. I’m not making this up.

I’ve worked with people like this before – senior management tends to love having people like this around because they force issues, upset the status quo and make things generally uncomfortable for those who need to change. In other words, they do senior management’s dirty work for them.

Like true pitbulls, they don’t let go once they have their teeth into something. They make things happen, that’s for sure. Whether they are always the right things is another matter.

On the other hand, you have consensus builders – the peacemakers. Short of bringing the guitar to meetings for a round of Kumbaya, they strive for accord. Never mind the fact that consensus means “what everyone can live with”, usually resulting in lowest common denominator solutions, instead of what’s best for the business or the customer. Peers often feel better in meetings led by these folks. They may not make things happen quickly, or make big things happen, but they tend to build a lot of support for whatever the team decides to do.

These are clearly extremes – most of us in the quality field probably have some of each, and have to exercise one over the other depending on the culture of our organizations, the personalities involved with the changes to be made, and the speed at which the changes are needed. These days, speed is probably more important in your firm than comfort – it is in mine.

At the end of the day, we have to be about results. Absolutely. Leadership should care about the process by which we achieve those results, though it often doesn’t.

So what’s your change management style? Has it changed during the economic downturn? Please post your thoughts in the comments section.

AIG Said to Offer $1 Billion in Retention Payments to Employees

As it turns out, this how AIG is choosing to spend part of the $150 Billion it received from the US Government, with much of it going to the very business units that caused AIG to falter in the first place. While the company maintains that these payments are part of contractual agreements that were disclosed in regulatory filings, the optics are horrible. Says one congressman, “I was extremely disappointed -- but not surprised -- to learn that AIG will be awarding bonuses to the very division that drove the company into the ground...”

Why comment on this in a Six Sigma blog? To me it serves as an object lesson about the Improve/Control phase. So much of a Black Belt's time seems to be consumed by data gathering and analysis, measurement system analysis, and development of metrics. Analyze gets a fair bit of attention, although really identifying the true root causes can be extremely difficult. But the real devil is in the details - how is the improvement going to be designed, implemented, validated, and then controlled? GE Energy's CEO recently commented that a powerpoint and a plan isn't enough; it takes digging in deep to find the problems and develop robust solutions.

Those of us at companies that have been doing Lean Six Sigma for several years may find that certain project areas are perennial favorites; the problems never get solved. Truly achieving control over processes (especially transactional ones) requires diligence, detailed procedures and training, regular audits and performance reviews, and corrective action when the outcomes deviate from requirements. In short, things that aren't nearly as much fun as drawing big red X's through non-value-added steps on a future state Value Stream Map.

So back to our disappointed, but not surprised, congressman. I have to ask - if you're not surprised, how could you have expected AIG to do any different? Why didn't the terms of the bailout cover such details? Didn't anyone analyze the situation sufficiently to uncover these possibilities - perhaps a quick FMEA? Did congress and the administration just hope that AIG would do the "right" thing with the bailout funds?

Hope isn't a strategy - not in billion dollar government programs, and not in achieving performance excellence.

While scanning news for lean and six sigma related articles this morning, I came across this gem: "Six Sigma Certification Booms as Employment Busts" - it was actually a press release posing as news over on msnbc.com. That's fine - I recall from my days in media relations that many news outlets craved pre-written content, especially now with the thinning of news gathering organizations.

Over the last few years, the business of Lean Six Sigma certification has bloomed trememdously - a phenomenon that has been discussed at length over on the forums. The consensus there seems to be that such cert programs in and of themselves are fine - I myself have gone through one such program, and had a fine experience with it. For some, online learning works as well, if not better, than classroom training. Different people learn differently. I've also had the opportunity to go through classroom training given at one of the most famous companies ever to use Six Sigma. Again, a fine experience.

So what's the harm in presenting Lean Six Sigma certification programs as a way for currently unemployed workers to get a leg up in a tough job market? Or any job market for that matter?

As most (if not all) experienced practitioners of Lean and Six Sigma have learned, there is a huge difference between learning the tools and concepts of Lean and Six Sigma and actually applying them in a real business setting, with real people, real (usually messy) data, solving real business problems. In my own experience, running a correct MSA, ANOVA or DOE is far less challenging than working through the politics and organizational challenges to create sustained improvements. And this is not something that one can really learn in the classroom or through an online course. It has to be experienced first hand. In this way, our field is no different than any other. The theory is important to know, but in the end, it's the practical outcome that matters most.

Worse yet, the change management approaches used in one company culture may not work in another, or even different cultures within a company. It's a process of continuous learning, re-learning, and adjustment to bring about the desired business impacts.

The certification question is not an issue unique to our field. Professional certification programs are widely available - the real question is, does the certificate provide the leg up during job searches? I would be very interested in seeing data on that question.

The bottom line: Is getting certified in Lean, Six Sigma, or anything else one of those critical X's for the millions of unemployed right now? Please post your thoughts in the comments section.

"Perhaps what you measure is what you get. More likely, what you measure is all you'll get. What you don't (or can't) measure is lost" - H. Thomas Johnson

Those of you who are Deming fans may liken this quote to Deming's admonition that "the most important figures that one needs for management are unknown or unknowable, but successful management must nevertheless take account of them." (from Out of the Crisis, p121).

I came across this quote recently, which was quite apt as I was completing the end of year wrap-up required of all employees at my firm. Like many firms that run on making the metrics, making them look good, having airtight explanations for variances, plans to move the needle, and so on, the powerpoint decks generally tell a tremendous story. (If only Wall St. could see them - perhaps stock prices would be better?).

Conversely, if you don't have numbers to back up your story, come back and talk to me when you do.

So back to my year end wrap-up, which, by the way, is a key component of performance evaluation, merit increases, and future career path within the firm. I was advised to include as many "quantifiable accomplishments" as possible. Having joined the firm only mid-year, and assigned to work on a quality issue that has plagued the industry for 10 or 20 years, it is probably too soon to declare victory and post a dramatic improvement to the things our customers care about most.

In fact, the bulk of my time has been spent trying to develop facts and data about the process performance, and impress upon the producing organizations the voice of the internal and external customers, so that we can focus our measurements and improvement efforts on the right things. Very basic questions - who are the customers? What do they need? How well are we meeting those needs?, basic questions that we are still trying to answer. All the while, the quality of this particular product hasn't changed at all since I launched the effort several months ago.

Our team has also been highly aware of the dark side of metrics - to Dr. Johnson's point, what you measure may be all you get. And to quote another favorite thinker of mine, The Lean Thinker, "you get what you measure, but don't be surprised of people are ingenious in destructive ways in how they get there" (full post here.) So we strive for 100% on-time performance, only to see our first time yields plummet. Or we strive to measure revisions, only to have needed corrections go un-made in order to show a reduction. As one of my colleagues put it, "tell me what number you want to move, and we'll make sure that we do".

Now, this is not a plea to remove metrics. Only to measure the right things, and measure them correctly, so that we account for the "dark side". So, present on-time performance figures, if that's what's important, but make sure the FTY % is always presented next to it. It's also a plea to keep taking account of the unknown or unmeasurable things that matter - just because we can't measure it, doesn't mean we get to ignore it.

Last week, a senior leader and sponsor of this effort jokingly asked whether I had the problem figured out. Not quite. But I was able to tell him that department X has several talented black belts on it, is now focused on measuring defects the right way, and is starting to really understand the needs of their internal and external customers. To which he replied, "That's a major accomplishment!".

I asked if I could quote him in my wrap-up - it's probably the best piece of data I have going for me thus far.

Whatever holiday you and yours celebrate, I hope it is a good one.

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.

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.