<?xml version="1.0" encoding="iso-8859-1"?>
<rss version="2.0">
	<channel>
		<title>Six Sigma Blogs at the iSixSigma Blogosphere</title>
		<link>http://blogs.isixsigma.com/RSS2.asp?action=full</link>
		<description>Six Sigma Blogs at the iSixSigma Blogosphere</description>
		<language>en-us</language>
		<copyright>Copyright 2004-2009 iSixSigma</copyright>
		<managingEditor>blogosphere@isixsigma.com</managingEditor>
		<webMaster>blogosphere@isixsigma.com</webMaster>
		<generator>iSixSigma Blog 1.0.5</generator>
		<lastBuildDate>Fri, 20 Nov 2009 15:37:24 -0800</lastBuildDate>
    	<ttl>60</ttl>

		<item>
			<title><![CDATA[Six Sigma Blogs: Business Scenarios]]></title>
			<link>http://blogs.isixsigma.com/archive/business_scenarios.html</link>
			<description><![CDATA[How do you describe a process to a team? There are lots of tools in the toolkit including value stream mapping, functional swim lanes, context diagrams and SIPOC to name a few. But I find they can be “a little cold” for a non-technical or cross-functional team and I want to “bring it to life”.
Take a simple example from the area I work in, general insurance. To describe the customer claims process in any depth takes time. So when you have a cross-functional team covering front, middle and back office it can mean (even with the tightest time keeping and agenda) that the people at the end of the process don’t get a look in as most of the day has been spent at the beginning/middle of the process, where all the customer interaction happens. So you end-up leaving people out. 
As the title suggests my recommendation is Business Scenarios. Rather than cover the generic customer claims process, cover it in a series of business scenarios like

The policy holder’s vehicle collided with a lamppost, no one else was involved, it happened at 11:45pm
The policy holder’s vehicle was hit by a 3rd party vehicle from behind, both vehicles were drivable, no one appears injured at the scene, 3rd party was insured and traceable
The policy holder’s vehicle collided was a 3rd party vehicle on a narrow street, liability is unclear, 3rd party injured and vehicle undriveable
If you start with the simplest scenario where nothing goes wrong (sunny-day) then you can rapidly walk the whole process.  You can add complexity as you need to. Maybe include failures in the process and known exceptions (rainy-day) e.g. 3rd party had no insurance. 
This approach really opens up the discussion as you are talking to people in the language they relate to. You get to see the true degree of variation required of the process which allows for more robust solutions.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 28 Sep 2009 08:41:11 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Training:  Enough, Already?]]></title>
			<link>http://blogs.isixsigma.com/archive/training_enough_already.html</link>
			<description><![CDATA[I enjoy teaching, so if you asked me whether you could do too much training, my first response would be "no, of course not!"
But, on second thought, I would have to say, "well, maybe."
It's been my experience that knowledge alone is usually not enough to create an improvement.  A lot of people enjoy being trained (a day away from the office, with lunch included) and also like knowing what could be done to create a better process.  But, having a lot of knowledgeable people bumping around in your organization doesn't necessarily mean that there are any improvement activities going in.  It's the doing - or execution, if you will - that separates the thinkers from the achievers.  So the important question seems to be, when do you know enough to start improving things?
There is a train of thought that runs like this:  "We don't need to train our whole organization in Lean or Six Sigma; that takes way to long to get any ROI (Return on Investment).  Let's start by getting some project teams together and use them to drive improvements."
There's another train of thought that says, "Let's not go shooting off in a lot of different directions. We'll train our executives, then our other leaders, then our managers, then our front-line staff; we'll come up with a deployment plan, and then we'll be ready to do projects."
So is there a "right" way to approach a Lean Six Sigma deployment?
Now, before you all write back to me telling saying that the answer is "IT DEPENDS!" I will ask the question a different way:  Have you, in your experiences, ever found that an organization did too much training?  Or that an organization did too little training?  What were the effects or consequences?  And what advice would you give an organization new to Lean Six Sigma, on the balance between training and project focus?  Thanks in advance for sharing your thoughts!
 ]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 26 May 2009 11:10:15 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Statistical Significance vs. Practical Significance - There Is a Difference]]></title>
			<link>http://blogs.isixsigma.com/archive/statistical_significance_vs_practical_significance_there_is_a_difference.html</link>
			<description><![CDATA[Today I was reflecting on a potential topic that could come up in a traditional project involving any test or DOE utilizing a 'p-value' criterion - it actually did for me a few times in the past.
Hypothetically, say for example there is a process that has very low inherent process variation (process s is very low), with a very high Cp or Pp (depends on how you define s, but say 2.0 or greater), yet has a very low Cpk or Ppk (or Z for that matter - basically the process is hugging or is outside either the upper or lower customer acceptance limits, but very stable at this level), so the situation is characterized as a classical optimization problem.
A black belt performs a DOE, and finds a factor that has a P-value of 0.05 or less on the output.  Using the information, the new factor setting is applied to the process, and the new Z value has barely improved.  The black belt is frustrated, because the factor was 'supposed' to be significant.  What gives?
In this case, the effect of the factor was much smaller than the level of optimization needed to make a real difference.  But the effect was large enough to make a statistical difference based on the low inherent variation level of the process.  A quick check of the main-effects plot (and the coefficients in the analysis for that matter) compared with what's needed to achieve the required optimization would confirm the situation.
So why would this happen anyway?  I've seen some black belts "go by the numbers" (specifically p-values) without looking at the graphics....and without looking at the real picture of what's needed at the output side of the project.
A great teacher once told me to look at the graphs first....he was right.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 22 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Financing Six Sigma Training During Difficult Times - An Option]]></title>
			<link>http://blogs.isixsigma.com/archive/financing_six_sigma_training_during_difficult_times_an_option.html</link>
			<description><![CDATA[During difficult times like we’re facing today, some of the first things that get cut are the "non-essential" items not related to core business.  Of course, the paradox here is that some items that are deemed "non-essential" are actually huge enablers to a company.  Take for instance Six Sigma....definitely an enabler, but if your program is in its infancy, it may be easy for it to be placed on the chopping block.
If you fear that your program is getting the ax, an option that you can consider is tapping into a training budget.  Many states (and maybe even other countries - but I’m not sure about that) offer training funding that is independent of operating budget.  You’ll have to check with your appropriate department at your company for the particular rules around this topic, but it may be a feasible option.
Be aware, you will most likely have to separate training from consulting services, but usually it’s just a matter of having your Six Sigma partner separate their quote accordingly.  
You could potentially lessen the blow to your operating budget, which is absolutely sacred in our current operating environment.
Has anyone found other creative ways to finance Six Sigma activity?  I’m always looking for them...;)]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 09 Apr 2009 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Can We Use Six Sigma Tools Outside of Projects?]]></title>
			<link>http://blogs.isixsigma.com/archive/can_we_use_six_sigma_tools_outside_of_projects.html</link>
			<description><![CDATA[One of the things that I see as a challenge to companies that grapple with a Six Sigma implementation is effective use of tools in "live" situations. By "live", I mean in a normal operations context, not in a project context. When looking at the use of Six Sigma tools, using them in a project mode in my opinion is an easier affair. A project leader can plan in a project context which tools to use, based on the DMAIC project model.But what about "live" application of tools? For example, why can’t DOE used to diagnose problems on the factory floor outside of the DMAIC formal context? Consider this:A product is defective, and it is composed of 4 parts. Run a four-factor DOE with the factors being part presence (yes/no) and find the potential contributor(s) and contributing interactions. This will at least give you an idea if the component part inputs are influencing the defective condition, and will get you at least half way to problem resolution.
Most of the time in the case above I’ve seen engineers "measure their way" into a guess of a root cause to the problem, which can be inefficient to say the least.
My opinion is that the real power of Six Sigma comes once culture change sets in and real problem solving occurs as part of the business, and NOT in the form of Six Sigma projects only.  It seems like common sense to me that advanced tools would be used anyway to solve problems, but in most of the different companies I’ve been involved with, I can honestly say that I have not seen much use of the statistical tools in "mainstream" use.
What restrains companies from using Six Sigma tools beyond the DMAIC project scope?
 ]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 03 Apr 2009 11:57:02 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma really sucks!]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_really_sucks.html</link>
			<description><![CDATA[Picking-up on Sue’s recent Home blog, I’d like to talk about my recent experience at home.
Over this weekend my wife and I had  “words” about the work I do helping on the home chores. There were a number of areas such as cooking, washing dishes, ironing, cleaning toilets, shopping, washing clothes, making beds, tidying-up, planning meals, and so on. I had no idea of the number of NVA factories at work and being a strong believer in Six Sigma I committed to resolve this problem. 
I dedicated my Saturday evening and produced what I believe to be a very polished piece of work. I reviewed the key processes and created a core set of current-state value stream maps. For each of these I developed some slick data collections sheets to baseline current performance. I even identified some time saving quick wins. I shared my work and must say I was most surprised by the reaction and being told exactly where to stick my data collection sheets.
But I am a committed practitioner and realised I may have misunderstood the problem statement and goals. It seemed helping to do the chores was more important than improving current performance? So Sunday night I cooked the evening meal and over dinner suggested we discuss our differences. Luckily to support this I had previously produced a fishbone diagram and recommended a rapid brainstorming exercise followed by constraint busting 5-whys to get quick results……. 
Back at work on Monday morning, I am having a tough job trying to explain my black eye. I’m sleeping in the spare bedroom and the kids think I am an idiot. 
Six Sigma really sucks!]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 01 Apr 2009 01:46:53 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Intelligence Status Report]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_intelligence_status_report.html</link>
			<description><![CDATA[After a long and extended absence, I am back to share some practical tips to help your Six Sigma program in times of economic turmoil. For starters, during the measure and analyze phases of a project, any of my readers know I talk about, this point of all projects and the introduction of BI, or business intelligence. 
Business intelligence represents the data within organizations that helps operationally drive, tactically drive and strategically drive better, more data driven decision making. Six Sigma, in parallel, is a process and quality methodology for reducing variation, defects, or increasing quality. 
Use this template as a starting to do list and status report out for all BI related project tasks. Click here for form
Sample Project Task Status Report]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Innovation&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 26 Feb 2009 18:06:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Targets – Part 2]]></title>
			<link>http://blogs.isixsigma.com/archive/targets__part_2.html</link>
			<description><![CDATA[In my last blog, Targets, I covered the situation of hitting time targets in a services environment. I thought I was onto something but wasn’t sure just what…….. 
Just to recap, people are targeted on delivering work within a certain time frame e.g. reply to a customer letter within X number of days. There was an understanding that this “drives the wrong behaviours” but no clarity on what to do. Here is what I have come to. 
What I did was look at the current measure and split time into value and non-value as shown.

Then I looked at the two time components and put together two principles:
1. The time an item is waiting in a queue should not be the handler’s problem; it’s a management problem. The idea of pushing people to “work harder” because of variation in demand doesn’t work and alternative solutions are required.2. The time that a handler is working on an item should not be driven by a time target but should be against a quality target. We want our people to do a great job as quality drives down rework, defects and costs.
Now the tricky bit, how to translate these principles into actual measures. What I looked for were rules for defining the measures and came to these from Vanguard


The measure should help in understanding and improving performance – capability measures rather than targets

The measure must relate to purpose – measure what is important to the customer

The measure must be integrated with work – the measures must be in the hands of the people who do the work
 Looking at these and my principles I came-up with two measures:


Lead Time - The time from receipt to when work starts. Leadership and not handlers own this. They are responsible for improving Lead Times by changing the system not “cracking the whip”

Right First Time – This is not a time measure but a quality measure. For each step in the process, the “Must-do” &amp; “Optional” requirements are defined. These are the items that ensure the work is done correctly without defects being created. It is as simple as a check-list to ensure work is done as required.
The approach extends across the whole life-cycle. This splits the process into value and non-value adding steps. It focuses the right people on doing the right things – leadership to reduce Lead Time by reducing waste in the process – handlers to improve Quality by defining, doing and measuring what is required. 
Sound good? I am already getting challenges and resistance. Would appreciate comment on the logic and how I could make the proposal even better….. ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 20 Feb 2009 10:18:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: WWDD?]]></title>
			<link>http://blogs.isixsigma.com/archive/wwdd.html</link>
			<description><![CDATA[Perhaps you all arrived at this conclusion way ahead of me, but I’m starting to worry more and more about the way we, as continuous improvement professionals, are spending our time.
It’s becoming increasingly clear that the world in general, and the economy in particular, has gone off meds. Yes, I know, this isn’t news at this point. But lest you think I’m the last one to get the message, seek out the open letter that John Stumpf, The CEO of Wells Fargo, recently placed in the New York Times and elsewhere. He was explaining his view on “the value of team member recognition”…which apparently boils down to paid travel to fun places in his mind. Clearly there’s at least one other person slower on the uptake than me.
The press has been all over this letter, including this piece by Maureen Dowd. I don’t have anything to say about it that hasn’t already been said by smarter people. But it does highlight that there is a true shift going on out there. What used to be reasonable, even commendable, has become detestable.
Deming exhorts me to create constancy of purpose, and Wheeler explains to me why reacting to random variation is a bad thing. I feel I have both and intuitive and statistical understanding of “special cause”, and I try to apply that understanding to the work in front of me. Usually that means resisting the tendency to chase special causes in favor of common cause work, and for a long time I have been confident that was the right thing to do.
But now? A lot of things are changing. Those changes feel drastic. Is it time to react in a special way? Or is this just fluctuation of the larger system? Do we keep running our Six Sigma programs, Lean initiatives, and Quality Management systems and wait it out? Or has the time come to move on to changes and initiatives that are more radical and sweeping? More special? Deming does advocate constancy of purpose, but in the next breath he points out the need to adopt a new philosophy for a new economic age. Which advice applies now? What would Deming do?
Let me offer a few more things to think on to frame this question. Continuous improvement programs usually rely on projects as units of work. Using various toolsets, each project is able to return more value to the organization than they consume in money and resources. Group a bunch of these projects together, add up the saving, and you have a program.
Successful programs might generate 5% productivity each year. In other words, if we do things right, we might produce 105% of what we produced last year for the same amount of money. Or maybe we produce the same amount for 95% of the cost. You get the idea. For the past several years, maintaining that sort of incremental improvement in consecutive years was a great result. 
But now? Your sales are down 80%. Your raw material cost are up 150%. You can’t spend $100,000 even for a guaranteed return of $125,000 because credit is frozen. Double digit percentage layoffs abound. In this environment, that ongoing 5% productivity that was great a few years ago is less than a rounding error compared to the huge swings that are happening largely outside our control.
Take Wiremold as a cautionary example. If you are reading this blog, there’s a good chance you already know something about this company from Womak and Jones’ book “Lean Thinking.”
Great company, hugely strong in Lean, right? Well, read this. Sure, there were clearly other factors involved, and maybe their commitment to Lean isn’t as strong as back in the day. But anyway you slice it, this is a titan in the continuous improvement world staggering from a serious blow. Lean can’t help if there is no demand. You can’t save your way to top line growth. It doesn’t matter how efficient you are if no one has money to buy what you are selling.
I think we at least need to ponder whether anything that we are doing matters at this point. Whether we are maybe even part of the problem. It’s easy to spank Wall Street CEOs as they assume the position in front of Congress, but are we just as guilty of failing to confront a new reality?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 12 Feb 2009 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Tip-Top Tip]]></title>
			<link>http://blogs.isixsigma.com/archive/tip_top_tip.html</link>
			<description><![CDATA[Happy New Year! Today, rather than talk about something deeply insightful I thought I would share one of the tools I like to use. 
Ever had to arrange a project meeting? Did you need to get say 10 people’s diaries aligned, usually at short notice? Was it fun?
There are many ways to approach this simple but sometimes frustrating task. 

You could swap lots of e-mail with everyone till you get agreement 
You could force the date &amp; location and that’s it 
You could ask someone else to do it for you 
You could forward plan and have a meeting schedule defined well in advance 
Your calendar software might even find the best date for you
Here is one way I find useful. There are a number of free on-line survey site on the internet. I take a couple minutes to set-up a survey and send it out as shown below.

Then sit back and wait for the responses.

Very useful tool.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 09 Jan 2009 08:54:48 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Don't Look Now - Here Comes the Wave]]></title>
			<link>http://blogs.isixsigma.com/archive/dont_look_now_here_comes_the_wave.html</link>
			<description><![CDATA[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.
 ]]></description>
			
			<author><![CDATA[James Considine]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Tue, 06 Jan 2009 06:40:40 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: When is Lean... Not Lean?]]></title>
			<link>http://blogs.isixsigma.com/archive/when_is_lean_not_lean.html</link>
			<description><![CDATA[I have been thinking a lot lately about how the Toyota Production System was developed.  Unlike those of us who have books, websites, and training programs in abundance, Toyota engineers took their process of assembly-line manufacture of automobiles and created, in incremental steps, the methodology that's now known as Lean.  It took shape over a long period, as different contributors added their ideas to create a strong "House of Quality" for the Toyota Motor Company.
But - what if these bright people had not come from automotive manufacturing?  What if they had come from (for example) healthcare?
I know that this is akin to imagining what the earth would be like today if there were no moon.  (Just think - no tides.  Different air and water currents.  Little shore erosion - no sand?  Hard to imagine!)

What if their initial process studies were not based on repetitive motions that could be adapted to robotic or at least automated mechanisms?
What if their major source of variation was not the mechanical devices, but the people who provided the process?
What if their processes were not amenable to on-the-job training, but required differentiation of skill and ability at the level of advanced education and training?
What if their product was not someone who "ordered" a tangible object, but someone who showed up unannounced with a mysterious problem that couldn't be solved by just looking at it?
It made me think that if those bright young engineers had worked in healthcare, that what we now call Lean would be vastly different than what was developed by Toyota.
And, as a related thought, it made me wonder what we are doing by applying lean manufacturing principles to healthcare.
Now, I'm not the healthcare equivalent to Eiji Toyoda.  Or Shigeo Shingo.  Or Genichi Taguchi.  Or any of the other brilliant minds that helped to develop the Toyota Production System.
But, am I doing a disservice to my providers and customers, when I try to fit lean manufacturing methods to a highly technically-skilled service environment?
I've heard over and over again that lean can be adapted to any process, anywhere, in any industry or branch of service.  I've done many lean projects myself, and seen the very tangible benefits that value-stream thinking and creation of flow can produce, along with level loading and consideration of takt time.
But are we only seeing the tip of the iceberg?  What further benefits might we see if we developed a "service system" that used tools uniquely intended for service processes, rather than adapting manufacturing tools as best we can?
Just asking!]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 29 Dec 2008 11:27:41 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: My journey towards Lean]]></title>
			<link>http://blogs.isixsigma.com/archive/my_journey_towards_lean.html</link>
			<description><![CDATA[When I started in continuous improvement (CI) four years ago it was via the traditional Six Sigma DMAIC route. I was indoctrinated into the Six Sigma world and have earned my ASQ CSSBB and can do impressive stuff with statistics. Lean was not even on the radar for me, it was just another approach that was used to solve the easy stuff. It did not have the rigour to make lasting improvements.
Then Lean appeared through our training material and we merged it to become Lean Six Sigma. But it was an unequal partnership. We had the DMAIC model with Lean as a bolt-on included in the Analyse phase. It focussed on analysing and removing waste in the process. It was a pretty easy concept; by removing waste you become a Lean business. And that’s how it stayed, everyone understood Lean.
Meanwhile I had nagging doubts that pure Six Sigma did not provide a complete package. There are the obvious issues around needing to include project management, stakeholder management, soft-skills training and deployment program management. There was also the concern that it was too generalist as specialist niches become prevalent, e.g. Customer Experience theory now goes way beyond the VoC approach. 
It started with The Goal. I really liked the concept of managing your process around exploiting the constraints &amp; bottle-necks. Then I met a few people who had started their CI journey from Lean who talked about different concepts &amp; approaches. Then I met someone who was a Systems Thinker and they thought Six Sigma was just plain wrong. Give these quotes a go, (more in a follow-up blog as I am still reading the book):

It starts with ‘define’ so the wrong problems get tackled, not the actual problems, which will only be revealed when you study the organisation as a system.
Loads of money is spent on training tools, most of which will never be used; and tools are not the means for changing the system. 
The reporting systems ensure benefits are ‘realised’ but they are, most often, spurious e.g. claiming productivity improvements through speeding up part of a process with no knowledge of the impact on the end-to-end process 
It has been used to focus on cost; managers should instead get focused on value as the better way to reduce costs and increasing capacity. 
In short, Six Sigma is a classic packaged invention aimed at gullible managers. The wrong facts are misleading; we should salute its demise.
All good stuff to challenge the orthodoxy. So I have been studying pure Lean. First problem I had was translating the tools out of manufacturing into a service organisation. With things like SMED you seem to have to abstract the concept and look for applications. Or 5S, it’s not a safety issue having a messy desk and I am doubtful on the benefits (I have a clean desk). But as I got deeper I found this doesn’t do Lean justice, the fundamental principles and practises go way beyond “just eliminate waste”. Lean seems to provide much more in terms of the complete package and inparticular around empowering people.
As ever, I still have my doubts e.g. how does break-though innovation happen in a Lean environment? And what about the “Lean is just removal of waste” label? But it has definitely shifted my thinking. Now I am "Learning to See" I wonder if there are any other approaches I should be looking at?]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 17 Oct 2008 06:46:13 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Rigmarole]]></title>
			<link>http://blogs.isixsigma.com/archive/rigmarole.html</link>
			<description><![CDATA[Six Sigma is an amazingly persistent program. I was left off the list for the official birth announcement, but someone should probably be planning ahead for a thirtieth birthday party in the next few years. That’s remarkable longevity for trumped up flavor-of-the-month program.
I think Six Sigma is utterly absurd in many respects. Even if you love the methodology, you have to admit that the jargon and belt terminology are over the top. Honestly, to the uninitiated we must sound like a group of arcane techno-monks spoiling for a fight. We're the drag queens of the quality world. Six Sigma training methods are generally excruciating, and often rooted in dubious pedagogy. Quality control at the program level is non-existent. Statistical methods are routinely abused. Many conclusions reach are just plain wrong. I can see all this quite clearly, and I like the program.
So why does Six Sigma survive? If it is patently ridiculous, potentially misleading on crucial questions, and generally very annoying, why do people keep using it? The answer is simple, I think: because despite all that, it works. But not for the reasons you might expect.
Consider the window dressing that accompanies a full-blown Six Sigma project. For the sake of this example, let’s assume we’re looking at one of the first projects in an organization. The process probably kicked off with the search for a consulting partner. Six Sigma consultants come at great expense, so some native set of requirements likely kicked in that required multiple consultancies to be evaluated by a high-level team. Once the consultant was picked, candidates for training had to be selected. Because the training is so expensive, this again required a great deal of concerted time and attention from the organization. Ditto for project selection. Finally training takes place, and everyone has to learn a whole new dictionary. The project gets rolling, toll gate reviews start up, and they’re unlike any project meetings ever seen before. No one really understands anything. Questions are asked, arguments begun, experts called in. Eventually paths forward are determined, and execution starts. Implementation is carefully staged and monitored because, let’s face it, no one involved can afford for the project to fail at this point. Results occur, processes are changed, metrics are reported, and success is celebrated. Everyone is happy, and not a little bit relieved. Now repeat, and repeat, and repeat.
That’s a lot of rigmarole. And it’s generally considered to be the ugly side of Six Sigma, the messy underbelly that necessarily accompanies the elegant statistical approach, the data driven decision making. But I think that view gets it backward, suggests that the tail wags the dog. Far from being undesirable, I think all that rigmarole is actually what adds the value in the whole process. I’m convinced the content of the program is immaterial. All the program content needs to do is trigger the window dressing, because the window dressing is what gets the right people in the room.
Let me put it another way. Many companies hire consultants to do things that they supposedly cannot do for themselves. But it is sometimes the case that consultants come in to the organization and seek answers to the question being asked entirely within the organization. Which is strange because logically, consultants are not needed if the answer is already present in the population hiring the consultant. (If you haven’t experienced this phenomenon you might think I‘m making it up. But ask around, because I’m sure you won’t have to go too far to find someone who can provide relevant story from your part of the world.) Development of corporate strategy is an archetypal example. So why use consultants in such cases? They are extremely expensive, and the answer is already there. Well, you use them precisely because they are expensive. Writing that check triggers a set of behaviors in the organization. It forces important players to take notice. It makes it politically dangerous to ignore the outcome of the project. It means people show up at meetings and complete their action items on time. And all that means that the answer is suddenly taken very seriously, even if it was known all along, and even if it happens to be incorrect.
I think Six Sigma works the same way. The crushing structure, bureaucracy, and cost of a deployment sends all kinds of signals to the organization that the program is important and needs to be taken seriously. I’m not saying it makes sense, but I am saying it works. All the rigmarole serves the very important purpose of getting the right people in the room, which means decisions can be made and execution can happen. The guts of the program don’t matter, as long as it serves that purpose in the end. Six Sigma does this by accident rather than by design, but it nonetheless does it very well. And that’s why I think we should probably be planning for a thirtieth birthday party.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 13 Oct 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Company Policy – Help or Hindrance?]]></title>
			<link>http://blogs.isixsigma.com/archive/company_policy__help_or_hindrance.html</link>
			<description><![CDATA[I recently bought some registry cleaning software on the internet using PayPal. My mistake, it was a scam. I made contact with the PayPal Dispute Resolution team to see if I could get my money back. Followed the highly efficient process (no human interaction) and made repeated attempts to contact the supplier before escalating to PayPal to resolve. Automated e-mail response, it is not their company policy to resolve this type of situation. I sent a follow-up e-mail but got another response talking about, “we are unable to blah, blah, blah….” So made contact with my credit card company and they gave me an immediate refund, their company policy was to resolve this type of situation.
Given I represent about 0.000000001% of their revenue I’m not a big loss, but to what degree can company policy be an incentive or disincentive to the customer experience?  
A company policy sets the guidelines for a companies activities and helps staff in areas where there appears to be latitude in deciding how best to operate. You could see company policy as one-way of defining the culture of the company and what is seen as important.

In a bureaucratic culture the policy might be shown as over complicated forms, slow decision making and having to always follow the company defined process
In a cost-cutting culture the policy might be shown as looking to use the cheapest channels to market (e.g. web &amp; e-mail) with a gradual decline in overall proposition
In a profit-driven culture the policy might be shown in overuse of cross-sell and up-sell and constant marketing communications
In a political culture the policy might be shown as a fragmented proposition as different teams use customers for their own political games
In a customer-centric culture the policy might show empowered staff being given the flexibility to do what’s right for the customer 
So when designing a customer policy it seems the key question to answer is, “from whose point of view should it be done?” From a Lean Six Sigma perspective this should be “outside-in” focussing on the Voice of the Customer. Not, to quote Carol from Little Britain, “Computer says no”. ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 03 Oct 2008 08:03:20 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Manufacturing]]></title>
			<link>http://blogs.isixsigma.com/archive/manufacturing.html</link>
			<description><![CDATA[For a hobby last year I started making cider (hard cider in the US). Below are some of the demijohns of apple juice I fermented. 

I cracked open a finished bottle and it looked &amp; smelt great, but the taste…. it was insipid, slightly acidic and low in alcohol. Not good. Being in the business of continuous improvement and this being my second year I am ready to develop my manufacturing process.
I have researched the issues and my proposed solutions are.

Insipidness: I believe was due to using just eating apples, it should have been a blend of eating, cooking and crab apples. Here is a sample of my raw materials



Acidity: I have my pH tester and acid reduction solution.

Alcohol: I have my hydrometer and bag of sugar to up the alcohol content. 
So the question is what makes the perfect product? What better than to design an experiment. Being by no means an expert in the practical design of DoE, here is my endeavour. The factors &amp; levels seem to be:




 Factor
 Levels

 pH reading 
 Two levels. Initial pH of blend or set to pH of 3.8 (which is highest recommended level)

 Sugar content
 Two levels. Initial natural sugar content or adjusted to give final product of 7% alcohol

 Apple Blend
 Tricky, I want to try different combinations but not at the extremes of 100% of any one. I would like to get my blends by having variations of eating apples from 40 to 80%, cooking apples from 40 to 80% and crab apple from 0 to 20%. Not sure on this bit yet, could do with some help
The output will be taste tests scored from 0 to 10. I have a limited number of trails as I only have 8 demijohns. this should create the product to scale-up next year. Any tips on the best design to ensure I get good results?]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Wed, 10 Sep 2008 03:35:13 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: My Husband the Black Belt]]></title>
			<link>http://blogs.isixsigma.com/archive/my_husband_the_black_belt.html</link>
			<description><![CDATA[When I first went to Six Sigma training, I was very enthusiastic about it and shared everything I learned over the dinner table with my family.  I talked about my projects and the tools, my successes and failures.  I always thought they listened politely and then forgot about it.  You know, Mom talking about work AGAIN, yada-yada-blah-blah-blah.
Then one day recently my husband came home and asked me to help him transfer some process maps into an electronic version.  With a team from his workplace, he had facilitated a current state and future state map, and then asked the team to come up with goals for the project.  They included:
- Identify opportunities for flow 
- Eliminate duplicate steps
- Standardize process
- Meet stakeholder requirements
- Ensure that accreditation requirements are met
- Develop metrics for monitoring the process long-term
Now, he had talked about doing an improvement project at work for this particular process, but I hadn't quizzed him on the details.  So I was surprised and pleased that his project incorporated so many elements of the Lean and Six Sigma methods.
"Wow, honey, that's great!" I said.  "You really learned a lot from hearing me talk about my job at the dinner table!"
"Well, not really," he replied, "it's just common sense!"
Now, while his answer was not particularly tactful, I did like it for one reason.  It made me reflect that it would be great to live in a world where utilizing process improvement tools and concepts is "just common sense!" - instead of the resistance-laden, data-poor, time-crunched activity that it sometimes is.
I'll think I'll spend a few moments in that imaginary world, before returning to the next task on my to-do list!]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 09 Aug 2008 15:04:08 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Being Right]]></title>
			<link>http://blogs.isixsigma.com/archive/being_right.html</link>
			<description><![CDATA[There are countless business books out there that present good reasons why it is not necessary to be 100% right all the time. Beyond being unnecessary, I think being completely right is highly over-rated in the context of business. Being 80% right and good at executing is probably more than sufficient in most cases. Not all cases, of course, but most. Being 50% or even 25% right and good at executing is certainly better than being 100% right and unable to execute. But clearly, this message is not getting through to the Six Sigma crowd.
I say this because the majority of philosophical conversations I hear about continuous improvement still revolve around a driving need to be right. These range from high level (Is Lean or Six Sigma the right program for this company? Have we got the right set of tools? Are our senior executives saying the right things?) to very specific (Are we doing measurement system analysis right? Do we have the right project selection process? Is our interpretation of capability indices right?). But they all rest on a common assumption that being right about the various aspects of continuous improvement is necessary.
I’ll do the 80% contingent one better and propose that being right is neither necessary nor sufficient for a continuous improvement program like Six Sigma to work. I’m not even sure it is worth worrying about.
The sufficiency clause is easier to argue, because libraries are filled with books by people that are right. Deming was right. Shewhart was right. Ishikawa was right. Juran was right. Womack is right. Wheeler is right. There are even some consultants out there who are right. Plenty of people over time have got things right. But there are still many of organizations doing it wrong, even though they’ve read all of the books and hired the consultants. So clearly being right isn’t sufficient for being successful.
There is also ample evidence that being right isn’t necessary for being successful. I’ve seen multitudinous cases where flawed methodology or assumptions were used to generate genuine process improvements. And not just by luck. There are plenty of Green Belts and Black Belts out there who misuse the statistical toolset they have been handed and still turn out great results. Same thing for Lean or any other methodology you care to mention.
Indeed, this latter phenomenon is a fixation both in the community and in the popular business press. There are plenty of detractors out there who gleefully point at holes in the methodology, highlight inappropriate shortcuts, and take pride in identifying errors. I’m tired of hearing from those people…not because they are incorrect, but because what they are correct about doesn’t matter. What those folks don’t realize is that being wrong doesn’t have much of an impact on the success of the program as a whole. Because being right is almost irrelevant.
You only have to be vaguely right – let’s say 25% for the sake of argument – to have a program that adds significant value for an organization. That’s because the real value of these programs is forging a common approach and methodology across the organization. Getting people on the same page and (to mix metaphors) marching in the same direction.
Let me put it another way. Take the usual assumptions about running a successful program. Any book, consultant, or expert will tell you that the following are needed (your list may vary):

The support of senior management
Top-notch training on the methodology
The best people assigned to the most important problems
Adequate resources, support, and budget
The focus of the organization for a sustained period of time
My point is simply this: if you manage to get all of those things in place, what you decide on as the content of the program is largely immaterial. You want to teach DMAIC? Fine. Want to make Lean your thing? Fine. Want to invent your own methodology? Fine. Want to have hula classes and a luau every Friday? Fine. It really doesn’t matter. The entire point of the program is to force the bullet points above to happen. Do whatever you have to do, call the program whatever you have to call it, just make sure those things happen. Because once they do, the rest is just details. Hula and luau can work just as well as Lean and Six Sigma.
This, ironically, is why Six Sigma has been so successful and so long-lived. Not because it is especially right - Lord knows there are holes in the philosophy and methodology you could drive a truck through. (1.5 sigma shift, anyone? CpK without control charts, anyone? I could go on…) But rather because it is very, very good at motivating the organization towards the goals described above. And that turns out to be much more important than being right.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 03 Aug 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma for the Office]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_for_the_office.html</link>
			<description><![CDATA[I love it when people in the office talk about what they can do to improve costs. Having said that, over the course of my career, I would say the majority of  Six Sigma office projects I’ve seen should’ve never been started in the first place.
Is there variation in the office? You bet.  Why is it one person can remember how to cancel a print job while the other waits for a novel to be printed before he realises he’s made a mistake? Why do you only need one pen when the person in the cube next to you needs eight to do the same job?
You, as many people I work with, would think the office atmosphere is ripe to reap the rewards of Six Sigma. I have seen projects geared to reduce office supplies, paper usage, color copies, shipping carriers, etc. You name it, I’ve probably seen it attempted to be done. And do you know what? The majority of the time, the projects fail. 
While the ideas have merit, it’s execution of piloting office projects that set the stage for failure. The fundamental rule of Six Sigma is to pick projects where the factors can be controlled.  When it comes to human nature in the office, it’s often very difficult to lock in changes unless you can error-proof the process (this puts the “Lean” in Lean Six Sigma).
For example, I remember a project to reduce shipment errors and costs by standardising with one company. Although the contract with the outgoing company was not renewed, its supplies were left in the mailroom only to have people continue to use them and the company charge a higher rate (because there was now no contracted discount).
Another example involved a project to reduce printing expenses.  Printers had their defaults changed to print black and white on both sides of the paper. Access to color copiers was restricted to only a few employees.  Announcements were even posted on copiers and printers.  Sounds like a success, right? Wrong. Although some of the modifications did initially post modest savings, they were offset by sales and marketing re-printing the double sided materials into a single sided format. Another issue arose when legitimate stakeholders did not have access to needed copiers. In addition to the rework involved to grant user access, a wave of discontent swept through the office.
This leads me to my next point. If you want an office project to succeed, you need to involve everyone working in the office. Any value you think you may save by standardising office supplies will be quickly lost in productivity by the individual making the rounds to whinge and moan about how he can’t write with the inferior pen that was 17 cents cheaper than the one he used to use.
Lastly, in order for an office project to be a success, an adequate control plan must be in place and communicated.  I’ve seen a project where a mini DOE on toner cartridges was conducted that clearly demonstrated the best product, only to have results overlooked because the person quit three months later and the supplier’s part number wasn’t uploaded into the ERP reorder system.
Controllable, error-proofed, customer focused and embedded. If your Six Sigma office project can’t use these words, then you may want to find another project.]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 28 Jul 2008 04:11:04 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Numb3rs]]></title>
			<link>http://blogs.isixsigma.com/archive/numb3rs.html</link>
			<description><![CDATA[You don't have to read much of the daily paper, in the US at least, to see data presented in very interesting ways.
"Gas price SKYROCKETS to $4 a gallon!"
"The Dow Jones Industrial Average PLUMMETS to 12,500!"
"Pistons [Basketball Team] Have the EDGE Now!"
"Kid Obesity Rate STEADY"
Now, part of the reason for this hyperbole is that exciting headlines get more people to buy the paper, and so you may think that the exaggeration is just a way to get people to read the accompanying story.
But when you look more closely, the gas price moved from $3.97 the week before; the DJIA had been 12,600 on the previous day, the Pistons were tied 2-2 with the Celtics, and buried in the paragraph about the kids was this statement:  "...it's too soon to know if this really means we're beginning to make meaningful inroads... it may simply be a statistical fluke."
Well, that puts a little different spin on the headlines.  I worry about this for two main reasons.  First, we are all at the mercy of first impressions, and while newspapers need to sell, they sometimes do it by presenting data in a way that is easy to get alarmed over, but not easy to understand (as we project engineers would understand it).  Now, no one expects to see or hear detailed information on how the data was collected, or how the sample size was calculated.  But how many people read the full story in depth?  At least, we should train ourselves (and our kids) to realize when data is being presented as a teaser for the story.  As I put it in my Lean Six Sigma class, "What questions should you ask about how this data was collected?"
The other reason that I worry is that the math that my kids were taught, in their suburban-Detroit high school, had very little to do with real life; they could figure cosines and vectors and the slope of a line, but not how to figure whether a drop of 12,600 to 12,500 was cataclysmic.  I for one would eliminate geometry in favor of a statistics class - including statistical process control, presented with real-life scenarios.  Then readers and viewers and listeners could have an idea about whether data was being presented in a rational way by the news media.
What do you think?  Is data presented in the news in an ALARMING fashion???
 ]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 28 May 2008 10:05:08 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Simplicity]]></title>
			<link>http://blogs.isixsigma.com/archive/simplicity.html</link>
			<description><![CDATA[I was recently perusing Time magazines “Top 100” list for 2008, and came across this entry for Peter Pronovost. I had never heard of Pronovost. Here’s part of what profiler Kathleen Kingsbury had to say about him:

“A critical-care researcher at Johns Hopkins University, Pronovost may have saved more lives than any laboratory scientist in the past decade by relying on a wonderfully simple tool…”
I know what you’re are thinking, but no, Six Sigma is not the tool. Before I tell you what it is, consider that after implementing it in hospital ICUs in Michigan, hospital-acquired infections dropped from 2.7 per 1,000 patients to zero. That means more than 1,500 lives were saved in the first 18 months.
So what is this ingenious invention? What critical breakthrough occurred? What fancy bit of science and statistics produced these stupendous results? Which process improvement methodology was put to work? 
A checklist.
That’s right, Pronovost provided physicians with a list of steps as a reminding them how to complete routine procedures. 1500 lives were saved over 18 months in one state by writing down the steps for procedures, photocopying them, and handing them out. Pronovost estimates he could roll his system out across the entire US for three million dollars. Which, I think it’s worth noting, might be comparable to the annual budget for a corporate Six Sigma deployment in bigger companies.
One of the reasons I was so captivated by this story is that more and more, I find myself returning to the basics and fundamentals of process improvement methodology. I read the primary literature and wonder at the complexity of current process improvement methodology. I wonder where the power of elegance of simplicity has gone.
For example, one of my favorite books is Kaoru Ishikawa’s “Guide to Quality Control”. It’s long out of print, but you can still pick up used copies online and elsewhere. You might not know Ishikawa by name, but if you’ve ever done a fishbone diagram, you know his work. He introduced his now-eponymous diagram along with six other quality tools in the Guide. Each was elegant and simple. Things like check sheets, Pareto charts, scatter plots, basic control charts - simple tools explained concisely. It’s a slim volume, but everything is there. Every time I read it, I wonder to myself how on earth we’ve allowed the continuous improvement world to become so complex and unapproachable. I’m at a loss to explain what value Six Sigma and similar methodologies add to Ishikawa’s approach. Sure, they provide the sizzle that sells programs to organizations, but it’s quite possible that that’s all they do. Which is worrisome.
Ishikawa and Pronovost have proven that very clear and simple approaches can yield stunning results. Much as Deming and others did before them. Modern Six Sigma is anything but simple. Most Black Belts take four week to train. But I can get through Ishikawa on a flight from Chicago to Denver, and I’m guessing Pronovost can train his folks in about five minutes.
Have we taken a wrong turn?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;History&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 22 May 2008 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: David Wickersham, President and COO Seagate]]></title>
			<link>http://www.sixsigmacompanies.com/archive/david_wickersham_president_and_coo_seagate.html</link>
			<description><![CDATA[2008 ISSSP Leadership Conference, Day One
“Best practices need to continue to improve.”
David’s presentation covered the Seagate Business Excellence Journey over the past 10 years highlighting some of the things they’ve learned.
One of the best practices David is particularly proud of is the training curriculum.  They have gone from traditional classroom training over a four week period to a hybrid blended approach of classroom complemented with eLearning over a three week period. Even more unique is he specialty training.  All belts are all trained in a core set of Lean and Six Sigma principles and tools.  Then they either go on to operational fundamentals or transactional fundamentals.  After that they get to specialize further in their respective fields.  A brilliant innovation for training.  The college approach.  
The next best practice they developed is the career path for business excellence employees.  Business Excellence employees have the option to stay in the business excellence community after their service.  A unique alternative to traditional repatriation after a period of time as a belt.  
He closed with a few bullets on sustaining the initiative:

It’s a journey and deployment will change over time.
Get commitment from the top, educate the middle, engage the whole
Development of Business Excellence resources (hard and soft skill) is crucial
Sharing best practices through annual seminar and newsletters
Career path for employees in Business Excellence.]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Conferences&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 20 May 2008 16:01:25 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Project Failure: Eight Reasons by Minitab]]></title>
			<link>http://www.sixsigmacompanies.com/archive/project_failure_eight_reasons_by_minitab.html</link>
			<description><![CDATA[Yesterday, I attended a Minitab Webinar showcasing the top 8 reasons Six Sigma projects fail.  Presented by Lou Johnson &amp; Cate Twohill.  Lou took care of the project failure segment (which was the vast majority) and Cate talked a bit about Minitab’s Quality Companion.  
First off they did a fantastic job. Lou’s history and experience with Six Sigma and statistics coupled with his passion for getting to the bottom of project failure…resulted in this fine presentation.  
The data was based off a survey of nearly 150 of Minitab’s customers at nearly 100 different companies.  And yes there were more than eight reasons for failure cited by respondents.  There were actually 42 reasons, but the top eight represented 62 percent of the total.  
Lou laid out the eight reasons with detailed explanations and examples for each reason.  I won’t go in to any detail besides listing them as Lou is sure to give this presentation again and again…
The Top Eight Reasons Six Sigma Projects Fail...
# 8 - The project solution was not implemented# 7 - Project scope too big# 6 - Not enough training# 5 - Project too small for DMAIC rigor# 4 - Project forced into DMAIC# 3 - Project had no data or bad data# 2 - Project not linked to Finances
and the #1 reason Six Sigma projects fail...No management support
The biggest takeaway was, as Lou described it, “Rule #1: Pick the right project.”  Four of the top eight reasons can be attributed to project selection (now comes my favorite part of the presentation, the iSixSigma research quote):

“While only 32% of respondents in organizations with new (less than one year) Six Sigma programs frequently or always use a formal prioritization process, 63% percent of those in organizations with five to ten years experience with Six Sigma do.” iSixSigma Magazine, March/April 2005
Throughout the presentation Lou offered a simple solution to each of the failure modes, and in most cases the solution could be found utilizing one of the features of Minitab’s Quality Companion.  
Thank you Minitab for sharing these findings. Below are some additional articles from iSixSigma about project failure. As you read them you will find that they support Minitab’s findings as well as offer a few other failure modes to consider. 
Tips and Suggestions for Six Sigma Project Success by Simon Bodie
Why Projects Fail by Holly Hawkins
How to Face Failed 6 Sigma Projects iSixSigma Discussion Forum
Understanding Six Sigma Deployment Failures by Mike Carnell
Project Selection Research by Jonathan Atwood, iSixSigma Magazine, March/April 2005
 
 ]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Thu, 24 Apr 2008 10:29:14 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The basic tools – project selection]]></title>
			<link>http://blogs.isixsigma.com/archive/the_basic_tools__project_selection.html</link>
			<description><![CDATA[Hello again Blogosphere. My apologies for 1 year of blogging silence. More and more I apply Lean methods to Six Sigma efforts. Overanalysis is a trap in many projects, especially when newly trained belts unleash their newly acquired skills to their first projects. Keep it simple and practical ! It’s amazing what a good executed basic quality or problem solving tool can bring in process improvement results. 
This first blog will be an illustration of how application of basic tools help to structure improvement project selection. 
Recently I was called to assist a customer that had identified a couple of hundred issues in their organization. Off course these can’t be resolved all at the same time. By using some basic tools we managed to sort the wheat from the chaff : categorizing these issues by the KANO model, mapping the issues to the organization process architecture helped us to identify the most critical processes for improvement. Then SIPOC studies of the critical processes identified potential improvement projects by the gap analysis between process inputs and process CTQ’s and process outputs and customer CTQ’s. 
From a couple of hundred issues crying for attention the situation is now focused on a couple of critical improvement projects, just by good execution of some basic tools ... and the good part is, it only took me and the customer team a couple of days to get to this point.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 21 Apr 2008 13:18:37 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Total Innovation]]></title>
			<link>http://blogs.isixsigma.com/archive/total_innovation.html</link>
			<description><![CDATA[In our business we are passionate about achieving breakthrough innovations and I’d like to share a few examples of how we really push the envelope. Lets start with the fire alarm. It’s seldom used for real but reaches right across the whole campus with a very clear message:

“Emergency, please leave the building by the nearest exit.” 
We tapped into this paradigm to alert our numerous project managers to consistently achieve the weekly status report deadline with a very clear message to instruct people wherever they are:

“Emergency, all project managers submit their status report immediately.” 
Imagine the employee delight we achieved with this regular reminder, a simple but really effective change.
Or how about the “Six Sigma Results Tree” we erected in head-office? Our black belts come and randomly pick a low-hanging fruit (project opportunity) and return when complete with a green-paper leaf for each £100k saved. It goes to prove that money does grow on trees.
What about group dynamics in meetings? We reviewed the Six Thinking Hats methodology and didn’t really understand it. So what did we do? We innovated of course! We took the Six Thinking Hats’ one-dimensional concept (e.g. creativity, optimism &amp; judgement) to the next dimension and applied the Roger Hargreaves’ management methodology. We found the Hargreaves - Mr Men approach provided a much richer set of one-dimensional characters as shown: 

We started strongly with clear insights from Mr Clever and outstanding levels of quality from Mr Perfect. Things started to wobble when we found Mr Quiet hiding in the cupboard and Mr Lazy would never show up for meetings. But we had to call a halt when Mr Tickle took his role too passionately and Little Miss Sunshine made a formal HR complaint! But we did enjoy seeing them run around and around the meeting table, “Here comes Mr Tickle……Tickle Tickle Tickle”.
I could share other groundbreaking innovations but I need maintain confidentiality to retain our truly competitive edge!]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Innovation&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 01 Apr 2008 01:37:34 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: House, M.D.]]></title>
			<link>http://blogs.isixsigma.com/archive/house_md.html</link>
			<description><![CDATA[While flipping around the channels a while ago, I happened to catch an episode of "House."  This show, for those unfamiliar with it, features a physician in a hospital setting.  He's faced with patients who have complex and puzzling disease conditions that he must diagnosis in order to save their lives.  I was intrigued, at first.
But after watching a few episodes, I found the plot of each episode to be similar.  House is confronted with a patient who has puzzling symptoms.  He guesses one diagnosis, and makes his residents do all kinds of diagnostic tests.  Sometimes he treats on the basis of his presumptive diagnosis, and this can lead to complications.  Then, when the first guess doesn't prove correct, he makes another guess and has his residents do lots more diagnostic testing, sometimes invasive.  Again, presumptive treatment may result in adverse effects.  When the puzzle still isn't solved, he tries a third time and (you guessed it) after further diagnostic tests, he hits on the correct solution and now can give the patient the treatment they've needed all along.
This may make for compelling medical drama, but I hope my own physician has a better diagnostic track record than House seems to have.
Upon reflection, I realized that it reminded me about how we improved our business processes before we started to use Lean and Six Sigma.  Often, the leader would guess at what was wrong with a process, come up with a solution, write the memo, and then be surprised when the expected improvement didn't appear.  Sometimes, the process became even less effective.  Then, it was "back to the drawing board" and another solution from the mind of the leader would get published as a memo.  And so on.
I am very happy to have learned a more  effective method for facilitating change in the business (in my case, healthcare) environment.  With leadership commitment, engagement of the front-line workers and stakeholders, setting targets according to the customer's CTQs, analyzing the process in order to create solutions, and using statistical process control to sustain the gains, we can produce positive change that gets the organization closer to where it needs to be to remain competitive.
Will anybody ever pitch a drama to the networks that uses a Lean / Six Sigma Black Belt as its protagonist?  But then, it's not very dramatic to show someone following a proven methodology to create streamlined, effective processes, is it???]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 20 Mar 2008 12:57:46 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: ASQ CSSBB]]></title>
			<link>http://blogs.isixsigma.com/archive/asq_cssbb.html</link>
			<description><![CDATA[In January I looked through the ASQ body of knowledge (BoK) for Black Belt and said to myself, “I know most of this stuff now”. So put in my entry and passed the Mar’08 exam. I thought I would share the experience, as I believe a number of practitioners may have looked at the ASQ exam. Get a good foundationI reviewed the ASQ exam a couple of years ago and concluded I did not have the experience to guarantee a pass. So waited until I had delivered the projects, trained the Black Belts and invested my spare time in learning the tools. After all this I decided I had the right foundations in place. ASQ recommend three-years work experience and that seems about right.
Find what you don’t knowReading through the BoK and doing the sample exam I identified clear areas of weakness. Coming from a Transactional background, there were manufacturing areas I had never covered in particular around Measurement Systems and Design of Experiments.
Invest the time in preparationI went through every section of the BoK. Be ready for set-piece questions that require calculating from equations, things like confidence intervals and probability. If you are used to having Minitab do the work, practice doing the equations. I invested in the QCI Exam CD and although I found some of the questions infuriatingly ambiguous it does help.
On the dayThe exam is open book and covers 150 questions over 4 hours so it’s a bit of a slog. I found my collection of books &amp; materials were good enough and included Six Sigma, Lean, DFSS, Statistics and quick-reference books. I found I needed to refer to all of these during the exam.
Next StepsI found the brief review of the industry greats, Deming, Juran, Ohno &amp;Taguchi whet my appetite and am keen to learn more. Now I have covered the BoK I am ready to move on and am looking now at understanding the big-picture stuff like strategy planning, target operating model and other related areas
Good luck if you are planning to gain ASQ, let me know if any questions.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 14 Mar 2008 09:46:33 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Right First Time, Every Time!]]></title>
			<link>http://blogs.isixsigma.com/archive/right_first_time_every_time.html</link>
			<description><![CDATA[Imagine a world in which we routinely do things Right First Time, Every Time. There would be no more rework as first time yield is 100% and no need to coach &amp; mentor as green &amp; black belts hit the ground running. Unfortunately it tends to be the case that in order to be Right First Time you need to Get It Wrong Lots of Times First. It’s just a people-thing, they learn from their mistakes.
But that’s where Six Sigma comes into play. Why bother getting improvements wrong when you can accurately define the key output as a function of the key inputs (DMAIC) or design new processes clearly linked to customer needs (DFSS)?
Now I have done numerous projects that require detailed technical analysis and lots of problem solving tools to get the root-cause. Extensive re-engineering follows with major IT changes. So it was nice to have a project that presented as essentially poor end-to-end process management. I have been looking forward to doing Kaizen for some time and must say it works. 
The change in style is important in order to get the people involved and engaged in owning and delivering improvements to their own processes. It’s all about looking to embed the idea that they own the continual improvement of their process rather than having a project come and “Do It” to them. It’s all about getting them into the habit of wanting to improve rather than trying to get it Right First Time. 
I guess it defines the difference between process improvement – highly targeted projects and continual improvement – people repeatedly improving their process?
 
 ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 13 Mar 2008 08:00:36 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: SigmaLeanZenOut]]></title>
			<link>http://blogs.isixsigma.com/archive/sigmaleanzenout.html</link>
			<description><![CDATA[
What the heck is SigmaLeanZenOut?   It is what a lot of people are doing in the world of continuous improvement.  No matter where you got started, most companies gradually evolve to SigmaLeanZenOut.  Six Sigma deployments add Lean, Kaizen, and then Workout (not necessarily in that order).   Lean Deployments add Kaizen, Workout then Six Sigma.  You get the picture.  So why is this happening?  It is because people are discovering that the combination of all these methodologies opens the door to applying continuous improvement methods to almost any situation.    Your starting point (which methodology) will depend on your initial bias but most likely, you will eventually end up incorporating or integrating many methodologies. 
So what are companies calling their ’thing’.  Most likely, it is whatever they started with.  Most companies don’t seem to go through the effort of renaming their continuous improvement approach as they add methodologies for fear that it might make the organization feel like whatever they started with was the "flavor of the day" and the organization must now move on to the next thing.  Nothing would be more fun for a naysayer than to jump up and shout "See, Six Sigma didn’t work so we now have to do Lean Six Sigma or Six Sigma Plus".   Some companies initially "brand" their approach by calling it "Customer First" or "Process Excellence" and incorporate Six Sigma, Lean, Kaizen and Workout as they deploy.
If you are just starting a deployment (whether it is Lean, Six Sigma, Workout, Kaizen, whatever), think about calling it something that is robust enough to handle the integration of other methodologies.  If you feel like you need to use the right ’name’ to get the industry credibility then incorporate an adder like ’plus’ to the name.   I sort of like naming your continuous improvement approach something that has the word ’excellence’ in it.  Who can argue with wanting to be excellent?
No matter what you name it or how you get started, the important part is that your foundation include the proper integration of your approach(es) with your company strategy, goals, and leadership development and that you keep adding to your continuous improvement toolkit.   Eventually you too will be doing SigmaLeanZenOut.  (and it is almost as much fun to say as "Farfegnugen"!)
How has your company integrated the methodologies and what do you call it?  Please feel free to post &amp; share.  ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 12 Mar 2008 04:36:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: To Transform, or Not to Transform – That is The Question]]></title>
			<link>http://blogs.isixsigma.com/archive/to_transform_or_not_to_transform__that_is_the_question.html</link>
			<description><![CDATA[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.
 ]]></description>
			
			<author><![CDATA[James Considine]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 25 Feb 2008 08:34:27 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma . . . Still Growing After All These Years]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma____still_growing_after_all_these_years.html</link>
			<description><![CDATA[I recently spoke at a Lean Six Sigma Conference for Services hosted by the American Strategic Management Institute (ASMI).  One of the morning speakers started her presentation by taking a quick survey.  She went around the room and asked everyone three questions . . . What industry are you from?   How long has your company been involved in Lean Six Sigma?  What is your personal level of Lean Six Sigma knowledge?  She charted each person’s answer as they spoke.  Although it took a few moments to work through the crowd of about fifty plus people, it was a marvelous way to demonstrate the value and power of Voice of the Customer and here’s why.  

The activity engaged everyone in the audience.  They were now "part" of something - not just a "spectator".
The information helped each delegate with their own networking activities.  Immediately following the session you could see people from like industries converging and trading business cards.  You could also see some of the ’newbies’ seek out the more experienced delegates.
And as a subsequent speaker I could now customize my approach to more closely fit the customer’s profile - speaking in terms that helped me better connect with the audience/customer.  
I was also pleasantly surprised by the number of companies that were just starting their Lean Six Sigma journey.  For me, this was just another affirmation of its staying power.  After all these years, Lean Six Sigma continues to be the method of choice for driving excellence throughout the business world,  No matter what type of business - from health-care to soft-ware to house-ware - Lean Six Sigma is making a difference every-where.  ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sat, 23 Feb 2008 04:51:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Is a Wait Always a Waste???]]></title>
			<link>http://blogs.isixsigma.com/archive/is_a_wait_always_a_waste.html</link>
			<description><![CDATA[In healthcare, we are definitely trying to speed things up for our patients.  Billboards around our area (and maybe, around the country) promise 30 minute door-to-doc time in their Emergency Departments (EDs).  One promises no waiting to be seen by a healthcare professional!  Mini-offices are springing up in chain pharmacies, promising no waiting for minor problems.  One health system promises a "money-back" guarantee if you have an "excessive wait time."
But there are still some things in healthcare that you have to wait for, with good reason.  When you receive a medication, sometimes you have to wait for it to take effect.  If you receive a breathing treatment, it may take awhile to breathe a little easier.  When you have surgery, you usually have to wait for some healing to occur before you are sent home - even if everything else is ready for the patient to be discharged and all other medical tasks have been completed.
In these cases, the waiting periods can't be made faster - they're processes, but not processes over which we have control.  When mapping these timeframes in a lean value stream map, are they automatically wastes?  Or something else?
In the automotive industry, it takes a certain amount of time for paint to dry, but you can work on faster-drying paint.  When you are working on a process that has a wait time required for a patient to heal up, should you just skip over that part and work on a different part of the value stream?I'd like to know your thoughts on that matter, and thanks in advance for helping to clarify my thinking!]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 19 Feb 2008 14:31:47 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: &quot;Someone Didn't Care Enough To Be Right&quot;]]></title>
			<link>http://blogs.isixsigma.com/archive/someone_didnt_care_enough_to_be_right.html</link>
			<description><![CDATA[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.]]></description>
			
			<author><![CDATA[James Considine]]></author>
			
			<category>
			<![CDATA[Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 13 Feb 2008 07:17:13 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Variance… Is it always a bad thing?]]></title>
			<link>http://blogs.isixsigma.com/archive/variance_is_it_always_a_bad_thing.html</link>
			<description><![CDATA[In Six Sigma we’re taught reducing variance is a good thing but is this really always the case?
Take currency for example. In the US all paper currency is the same size and the same color. By reducing variance I’m sure the US Mint has saved costs by having a standardized ink color, standardized cutting machines, etc. However, how does this benefit me as a user? When looking at a $5 and $10 bill twenty feet away, most people can not tell the difference. How many times have you had to thumb through your wallet to find the correct bill or worried you gave someone an incorrect note (or been accused of giving back incorrect change if you’ve been on the receiving end)?
Now compare the US currency with Australian currency. Each denomination of paper money is a slightly different size and color (note: while there are extra upfront costs to the process, they are greatly offset by reduced printing demand as the result of an applied plastic coating.).Essentially the country has error proofed (i.e. Lean manufacturing) its currency to the end user.
The point I’m trying to make is that sometimes in Six Sigma we focus so hard on reducing variance to cut costs that we overlook characteristics deemed critical to quality by the end user. Even though costs have been reduced, underlying problems still exist, leaving the customer to view the product service of sub par quality.  By introducing variance as a possible solution, one may be able greatly improve customer satisfaction.]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 06 Feb 2008 20:21:16 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Continuously Improving Continuous Improvement]]></title>
			<link>http://blogs.isixsigma.com/archive/continuously_improving_continuous_improvement.html</link>
			<description><![CDATA[I just spent three days at IQPC’s 2008 Lean Six Sigma and Process Improvement Summit where more than 600 process improvement professionals came together to learn, share and network.  In addition to getting a "booster shot" from Jack Welch, it was great hearing other professionals share their thoughts and experiences about how they have applied Six Sigma to facilitate continuous improvement, drive transformation and spark innovation.   I met more than 200 new people, acquired dozens of new ideas and even set up a potential benchmarking trip.  (By the way, the IQPC staff from London did a phenomenal job in providing an awesome speaker line-up as well as making sure things ran smoothly and on time.  Smashing job!)
As I listened to speaker after speaker, I would write down key points and new ideas in my journal.  It’s great being back where I can now put some of my key learnings into play.  My favorite part is taking the best of the best ideas, mixing them together and creating something new . . . but then that’s what continuous improvement is all about isn’t it?]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 03 Feb 2008 05:51:35 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: To MSA or Not to MSA]]></title>
			<link>http://blogs.isixsigma.com/archive/to_msa_or_not_to_msa.html</link>
			<description><![CDATA[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&amp;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&amp;V, and H&amp;P. MSA,
is fairly self-explanatory. A&amp;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&amp;P is the least desirable: Hope and Pray, and is our default
position if the MSA and A&amp;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&amp;V sufficient? Like most things, it
depends. In an effort to keep DMAIC project work lean, I tend to start with
A&amp;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&amp;V and
H&amp;P concepts.]]></description>
			
			<author><![CDATA[James Considine]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 28 Jan 2008 11:02:34 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Decision Point – Transactional Defect Bonanza]]></title>
			<link>http://blogs.isixsigma.com/archive/the_decision_point__transactional_defect_bonanza.html</link>
			<description><![CDATA[Having now delivered many transactional projects I have noticed common themes repeatedly occurring. These include:

IT Systems that have been poorly designed or operated
Inadequately thought through policies &amp; procedures
Opaque, non-existent or duplicate processes
Lack of viable information on process performance
But there is one area I would like to focus, decision points. People play a big part in the execution &amp; success of many transactional processes. Every day, many times over, they need to rapidly assimilate a situation and make the right decision on what action to take for success.
Consider a manufacturing process; say a bottling factory continually producing 20-40% defective products. I suspect that would seem unbelievable. They may well go out of business. But in a transactional environment that kind of defect rate is not unusual and can sometime go much higher.
Take a look at a generic example, the IT Helpdesk; this front-line support team receives numerous requests each day. They review the details and forward the request to the relevant technical support team.

The core value-adding element here is to understand the issue and deliver it to the correct team. What sort of influences impact on correctly making that decision?

Staff Training, Skills &amp; Experience
Policies &amp; Procedures
Information Available
Incentives
Now imagine the IT Help Desk’s primary metric is based on the time taken to pass a request on. The business is looking for efficiency, do it quick…..no quicker…..no quicker than that!
So here we are at the most vital part of the process, the key point where the person is evaluating and making the decision, they are adding the value and what happens, they rapidly scan it and forward on to the most likely candidate, job done, service level hit, a new defect has been created. Into the rework loop we go, technical team A calls technical team B to see if they should have got the request, they then call technical team C to see if they will take it. Technical Team A passes the request onto Technical Team C (the hidden factory).
But it’s a balancing act between being effective and being efficient? Can’t have unlimited time the business can’t afford the cost.
Being effective means securing the right outcome, getting the request to the right team. Being efficient means securing the right outcome, with the minimum of waste, expense, or unnecessary effort. A process that is not firstly effective can never be efficient no matter how cheap it is to run (look at Rolled Throughput Yield).
And this is why Lean &amp; Six Sigma combines so well in a transactional environment. The Six Sigma part focuses on the root-causes for ineffectiveness it provides a wealth of tools to understand and address the vital few. The Lean part strips the waste out of inefficient processes. Does that mean you go DMAIC and include Lean or Value Stream Management and include statistics? I think its about removing the defects then speeding the process by removing the waste, but its different for every project.
 ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Thu, 17 Jan 2008 06:42:42 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: A quality bubble?]]></title>
			<link>http://blogs.isixsigma.com/archive/a_quality_bubble.html</link>
			<description><![CDATA[Gianna Clark notes that several hundred companies began their Six Sigma journeys about seven years ago. 
Is Six Sigma the quality equivalent of a stock market bubble? Are we cheerleaders of an irrational exuberance where performance economics do not match the hype we create? Is Six Sigma on the verge of becoming the next TQM - run over by advances in technology and easier approaches to improving performance? ]]></description>
			
			<author><![CDATA[Charles McKinney]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;Change Management&nbsp;,&nbsp;Conferences&nbsp;,&nbsp;Customer Satisfaction&nbsp;,&nbsp;General&nbsp;,&nbsp;Government&nbsp;,&nbsp;Guest Blog&nbsp;,&nbsp;History&nbsp;,&nbsp;Innovation&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Podcasts&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Sat, 12 Jan 2008 12:32:57 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Downgrading the applicability of Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/downgrading_the_applicability_of_six_sigma.html</link>
			<description><![CDATA[In a recent blog at Harvard Business School Press Online, Tom Davenport challenges the applicability of Six Sigma. You can read his post at http://discussionleader.hbsp.com/davenport/. 
Coming from anyone else, a statement that Six Sigma "should only be used in product manufacturing, where the idea of reducing defects to one in six standard deviations really makes sense" might be dismissed out of hand. But Davenport has credibility as an expert on business process management and information technology.
Perhaps he’s right, and Six Sigma should be viewed as one among several toolkits to embed statistical methods and scientific thinking in managerial practices.]]></description>
			
			<author><![CDATA[Charles McKinney]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Sat, 12 Jan 2008 12:21:54 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Seven Year Itch]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_seven_year_itch.html</link>
			<description><![CDATA[Hundreds of companies embarked on their Six Sigma journey in 2000 and 2001.  Today, Six Sigma deployments haven’t slowed a bit but instead have expanded and grown and are a driving force in achieving excellence in almost any type of business.  And, because of industry experience and forums for sharing, are being implemented with the benefit of lessons learned from the early pioneers. 
But what of those companies that have been at it for seven or more years? Are they experiencing the "Seven Year Itch" or are things just as exciting as ever?  I think it’s the latter.   Why?  Because the one thing that has differentiated Six Sigma from other approaches is its ability to grow and shape itself to meet constantly changing business needs.  
Keeping the excitement and engagement going for seven, eight, nine years, or however long it takes to truly shape a culture of excellence is not an easy task.  It requires a solid and dynamic Six Sigma plan that 1) addresses your deployment strategy at least three years out, 2) reflects and complements your organization’s business goals and objectives 3) introduces a new tool, skill, or method every year that allows employees to continue to grow their skills and participate in new ways and 4) is flexible enough to react to changing customer needs.   
The absence of these four components can create the perfect breeding ground for a bad case of the Six Sigma Seven Year Itch.  Don’t ignore the symptoms.   Act now and you may escape without a scratch!]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 11 Jan 2008 02:38:32 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: How to approach Improve]]></title>
			<link>http://blogs.isixsigma.com/archive/how_to_approach_improve.html</link>
			<description><![CDATA[The very first Six Sigma book I read was “The Six Sigma Way”. The first page describes the story of a CEO jumping to solutions and being educated by a Black Belt on the methodology. He is turned around and states, “We’re not in the ‘Just Do It’ mode anymore”. My take-away being, we take a disciplined and structured approach we improve the right things in the right way.
The lack of an official “Six Sigma” can mean different versions being taught. Overall I think there is broad agreement on the approaches and tools we use in Define, Measure &amp; Analyse. Of course, the setting drives the specific tools we use (see What Flavour Are You). But if you are looking for variation take a look at Improve. 
Over the years I have been using the ASQ Black Belt body of knowledge as the basis for my continual learning, working through subjects in my own time to ensure I really understand them. I have got to Improve and there is a problem. Now the approach I was taught and deliver to our Green &amp; Black Belts is to:

Use creative thinking to develop a long-list of potential solutions
Use convergent thinking to develop the optimal solution
Establish and mitigate risks
Run pilots and DoE to establish and prove solution achieves goal
Develop implementation plan ready for toll gate
Reading through my now wide collection of books this is quite an orthodox approach with two exceptions. Firstly, the ASQ BoK I use describes Improve as below.

Design of experiments
Response surface methodology
Evolutionary operations
I checked and the newest version now introduces Implementation Planning, Risk Analysis and the Lean concepts of Waste, TOC &amp; Kaizen. Secondly my copy of  “Implementing Six Sigma” covers:

Design of experiments
Response surface methodology
Evolutionary operations
My guess is that the people who developed the ASQ BoK and “Implementing Six Sigma” must have collaborated and describe an Improve phase that is different to a number of other authors. There is no mention of the creative processes:- divergent thinking, six thinking hats, brain writing, or lateral thinking. 
As a practitioner what it means to me is I learn both and decide which to apply and when.  I am also updating my copy of the ASQ BoK to the latest version.
 ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Innovation&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Fri, 04 Jan 2008 03:50:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Speeding Cameras: A Zero Sum Gain in the World of Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/speeding_cameras_a_zero_sum_gain_in_the_world_of_six_sigma.html</link>
			<description><![CDATA[I’m driving home from work yesterday and I noticed something different at the intersection by my house. A traffic camera has been installed just in time to give some people a not so merry Christmas present.
Traffic cameras, such as the one I saw, have been introduced as a visual control with the intent to improve safety. Reducing the amount of defects (in this case, an accident) sounds like a worthy Six Sigma project. In fact, studies have shown when placed at intersections, cameras can reduce the chance of drivers’ running a red light. Unfortunately, those same studies also concluded cameras contribute to a higher number of rear ending accidents.
Good intentions are not enough when defining a Six Sigma project. A key question when scoping a project should be “What are the primary and secondary metrics?” Most of us are familiar with a primary metric, a general measurement of how we will deem the project successful.  This could be cycle time, throughput rate, added revenue, etc. However, for most projects, secondary metrics are just as important. The secondary metric serves as a “check and balance” to ensure your project has not created problems somewhere else in the process. For example, a project may reduce claim processing time in a certain department but creates additional work in the preceding department, resulting in an increase in the overall processing time (and thus defeating the point of the project). A key manufacturing example is ensuring production throughput increases (primary metric) without increasing the overall scrap rate (secondary metric).
The next time you are defining a Six Sigma project, remember traffic cameras. After all, you don’t want to complete a project to have a zero sum gain in the end.]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 19 Dec 2007 21:38:55 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Give me the power]]></title>
			<link>http://blogs.isixsigma.com/archive/give_me_the_power.html</link>
			<description><![CDATA[While reading about type I &amp; II errors and specifically beta-risk I realised that although I was happy with alpha-risk I didn’t recall seeing beta-risk in any of our sampling or hypothesis equations. Being curious, I wondered why I was only accounting for type I errors in my work?
Just to review, we need to be aware of and manage our risks when running a hypothesis test. We term the potential errors as Type I &amp; II and they can be quite insidious:

Type I – False Positive – You call a difference when there isn’t oneOn March 23rd 1998, Professors Fleischmann &amp; Pons announced they had achieved sustained thermonuclear reactions in a test tube. They believed they had created Cold Fusion. Unfortunately it was not to be.
Type II – False Negative – You do not call a difference when there is oneThe effects here can be devastating, such as releasing harmful new drugs or missing production defects in car-tyres. Imagine a control chart showing no issues while bad product is being pumped-out?

Our (abbreviated) process for hypotheses testing being:a. Define Hob. Set the alpha-risk (normally 95%)c. Calculate p-value for the hypothesisd. Accept or reject Ho
No mention of beta-risk here. I reviewed assorted materials to get up to speed and discovered all about beta-risk. Here is the concept (not the math), big disclaimer, I might be wrong or have missed something.
Imagine you draw a sample from a process and get an estimate for the mean and confidence interval. You decide the process needs a touch of improvement. You draw a sample from the new process and get the mean and confidence interval. Where the beta-risk comes into play is the when looking at the potential degree of overlap of the second sample with the first. 
In the first picture (below) the red &amp; green lines show the respective samples 95% confidence intervals. The two sample distributions are miles apart. Not much beta-risk here.

In the second picture (below) the two distributions overlap. So for any given sample from B there is a probability it will be in the zone to the left of the red-line, the 95% confidence interval of sample A, hence accepting Ho when the two means are different.

The shapes of the sampling distributions are governed by the sample size, alpha and standard deviation and have not given you the resolution to see the change in mean. The distributions are too wide. So the beta-risk is the probability of drawing a sample from B in the region left of the red-line, within the 95% interval of sample A.
You can find the beta-risk for any given hypothesis test in Minitab under Stats--&amp;gt;Power &amp; Sample Size. If you find you have a low score, The Power of the Test, you may wish to change your key parameters, sample size, and alpha, to improve the sampling resolution.
My conclusion on why beta-risk does not appear more prominent in our manuals is because we look for “big improvements”. If our process improvement has shifted the mean by a small-margin (so that beta-risk applies) then its not much of an improvement. Bit of a generalisation and am sure there must be exceptions.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Fri, 14 Dec 2007 09:24:01 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Innovation on Tap]]></title>
			<link>http://blogs.isixsigma.com/archive/innovation_on_tap.html</link>
			<description><![CDATA[
Innovative solutions are frequently the answer to new or age old problems.  But what kind of tools can help you and your team get out-of-the -box?   Seems like way back when, we didn’t spend enough time in training talking about innovation in the "Improve" stage.   Armed with the 5 S’s, a DOE and some poka-yoke, we’d trudge on to find the much wanted answer without ever really stopping to think about driving innovation into our thought process.   This probably occurred because once we found an answer that seemed to work, we sometimes stopped looking for other options.   
A great tool that can keep us on our toes is the morphological box.   The morph box helps you divide a solution into various parts and then mix and match the alternatives to sometimes create a whole new solution - one that you may not have initially thought of if you had stopped looking after identifying the first one.  The 2007 July/August Issue of iSixSigma Magazine had a nice description of the morph box in the "Tool Spotlight" section.  Putting the tool in practice while focusing on innovative solutions can help drive your team to find not just an answer but a better and sometimes more innovative answer. 
The whole process of using the morph box reminds me of my kids at the restaurant soda dispenser.  A little bit of this and a little bit of that and it’s like they have invented a new drink.  So next time you need to quench your thirst for a new and different answer, try using the morph box.  It might be the most refreshing thing you’ve tried in years!]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Innovation&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 11 Dec 2007 03:07:35 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma . . . The Winning Hand]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma____the_winning_hand.html</link>
			<description><![CDATA[What started out 20 years ago as a way to reduce variation is now the hottest game in town - Six Sigma.  Although it has been reshaped through the years to meet constantly changing business needs, the definition is still the same:   "Near perfect performance"  . . . and customers still demand it.
When first introduced, Six Sigma was pegged as a "one-card" game - DMAIC.  Over the years, it became clear that those willing to draw some new cards were stacking the deck in their favor when it came to achieving near perfect performance. And so the game evolved as DFSS, Workout, Lean, Kaizen and a host of other methods were shuffled into play.  Even some Change Management and Innovation "wild" cards were introduced and a full deck of cards is now available.  Winning is just a matter of knowing which card to play for the situation at hand.
So what do you call the new game?  I call it Six Sigma.  Why?  Because it is still about achieving near perfect performance (99.9997% good).  When I was first introduced to Six Sigma, it was all about eliminating defects and a defect was defined as anything that kept you from achieving near perfect performance (i.e. variation, waste, lengthy cycle times, errors, no process, etc.).  So even though some new cards have been added, it’s still all Six Sigma to me.   
I’m thinking that people with strong roots in Lean or Kaizen may have a different view.  We could spend years debating what to call it but one thing’s for sure.  Today’s marketplace demands that you play with a full deck if you want to stay in the game.  If not, you will surely get "trumped" by a competitor.  ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sun, 02 Dec 2007 05:40:59 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Elevating strategic relevance: Understand and inform strategy implementation]]></title>
			<link>http://blogs.isixsigma.com/archive/elevating_strategic_relevance_understand_and_inform_strategy_implementation.html</link>
			<description><![CDATA[My last blog discussed elevating the strategic relevance of Lean, Six Sigma and process excellence.  My view is that mature Process Excellence Organizations enjoy or achieve credibility and success by executing a flexible performance-improvement process—attacking the top priorities, employing the best tools, selecting the right projects and leveraging organizational momentum.  The first thing mature Process Excellence Organizations do well is informing strategy setting and implementation (beginning with their own understanding of their enterprise’s strategy).
The most successful process improvement professionals are proactive rather than reactive about understanding and discussing strategy.  Executive level process excellence leaders share in common an understanding of the competitive position of their companies, options to shape competitiveness, and critical factors for success.  Further, these individuals understand the mechanics of a strategic management process and dynamics of organizational behavior that affect managerial commitment to change, execution against a plan, and responsiveness to opportunities and threats.
Positioning of the Process Excellence Organization determines its access to inform strategy setting and implementation.  Commitment from the COO to deploy best practices, for example, is more likely to result in Lean and Six Sigma becoming strategic levers, embedded in an organization’s culture and practice, than localized, bottom-up advocacy by a business unit executive, shared services leader or plant manager.  Yet unless market pressure, a crisis or some other impetus motivates a senior executive team to broadly rely on Lean and Six Sigma, Process Excellence Organizations must demonstrate credibility through their recommendations to improve performance and their track record of delivering returns to their companies.
Lean and Six Sigma professionals may ask how they are to shape strategy setting and implementation, if they lack access to regularly advise and influence senior leaders at their companies—the CEO, COO, CFO and especially the senior vice presidents in charge of business units, operations and technology.  Starting from their current base of deployment, Process Excellence Organizations should position themselves to identify and focus on strategically aligned opportunities for Lean and Six Sigma.
My assertion may not be fruitful in bureaucratic organizations—such as government institutions where the pace of change is slow, and status quo prevails.  At other companies the Process Excellence Organization can influence strategy. There is the annual planning cycle, where Lean and Six Sigma can inform the definition of change initiatives and funding of these projects, as well as progressive reduction of sales, general and administrative expenses.  Second, Process Excellence Organizations can bring a unique perspective to dialogue about longer-term strategies and programs.
Process Excellence Organizations can influence strategy because the strategic decision-making is ambiguous, dynamic and often chaotic.  Academics frame strategic planning as a formal process of answering three questions: (1) What does the business do?  (2) Form whom does it do these things?  (3) How does the business excel?  And the process has stages: evaluating the current situation, defining goals, mapping a route to achieve these goals, and monitoring implementation.  In a formal sense, the stages of strategic planning are not unlike the Deming lifecycle of planning, doing, studying and acting.  In practice, though, strategic planning is a communicative process, and strategies emerge from the habits and behaviors of organizations and their managers.  Executive dialogue, shareholder concerns, customer interactions, supplier dynamics, labor relations, information technologies, managerial fads all interact to form the content of strategy and direction of execution.
As an aside, I encourage anyone interested in sociological and behavioral approaches to strategy to look into research focusing on strategy as practice.  Over the last three decades, strategy research has tended to focus increasingly on organizational strategies as opposed to the activities of people in organizations as they define, elaborate, and implement strategies.  In contrast, strategy as practice is concerned with issues of practice within organizational contexts.  Lancaster University’s Management School is a good source of information about strategy as practice.
Start with the basics
Much is written about Lean and Six Sigma as tools for cost reduction.  More recently, the exploits of Starwood, Procter and Gamble, Capital One, and others highlight their relevance to innovation.  In terms of basic strategies, companies have three options, according to Michael Porter and others: low-cost production, differentiation, or some combination of the two.
Low cost production is a familiar paradigm among Lean and Six Sigma professionals in manufacturing, consumer products, healthcare, retail and service, and financial services industries.  Every industry has its favorite measures of efficiency: funding costs as a percentage of portfolio size for a mutual fund, percent of seats sold per airline flight, gross margin for product categories, etc.  Lean and Six Sigma professionals are familiar with the notion that reducing defects or eliminating cycle time can improve operating metrics, and these metrics contribute to the enablers of low cost production (e.g., economies of scale).
Differentiation is less familiar, especially for those of us who have focused on reducing variance of a distribution instead of shifting a mean.  Innovation is one way to differentiate.  Apple Computer is the most interesting, popular case study of innovation in the business literature today.  Another example is Proctor and Gamble’s shared services business unit.  After four years of successful cost cutting, Proctor and Gamble is now focused on managing its shared services as a business—figuring that exploiting core competencies in brand management and aligning delivery with marketing strategies can create sources of differentiation.  Whereas efficient production and processes are appropriable, strategies of differentiation are hard to craft and implement.
Corporate strategies are never as simple as low cost production or differentiation.  Rather, they emerge from the structures, habits and power in industries and at companies.  A few companies do well at managing strategy.  Most other are stuck in the middle—including companies with a significant investment in Lean and Six Sigma training and deployment.
A process excellence paradox highlights why understanding strategy is important—starting with the basics to develop a perspective on an enterprise’s current competitive position and future outlook.  The paradox goes something like this: Lean and Six Sigma have potential to raise any company to industry leader status, but too often returns on investing in process excellence are measured in six and seven figures instead of payback multiples greater than 20:1.  Pulling process excellence out of a rut and companies ahead in their industry has to be an exercise in strategic execution.
Institute disciplines to understand strategy
Efforts to understand strategy need to be disciplined, more than informal or one-off conversations.  Depending on the potential of the process excellence organization, many tools are available to understand strategies and their implementation at companies.  If formalizing disciplines to understand strategy is new, my advice is to start with a brown-bag discussion of your company within the process excellence organization or among its professionals and key business partners.  Things to cover include the economics of your firm’s industry, the external environment in which your company operates, and the internal capabilities of your firm.
The discussion should focus on understanding current state and future direction of the company at three levels of strategy: enterprise, business units and functions.  Leverage of Lean and Six Sigma tools is most often part of functional strategies, such as a multiyear plan to transform the operations and technology of a company or expand plant infrastructure in an overseas location.  Finding opportunities to have strategic impact depends on plans for the company and its business units.
These discussions do not need to produce a specific deliverable, but should factor into deployment planning and performance measurement for process excellence.  A number of frameworks can assist strategy discussions and create segues to efforts to evangelize, measure and govern process excellence.  One of my favorites is McKinsey’s “Star” or “7S” framework because it offers a holistic context in which to examine strategy implementation.
Accumulate knowledge from staff and line functions
By signaling its interest in understanding strategy, process excellence organizations may accumulate sufficient knowledge of strategy from their own professionals, colleagues in business areas and executive sponsors.  In my experience, Lean and Six Sigma advocates are willing to share knowledge and generous with information.  Though it never hurts to cast a wide net for knowledge and reach out to unlikely sources.
 Here are a few places to look:

Strategic planning: Many large companies have a strategic planning function, and a Chief Strategy Officer is becoming fashionable.  Often staffed by ex-management consultants, strategic planning departments provide analysis and advice to senior management about competitive positioning of the company.  While these departments may guard their work, they can facilitate building mind share with senior executives.
Corporate development: If your company relies on mergers and acquisitions to grow and compete, the team in charge of corporate development may provide a forward-looking perspective on the company, and assist tactical positioning of the process excellence organization.  Post-acquisition integration is a driver of strategic risk, and this is an area where Lean and Six Sigma can add value.
Corporate planning, budgeting and finance: These functions manage the multiyear and annual process of budgeting for programs, initiatives and operations.  Corporate planning functions can provide information about the efficiency of the company and performance of internal firm capabilities (e.g., operating metrics and ratios).  Information from the corporate planning department can be instrumental and is often necessary to sell a deployment strategy and benefits tracking process to senior management.
Financial engineering and modeling: Not all companies employ financial engineers or utilize financial modeling outside the strategic planning department.  At banks, insurance companies and firms with complex balance sheets, financial engineering disciplines can provide knowledge about the esoteric aspects of corporate finance that impact financial health and shareholder value.  Expertise in corporate finance is a weakness for most process excellence organizations that plan to market Lean and Six Sigma to finance departments.
Market research: Market research departments review secondary data, conduct original studies, and use qualitative methods to understand market and customer requirements.  Their work is a sophisticated voice of customer process, so market research managers can provide unique information about how markets and customers perceive a company.  Obtaining input from the market research department can assist with framing your understanding of market-facing strategies and opportunities to improve customer-facing processes.
Information technology: In companies that rely on information (most organizations today), the information technology architecture, program management office and database administration functions can provide useful information about problems with technology that limit internal firm capabilities.  In my experience with Six Sigma, data quality is an overlooked area that holds real potential for having strategic impact on cost and customer satisfaction.
Internal audit: Internal audit departments have a deep understanding of internal capabilities gained from rotational audits of all parts of a company.  Reaching out to an internal audit director requires sensitivity to matters of professional independence.  An internal auditor’s perspective on planning and control systems can provide useful information about governance, risk and compliance constraints that will impact opportunity identification and project selection.
Human resources: Many human resources departments cover organizational development and performance management.  Human resources managers who specialize in these areas can provide useful information about how raising employee satisfaction, reducing turnover and generally improving human capital will boost company performance.
These are a few areas where conversations about strategy may yield unexpected insight.  When reaching out, it’s important to frame discussions with these areas.  Asking focused questions, gathering perspectives, and testing impressions of a company’s strategy are the right level for these discussions.  If opportunities for Lean and Six Sigma come up, capture them in a pipeline of future projects and carry forward the discussion to deployment when the time is right.
Inform strategy through ideas for process excellence
The most successful process excellence organizations guide themselves with a deployment plan and through a governance process.  Some companies charter a management committee to decide where to apply Lean and Six Sigma and monitor realization of benefits.  In addition to promoting rigorous project selection, formal governance offers a forum in which to discuss strategies and influence big decisions.  Process excellence organizations with a bottom-up or less formal structure may want to pitch senior executives on possibilities for the company – pilot projects that may lead to strategic initiatives or higher impact participation of Lean and Six Sigma in ongoing initiatives.
To prepare for these discussions, the process excellence organization needs to synthesize its understanding of the company’s strategy.  One approach is to prepare an aide memoir that documents the following:

Industry and company facts
Key financial and operating metrics
Industry facts and analysis
Assessment of internal firm capabilities
Overviews of key company strategies and initiatives
Opportunities for process excellence
Key success factors for deployment
An aide memoir can take on many forms, and it should guide marketing and governance of Lean and Six Sigma deployment within a company.  To prepare an aide memoir, opportunities for process excellence need to be defined and mapped to company strategies and initiatives.  In this respect, one purpose of an aide memoir is to serve as the foundation of a marketing plan.
Ideation of opportunities is perhaps the most critical and actionable part of understanding and informing strategy.  In my experience, the most successful process excellence organizations use tacit or explicit methods to define opportunities to further implementation of strategy through Lean, Six Sigma and other best practices.  One approach is to set aside time for brainstorming at key points after conversations about strategy with business partners in a company.  The purpose of these sessions is to creatively tackle problems facing the company where Lean and Six Sigma can add value.  Another is to use nominal group techniques to structure similar discussions and to conduct a concurrent review of project opportunities in the pipeline.
Informing strategy depends on ideas from the process excellence organization.  In fact, informing strategy is continuous, subconscious and played out through the marketing, selling, execution and measurement of Lean and Six Sigma projects.  Bringing opportunities to the project selection process that are informed by an understanding of corporate strategy will help the process excellence organization create mindshare with senior management and build credibility through its focus on solving the most relevant problems through Lean and Six Sigma.
The deployment plan is a cornerstone of execution by the process excellence organization.  My next blog will cover deployment, starting with the early activities of marketing and selling process excellence.]]></description>
			
			<author><![CDATA[Charles McKinney]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;Customer Satisfaction&nbsp;,&nbsp;General&nbsp;,&nbsp;Government&nbsp;,&nbsp;Innovation&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 25 Nov 2007 18:18:21 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Process Improvement Training Video]]></title>
			<link>http://www.sixsigmacompanies.com/archive/process_improvement_training_video.html</link>
			<description><![CDATA[This training video was made for CISCO by the Creative Learning Studio. It’s an entertaining explanation of process improvement as told by a fictitious news station in need of better proceses.  DMAIC gets a plug as a way to achieve improved processes.  Enjoy. 


]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 05 Nov 2007 16:22:42 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Why Projects Fail]]></title>
			<link>http://blogs.isixsigma.com/archive/why_projects_fail.html</link>
			<description><![CDATA[My last article discussed the importance of verifying the sustainability of project work.  Although there are many positives to living in a Six Sigma world, it does have a dark side- failed project audits.
My experience, dependent on my employer at the time, has been that anywhere from 10-50% of projects are not embedded into an organization’s culture at the time of a 12 month audit.
So why do projects fail? I’m sure there are countless articles and statistical analysis performed on this issue, however here are my thoughts…

Change in Key Stakeholder Role. A new Project Champion, Process Owner, etc. moves into the role. Unless solid communication has been made, the value of the project can be ignored or unseen. Also, new blood may mean an absence of Six Sigma training, and as a result, the stakeholder may be oblivious as to what his/her responsibilities are in supporting the aftermath of a project implementation.
Poor Project Definition/ Scope of Project.  I’ve seen people try to save the world on certain projects, rather than breaking problems down into manageable “chunks”. Other projects have had their definition scope change and as a result the expectation of what the project will focus on/ deliver gets mis-communicated among staff, often resulting in a myriad of expectations for results that are often unachievable. 
Targets are too Ambitious.  Again with the comment regarding saving the world. I think sometimes people get pressured into thinking they have to save “x” dollars every time they do a project and truly don’t due their due diligence when estimating the return on a project. If your employer has a set minimum amount of return for a project and you initially think you can’t achieve it, then it might not necessarily be the best Six Sigma project.
Project not Linked to Plan.  Especially when training new Black and Green Belts, I’ve seen what I call “feel good” projects. The belt feels good because he/she has come up with a good problem to solve. However, if that problem is not linked to a gap existing between the company plan, metrics, mission statement, etc. and the current state, then it may be hard to garner long term support of embedding any long term improvement work (combined with a role change this can be the kiss of death).
One final note- I have never seen a project fail because the wrong statistical tool was used. Although statistics are important, it’s generally people and their behaviors that will make or break the success of a project. ]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 08 Oct 2007 23:01:19 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: ”V”… The importance of Verifying Projects]]></title>
			<link>http://blogs.isixsigma.com/archive/v_the_importance_of_verifying_projects.html</link>
			<description><![CDATA[Most of us are familiar with the DMAIC approach to Six Sigma.  But what happens after control phase is completed? The answer is verification. A lot of hard work has gone into the project and as a project leader you need to be able to walk away from an improvement that is embedded and is meeting its target(s). Here are my thoughts on verifying a Six Sigma project…

Have a primary 3 or 6 month audit, with a 12 month audit serving as a secondary, follow-up audit. The early audit will tell you if project work has been embedded into the organization. The later audit can be used to verify maintainability and if financial targets were achieved. 
Audits should not be conducted by someone directly involved with the project, or employees in the department where the project was implemented. It creates too much inherent bias. 
Project metrics should be evaluated in terms of baseline (before project began), target values, and achieved results. Note: in a 3 or 6 month audit, it may be impractical to look at NPV, ROI, and other financial indicators. Additionally project costs should be factored into financial results. 
Additional detail such as project cycle time, project handover and lessons learned should be discussed. 
The audit should obtain feedback from those impacted about the project’s stability, functionality, and relation to any key planning measures (e.g. safety, maintenance, etc.) 
Once the audit is completed (including any action items noted and references on who/ where information was obtained from), a summary should be shared with stakeholders. 
I like to classify audit findings into one of four categories: Pass, Systems not Embedded but Targets Met, Targets Met but Systems not Embedded, and Targets not met and Systems not Embedded. For audits that do not pass, stakeholders should have consensus about the rating prior to the audit’s final publishing.  ]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 08 Oct 2007 21:19:13 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Pause that Refreshes?]]></title>
			<link>http://blogs.isixsigma.com/archive/the_pause_that_refreshes.html</link>
			<description><![CDATA[Some of our Black Belts were talking the other day about how many projects they've got going, and (in spite of focusing our projects on specific value streams) how they sometimes feel pretty fragmented, getting pulled from project to project.
We discussed whether it would be reasonable to pause for a short while, to ensure that project follow-up is being completed and all the t's have been crossed and the i's dotted, within a particular value stream or project area.Our Black Belts are training our Process Owners as we go - project by project - and sometimes the POs need extra help to get the data collection and monitoring going.  In our healthcare organization, much of the data is collected manually by chart review or observation, so it's a little more cumbersome than pulling reports off of the computer (although, granted, that has its own MSA issues!).
We've been pushing the Black Belts to complete a certain number of projects each month, and sometimes it seems as if the goal of quantity is overshadowing that of quality.
I wonder whether this same feeling is familiar to Black Belts at other organizations, or are we unique?
I'd appreciate any comments you'd like to share!
 ]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 08 Oct 2007 14:09:45 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: A Unique Raytheon Six Sigma Project]]></title>
			<link>http://www.sixsigmacompanies.com/archive/a_unique_raytheon_six_sigma_project.html</link>
			<description><![CDATA[There is just no end to the kinds of business problems Six Sigma is able to help solve.  A news release picked up by CNNMoney.com, Forbes.com as well as others websites discusses a unique application of Six Sigma at Raytheon…







A team of Raytheon Six Sigma(TM) experts used the Raytheon Six Sigma process to validate and prioritize issues, determine root causes of barriers and identify and document optimal system changes and implementation actions required to truly remove barriers for people with disabilities to be competitively employed.
Talk about a Six Sigma project to improve quality of life!  Six Sigma doesn’t always have to be about product quality or financial savings.  Companies that use Six Sigma to solve these kinds of issues really understand the power of the methodology.]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 05 Oct 2007 12:38:25 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Lean Six Sigma Project #1031]]></title>
			<link>http://blogs.isixsigma.com/archive/lean_six_sigma_project_1031.html</link>
			<description><![CDATA[To:  Executive Sponsor
From:  Six Sigma Black Belt
Re:  Lean Six Sigma Project #1031
Our Define Report-Out is now ready for presentation.  This memo serves as an executive summary for your review.
Customers:  Children (primary), Parents (indirect)
Problem Statement:  Too many children in the United States receive Halloween candy in a way that is unpredictable.  Too much candy leads to inventory waste, while too little leads to sugar deprivation (a significant clinical condition).  An excessive candy supply may also lead to chocolate overdose or, worse, hard-candy-cavity syndrome.
Project Description:  Decrease variability in the amount and types of candy collected on Halloween.
Project Scope:  In scope - Children in costume on the night of October 31 between the ages of 2 and 12 living in the Detroit Metropoliltan area (map included in full R0).  Out of scope:  Teenagers, adults, babies younger than 2 years of age, children who don’t participate in trick-or-treating.
Alignment with strategic plan:  The two areas that will benefit most are efficiency and growth.
CTQ Expectations:  Children who go trick-or-treating on Halloween have two key expectations (per VOC survey).  1) At least 5 pounds of candy collected over the course of the evening (however this is the type of target where more is better).  2) A wide variety of chocolate, hard, and soft candies in approximately equal proportions.  (Note: Non-candy items such as pennies, apples, or trinkets are usually NOT appreciated.)  Therefore the Y to measure will be a) net weight of all candy items including wrappers and b) equality of candy among  four categories (those mentioned above plus a miscellaneous category).
Project Goal:  Improvement in the amount (weight) of candy collected and variety (distribution) of candy collected by at least 50% for 90% of the children who go trick-or-treating in the Detroit Metro area.
High level process map (from SIPOC):  Child is dressed in costume with collection bag - Parents convey child to location(s) for trick-or-treating - Child collects candy - Child and parents return home - Child consumes candy (Optional last step:  Child becomes ill).
Lean, Six Sigma, and Change Management approach:  There are many wastes to be observed in this process, therefore the project team will use Lean tools as a primary approach.  Transportation, Motion, Inventory, and in some cases Overprocessing are prevalent.  The Improve phase many utilize a Rapid Improvement Event (Kaizen Event), although data will be collected for statistical analysis as well.
The full R0 will be presented at our next Lean Six Sigma Report-Out next week.  Please feel free to share any comments or suggestions about this executive summary.
 ]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 03 Oct 2007 07:15:39 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: To p Or Not To p]]></title>
			<link>http://blogs.isixsigma.com/archive/to_p_or_not_to_p.html</link>
			<description><![CDATA[Let me end the suspense: not to p. At least for me. Also not to F. And not to t.
I got thinking about this topic after reading an article in the Wall Street Journal about “sloppy analysis” in scientific studies. That article is here, but you'll have to pay to see it. However, the primary source for the article, available here, is an open access study by John Ioannidis. What originally caught my eye in the Wall Street Journal article was this zinger:

Statistically speaking, science suffers from an excess of significance. Overeager researchers often tinker too much with the statistical variables of their analysis to coax any meaningful insight from their data sets. "People are messing around with the data to find anything that seems significant, to show they have found something that is new and unusual," Dr. Ioannidis said.
This situation sounded very familiar to me. In fact, substitute “Six Sigma” for “science” in the first sentence and I think the passage becomes even more true. We, as a Six Sigma community, rely far too much on formal tests of statistical significance to tell us what to do.
Statistical significance is nothing more and nothing less than a comparison of one thing to another. A comparison of a supposed “signal” to observed “noise” is the classic example. What gets forgotten is that when we experiment or otherwise collect data, we have complete and total control over what goes in both buckets. We decide what gets counted as signal, and what gets counted as noise. So the results depend entirely on how we sample. And there is no statistical test that can assess significance with this in mind,  because it's not a statistical question. It's a practical one. Want better p-values? Sample differently. Want to make your F-test look good? Or bad? Change how you collect the data. Want that t-test to have a different result? Run the study again. Go ahead. Try. It's really easy.
Don't believe me? Check out Ioannidis’ study, which goes into much greater depth on this topic than I have the time (or admittedly, the intellect) to do. And note in particular the comments about lack of replicability of most studies, regardless of p-values. In other words, a study with a high p-value is no more likely to repeat than one with a low p-value. And the standard of p must be less than 0.05 has no practical relevance at all. To anything. Scary, right?
Now don't get me wrong; I certainly don't intend to condone manipulation of data to make things “look good” or support some pre-determined outcome when they really don't. But on the other hand, I want to be very clear that blind faith in statistical test is just as bad. If you are letting software make business decisions for you on the basis of a p-value or F-test, you are behaving foolishly. After all, who made up the rules about what does and doesn't constitute statistical significance? What were the circumstances, and what were they trying to do? Unless the circumstances were the same as yours and they were trying to do the same thing you are, you should make up your own mind. What your software package happens to think about statistical significance out to be immaterial.
So what good are these tests of statistical significance? Well, for enumerative work on historical datasets they can be useful. But in the world of Six Sigma where we are charged with predicting the future behavior of a process, let me be clear: they aren't much good at all. You should be making your own decisions on what is and isn't significant in your data. This will be based on tolerance for risk and how well you have sampled the process, among other things. You need to fully understand the level of knowledge you have based on your sampling strategy, assess your confidence in your conclusions accordingly, and make the best decision you can about how to proceed based on the particular situation you are in. Beyond some basic number-crunching, these are practical questions and concerns, not statistical ones.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 23 Sep 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Why Does This Keep Happening to Me?]]></title>
			<link>http://blogs.isixsigma.com/archive/why_does_this_keep_happening_to_me.html</link>
			<description><![CDATA[An iSixSigma reader submitted the following article for publication on iSixSigma.com.  From time to time we receive excellent submissions such as this one, but they are just a bit too short for publishing to the website.  The iSixSigma Blogosphere, however, is the perfect place for these "mini" articles. 
By Johnny Welch (Originally posted on his blog.)
The unique demands on repairs, presented by the production environment, do not prevent us from revisiting the machine later and planning for a more permanent repair, if needed.
Likewise, we are not prevented -- and are again obligated -- to not only repair the problem, but to prevent the problem if at all possible. Just a few minutes of failure analysis can prevent hours of downtime later.
One of the Lean/Six Sigma tools that lends itself perfectly to this is the 5 Whys. By stating what happened, and continuing to ask why, we hope to arrive at the root cause of the problem. (Even though it is called the Five Whys, we only need to use as many as are necessary to arrive at the root.)
For example: “We had half of an hour downtime because we had to replace a sensor.”

Why? — because the sensor failed. 
Why? — because it had a crack in the casing. 
Why? — because it is sometimes hit when unjamming product in the machine. 
Stop — put a guard over the sensor.
Of course, this begs the question of why the operators are having to unjam product from the machine, but for purposes of this discussion we’ll stop.
This is a simple example, but I hope we can see that this could be and should be used for all failures, no matter how complex.
However, we are not only tasked with preventing and correcting failures. As important as getting the problem fixed, in the industrial world, is the amount of time it takes to fix the problem. Therefore, our analysis of the failure is not yet complete.
Call it the 10 Whys, 5 Whys Times Two, whatever, we have not done our job until we have analyzed both the failure and the time involved in repairing it. This is where we finally locate the gun we keep shooting ourselves in the foot with — parts, documentation, training, etc.
For example: “It took an hour to replace a sensor.” 

Why? — because it took fifty-five minutes to isolate the problem to the sensor. 
Why? — because we changed another switch first. 
Why? — because we thought it was the only sensor involved. 
Why? — because we didn’t fully understand the sequence of operation.
We’ll stop here, but we see what needs to be done — we need to spend the couple of hours offline figuring the sequence out and then train everyone accordingly. 
About the Author: Johnny Welch is an industrial electrician/electronics tech that has been working in industry for fifteen years.  He has held leadership and supervision/management positions for more than seven years.  He is currently working as a maintenance supervisor at a leading manufacturer of flooring products.  Johnny recently completed Black Belt level Lean/Six Sigma training.]]></description>
			
			<author><![CDATA[iSixSigma Editor]]></author>
			
			<category>
			<![CDATA[Guest Blog&nbsp;,&nbsp;Lean&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 17 Sep 2007 10:27:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: I have been blind]]></title>
			<link>http://blogs.isixsigma.com/archive/i_have_been_blind.html</link>
			<description><![CDATA[Now I like to think I am quite an objective &amp; freethinking person and don’t always follow the herd when I think something is wrong. I’m not a complete contrarian but am willing to “go it alone” when I feel something is important. So it is a great disappointment to me to say I have only recently discovered DoE. Let me explain the circumstance of enlightenment first.
Over about a month, one of our processes fires two letters and an outbound telephone call to our customers to achieve a particular goal. The process is about 50% effective and we were discussing options for improvement. People talked about changing the wording on the letters or the call date. During the meeting, memories rushed-in of me in BB training, adjusting the settings on a catapult and measuring the distance the ball travelled and I slowly said, “we…could...design...an...Experiment”. I nearly pulled it off but didn’t quite have the confidence or conviction to convince people that DoE would fit the bill.
As I do, I dived into the DoE material, we had a classic 3-factor, 2-level, factorial experiment and I didn’t see it! How could I have got myself into a situation where I have ignored one of the fundamental tools of Lean Six Sigma? How could I have been so blind?
Since my earliest days on BB training when we covered DoE, the picture was painted of a tool used in manufacturing that really does not transfer into a transactional environment. The exercise was “manufacturing”, the examples were manufacturing. The books I have give manufacturing DoE examples; one of the more transactional books completely ignores it and most give a passing reference. My coaches have never really talked about using DoE and when they did they talked about it being difficult to apply in a transactional environment. 
I never really challenged the orthodoxy here and feel I have really missed out. Am making serious amends and it’s a strict study diet of confounding, blocking, attribute response, response surface design and loss function for me.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 05 Sep 2007 11:28:45 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Seeing the wood from the trees]]></title>
			<link>http://blogs.isixsigma.com/archive/seeing_the_wood_from_the_trees.html</link>
			<description><![CDATA[I have been working with my colleague, Dave Baker, here at Aviva and we have been researching the long-term behaviour of our processes. 
Now I am not going to go down the path of process capability analysis, Cp, Cpk, Zshift and the like. Take a look at this simple time series plot to see why.

Over the long-term some of our processes are extremely seasonal and what we were interested in is understanding was how much of the process variation was due to seasonality, long-term trend or random process variation. It has been a bit of the blind leading the blind; we have reviewed statistics books, experimented in Minitab and tried to figure this out. 
What we found was Minitab has a capability to decompose the data and with a bit of experimentation we produced an output that showed the seasonal variation and long-term trend.

From this we could eyeball when the process (black-line) moved away from the seasonally expected value (red-line) and also the long-term trend. We then found how to strip-out the seasonal-variation to see the process performance as shown below.

So we believe we have discovered the basics for long-term trend analysis and some of the benefits appear to be:

Ability to see degree to which seasonality affects process performance 
Ability to better understand long-term trends 
Gain a clearer picture of process performance without seasonal interference 
Ability to address short-term customer issues that can be explained by seasonality.
We have some way to go yet but feel we are moving in the right direction and this is getting us a lot of success on a current project.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 30 Aug 2007 09:29:37 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What's In Your Toolbox?]]></title>
			<link>http://blogs.isixsigma.com/archive/whats_in_your_toolbox.html</link>
			<description><![CDATA[
In every company, people in organizations make decisions and implement changes every day.  Many of these changes are not typically the type of things that warrant a Six Sigma project.  That being said, it should be recognized that the application of some Six Sigma tools in these everyday activities can provide a significant positive impact on daily business as well as serve as a catalyst for cultural transformation.  For example:

Completing a FMEA for a "just do it" can increase the probability of "just doing it right"
A simple process change accompanied by a SIPOC may identify a customer that may not have been previously considered
Using a C&amp;E matrix to rank employment candidates against desirable knowledge, skills and abilities can be helpful in developing the "short list" of candidates to further interview
No, these are not Six Sigma projects nor should they be.  But these are great examples of how basic Six Sigma tools can help leaders and employees make better business decisions on a daily basis.  
Having a Six Sigma toolbox chocked full of DMAIC and DFSS power tools is great.  Keeping a couple of wrenches in your toolbox to help folks turn their "just do it" into "just do it better " may be just the twist needed to close the gap between doing Six Sigma and being Six Sigma.  ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 27 Aug 2007 10:51:59 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Candy]]></title>
			<link>http://blogs.isixsigma.com/archive/candy.html</link>
			<description><![CDATA[Things that make you feel good in right away aren’t always beneficial in the long run. Some things, like candy, are actually harmful in the long term. While others, like getting the high score on Space Invaders, just don’t end up mattering very much. You feel good as they are happening, but beyond that they don’t improve your life too much. A lot of things that make us feel good fall into this category. Maybe even most things.
Now this is hardly news. It’s not a novel insight into the human condition. But it is remarkably tough to remember in the moment. Human nature makes it very difficult to pass up short term gratification in favor of long term rewards. Especially when those long term rewards might require not only missing out on short term pleasure, but perhaps even opening ourselves up to short term pain. It’s one thing to understand the equation on an intellectual level, but quite another to have the discipline to put it into practice. After all, who doesn’t like candy?
So what does this have to with Six Sigma? Well, even in the best intentioned organizations, people like candy. For deployment leaders, that means there is strong temptation to dispense instant gratification to the organization. Training programs that are short, snappy, and enjoyable. Projects that deliver immediate return on investment. Minimal disruption. Quick results. Excitement. Fun. Candy.
How powerful is this temptation? Very. And enablers abound. Consider, for example, the graphic below, which appears on the homepage of SBTI. What does it suggest? That within five months (roughly), return will exceed investment. That within twelve months, return will be more than three times greater than investment. In short, it suggests candy. Which I suppose might be okay, if that’s what you are looking for. And if you are a deployment leader, it probably is what your boss is looking for.

The trouble is, just because our kids want ice cream for breakfast every morning, feeding it to them doesn’t make us good parents. The entire point of an intensive methodology like Six Sigma is to go after difficult, thorny problems. The kind that have been around for a long time. The ones with solutions that are not obvious. The ones that require time, effort, expertise, creativity, deep thought, and hard work to solve. For goodness sake – if you have a list of projects that can be easily solved and deliver return on investment within five months, what on earth are you messing around with Black Belt training for? You don’t need Six Sigma, you just need focus.
Perhaps the most concrete manifestation of this phenomenon is Six Sigma training. Those of you who have lived through Six Sigma deployments, tell me if the following conversation sounds familiar: “Black Belt training? Way too long – we can’t spare our people for four months.” How about Green Belt training? “Two months is better – but how about we do the second week online so they don’t have to travel?” Well…I guess we could… . “In fact, can we do the whole thing online?” Um, not really… . “Perfect! And we can get champions through in a single day, right?” Curricula shrink to the point of becoming series of self-evident statements spread over PowerPoint slides. Any sense of challenge and achievement disappears. The chance to modify the behavior of a class over a significant time period evaporates. But, boy, do we ever get good a delivering a snappy one-day class.
If you think I’m exaggerating, I encourage you to troll the websites of major and minor providers of Six Sigma training today. You’ll find a lot of candy. Six day, online MBB certification, anyone?
You already know where I’m heading with this. Like I said in the beginning, it is something we all realize intellectually. It’s just tough to actually do it. Our job as Six Sigma professionals can’t be to dispense candy to the organization. No more ice cream for breakfast. Even though it’s no fun for anyone involved, we need to become the bringers of organizational All Bran. We all know what to do, we just need to have the courage to do it.
(One final note: Shortly after I wrote this entry I stumbled across this article by Mark Kiemele on the Air Academy website, which makes many of the same points I make here.)
 ]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 25 Aug 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Nail Down Your Project with PBL]]></title>
			<link>http://blogs.isixsigma.com/archive/nail_down_your_project_with_pbl.html</link>
			<description><![CDATA[A good project gets you the facts, the data. Talk objectively with those facts and you have a water tight case for any ‘rhetoric’! 
In my Blog Man v. Machine I talked about PBL; ’Performance Based Leadership’, basically Behavioral Science that at Bechtel they use hand in hand with DMAICT. They have an acronym called NORMS that I use when stating a case or giving difficult feedback. This has dug me out of many tricky confrontations. When giving feedback ensure it’s:

Not an Interpretation – an unbiased statement about an event or behaviour
Observable – Based on specific behaviours or events that are actually seen or heard
Reliable – 2 or more people can independently agree on events that are seen or heard
Measurable – a number can be used to describe behaviour
Specific – who, what, where, when, context, sequence
I find it especially useful for Black Belts who often have the facts and the data and it’s especially useful in providing feedback to colleagues / individuals. 
Do you have any other methods of delivering effective feedback?]]></description>
			
			<author><![CDATA[J P Spencer]]></author>
			
			<category>
			<![CDATA[Change Management&nbsp;,&nbsp;General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 20 Aug 2007 09:25:55 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Variation and special cause: Discovering the facts]]></title>
			<link>http://blogs.isixsigma.com/archive/variation_and_special_cause_discovering_the_facts.html</link>
			<description><![CDATA[Conformance is how well a process performs within its CTQs and specification limits. Variation is the opposite of it- the difference in the process output over time. Variation is often caused by elements which are part of the process itself (common cause), or elements which are external to the process (special cause). 
Common Cause variation is effected by elements within the process. They are mostly random and independent of each other; conforming to the normal distribution curve ie stable. However, a stable process does not mean good or satisfactory output- it merely means the process is consistent within specification limits and the variations are contained within these limits. In the formula y=f(x), there are many x’s but low impact x’s (described in iSix Sigma’s dictionary). Tweak the process to get improvements in output. 
Special Causes of variation are arising from unusual circumstances. They are not random, do not reflect historical trends and is not normally distributed. If Special Cause variation is detected in a process this process is considered not stable. In the formula y=f(x), there are few x’s but high impact x’s (described in iSix Sigma’s dictionary). It’s probably not a good idea to change the process first, but dig deeper into the root cause of this kind of variation. Tweaking the process won’t make the special cause variation disappear because these variations may have nothing to do with the process. Introducing a process change may result in worse variation than before -the normal ‘ups and downs’ of the process may turn into irregular spikes. 
Hotels sell ‘moods’ and ‘senses’- it’s inevitable these elements influence comment forms or process output but what’s the connection between variation cause and customer experience? This brings us back to that particular set of dots outside specification limits in that project run chart that had the food &amp; beverage team bewildered. If the Five Whys and Cause-And-Effect can’t provide a direction, it’s time to look at the ‘history’ of the guest who contributed to the data point. Were there any complaints logged on this particular guest prior to this project’s process? In the hotel industry, the guest goes through processes back-to-back. Any ‘unhappiness’ or ‘joy’ from the previous process is retained and brought forward to the next process, the degree which depends on how the guest interacts with hotel employees, hotel products and the customer recovery process. For instance, the guest ‘suffers’ a ‘bad’ check-in (room not ready &amp; guest waits unreasonably; assigned a smoking instead of a non-smoking room, failed elevator, etc.) and is still unhappy at dinner time gives a poor rating to the food &amp; beverage service. Properly identifying data points like this tells a clearer picture of project performance- what to change and what not to change.]]></description>
			
			<author><![CDATA[Vincent Chin]]></author>
			
			<category>
			<![CDATA[Customer Satisfaction&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 13 Aug 2007 13:17:46 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: For Example]]></title>
			<link>http://blogs.isixsigma.com/archive/for_example.html</link>
			<description><![CDATA[If you do any sort of training, you’ve probably struggled to come up with good examples to drive a concept home. Nothing crystallizes difficult material like the perfect example to make it all real. Every train-the-trainer workshop you’ve ever been to has doubtless spent time worrying about this. And if you’ve ever been through the experience of having one of your carefully constructed examples picked apart at the front of a training room, you’ll know that it’s important to think hard in advance about examples you are going to present. Very hard. Because having your example unraveled is not pleasant, especially when a few dozen sets of eyes are watching you every step of the way.
Many trainers confuse analogies with examples. Personally, I try never to rely on analogies to prove a point. Why? Because by definition, situations that are analogous are different. Same with similes and metaphors. If you find yourself arguing some point by saying “a project is like running a race…”, I guarantee half of your audience is thinking “no, it’s not”. And they are right. Projects are not races. They aren’t fruit either, and they can’t be “low hanging” or “sweet”. And managing using Cpk is nothing like parking a car in a garage. I could go on, but I probably don’t have to. I’m sure you’ve seen all the classic PowerPoint slides just like I have. Points made this way are inherently weak because if pushed, analogies cannot possibly hold. Even a mild inquisitor can undo you. Sure, use these devices to illuminate and enrich understanding, but don’t base your arguments on them. You need a more solid foundation.
Which brings us back to examples. Examples have a weakness too, which is that they are inherently specific. For every example that fits your argument, there will be another example that does not. So selection of illustrative examples in the context of training becomes very important. Not only do your examples have to be clear, concise, and obviously linked to the concepts in your material, but they have to be persuasive enough that folks can easily generalize from the specific to the general. That’s a tall order.
If you ask most audiences, they will tell you that they want examples that are clearly related to their work. Put another way, they want examples that are almost the same as what they will have to do in real life. Fair enough, but as a trainer, it is practically impossible to deliver those kinds of examples unless you have a lot of prep time, a very homogeneous audience, and a big library of examples to work from. If you are teaching a lot of classes in a row, or if the folks in those classes are working on different things, or if you are treading new ground, forget about it. There’s not enough hours in a day to do it right!
Happily, there is a way around this problem. One so blindingly obvious that a lot of people miss it. Eliminate the examples altogether and work on projects live, in class. Make all the points you need to make in real time, using actual situations being encountered right now. Go straight from presentation of the concept to application in a real situation. Know your project portfolio like the back of your hand, and rely heavily on project reviews to back up your points. This is old news to folks who run kaizen events, where the journey from theory to application is often measured in minutes. But for whatever reason it seldom seems to happen in longer Six Sigma training courses. Too, bad because it’s an extremely powerful way to make points. Not instructor friendly at all, but much more powerful in the long run than prattling on about making cookies to explain interactions.
The downside to this approach is that, in the short term, folks in the class don’t like it very much. People want the comfort of easy, familiar examples. Skip those examples and your scores on end-of-class surveys will plummet. Be prepared for that. You might even lose a few people entirely. Possibly those already on the low end of the distribution, and probably those that aren’t doing project work like they should. But who you should be catering to anyway? And is the job to change behavior and deliver results, or make participants feel good?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 01 Aug 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Micro map]]></title>
			<link>http://blogs.isixsigma.com/archive/micro_map.html</link>
			<description><![CDATA[A couple of days ago, during a particularly boring meeting I started to doodle. But it wasn’t one of those doodles where you draw a box, then put a cross in it, then shade it, add a couple of surrounding circles, give it legs etc…. it was a doodle with purpose, I started doodling Lean Six Sigma!
It started with a SIPOC. I think the SIPOC has huge value and is somewhat a misunderstood tool. I started drawing the relationships between the SIPOC and other tools used in Define. Things just started appearing around it. I have had a go at distilling some of the areas with the “mind map” below. I have journeyed from Define to Improve on paper so far.

I hunted around the Internet to see where this has been done before so I can see what the finished article would look like. But in terms of models, most describe Lean Six Sigma from 30,000 ft or describe things like which tool to use and when, the outputs at each DMAIC stage, the roles and responsibilities required, the maturity of the deployment and the best structure and critical success factors. All these are extremely useful, but not quite what I was after.
What I imagined was an A3 size poster with all the tools shown with the inter-relationships, a picture that would “jigsaw” all the tools together. Not sure if one exists, so am pursuing my own endeavours.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Mon, 23 Jul 2007 04:22:47 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Project Rigor versus Project Cycle Time]]></title>
			<link>http://blogs.isixsigma.com/archive/project_rigor_versus_project_cycle_time.html</link>
			<description><![CDATA[For the Army deployment, this is " the year of production." We are in full swing of BB and GB training plus project completion for certification. The work in progress is pretty high. We have a full pipeline of newly trained belts itching to do projects. But with a constraint to complete x number by the end of the year, do we accept lower project rigor in order to finish? Then increase the rigor as we go along? Or do we ensure belts really understand how to go from "soup to nuts" on a project before releasing them into the wild?
Surely project mentoring is a huge part of the equation, but will we end up mentoring more once they are done or less? What is the right mix? 
 ]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Military]]>
			</category>
			<pubDate>Fri, 29 Jun 2007 09:03:50 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Benefit Pit-falls]]></title>
			<link>http://blogs.isixsigma.com/archive/benefit_pit_falls.html</link>
			<description><![CDATA[One of the foundations of Lean Six Sigma is its clear link to benefits. Take a look at some of the quoted benefits from the Lean Six Sigma behemoths:

GE saved $12 billion over five years and added $1 to its earnings per share
Honeywell (AlliedSignal) recorded more than $800 million in savings
Six Sigma reportedly saved Motorola $15 billion over the last 11 years
Unfortunately our deployment is by no means as mature; we aspire to reach these levels. Along our journey we have learned just how important it is to get the benefits story right. Here are some of the pit-falls encountered and may be of assistance.
Tangible means financial?I see people using of the terms tangible and financial interchangeably based on the idea that financial benefits are the only tangible and anything else is intangible. We have a simple rule; if you can measure it it’s tangible otherwise it’s intangible. Simple as that. So for example you can have for tangible benefits covering:

Customer - e.g. Customer satisfaction
Financial - e.g. Revenue growth
Process -  e.g.Product defects
People - e.g. Increased pay
You’ve got to grab the benefitsWe sometimes find we have multiple projects working on a process some being Lean Six Sigma and some not. If the process improves which project bags the benefits? We look to get an agreement between the various projects on the allocations. Looking forward we hope to become more sophisticated based on the Y=f(X) approach and the X’s can always be other improvement projects.
You’ve got to bank the benefitsAgain sounds simple but I have found not all tangible benefits translate into Business Benefits. 
For example removing non-value activities in a process makes it more efficient. But if you don’t make use of that improvement by for example increasing the volume or redeploying people to other areas then you haven’t achieved a business benefit.
Another example is we sometimes run DMA projects where we do rapid analysis down to root-cause and identify the benefits available. We don’t do so many of these now as we realised the improvements were not sticking and you can’t achieve a Business Benefit until you have delivered the improvement 
These are a few examples of the pit-falls encountered. What is important is making sure every single project can clearly define and manage its Business Benefits.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 22 Jun 2007 07:43:41 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Is Six Sigma Really the Baaaaaaad Boy?]]></title>
			<link>http://blogs.isixsigma.com/archive/is_six_sigma_really_the_baaaaaaad_boy.html</link>
			<description><![CDATA[Lately, there has been a lot of talk about Six Sigma.  Believers tout stories of business success, unprecedented customer satisfaction and countless dollars to the bottom line. Naysayers point to near business ruin and cultural impacts that stifle innovation and growth.  Whether you are an avid believer or a practicing naysayer there is one thing that everyone seems to agree on - Six Sigma is a powerful methodology.  So the question remains: Is Six Sigma really the bad boy . . . or the scapegoat?
In pondering the answer to this question, the first challenge presents itself when asked to define Six Sigma.  Traditionalists often speak of Six Sigma as an improvement methodology created by Motorola more than 20 years ago or define it as 3.4 DPMO (defects per million opportunities).  To me, that is sort of like describing today’s car by referring to an early Model T Ford.  Yeah, it is still a car but it is nothing like the car of today by any stretch of the imagination.  Over the past 20 years, Six Sigma has evolved and reshaped itself many times over.  It is this "megamorphosis" that has allowed it to continue to bring value to those who know how to wield its power.
So what is today’s definition of Six Sigma?  It is a powerful business methodology that helps companies transform their work environment into one where collaborative teams routinely work across the total value chain to identify new and innovative ways to meet changing customer expectations.  Whew!  Sounds like a bunch of ’wugga" words at first glance but fittingly serves as a high level definition for the new and improved Six Sigma of the 21st century.  Six Sigma today does not only consist of a DMAIC, Lean and DFSS toolbox but also includes aspects of change management, innovative thinking, team dynamics and other skills that must be mastered in order to effectively use the toolbox.  In addition, the synchronization of Six Sigma with strategic objectives, goals, leadership development, workforce planning, incentives and communication creates a powerful engine that drives organizational transformation.   But with this power comes the responsibility to define what you want to transform your organization into.  Left undefined, you might find yourself the victim of transformation rather than the shaper.
Before embarking on any transformational journey, an organization’s leadership must define a vision and the behaviors needed to achieve and sustain that vision.  Once defined, a Six Sigma deployment strategy can be shaped to serve as the enabler.  Many times the vision may be clear but the organization has not thought about the behaviors needed to support the vision.  Other times, a single threaded vision may drive an organization to use Six Sigma to become "cost focused" or "defect reduction focused" at the expense of growth or innovation.  Is Six Sigma to blame for this?  Some say yes because it served as the pathway to get there.   But the reality is just that - it is only a pathway.   The destination was defined (whether knowingly or not) by leadership and Six Sigma was the enabler - and a powerful one at that.
As such, leaders must make sure that Six Sigma does not evolve into a life of its own but maintains its rightful place as a pathway to achieving the company’s vision.   As a company’s vision and strategy is reshaped to satisfy ever changing markets and customers, Six Sigma must also reshape itself to complement these changes.  It is this ability to constantly synchronize Six Sigma with a company’s vision that distinguishes true Six Sigma companies from those that are just "doing it".
Six Sigma . . . bad boy or scapegoat?  You make the call.]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 16 Jun 2007 11:12:01 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: In Control or Out: How Human Process Control Can Make a Difference]]></title>
			<link>http://blogs.isixsigma.com/archive/in_control_or_out_how_human_process_control_can_make_a_difference.html</link>
			<description><![CDATA[Lately, I have written a lot on call center points of interest, as I have just rolled off three back to back projects in that space. These are some of the hardest six sigma project types, that is, when compared to manufacturing from the control perspective only. Now, I am not at all claiming that manufacturing projects are any less significant. But, in reality, when you are "controlling" a machine using control charts, and watching for deviations outside of your control limits, you can go and tweak a knob here or pull down a lever there, as based on your control plan, and immediately see the results in your SPC charts.
In human processes, however, it is a bit trickier. When a process goes out of control due to human variation, there is no level to pull that can quickly show results in a set of SPC’s. Instead, one often has to look deeper into the root causes that they are controlling, for the potential of multi-colinearity between inputs, or inputs that were not surfaced during the DMAI of your project. Many things affect human performance. In fact, have you ever done a process the same every day, whether getting dressed in the morning or the classic, making toast example? I dare to guess that the answer is NO, if you are like me. 
The frustrating part of this for black belts is that often deployment leaders expect similar results as they saw in manufacturing companies which again isn’t an apples to apples comparison. Instead, one must look into the softer motivational tactics that keep these agents coming to work, and most often, will need to look into how your incentivize their work. You get what you pay for, in soft dollars (i.e. free food, recognition programs like Agent of the Month, etc) as well as hard dollars (i.e. salaries), so make sure you align your performance management goals with your incentives. 
For example, if you are looking to reduce AHT but incentivize your centers for high C-Sat, you are shooting yourself in the foot. Quality often slows down a call, because agents are truly "listening to needs" and proactively driving suggestions that will help them appear more knowledgeable and willing to assist a customer’s request. If you incent time, you will find agents doing what ever they can to get off the phone by the target time, in order to get incentive, even if it means taking a QA hit (if that was how you were thinking of controlling the C-Sat situation). 
Instead, look at building in controls that band behavior, like a scorecard would. Instead of having an AHT incentive, look to rewarding low hold time or ACW time (two components of the AHT calculation) because talk time is the true driver of C-Sat. Hold time, BTW, is not the time it takes for an agent to pick up the phone, a.k.a Average Speed of Answer, as that is a C-Sat driver, but isn’t part of the AHT calculation. Don’t confuse the two. Hold time during a call, is when an agent asks to put you on hold while they (...call the carrier for you, process your request, waive fees etc). This is seen as VA time if you look at your own VOC. I promise you...Just dig deeper, and know that you can control human variation but you must align your incentive and performance management structure to do so.]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 13 Jun 2007 10:21:54 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Hold Time: the real hidden factory of waste]]></title>
			<link>http://blogs.isixsigma.com/archive/hold_time_the_real_hidden_factory_of_waste.html</link>
			<description><![CDATA[Resolution, resolution, resolution...that’s what I always say...and so when I see black belts going after AHT (average handle time) as their key output (KPOV) variable, I cringe. Instead, why not break it down to the components of AHT: Talk Time, Hold Time and After-Call Wrap Time. 
Ok, some of you are saying , "what if you don’t include hold time in your AHT calculation?" To that, I would challenge your calculation by saying that you are missing a huge opportunity and understating the true AHT. WHY? If you have a complex product like we do, you will find that during periods of lower agent tenure, your hold time will increase substantially because those newbie agents are somewhat unsure of themselves, even after nesting. Thus, talk time might be affected, but they are more likely to put customer’s on hold during a call to ask a supervisor or lead a question -- Result: a high amount of hold time = large opportunity for improvement. Break it down. Go after one of the three components. 
If you only include Talk Time and ACW, then add hold time to the mix. Most switch’s will output hold time, so grab it. Going after AHT will only frustrate the black belt as they try to prove reductions. By reducing one of the components in the calculation, you by default, will improve the overall AHT]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 07 Jun 2007 11:41:46 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: ANOVA]]></title>
			<link>http://blogs.isixsigma.com/archive/anova.html</link>
			<description><![CDATA[In my on-going journey to master the tools &amp; techniques of Lean Sigma I have been reviewing the materials on ANOVA. How useful this has been, it has really moved me on a level.
ANOVA comes across in training as a very useful tool and Tukey’s pairwise comparison really hits the spot. However in our business with samples of skewed non-normal distributions with unequal variance, I infrequently meet the assumptions for use, “Samples must be normally distributed and of equal variance” and swap over to Mood’s Median Test. 
So when I reviewed this topic in my own time I was surprised to read in Principles of Applied Statistics that “in practise the normality and equal variance assumptions are not important” I was intrigued. Not having a statistical background I had always assumed these were fixed assumptions and used the tools accordingly. Could it be that I had misunderstood the theory? What about the other statistical tests based on the normal distribution e.g. 1-sample t-test, 2-sample t-test, paired t-test and F-test for equal variance, could these be used as well?
I started doing some empirical tests in Minitab. Useful research but did not answer the questions. I then reread my collection of Six Sigma books. These gave differing and sometimes vague advice on how to handle hypothesis tests on non-normal &amp; unequal variance samples. From this I got two things, first I needed to look outside of my “Universe” to find an information source I could trust, second I needed to be more specific in my questions. So I framed the questions:

To what degree does non-normality impact the hypothesis test? 
To what degree does unequal variance impact the hypothesis test?
To find an information source I could trust I went to the library and borrowed the biggest academic book on statistics I could find, Introduction to the Practice of Statistics. It went in-depth in the areas I was looking for guidance.
In terms of output I wanted to produce a simple table of practical advice that could be used. Here is what it looks like now, still working on it and going through the theory.




Hypothesis Test
 Non-normal Data
Unequal Variance

1-sample t-test
Robust test except against outliers or strongly skewed data. Samples less than 15 - must have normal data, less than 40 - no outliers or strongly skewed and greater than 40 - no outliers but can be skewed
 No significant impact

2-sample t-test
 In research
 In research

Paired t-test
In research
In research

F-test
Do not run test, use Levene’s test
In research

ANOVA
In research
Largest standard deviation should be less than twice smallest standard deviation
This is the start of the research and joins the growing body of knowledge I am building in the subject. What it does is provoke the next set of questions, things like what is the risk of using the results, how does sample size impact on confidence intervals in these situations, what other situations should be considered e.g. outliers &amp; different distributions and when should non-parametric tests be used.
Anyone out there with the answers?]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Research]]>
			</category>
			<pubDate>Wed, 06 Jun 2007 03:41:38 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Is Six Sigma Kryptonite to the Superhuman Forces of Innovation?]]></title>
			<link>http://www.sixsigmacompanies.com/archive/is_six_sigma_kryptonite_to_the_superhuman_forces_of_innovation.html</link>
			<description><![CDATA[It’s almost becoming an age-old debate whether or not Six Sigma and innovation can co-exist in a symbiotic relationship.  We have heard time and time again that Six Sigma "stifles innovation." But where’s the data to prove it? 
The most recent issue of BusinessWeek covers innovation at 3M and what Six Sigma has to do with it (but more about what Six Sigma doesn’t have to do with it).  Apparently 3M is scaling down their Six Sigma efforts in the “innovation” centers of the company.  It looks like we have one data point now.
Business blogs have been going crazy commenting on the BusinessWeek cover storie.  Most bloggers quickly agreeing with what mainstream media prints. Hey, if it’s in BusinessWeek, Fortune, or the the WSJ, it’s gotta be true!  While I could never agree that citing one company example is proof an entire methodology is corrupt, the article does dig deep in to how company culture influences innovation - and 3M surely has/had a data driven culture.  
Mike Lopez, over at the Lean Blog, shares his first impression of the article:

"As a Lean Six Sigma black belt at my company, I find that reading these types of articles continuously reminds me that neither Lean nor Six Sigma is a panacea."
I thought the exact same thing after reading the article (independent of Mike’s blog entry). Six Sigma is hardly a cure all.  And please do not blame all consultants for perpetuating this fallicy. I have never met a consultant who preached such falshoods. Unfortunately, if a company is not hitting their numbers, something must be blamed.  Six Sigma companies (those that use the methodology) are perfect targets for this misguided blame.  They are "supposed" to be perfect. 
A comment to Mike’s post sums up my thoughts on the relationship between Six Sigma and innovation: 

"It seems positively stupid to think you can’t have both Six Sigma AND innovation at the same time at a company.  This is more of the "we can only focus on one management tool at a time" mentality that’s harmful and destructive. We have to throw out Six Sigma from the places it’s useful because our innovation has suffered?"
Amen.  3M needs to get to the root cause of their lackluster innovation instead of beating up Six Sigma… the same Six Sigma that has saved 3M billions of dollars.  Sounds like an interesting and profitable Six Sigma project...  
The July/Aug 2007 issue of iSixSigma Magazine will include my latest research on Innovation and Six Sigma. We surveyed 1,000 people. Here’s a sneak preview of Finding Two: 



    
 


The two keys to effective innovation are an actionable strategy and use of a systematic process.
Survey data suggests that two characteristics make an innovation program successful: an actionable strategy and using a systematic process. 
Eighty-one percent of respondents who rated the innovation efforts of their company “effective” said the company is executing an innovation strategy. The strategy alone is not enough; the key is to be taking action on the strategy. 
Half of the survey respondents indicated that their company has no innovation strategy. 
Regarding how innovation occurs, of the respondents who rated their company’s innovation program effective, 84 percent said innovation occurs through a systematic process or methodology; 16 percent said it occurs on an ad hoc basis. This compares to respondents from programs rated “ineffective,” of which 2 percent said innovation is systematic and 98 percent said it is ad hoc. 

If you’d like the full results of this research, subscribe to the Magazine, borrow the issue from a friend next month or make a meaningful comment below.  I’ll send out a free copy of the magazine to the first person who shares their reaction/thoughts/opinion on the subject of innovation and Six Sigma. Go ahead share...
Links
At 3M, A Struggle Between Efficiency And Creativity, BusinessWeek, June 11, 2007
Six Sigma: So Yesterday?, BusinessWeek, June 11, 2007
Bloggers commenting on the BusinessWeek article
Innovation and Six Sigma, Real Innovation Commentary
Improvement and Innovation, Real Innovation Commentary
Putting Six Sigma back in its box, Cognitive Edge
More blogs from Technorati: six sigma 3m]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;Guest Blog&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 04 Jun 2007 17:48:47 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Synergy of Projects]]></title>
			<link>http://blogs.isixsigma.com/archive/the_synergy_of_projects.html</link>
			<description><![CDATA[I recently received an e-mail from another Command that outlined a program of LSS projects regarding the Army Reserves Family Support Group. The Family Support Group is essential a booster organization that supports military families during deployments and other activities that make their loved one absent. They provide resources such as Red Cross Assistance, small household goods and the like. As part of our initial project sponsor workshop, we identified opportunities for improvement with the Family Support Group within the 335th Command. We assigned an initial project regarding the management of the database that houses contact information. We are looking to improve a couple of items: the cycle time to input data into the portal and reducing the number of discrepancies in the database that causes mail to be returned or prevent us from contacting a family member by phone. 
The adjacent Command outlined a similar project regarding contact information on the Family Readiness database. I found it quite interesting and proceeded to talk with our Family Programs Coordinator who was somewhat surprised. I think so  too given that we operate off of Power steering to give visibility to all projects. I then contacted the Coordinator of the database project who exclaimed this is the first time he heard of it also. We both agreed to begin steps to work in this jointly. 
The bottom line is that with such a huge organization sharing similar problems, yet attacking them disjointly dilutes the potential for effective and innovative solutions. As we journey through this, I am hopeful that we can establish a more robust Enterprise level project communication system to facilitate the synergy needed to build the critical mass we are seeking to develop. 
 ]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 01 Jun 2007 06:51:26 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Documentation Dilemma]]></title>
			<link>http://blogs.isixsigma.com/archive/documentation_dilemma.html</link>
			<description><![CDATA[“Dilemma” is term properly reserved to describe a situation in which we must choose between two more-or-less equally unpleasant alternatives. This pretty much sums up how most organizations feel about documentation for Six Sigma projects.
On the one hand, there is always an organizational craving (note that I am specifically avoiding the term “need” here) for templates, documents, forms, and metrics that can feed the dreaded “roll-up” of information. These roll-ups often result in dashboards or scorecards that are supposed to be used to make decisions and steer a program.
On the other hand, there are Black Belts and their teams who are probably already working 16 hour days and still not finding enough hours to get everything done. They are digging deeply into problems and opportunities using techniques and tools they have been trained to use at great expense to the organization. They see documentation mostly as a distraction (“non-value-added work,” they will knowingly mutter) and something that takes away from their more important tasks.
A dilemma indeed. On the surface of it, the organization has to choose between having limited visibility and little information on which to base decisions, or saddling the “best and brightest” with a lot of busy work filling out incredibly repetitive templates and forms. Neither alternative is palatable.
In a sense, the answer is simple: strike a balance. But from what I’ve seen, finding that balance is very tricky, and organizations rarely get it right.
Part of the problem is that often the higher one goes in a company, the more simple and summarized information becomes. This phenomenon drives a pyramid of information collection in which many people at the bottom scramble to produce information and reports in a pre-determined format at whatever frequency is seen as “necessary” to a small audience at the top. The “roll-ups” thus produced containing a surprisingly small amount of information which may or may not accurately reflect what is actually going on. This is almost certainly not what the folks at the top want to have happen, but it’s usually what does happen.
At the other end, Black Belts and template designers often prefer to provide information that is easy to provide, rather than what is useful. Automated software “solutions” are terrible for this, enabling the tendency rather than reversing it. For example, many electronic dashboards ask users to enter project phases so they can show a roll-up of, for example, what percentage of projects are currently in the “improve phase.” This is what I like to call a “feel good” metric; it doesn’t really mean anything, so the presenter can spin it any way they want to make the audience feel good. Number of projects in the improve phase going up this month? Great! We love improvements! Number of projects in the improve phase going down this month? Great! More project proceeding towards completion! I can’t imagine a scenario in which we could make a decision based on a metric like this, but it makes us feel good to see it displayed (in color) on a dashboard. Trouble is, it takes a huge number of people building and maintaining projects plans, then doing data entry on a repeated basis, to generate the dashboard. It’s a huge investment of time just to make a few people feel good.
And no small part of the problem are the template-and-form crowd (which includes me, by the way). Buy a few drinks for your table at any Six Sigma conference and you’ll soon hear a litany of complaints about being forced to re-format templates so they are in the “right” font, or fit on two pages instead of three, or meet any number of other arbitrary requirements. Black Belts hate doing all this, and the people who have to provide the roll-ups hate it when Black Belts don’t do it.
So what to do about all the dilemma? Like I said above, the answer is simple: find the right balance. Design project tracking processes to be minimal in terms of the work required. Ask only for information that will inform decisions at some level. Provide a mechanism to flag problems and exceptions when they arise rather than monitoring whatever is convenient to monitor. Roll-up where you need to roll-up, but don’t assume the recipients of that rolled-up  information are incapable of understanding complicated relationships between variables and non-intuitive conclusions. In short, treat documentation like a process, strive to manage the inputs and outputs, and keep your Lean and Six Sigma hats on when you do so. Easy to say, very hard to do it right. ]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 28 May 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: QualPro vs. Six Sigma - Revisited]]></title>
			<link>http://www.sixsigmacompanies.com/archive/qualpro_vs_six_sigma_revisited.html</link>
			<description><![CDATA[The QualPro vs. Six Sigma debate is hot again.  Forrest Breyfogle has written an article on iSixSigma.com poking holes in Charles Holland’s research of 58 Six Sigma companies…. For those unfamiliar with the debate sparked by the July 2006 Fortune article and subsequent Dilbert cartoon, go ahead and read up.
Forrest isn’t the only one who has refuted Holland’s research.  Last year Kevin Meyer wrote what he thought of the research and earlier this year Ron at the Lean Six Sigma Academy threw in his two cents.
More recently Dave Silverstein, CEO of BMG joined the debate after reading an article Holland wrote for Chief Executive Magazine. Then Ron piped up again and couldn’t resist giving Holland a taste of his own medicine by saying "Look, Lowe’s uses MVT and they still saw a drop in sales and earnings...  Mark Graban from the Lean Blog called him on the whole correlation/causation issue with a comment and he publicly acknowledged his error.  
I wonder how long this fight will go on?  I do say that Chuck should have know better than to step in to the ring with an army of Black Belts...]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 28 May 2007 20:57:57 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: “AND SOME THINGS THAT SHOULD NOT HAVE BEEN FORGOTTEN, WERE LOST”. JRR Tolkien]]></title>
			<link>http://blogs.isixsigma.com/archive/and_some_things_that_should_not_have_been_forgotten_were_lost_jrr_tolkien.html</link>
			<description><![CDATA[I have recently gone through ’Train The Trainer’ for Green Belt. I discovered on the training some excellent tools I had not been using, or have just plain forgotten about.  
Over the next few Blogs I would like to talk about ’Lost Tools’ and ask why they are not being used, and the impact on not using them, both on the Improvement Project and on the business.
Lost Tools #1 ’The Project Criteria Check List’
A well conceived business case is the key to project success. But how many projects have you seen or even been given, that do not meet the criteria that was taught to us in week 1 of Black Belt training? The checklist which should be in all the Six Sigma Training material reads something like this:
•         Are the goals of the project clear and realistic at this stage?
•         Does this problem affect our ability to successfully deliver our key business objectives?
•         Does this problem stem from an on-going, high volume process?
•         Is this process measurable?
•         Is this problem creating defects?
•         Can we estimate the potential business benefits in cash?
•         Will this project lead to improvements with little or no capital?
•         Can this project be completed in 4 to 6 months?
•         Does the process owner approve and support this project?
•         Is the scope of the project clear?
If the answer is No to any of these, and you still take the project forwards, it will spell trouble, big trouble downstream. I’ve been there, most Black Belts have.
If the answer is YES to all the criteria above, I submit that all you need is a good understanding of the tools to deliver great success within the business. 
But do all your projects tick all these boxes, all the time? In the transactional world, my world, I would be surprised. 
What do we do?

We now have a deployment that needs to be fuelled with savings.
We need to justify our own existence, and we may not have any text book process improvement projects out there.
“Get in Lean! Call it a Lean project” comes the cry.
But does every proposed business case that is not a DMAIC project fall into the Lean bucket?
Proposed Solution

Strong Six Sigma leadership on quality control for potential initiatives, UP FRONT. 
Someone who is not scared to say NO to the bosses.
Someone who can decipher a good business case from a bad one.
I feel like I am stating the obvious here, but the obvious is so often overlooked.
What does your deployment do to stop ’dodgy’ business cases getting through? Do you have a different / better list of criteria to check your business cases? What other ’lost tools’ can you think of?]]></description>
			
			<author><![CDATA[J P Spencer]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 24 May 2007 08:37:24 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Next Generation]]></title>
			<link>http://blogs.isixsigma.com/archive/the_next_generation.html</link>
			<description><![CDATA[From Gauss defining the normal distribution to Galton designing his theories on correlation to Onho developing the Toyota Production system, we are proud of our rich heritage and the number &amp; variety of sources that have come together to create the Lean Six Sigma model.
So it is encouraging to see what may be an example of the next generation of methodology. I was doing a bit of research on Business Process Management and found the BPMG web site. This covered the 8 Omega framework which included:

The 8-step DADVIICI approach
Six defined roles, and the skills and responsibilities assigned to each of these roles
Four dimensions (Strategy, People, Process, Systems) of organizational alignment that must be addressed to achieve excellence
Education, training and skill building spanning the entire 8 Omega performance model

Sounds an exciting break-through innovation and I wondered if anyone had any experience in its use?
 ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 17 May 2007 06:59:58 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: VOC Gone Wild]]></title>
			<link>http://blogs.isixsigma.com/archive/voc_gone_wild.html</link>
			<description><![CDATA[It seems "Voice of the Customer" (VOC) is a label applied to almost any interaction between a business and a customer these days. Anything from direct interaction to the vaguest involvement along the periphery.  Anything from highly structured, planned, and observed interactions to informal, anecdotal, and third-hand accounts.
Some VOC is certainly useful. But more and more, my experience with VOC as it is typically gathered and used causes me concern. For one thing, I find VOC usually ignores even the most basic statistical thinking - especially special cause/common cause and notions of representative sampling. But even if we assume the best VOC methodology, there are two additional problems:

Customers usually aren’t well qualified to tell us what they want. What customer ever stood up and said they wanted an iPod? Or eBay? Or Facebook? And even when customers can accurately articulate what they want, it’ not always something that is practical or wise to deliver. For these reasons among others, direct VOC may be very useful for incremental innovation and improvement, but in my opinion it’s a unreliable path to breakthroughs.
The definition of "customer" is more difficult than it first appears. For example, are shareholders of public companies customers? Surely they are. And surely hearing their "voice" is not difficult. They vote each and every day on the markets. And we don’t have to conduct special studies to know what they want - most companies report to shareholders every quarter, and the shareholders make it instantly and extremely clear what they like and don’t like.
This second issue is especially problematic. Take airlines. Traditionally we think of the customer of an airline as the person flying. But obviously airlines don’t care too much about the voice of these "customers" - if they did, air travel would be a lot different. Every seat would be roomy and comfortable. Food and drink would be plentiful and of high quality. Airlines would do everything in their power to take off and land every flight on time, including having extra planes and crews on standby at every airport.
So why aren’t things this way? Because the actual customer being served is the shareholder, who demands that airlines do only what is necessary to be profitable and deliver results quarter by quarter. The shareholders care nothing for the voice of the flying "customers" - indeed, the average shareholder almost certainly has no idea how to run an airline or serve the flying public. In fact, given the prevalence of mutual funds, pension funds, and similar investment vehicles, it is doubtful whether most shareholders even know they own a given stock. But even so, they definitely want their stocks to rise. And despite thier mostly irrational behavior, it is these customers that make their voice know most clearly, and drive the most behavior by businesses.
The thorny part is that the actions that will make the stock rise can be very different from the ones that would make flying passengers happier. Diametrically opposite, even. Of course, the airline can’t lose market share - no one involved wants that - but if all airlines offer equally poor service and the total number of people flying still increases each year increases, then the rate at which customers come and go from any particular airline isn’t likely to matter (at least among the big players). I have virtually no knowledge of the airline industry, but I’m guessing this is the situation we’re in. And because of this, the voice of the shareholders becomes much, much more important than the voice of the flying customers, and we get the kind of airline service we have today.
As I said, I’m not an expert on airlines by any means, and anyone who is should feel free to pick apart my example. But the root cause stands, regardless of the specific example chosen: customers in general, whether shareholders or consumers, are unlikely to know anything about the business they patronize or own. And because shareholders demand only that stocks rise quarter by quarter, regardless of the good of the business in the long term, they are very likely to demand behaviors that directly injure "customers". Examine any publicly held company and you’ll be certain to find similar tension between these different groups of "customers", and neither group is particularly concerned about the long term well-being of the business. All of which means that reading too much into VOC is a very risky proposition.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 05 May 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Belts in Part Time Roles]]></title>
			<link>http://blogs.isixsigma.com/archive/belts_in_part_time_roles.html</link>
			<description><![CDATA[Most methodologies warn against the use of part time resources as project leaders. This is more so true with Blackbelts. However, the Army has a unique situation with the Army Reserves. These are true full time members who serve up to a total of 38 days per year. Couple that with the fact that most if not all are being pulled in other directions on other mission essential tasks, and their availability becomes even less so. 
We currently have 1 Blackbelt and 2 Greenbelt candidates who fit these roles. A strategy we are looking at is having those memebers/candidates report for active duty to complete the critical pieces of the project. ]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 27 Apr 2007 11:11:04 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Next Next Big Thing]]></title>
			<link>http://blogs.isixsigma.com/archive/the_next_next_big_thing.html</link>
			<description><![CDATA[Six Sigma critics are right about one of their chief complaints: the program is a re-packaging of a lot of tools and ideas that have been around for a long time. Personally I don’t think that’s a bad thing, since many of the ideas that have been re-packaged were languishing before. Regardless of where the tools and ideas originally came from, the hype of Six Sigma has driven a lot of useful activity in areas where it wasn’t happening before.
Trouble is, the same thing is happening in a lot of different areas. Six Sigma as a program has several analogs, some competing and some in areas that Six Sigma hasn’t reached yet (like software design). You could argue that each program is different, but I would counter that even if that’s true, all of them have a similar aim. You could also argue about which of them is best; indeed, a great amount of energy seems to go into this argument every day.
But back to the aim. Beyond the specific project-level objectives of each program, what they all seek to provide is a conceptual framework. They collect different tools and ideas and put them together in a way that tries to be easily comprehensible. Lean does this. Six Sigma does this. 5S does this. SMED does this. 23 other continuous improvement programs do this. All of which leads to another question: what do you do in an organization that has Lean, Six Sigma, 5S, SMED, and all 23 of those other programs?
This is not hyperbole. In more and more organizations with good programs in individual discipline, it is a real problem. Just as Six Sigma provided and organizing framework for of a lot of disparate ideas and tools, we now need something to organize the various organizing frameworks. Failure to do this results in lack of alignment and missed synergies at best, and utterly disconnected silos working in opposition at worst. And it tends to be very difficult to address, because everyone involved is already genuinely working towards continuous improvement to the best of their ability. Change management experts will tell us we need a burning platform to make change happen – that’s unlikely to be the case in this scenario.
So what to do? How do we move up the next level in the hierarchy of organization? Once the Six Sigma program is running on all cylinders, the SMED team is in a groove, and the 5S group is having wild success, how do you tie them all together without killing the individual components? The obvious answer is not to let it happen in the first place. But in organizations of any size, it has almost certainly already happened. And it happens precisely because people on the ground want to do the right thing.
I don’t have the answers yet, but I think I’m coming closer to asking the right questions.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 26 Apr 2007 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Taking the Toolkit Approach: LSS with Balanced Scorecards]]></title>
			<link>http://blogs.isixsigma.com/archive/taking_the_toolkit_approach_lss_with_balanced_scorecards.html</link>
			<description><![CDATA[In preparation for an award I am accepting for being a pioneer in the CPM (Corporate Performance Management) and BI space for the work done infusing the balanced scorecard (BSC) methodology prior to our deployment of lean six sigma (LSS) , I started thinking about how many blank faces I see when I start talking about the natural overlap between the two methodologies. 
There are those who will vehemently argue that there is no overlap, while others see the two schools of thought as having the potential to intersect but not without intervention -- Then there are those, myself included, who view LSS and BSC more holistically -- After all, aren’t they both methodologies for measuring and improving performance from either the top-down or bottoms-up vantage point? As Praveen Gupta quoted in his book Six Sigma Business Scorecard, without a strong grasp of performance metrics, a company can have no clear, quantitative indication of its quality improvements." From this standpoint, let’s dive further into where I think Praveen fell short --&amp;gt; Yes, scorecards are a great way to measure project success...But it doesn’t stop there --
Instead, if you look at LSS and BSC more holistically, there emerges this kind of "proverbial toolkit" to be situationally employed to help 1) measure and improve products or processes and quality improvement initiatives...as well as 2) BSC can effectively help a deployment leader with project prioritization and selection - In fact, it is one of the 5 pathways to selecting and stack ranking potential future projects.
The "proverbial toolkit approach" is a way to build a quality empire, one improvement initiative at a time, without tying up corporate resources or dollars - Huh? 
Think of it like this: even in a pure DMAIC organization, do all six sigma projects require the rigor that DMAIC or DMADV prescribe? Well, no...Not when you add the "L" (Lean) to "LSS" (Lean Six Sigma). With Lean, comes the concepts of Kaizen &amp; JIT (’Just In Time’), to name a few. So, should any organization who employs LSS start calling themselves a LSS with Kaizen shop? or LSS with a little bit of JIT?
Not in our eyes. Kaizen, JIT, Lean, Six Sigma all represent tools in our tool-belt; Balanced Scorecards are another tool, equal to those aforementioned in our toolkit. When a Green or Black belt is assigned a project, they shouldn’t be forced to ’pick’ a certain methodology; likewise, when a company starts planning a Six Sigma deployment, they should not force themselves to determine a % to allocate to DMAIC projects vs. Lean projects vs. Kaizens. They will end up moving the target so much to meet the needs of the business, (today, we are a 40% / 40% / 20% shop across all three methodologies; tomorrow, the business shifts slightly, and we are a 50% / 30% / 20%, etc), that they will seem like they are unsure of their program and what they are trying to accomplish . Sounds like a lot of rework to me, and if anybody should know better than to cause a lot of rework in a given process, it is the prescribers themselves, i.e. the deployment leader, MBB &amp;/or GB / BB. 
Instead, try looking at as a "Toolkit Approach" with guidelines that mirror business rules, such that they have criteria around them defining which path would most likely yield the biggest bang for the buck without causing work to be scrapped or reworked -- The following are example business rules that one can build around their process.
"If project type A is XXXX, then employ DMAIC with a black belt driving, where XXXX = 

big and hairy 
tried by others but without success 
high DPMO, large gaps between VOC and VOP caused by process variability and/or defects 
top down support and exposure 
4-6 month expected project duration 
minimum hard dollar savings of $250K 
is a red key performance indicator as measured on the executive scorecard; if it isn’t measured in the same place as the CEO or president measures their success, one should ask why they are taking it on as a black belt project; we manage what we measure, and more importantly, we measure what we manage (aka care about, to be frank)"
If you hear someone say "we need to stop the bleeding" or "quick wins", than you should move onto the next example since both are synonymous with the shorter, "get in, get out" projects ; Thus...
"If project B is YYYY, then employ Lean Principles with a Green or Black Belt driving, where YYYY = 

1 -4 month project duration 
Process is filled with waste (think 8 wastes) 
Cycle time deficiencies 
Gap between VOP and VOC caused by delivery (time) delays rather than quality (though the latter may be a driver, it isn’t the focus of Lean) 
Something than might be bottoms-up or top-down 
Something than can be driven by a green or black belt"
"If project C is ZZZZ, then employ Kaizen, where ZZZZ =

1 week project duration 
New or improved standards can be developed and implemented during the Kaizen event window (or at a minimum, submitted for approval) 
Can be used to supplement both DMAIC and Lean projects at two different phases of the project lifecycle: 


First, it can be used to help kick off a larger project from a discovery POV 
During the Improve phase, Kaizen events are extremely helpful when there are multiple work streams and processes that need to be improved (though each one should have their own Kaizen event dedicated to improving that individual process - If lumped together, you will be less effective at driving the improvements, as you wont have one process to walk, but many. 
Lastly, no matter what type of tool you utilize based on the given criteria, you should leverage the concept of BSC and strategy maps (more to come on the latter point in a separate post). Not only can it help you select your project, but it can also be used to measure and track you GB/BB project status and performance as they move through the project lifecycle. In addition, if you are the GB/BB, as you get into the Control phase or to the point of implementing Visual Controls, SPC/SPM charts, how best to do that than by building a project related dashboard/scorecard that rolls up your outputs into the strategic goals that you are working towards improving, which if done correctly, should have come to the business unit as they cascaded down from the top line senior leadership performance indicators which should only be referencing those metrics that will shape how successful the company was at meeting their annual strategic goals &amp; objectives.
Stay tuned for part 2: What is a Strategy Map in terms of Balanced Scorecards, and how can they help me elevate my Six Sigma deployment to gain true visibility at the executive level in my organization...]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 26 Apr 2007 08:07:18 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Changing the Clutch in the Paradigm Shift]]></title>
			<link>http://blogs.isixsigma.com/archive/changing_the_clutch_in_the_paradigm_shift.html</link>
			<description><![CDATA[One of the most recent moves to engage the leadership in Business Transformation is to have the Project Sponsors brief/present BB/GB projects to the Deployment Directors/Senior Leadership. The strategy is a great way to change the old thought process of "kicking the can down the road" or "maintaining the status quo" until the next bloke takes over. This now makes them responsible for ensuring we don’t create problems that blow up in someone elses face. The threat is that a backlogged issue that must be dealt with now could derail another serious issue in the future.]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 23 Apr 2007 14:00:13 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Process driven improvements]]></title>
			<link>http://blogs.isixsigma.com/archive/process_driven_improvements.html</link>
			<description><![CDATA[When you are just started to work on a new project, as Six Sigma professional you are conditioned not to jump to conclusions and let the data and facts guide you to process improvements. However, by asking yourself two simple questions at the start of such an improvement initiative, you be able to get a first idea of where to start looking for improvement ideas. 1. Is the process customer facing or not ? A customer facing process delivers its outputs to external customers (or front office if you like) Examples : call centres operations, sales and after sales service …. Non-customer facing processes deliver their output to internal customers. These are typically back-office operations like planning, dispatching, purchasing, etc … 
2. Is the process a repetitive or not ? Repetitive processes return in a time set manner. The repetition can continuous or can be separated in time. Examples of repetitive processes : the financial reporting that has to run every month (separated in time), many manufacturing-like  processes repeat continuously.
In a non-customer facing process with repetitive work you need factory-like processes. Improvements will be focussing on flow creation, reducing waste and overburden, improving ergonomics, automation and standardization of work. 
Non repetitive and non customer facing processes need the job shop approach and  require highly skilled employees, specialist in their area, supported by the required systems and organisational structures.
A non-repetitive and customer facing process requires  professional service type of processes. Improvements will focus on skill development building, first time resolution improvement,  building customer relationships, etc …
Repetitive and customer facing : mass service process. Think about services like postal offices, hospital admissions, fast food restaurant services, etc … Standardization of work and customer friendliness in all its aspects are main areas for improvements.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 23 Apr 2007 12:36:39 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Standard Work in LSS]]></title>
			<link>http://blogs.isixsigma.com/archive/standard_work_in_lss.html</link>
			<description><![CDATA[Reading Robin Barnwell's lastest post, I was reminded of a conversation I had recently regarding standard work in our own projects.  When our Black Belts share their experiences, it's really interesting to see how parts of the project structure are valued differently by each individual.  
Let me give you an example.  We have a guideline for rapid improvement (kaizen) events that says we should be doing a risk assessment of the new (future state) process on Day 4 of the 5-day event.  Some BBs are doing this and say it works fine at that point.  Other BBs say that's too late - you should do a risk assessment on Day 2 when you're creating the solution - so you can foresee problems and address them as you're creating your new standard work.  Also, the guideline says we should do an FMEA - Failure Mode Effects Analysis - but some BBs say that's too complicated for most teams when you're dealing with over 100 process steps.  One team in a past project spent almost 8 hours trying faithfully to complete the FMEA as directed, for every process step, since they thought that's what they needed to do.  So some BBs are using a simplified risk assessment form or other contingency planning tool that worked for them in a previous life.
I'd be very interested in anyone's opinion on  how far is too far, when "adapting" project methodology standards or guidelines to a particular situation.  Should a strict standard be enforced - we're supposed to be modeling standard work, after all - or would this result in such an inflexible approach that we might jeopardize the result of a particular project?  Would we be hampering the BB's ability to use his/her own judgment in a situation that calls for compromise?
I'd love to hear your thoughts on this.]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 23 Apr 2007 07:22:17 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Helpful Tips: Contact Center Related Project - Process Owner Hand-Off Meeting]]></title>
			<link>http://blogs.isixsigma.com/archive/helpful_tips_contact_center_related_project_process_owner_hand_off_meeting.html</link>
			<description><![CDATA[Successful operations planning can be a powerful cost reduction and organizational development strategy to help define resources and processes needed to sustain the project’s business outcome after control phase, especially in the contact center space. The black/green belts should not keep the responsibility for the product after delivery, nor be listed anywhere in the control plan. You need to agree ahead of time with the vendor:
a. how the new process/product will be maintained
b. who will have responsibility for maintaining it
c. how will it be enforced in the centers
Process Owner Reviews: Assuming you have already decided amongst alternative project solutions, stack ranked against market conditions, call center performance metrics, like Time to Resolve and AHT, in a prioritization matrix or QFD (my personal fave), has it been reviewed with your process owners? If not, use a QFD to rank your call center initiatives with the least impact to the day to day operations as possible.
Project Closure Approach Transparency: Once reviewed, develop an overall project closure approach for to be discussed with the vendor. In it, identify the resources and schedule for the implementation and control plan reviews - I recommend a 60/40% mix of call center to non-call center representation – Some things to consider:


Have the failure modes on outputs and vital inputs of the process been updated in the FMEA? 
Next, determine how changes to the process happen &amp; who makes them happen : 
Update the project RACI using the lens of who (roles) and what (responsibilities) will enable your implementation and control plans to be successful (for example, your process owner is certainly a candidate) -- Send assigned tasks to them for review.  &amp;lt;Decision Point&amp;gt; 
Is there a project team role gap (i.e. roles needed but not assigned/available?  
If yes, have staffing options been identified, either Contractor/vendor or FTE? 
Determine who is responsible for maintenance and ongoing report-outs – process owner may delegate to an operations excellence role or similar for ongoing support 
Has a timeline been determined for frequency of SPC/SPM measurements for your control charts; for other visual controls? 
List tasks associated with your preventative maintenance and control chart KPIs (inputs/outputs) that swing out of control, including: 

Have measurement systems been set up to capture project outputs being tracked &amp; how are they being tracked: online/offline? 
Are costs associated with post-implementation operations documented and understood in your COPQ analysis? (Black Belt note: Often a hidden cost that gets overlooked during the financial cost / benefit analysis period, though seldom passes the eye of your financial champion).
Enforcing the changes : Control plan hand-off process to your process owner including hand-off of the FMEA, implementation plan and visual control mechanisms.



Was information enough for process owners and champion to feel comfortable enough to signoff on belt project? 

Do the process owners see any existing gaps to enforcing control plan and preventative maintenance tasks associated with the newly optimized processes and practices within the centers, in-source or outsource? 
If not, has sufficient documentation been reviewed and propagated online/offline by the belts for the process owner such that the latter knows where to go when something goes out of control? (Black Belt note: We use Sharepoint to deliver the content)
Has a process been identified and provided for how change requests to the process are made, by whom and with what SLA? 

Has version control been built into the control plan, should the process need to be reverted? 

If so, was there reference to the Preventative maintenance task associated to the control plan input/output by the black belt? 
Have you identified the current preventative maintenance task owners? (Black Belt note: Often this is your process owner, but the role / persons may have changed since project hand-off). 
Have you drafted “how-to process guides” or “helpful hints” to fill knowledge gaps found to be a critical X in the control plan? (Black Belt note: in call center projects, having a document that specifies “if this call type, then do that action” is highly effective if and only if it is kept in front of agents for each of the Top call drivers (go after 80% coverage of call types; if it is cluttered with too many scenarios, they wont use it).
For your champion &amp; deployment leaders to think about: Are you capturing a project management health metric (i.e. metrics that grade the individual project or black belt)? These should be cascaded down from a program management (i.e. Six Sigma program) level set of metrics. (Black belt note: this will prevent downstream issues with the project success metrics should they not be followed by the process owners so that the belt doesn’t take full blame).
 ]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sat, 14 Apr 2007 15:21:49 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Scope/Mission Creep]]></title>
			<link>http://blogs.isixsigma.com/archive/scope_mission_creep.html</link>
			<description><![CDATA[The term "Mission Creep" with the Military can be applied to "Scope Creep" in a LSS Project. The constant tension to solve problems has to be tempered with the fact that many problems are "Elephants" that need to be eaten one bite a time. The issue of Mission/Scope Creep boils down to being able to define what is critical and what is not (CTQ). At a higher level, this may represent a Balanced Scorecard, KPI’s, etc. 
Most Army units don’t measure their outputs. However, the Army uses a material weakness report to outline and list what prevents them from accomplishing its mission. By essentially transforming this report to measurable KPI’s, the Army can begin to focus on its; critical processes and prioritze is improvement efforts. ]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 13 Apr 2007 08:12:28 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: More on Six Sigma and Data Quality]]></title>
			<link>http://blogs.isixsigma.com/archive/more_on_six_sigma_and_data_quality.html</link>
			<description><![CDATA[In two previous blogs, I wrote about intersections between Six Sigma, internal control and data quality. By way of background information, my department performs compliance functions, where we monitor information delivered by third parties and created through internal operations. 
For example, we receive property-address information and derive new information like geospatial position through "geocoding" processes. Since we monitor data for compliance, our process inputs are hundreds of data elements, and our output is systematic, timely determination of whether data quality is acceptable or needs improvement. Anyone who works in the "governance, risk and compliance" arenas will appreciate the unique challenges associated with designing and optimizing monitoring processes. Characterizing measurement error is a constant challenge. 
In a future blog, I will share our experiences with assessing measurement precision (Gage R&amp;R) and understanding stability and bias. Here I want to focus on an immediate challenge, and request insight on best practices. Our compliance monitoring is very new. We are designing processes that will move compliance to the front end of our value chain, so we measure data quality at the "point of truth" and reconcile these data to points of consumption by risk, control and compliance functions. Our focus right now is on designing, piloting and calibrating our compliance monitoring. 
Our approach is highlighted in my earlier blog on Six Sigma and data quality. We are beginning to produce expected-versus-actual defect rate observations for our critical data elements. These statistics are generating lots of interest and questions about how we define an expected defect rate (voice of customer) and determine the importance of a lower-than-expected defect rate (the focus of my writing). Two questions perenially come up: 
First, does a lower-than-expected defect rate indicate a high, medium or low level of risk? Some critical data elements are more important than others and more sensitive to variance. Second, how do we come up with a risk rating? 
We are now beginning to explore these questions. One approach would determine the financial risk associated with an unfavorable variance in data quality. Our enterprise risk management processes have not matured to the point, where a reliable methodology is available to us. A broader perspective would consider the reputational risk associated with an unfavorable variance in data quality. Other than benchmarking internal data quality against our industry, judgment prevails because methodological scoring for reputational risk is not feasible. In practice, risk assessment frameworks seem to offer broad criteria or rules of thumb, whereby we can draw conclusions about risk exposure. 
Another challenge is connecting these criteria to defect-rate observations. We are exploring alternative tools, including FMEA. Your insight about the following will be appreciated:

Are there best practices for assessing risk or cost of poor data quality? Are these best practices applicable to measurement observations?
Are there lessons to be learned from manufacturing settings (e.g., techniques to estimate risk of product liability or cost of poor quality from raw-material defect rate observations)?
How are companies using FMEA to assess process risks, based on process metrics? After all, data quality is a type of process metric.
Your comments are encouraged, or please email me at charles@charlescmckinney.com.]]></description>
			
			<author><![CDATA[Charles McKinney]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 11 Apr 2007 12:30:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: First-Call Resolution by Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/first_call_resolution_by_six_sigma.html</link>
			<description><![CDATA[Part two in a two part series on First-Call Resolution.  Read Part one, Inputs Driving Poor First-Call Resolution
Here's how to get started with a Six Sigma project:
Step 1. Define: Conduct an information-seeking drill-down with SME's (Subject Matter Experts) who are proven resources in the center. This can help determine the objective and scope of your project. Those SME's should also be a part of your project team.
Step 2. Measure: Track calls for a 30 day window in an excel spreadsheet, if you do not have a more sophisticated system. 
Step 3. Analyze: Flag repeat calls by analyzing those agent logs and any IVR system data (if you have an IVR or any other self-service tools, they should be included here). Identify whether an issue was resolved on the first call and if not, the actual reasons for repeated calls. Look at all customer interface points, because if the customer first contacted you via self-service systems, that counts as a call. 
Step 4a. Improve: Make certain you provide a measurement system of record to measure FCR from the first day forward. You need useful information to conduct further root cause analyses and provide data for your control charts. What's one ideal outcome? Could it be one where you continue to use the technology now in place - but making it work better for you or leverage new technology?
Step 4b. Improve: Perform an MSA once that measurement system is in place on IVR transactions and track where calls go once they are handled (*handled = call is answered) -- Look at calls and how the IVR is handling them. Many customers merely opt to zero out. That choice, however, isn't giving you interpretable data. Callers choose to zero out for numerous reasons, including their desire to speak with a live agent. 
One method of measurement can be a standard question agents can ask the customer at the close of a call: 
"Is there anything else I can do?" or "Is this what you wanted?"  These questions allow a crude estimate of FCR. The best way to measure FCR as part of Improve, is to add a question to your post call survey (if you have one), that asks:
"What your call successfully resolved the first time you called?
If No, follow-up that question with a series of options asking the caller why wasn't it resolved during that 1st call:
a) Agent lacked authorityb) Agent lacked knowledgec) etc…
Step 5: Build control charts around the “Done in One” concept (a.k.a. FCR) and publish, like we do, to an intranet that the agents have access to. Make sure you multi-dimensionalize it to allow agents to drill though center metrics to their individual agent FCR score.]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 11 Apr 2007 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Inputs Driving Poor First-Call Resolution]]></title>
			<link>http://blogs.isixsigma.com/archive/inputs_driving_poor_first_call_resolution.html</link>
			<description><![CDATA[Part one in a two part series on First-Call Resolution
For most contact centers, nearly one-third of inbound calls are repeat callers who weren’t satisfied the first time, and more often than not, the antiquated switches that contact centers leverage, just do not do that great of a job reporting on the true FCR (First-Call Resolution) in a given center...Why? Think of the iceberg analogy than Lean practitioners often use to explain COPQ and the hidden costs that fall below the water line. What rises above that line is easy to quantify...it is the lowest hanging fruit though highest on the berg, so to speak. 
Below the line, especially in contact centers are things like repeat callbacks, which is the opposite of FCR.  In the old call center mentality pre-six sigma for service days, FCR was a blue sky, nice to have metric, but nothing that managers held agents accountable for achieving. Instead, they opted for metrics focusing solely on time, like AHT (Average Handle time = talk time + post-call wrap up and any hold time during the call) or ASA (Average Speed of Answer = how fast you pick up the phone). 
What these metrics actually do is incite bad behavior, i.e. the kind of behavior that you do not want your agents to learn. For example, an agent can keep AHT low as well as ASA by picking up the call and immediately hanging up on the customer, something most of us have experienced should we had to have called a call center (something I would rather cut my left leg off or will spend hours online searching for rather than having to call). 
The agent AHT is an average of the daily AHT for a given time period, so naturally if they hang up, they will have a few second AHT. Mix that into the normal AHT of an agent, and suddenly, their monthly stats look the lowest of any other agent. See what I mean by ’incite bad behavior’? We like to call this ’Agent Badness’ though personally, I think it is more of a sign that the agent’s are not getting adequate coaching, but that is for another blog. 
And, AHT is influenced by multiple, equally likely root causes, so pinpointing improvements will only frustrate your black belts (I do not suggest contact center AHT projects for Green Belts ever, unless they are working on addressing a component of a larger Black Belt project). By shifting your objective to improving FCR, you will have a much easier time proving and sustaining your results, namely reduced Cost of Goods Sold and improved customer satisfaction ratings.  A focus on FCR will also reduce customer churn and improve agent morale.
First, it helps to understand the inputs that drive poor FCR performance:  

Agents frequently don’t have the authority to resolve an issue, even when the solution is obvious (EMPOWERMENT). This results in call escalations to a higher tier, with increased hold time and abandons. It also means the next callback will be an escalation call that ties up supervisor time. 
The agent may not have sufficient coaching time or ability to effectively deal with the customer call. (COACHING, NOT TRAINING, as the latter has been proven to not move the needle at all whereas the former, is very successful at driving higher FCR rates). 
Agents need to find information more easily to provide answers or actions for customers. When the information is difficult to access or unavailable, sometimes agents will guess at the answer or fail to provide an answer, both of which can lead to a callback. 
The back-end systems might not be up to the task. If the agent makes an address change, but it doesn’t propagate through the systems, then the customer will call back. 
You need clues into customer perceptions and behaviors and why the repeat calls are happening in the first place. This can help, for instance, when you discover customers are calling back trying to get a different result if their account is being suspended. 
Part two will list the steps to getting started with a Six Sigma project...]]></description>
			
			<author><![CDATA[Laura Gibbons]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 06 Apr 2007 09:28:10 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Mission Impossible]]></title>
			<link>http://blogs.isixsigma.com/archive/mission_impossible.html</link>
			<description><![CDATA[After last year’s run-in with my broadband provider, here is an equally nonsensical situation encountered with my wireless provider. It highlights another core business issue. 
My mobile phone (cell phone) broke, so I ordered a new one and it arrived the next day. Handed over the broken phone and started-up the new one. Hold on, where are the 5-years worth of telephone numbers I have accumulated! 
Emergency call to customer services, seems I should have backed-up the information onto my PC. OK, so can I have my old phone back? No, our contract states that once the phone has been taken it can’t be returned. Yes, but I need it back, its been less than an hour since it was taken, the courier will still have it. No, it is impossible, the contract states that once taken it can’t be returned. And so it went on.
Emergency call to the account management team, explained situation and asked if they could intervene. No, it is impossible the phone has gone; it will be in a skip with hundreds of others by now. The contract states that once the phone has been taken…… 
So I call the courier business, can I get my phone back? No, it is impossible our contract is with the wireless provider we are not authorised to return phones. But it must be possible? No, our contract states that…….
This called for drastic measures. I call the courier business again and ask to be put through to the local depot. I get the job number for the delivery and eventually discover the phone will be delivered back to the local depot at 9am the next morning. After a number of calls I get agreement from both head-offices that I can retrieve the phone. Drive the 20 miles next morning and physically pull the phone out of the process. Have to replace it with the new working phone as they are contracted to return a phone to be scrapped else they have to pay a £200 charge! 
Order new phone and discuss with courier (during maximum of 4 minutes allowed for in contract). Seems this situation happens all the time, never known anyone who has managed to retrieve a phone before. Has had directors begging to get their phones back but the contract states……. 
I imagine the team that designed this process with its strict polices &amp; business service levels must feel very proud. It runs like clockwork. One phone delivered one phone returned, prid pro quo. All accounted for, none lost, perfect, possibly giving an extremely high sigma metric for the Big Y. Some imaginative poka-yoke included, its impossible to return a phone, no rework, simple message to customers, everyone complies. 
It’s the unintended consequences that concern me here. The impact on the secondary process metrics and impact on the customer. I get the impression that the process is more important than the customer. 
As you all know three data points makes a clear trend, so interested to see if telco’s get a third mention here.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 03 Apr 2007 04:01:56 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Pay for Skills Project-Control Update]]></title>
			<link>http://blogs.isixsigma.com/archive/pay_for_skills_project_control_update.html</link>
			<description><![CDATA[Update on Pay for Skills
A while back I wrote about a Six Sigma project that focused on implementing a pay for skills initiative. I am happy to say the project has passed through control phase and is currently institutionalized.
Validating cross training employees created savings was a little difficult at first.   Sure, there were tons of soft savings. Employee satisfaction survey scores increased. The production schedule remained on plan more frequently than it did before. Retention increased with zero turnover in production during the six month control period. On time product shipment metrics improved.
At first I thought about using amount of overtime worked as a metric, however when the project initially went into control phase the company encountered the slow period of its yearly cyclical cycle. Differentiating a natural slowdown vs. improved efficiency driving reduced overtime would be a daunting task that may not receive buy in from all stakeholders. I ran into the same obstacle when looking at using revenue dollars per employee as a hard savings metric.
I thought using a labor efficiency metric would capture hard savings. Because of the cross training there was less dependence on key individuals who had previously known how to operate only one or two machines. Wait times for machine changeovers were significantly reduced and production time better adhered to planning with the end effect being a consistent improvement of approximately 10% in labor efficiency.  However with improvements made and cyclical capacity increasing, I now had too many people.  Plus I had to contend with the additional labor costs that resulted from adding additional salary bands for skillsets.
 You may be saying “This is a no brainer.  You have excess employees. Have a layoff to achieve hard savings.” Yet executive management had made promises to employees that there would be no lay-offs so another option was crossed off the list.
When I was just about to run out of ideas, I made a final stop to visit the sales department. I was hoping the increase in efficiency could somehow translate into better profit margins. It just so happened that sales was on the brink of postponing a quote to distribute a developmental product line to a large customer because of concerns about production capacity and time to market.
When I shared production trending data along with forecasted production capacity for the proposed delivery dates, the quote was submitted and the business was acquired. In the span of a very short time, I had gone from having too many people to saving the company the equivalent of hiring six full time employees and filling any excess capacity indefinitely.
Throughout my pay for skills journey, I learned several lessons. Transactional projects can be just as successful as technical Six Sigma projects, although hard savings may take time to document. If you make a promise to employees, you must keep it even if it impacts your savings results, otherwise you will lose all credibility and never get support on any future projects. Lastly, even though I focused my initiatives towards production, other departments outside the initial scope of the project may provide the pot of gold at the end of your Six Sigma rainbow.]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 30 Mar 2007 18:35:02 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Training Variation]]></title>
			<link>http://blogs.isixsigma.com/archive/training_variation.html</link>
			<description><![CDATA[The training and curriculum of Lean Six Sigma is the perfect example of variation in action. I have the ability to see about 4 different types of curriculum for GB’s and BB’s. In all cases, each one presents you with a almost totally different perspective of what the trainers want you to be able to do. Some are more statistically oriented, some on processes and others on tools. 
I couldn’t say which one is better or worse, but I think the organization that employs a training program needs to think about the orientation of the curriculum format. In this sense the organization can ensure their GB’s or BB’s have a effective transition from class to project. ]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 30 Mar 2007 10:10:54 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Questions about Six Sigma in outsourced functions]]></title>
			<link>http://blogs.isixsigma.com/archive/questions_about_six_sigma_in_outsourced_functions.html</link>
			<description><![CDATA[KPMG, the public accounting firm, recently published a survey of outsourcing. Nearly three out of four companies in the survey do not measure the value of their outsourcing arrangements. Yet paradoxically, KPMG concludes outsourcing is working because 89% of their survey participants plan to maintain or increase their use of outsourcing.
The survey leads me to ask a few questions:

Is satisfaction with outsourcing based on notions of comparative efficiency, or do organizations have performance metrics?
How do companies apply business process management and integrate control plans into their outsourcing arrangements? 
Not all outsourcing arrangements are created equal. Do companies use Quality Function Deployment or other techniques to (re)design their outsourced processes? 
Are any organizations using Six Sigma in an inter-enterprise fashion to improve overall performance of outsourced processes? 
Do contract terms and conditions create high barriers to leveraging Six Sigma within an outsourced process?
Any insights would be appreciated.  ]]></description>
			
			<author><![CDATA[Charles McKinney]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 24 Mar 2007 05:55:47 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Global Process? No Such Thing.]]></title>
			<link>http://blogs.isixsigma.com/archive/global_process_no_such_thing.html</link>
			<description><![CDATA[The first business process I ever put together was heavily indebted to Kevin Costner. If I build it, I figured, they will come.
And I did build it. A perfect process, polished in every detail. A global process, that everyone involved would adopt. A useful process, that would solve many disparate problems in a foul swoop. The documentation gleamed. The diagrams leapt off the page. The prose flowed like a swift mountain stream. It was a thing of beauty. Everyone was going to do everything the same way, and life would be perfect. But no one came.
In fact, my first process was a complete and utter flop. Despite being well thought out (all the right people were involved), well designed (people smarter than me worked on it), and otherwise pretty solid on paper, we ended up building a road that led precisely nowhere. Why? Because we set out to design the fabled “global process.” And it’s taken me a long time to learn why that almost never works.
The idea of global process is enchanting. Left alone, most organizations will develop several variants of even the simplest common processes. Over time, this leads to variation in output, inability to communicate between areas, and eventually a move away from the very idea of process as “a repeated set of actions.” The endpoint of this progression can be chaos, and chaos is mighty hard to manage.
Faced with this possibility, global process seems like a very good idea. The higher you go in an organization, the more fervent the desire to have everyone doing things the same way. And as the experience I described above illustrates, it’s not hard to put a team together to develop a good single process that maximizes benefit to everyone involved.
But once you have that global process in hand, a thorny questions arises. What do you do with it? A good process that exists only on paper is useless. Change management and similar methodologies can help us a lot here, but whatever the new process is and whatever methodology we use to deploy it, we have teach individuals to interact with the process. And it’s generally right around this point that global anything goes out the window.
It has to. Process lives in individuals. As any line manager can tell you, even if you have only 10 individuals to worry about, you can easily spend your entire day trying to get folks to operate a simple process in a consistent manner. You might accomplish it in a technical environment through rigorous, ongoing training and techniques like poka-yoke. But in a transactional or business process environment you wouldn’t have a prayer. Now what about 100 people? Or 10,000? Or 100,000? You get the idea. Unless you intend to hover over every one of them every moment of the day, you can toss the notion of global process out the window.
I suspect the halls of most corporations are littered with the skeletons of global processes that fell prey to this failure mode. It’s incredibly common. Teams are chartered every day to design processes that never achieve the intended result, or even see the light of day. So what do we do about it? How do we get around the paradox that even global process must necessarily be customized to the environment of every single user?
For me, the answer can be summed up in a word: robustness. The best place to start is not by asking “how can we make everybody do the same thing?”, but rather by asking “how can we accommodate the differences that we know are going to exist anyway.” Or by asking “what do we absolutely have to make consistent?” rather than “what can we make consistent?” This subtle difference in thinking can have a profound effect on the outcome of process design.
Take project tracking. Most Six Sigma programs tend towards forcing all projects into a global tracking system; everyone is asked to do it the same way, with the same templates, forms, deadlines, etc. This is a logical response to the question of “what can we make consistent?” The answer is “just about everything.” But if you scratch below the surface of this supposedly global process, you’ll either find a team of people running hard (and probably failing) to try and make everyone do everything the same way every time, or a lot of practitioners simply ignoring the global process. If you don’t see one of these things, you’ll almost certainly see the other. Which is why global process usually doesn’t exist in practice, although it’s alive an well in theory.
But what if we design our system by asking a different question: what is the smallest number of things we can get away with making consistent? The answer is usually a tiny subset of the things that we could make consistent. Maybe we need a few pieces of crucial information on each project at a particular time to feed our roll-ups. Maybe we need a consistent way to view progress towards goals. As for the rest…who cares? So what if everyone does it differently? Does it really matter if a Black Belt working on widgets in Wichita uses the same PowerPoint template as a Green Belt working on new hire provisioning in New Hampshire? Does it matter if their team meetings have the same agenda? Does it matter if they follow the same roadmap? Not to me, and I suspect not to anyone. And furthermore, the chances that I can optimize the process for every environment better than the person actually doing the work are vanishingly small.
Armed with this realization, I figured I would work towards an 80/20 rule. That is, I’d build in robustness by leaving 80% of the process local in nature, while doing my best to maintain global consistency around the remaining 20%. In other words, for every 1 thing I was prepared to insist folks do my way, I tried to leave 4 things that they could do however they wanted. This made a tremendous difference in my day-to-day activities (wow – I have time to eat lunch again!) and an even bigger difference in the reception I got. Managing change became a whole lot easier, because the magnitude of change at the individual level was minimal. But the process still looked global from above, much more than when I was trying to make every single thing consistent. It really was paradoxical. It felt like I was doing a lot less work and catalyzing a lot less change, but the outcomes were far more successful that when I had tried to make everything global.
Think of this as the YouTube approach. To get something on YouTube you need meet only a tiny number of consistent criteria. Your content needs to be video, and you need to be able to upload it via the YouTube interface. What device captures the video? Doesn’t matter. What kind of computer do you use? Doesn’t matter. How do you describe it? Doesn’t matter. When should you upload it? Doesn’t matter. I could go on, but you get the idea. The very little bit of global process that YouTube employs meshing with the massive amount of customization done by the user, which has the effect of democratizing the process as a whole. And paradoxically, this makes the process seem globally consistent, even though it’s almost entirely different for every single person. This is intelligent use of robustness in process design. And it works beautifully.
If those initial efforts taught me one thing, it was that I hadn’t gone far enough. I now tend towards a 90/10 rule, and I’m toying with a 95/5 rule. It works for YouTube, and it’s been working for me.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 23 Mar 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Measures of Success]]></title>
			<link>http://blogs.isixsigma.com/archive/measures_of_success.html</link>
			<description><![CDATA[As is well known by all, the Army exists as a non-profit organization. Our motives and measures of success are not around EPS or net profit. We measure mission accomplishment and effectiveness. Our motto is always, "make it happen" or as the cable guys says, "get ’er done."
However we do measure project success in terms of money:
Type 1- direct expenses or costs not paid or reduced
Type 2- cost avoidance
Type 3- increased capability
As a capital intensive business, I am contemplating a new measure of economic efficiency: capital intensity ratio. Because we do not show profit, the numerator-net profit is irrelevant. So I am struggling to calculate a new output measure of mission success.  I am currently evaluating the Value Measurement Methodology used by the Government in the evaluation of IT investments.]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 21 Mar 2007 06:15:06 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Need for Change]]></title>
			<link>http://blogs.isixsigma.com/archive/the_need_for_change.html</link>
			<description><![CDATA[Recently the Under Secretary for Business Transformation (DUSA-BT), "the Honorable" Mike Kirby spoke with our Command and BB/GB trainees on the need for change. He presented an hour long slide show on why we must change the way we do business. Most compelling was his analysis of the evolution of the capability of the war fighter but the waning of the administrator. In essence, a disparity has been created in how the Army conducts business and how it supports those who conduct military operations. 
Most will question the relevance of process improvement in the Army. However the Army is involved in every industry that exists in the private sector: supply chain, aviation, engineering, maintenance, accounting, IT, security, information management. 
The Military and the Private Sector have exchanged management philosophies many times. The use of Standard Operating Procedures or SOP’s came from the military. The translation of Lean Six Sigma to benefit the way the Army conducts business is further evolution of this exchange. 
The US Navy and the US Army Materiel Command have been the first in the military to utilize Lean Six Sigma. They have seen tremendous benefits in its adoption. As the largest deployment in the world, our biggest challenge will be changing mindsets and attitudes. ]]></description>
			
			<author><![CDATA[Capt. Harris]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 08 Mar 2007 10:38:27 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma and Data Quality]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_and_data_quality.html</link>
			<description><![CDATA[After spending considerable time over the last few weeks on designing a compliance process to measure the quality of information, I want to share a few observations.  Feedback about how companies are addressing data quality through Six Sigma would be most helpful.
Companies are approaching an inflection point: exploiting information is their next lever to innovate or become efficient.  Chief Executive Officers believe information technology (IT) can be a competitive differentiator. Cost savings initiatives in the information systems function are winding down because of diminishing returns. The volume of corporate data is on the rise.  Opportunities for growth and diversification may arise through how companies exploit their Information.  This depends on understanding quality of information -- starting with the basics of how to measure data for defects -- and setting a foundation to improve its reliability.
This inflection point is not lost on control, risk and compliance executives. Sarbanes Oxley increased the scope of internal controls testing, and audit fees skyrocketed. While audit costs are coming down, new data-centric threats are emerging: states' privacy legislation, consumer protections, international regulations and other corporate mandates are placing new demands on how companies collect, analyze, control and disclose information. And data quality is a challenge on multiple fronts ranging from how companies accrue liabilities to model their operational risks. Today, many companies lack a framework to measure data quality through a "mandate" lens and extrapolate a corporate data quality index.
Business process management can help. One form of business process management is a "current state assessment" to ease a department into process improvement with DMAIC or organizational transformation with Design for Six Sigma. It goes something like this: document process flows, inputs and outputs; understand voice of customer; propose metrics and collect data; and define opportunities for process improvement. In situations like this, achieving a state where executives receive useful information about process performance is often a significant achievement.
Companies can tailor business process management framework to understand data quality:

Start by understanding your important corporate mandates that depend on data quality. For a credit card company, these mandates might include financial reporting, credit risk and management reporting about trends that would signal predatory or discriminatory practices. 
For each of these mandates, document their information dependencies (i.e., the critical data elements needed to obtain information to fulfill the mandate).  Determine where data are provisioned within the company, and whether they are created by upstream business processes or obtained from customers or third parties. 
With this knowledge, determine criteria for "good" or "bad" data -- criteria for completeness, accuracy, consistency, reasonableness, and other relevant quality dimensions. Embed these criteria in query software to measure data, use your method of choice to calculate data quality, and begin spending time on root cause analysis.
A variety of formats is available to present measurement and analysis. Consider modifying statistical process control charts to track data quality. Create a simple scorecard to summarize trends by showing critical data elements on one axis, "mandates" on another axis, and data quality yield rates by mandate in cells. Feedback on other approaches, methods and presentation tools is encouraged.
Over the coming months, I look forward to expanding dialogue about applying Six Sigma to information management and data quality.]]></description>
			
			<author><![CDATA[Charles McKinney]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 08 Mar 2007 10:11:56 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: On Averages]]></title>
			<link>http://blogs.isixsigma.com/archive/on_averages.html</link>
			<description><![CDATA[(Or “On Arithmetic Means”, if you prefer.)
I hardly need mention in this forum that as a standalone descriptive statistic, the average can be a dangerous piece of information. Averages quoted in the absence of other descriptive statistics are generally insufficient at best, and downright misleading at worst. I’ll skip the lecture on the importance of variation and related topics (Wheeler already has it nailed in this book anyway), but I do want to focus on one particular aspect of averages that I find a lot of people forget. Including me.
A lot of the time, the average never occurs.
For example, the average weight of the four residents in my household is 31 pounds. No, we aren’t long lost Lilliputians – in fact, no one in the house (me, my wife, the cat, the dog, 6 fish) weighs anything close to 31 pounds. Or to paraphrase the old joke about statisticians, on average they feel like the temperature is just fine if they are sleeping with their head in the freezer and their feet in the fire.
To a statistician or Black Belt or anyone else suitably well versed on the topic, this is hardly earth-shattering news. But to some people, the fact that a statistical average isn’t synonymous with a “usual” or “typical” value within the population is surprising. And even to those of us who know better, this fact can be a slippery one to hold on to.
Mathematically, the fact that the average might never occur in a population is not hard to understand or explain. And I don’t have trouble remembering it mathematically. The mistake I tend to make is conceptual.
Suppose, for example, you are designing a project tracking process. You might be using Excel spreadsheets and creating a home-grown solution for a dozen projects, or working with a vendor to roll out something much bigger and more complex for hundreds of projects. Either way, in my experience the tendency is to design the system for a project with “average needs” and “average complexity”. The problem is that the "average project" isn’t in your portfolio – it’s an entirely hypothetical entity. Design for it, and you’ll have a solution that perfectly fits a need that doesn’t exist.
Another example is assigning pre-work before Black Belt training. Sure, we might know what the “average person” needs to do – we’ve almost certainly designed our class for the “average participant” who has an “average background”, right? But our classes don’t fill with average people. They fill with some people who know a lot and don’t need much pre-work, or with people who don’t know much and need a lot, or for people somewhere in between. Assigning the same pre-work to every person will serve none of them adequately. We’d be far better off assessing each individual and offering a range of options based on specific needs. But for whatever reason, that's almost never done. We get stuck on the "average need" and cater to it exclusively.
In both of these cases, the problem is that we use summary statistics like the average even though probably we shouldn’t be summarizing at all. If we are interested in accommodating every member of the population, what business do we have basing anything on summary statistics anyway? The entire point of many summary statistics is that they hide variation and complexity – they hide the mess, if you will. But sometimes the mess is exactly what we need to see and deal with. Which is counter-intuitive, and counter to a lot of the training we Six Sigma folks give and receive. 
(For some related thoughts on this topic, see Holly Hawkins last blog entry. Standardization is not always the answer!)]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 21 Feb 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma and Standardization]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_and_standardization.html</link>
			<description><![CDATA[While travelling on an international flight earlier this year, I was asked to fill out forms for customs. After filling out the forms I proceeded to wait in line where fellow travellers in front of me delayed processing time because of a simple data entry error on their customs card. Apparently 1/11/07 is read as a date of November 1st in some countries while interpreted as January 11th in others. I estimated this simple lost in translation issue made me wait an additional 15 minutes in line and caused rework of five to six forms.
As I continued my travel I realized additional differences. People walked and drove on the left side (and not the right). The streets were only painted with white indicators as opposed to white and yellow paint used in the US. Riding in the back seat of the taxi cab was considered inappropriate as was tipping. Familiar measurements in pounds, miles, and Fahrenheit were replaced with kilograms, kilometres, and Celsius.
The experience made me trigger a debate with my husband. Could standardization be considered a key tool in Six Sigma? I’ll admit standardization would’ve certainly helped my trip in multiple ways. Aside from the lost wait time in airport customs (due to defective forms), I encountered rework from walking (and briefly driving) the wrong way. Time was lost and I’m sure errors were made doing conversions from metric to imperial.
Standardization definitely has its benefits as a Six Sigma tool when it comes to black and white data, such as measurement systems. I remember reading a few years ago where a company has a major operation fail because a key calculation was performed in metric while all other measurements were done in imperial. The failure cost the company millions of dollars. Creating a standardized system would serve as a poke yoke tool to effectively eliminate conversion calculation errors.
Standardization could also be seen as a method to improve efficiencies in processes that have great variation. For example, during my last trip, I visited four airports- each of which had their own process for security screening. While the majority of the process was the same for each airport, subtle differences, such as when to remove shoes and show identification, often confused travellers and created delays. 
There were a few examples that I could think of where standardization could’ve been of little value in a Six Sigma application. For example, it would be hard for me to make a standardization case of where to sit in a taxi. One may be able to do a correlation analysis comparing seat location to customer satisfaction but at the end of the day where I sat in the taxi bore no black and white effect on the travelling process, nor did it create rework by me having to change seats. Aside from feeling a bit embarrassed after the ride to have learned I should’ve sat in the front, standardization would have not made a significant difference.
In summary, there are many applications where standardization can be a very positive Six Sigma aide. Standardizing measurement systems and creating standard operating procedures are two examples of initiatives that can greatly reduce defects. However standardization is not the answer to creating a poke yoke world. There will always be a debateable gray area such as the optimum location of a steering wheel in a car (left or right side) the best seat in a taxi, etc., that standardization may not improve. Tools such as voice of the customer analysis are more suitable for examples such as the ones above. However, this leads to another debate- How does Six Sigma balance voice of the customer when the customer requests variety, (the exact opposite of standardization) which could lead to variance (and defects)? 
The debate will be continued in a future blog entry.]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 19 Feb 2007 01:28:11 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What's In a Name?]]></title>
			<link>http://blogs.isixsigma.com/archive/whats_in_a_name.html</link>
			<description><![CDATA[Nayism 41:  "Six Sigma" is not for us.  We’re past all the buzz words and latest fads.
For various and sometimes unknown reasons, people shy away from Six Sigma because of the name.  In fact, Six Sigma has become so popular that it could be the hype surrounding the name that turns them off.  So how do you get past the "name-calling" and start focusing on the journey forward?  Here’s what I say . . . 
First you must acknowledge that the emotional barrier resulting from the name "Six Sigma" is real.  Trying to overcome this barrier may take more time and effort than it is worth.  So what have some companies done?  They have named their initiative something else.  By calling their approach "Continuous Process Improvement", "Business Excellence", or "Quality Quest", they have been able to overcome the initial resistance that may have been linked to the name "Six Sigma".   Some companies have gone as far as re-naming their Black Belts and Green Belts "Process Experts" or "Quality Specialists".   (If any of you are doing this, please post a comment with your initiative’s name. It might be helpful to folks who are wrestling with the same issue).
Identifying and removing barriers to success is an integral part of any successful deployment.  Don’t let "name-calling" get in the way.  After all, a rose by any other name is still a rose!]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sun, 18 Feb 2007 07:43:27 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Off The Map]]></title>
			<link>http://blogs.isixsigma.com/archive/off_the_map.html</link>
			<description><![CDATA[If you’ve read some of my previous blog entries, you’ll know I’m no fan of roadmaps. I used to think this was a radical proposition in the Six Sigma community. But more and more, when I talk to practitioners – the people on the ground who do the hands-on work of process improvement – I am finding that this opinion is perhaps not a minority view after all.
Yes, this is even true of DMAIC, the Lord’s Prayer of Six Sigma that is etched into Black Belt brains around the globe. And to be perfectly clear, I realize that in many places DMAIC is considered past its prime, having been supplanted by various Lean-Six Sigma hybrid roadmaps, or design roadmaps like IDOV and DMADV. To be fair to acronyms of all stripe, I’ll go on record and confess that it’s not any one specific roadmap I have an aversion to, it’s the use of roadmaps in general.
To be sure, roadmaps do have several advantages. They’re easy to teach. They lend themselves well to dashboard displays. They provide and easy point of reference for senior executives and other stakeholders. They make projects seem like they are progressing. And they’re a crutch, especially for beginners. But beyond this last point (which I’ll get to in a minute) I don’t think they’re especially useful for the people actually doing the work. In fact, in my experience, they lead to a lot of waste as folks “check off the box” on various tools in each stage of the roadmap as opposed to doing strictly what is necessary to advance the project. And on the flipside, they let people get away without thinking through the best approach for themselves. Think of it this way: the roadmap is an a priori answer to the question of “how should this project be done” that utterly ignores variation in circumstances. For the life of me, I can’t understand why we as a community believe it’s going to be the right answer in more than a few lucky cases.
Then again, maybe we don’t believe it. When I’ve asked around, I’ve found that projects that truly follow a roadmap are far and few between. This is puzzling, given the standard Six Sigma dogma. But it has been my experience that the vast majority of good work going on out there involved subverting whatever roadmap it’s supposed to be following. Experienced Black Belts regularly skip stages, do them out of order, repeat them, and add new ones of their own invention. Master Black Belts speak in hushed tones about projects that succeeded after a simple visual display of data showed what changes needed to be made. Green Belts sometimes find that they need to work on the measurement system again after doing some “improve” work. Gasp!
My point is that disregard for roadmaps is an open secret. Turns out my views are probably within the distribution after all. Given this is the case, what I can’t figure out is why roadmaps are still peddled so aggressively in the Six Sigma community. If every project is an exception to the process, why are we still teaching the process? Why not embrace the freedom of a non-roadmap approach?
Don’t get me wrong: I love organizing concepts for continuous improvement work, and understand the necessity of having something more than a random collection of tools. I’m especially enamored of iterative models like the scientific method and PDCA. (Even DMAIC becomes a lot more palatable to me if we admit MAI are likely to iterate along parallel paths between D and C, but that’s a pretty messy acronym.) But beyond that, I think what we ought to be doing is encouraging folks to understand data: collection, display, analysis, uses and abuses of data. We ought to be encouraging them to think for themselves what sequence of steps are necessary to get through a project, what data are required, and how those data should be collected and analyzed. And if we want folks to truly get good at this, I contend that handing them roadmaps when they start out hinders rather than helps the journey.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 01 Feb 2007 04:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Root-cause effects]]></title>
			<link>http://blogs.isixsigma.com/archive/root_cause_effects.html</link>
			<description><![CDATA[Because I’m currently reviewing the materials on cause and effect I seem to be noticing it everywhere, I wonder why? Either way finding root-causes is an essential part of my job and I have a wealth of tools available such as Ishikawa diagrams, correlation, regression models, DOE and multivariate charts. In reviewing the on-line materials I discovered the limits of my understanding here and plan to stick with this for some more time. 
But what struck me was not the ability to discover a root cause but people’s reaction to its discovery. There seem to be a range of responses and here are some examples.
“Well of course that’s the root-cause, you should have asked me”In the morning when I wake-up it gets light. After many months of careful record keeping I have discovered a perfect correlation with the appearance of the Sun. By using Occam’s razor I propose that the Sun is the root-cause! 
“By the time I’m old they’ll have a cure”Lung cancer is the leading cause of cancer death and 87% of lung cancer deaths can be attributed to tobacco use. SURGEON GENERAL'S WARNING: Smoking Causes Lung Cancer, Heart Disease, Emphysema, And May Complicate Pregnancy.
“I doubt the root cause it’s a natural phenomena”Global average near-surface atmospheric temperature rose 0.6 ± 0.2 ° in the 20th century. The prevailing scientific opinion is that "most of the warming observed over the last 50 years is attributable to human activities.” The main cause is the increased atmospheric concentration of greenhouse gases (GHGs) such as carbon dioxide (CO2).
“Its cheaper to address the rework”“I agree with the results but the real issue is .....”“You can’t measure peoples behaviour with statistics”“This report really hit the spot, I’ll let you know”
Sometimes, "We need to fix this immediately" So for all the sense of accomplishment in making the fundamental discovery, it’s just a part of the job. It also includes persuading and gaining other peoples support and driving the decision making process.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 24 Jan 2007 02:41:21 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What Does a Process Cookbook Look Like?]]></title>
			<link>http://blogs.isixsigma.com/archive/what_does_a_process_cookbook_look_like.html</link>
			<description><![CDATA[Each of our hundred of processes required a common format/look for consistency in the creation of our cookbook.
We sit down with our Knowledge Management team to discuss what our users should know about a process and we came up with this list:
Procedure Name--The identifying name of the procedure that makes a distinction between itself and other procedures
Difficulty Level--The amount of difficulty assigned to a process or procedure that is derived from the collection, calculation, and analysis of difficulty factors withint a process or procedure [We’re using: Number of steps within the process with connecting processes counting once; number of possible conflicts; and number of vocabulary words]
Author--The person or persons to whom the creation of a document is credited
Creation Date--The date in which a process was initially created
Update Date--The last date in which changes were made to a process
Updated By--The person or persons to whom the most recent updating is credited
Audience--The person, persons, or groups to which a process is intended
Stakeholders--The group of organizations, departments, and/or people that a specific process deals with in order to obtain the end result of said process
Core Processes--The main process area a process belongs to
Connecting Processes--The separate processes within a procedure
Vocabulary--All key words relevant to a process or procedure that are likely to be misunderstood or not understood by all
Knowledge Experts--The person or persons whom problems may be escalated to, if the need arises
Forms--Any forms related to a specific policy or procedure
Description--A statement or an account describing a process or procedure that serves as a brief overview of a process or procedure
Needed to Complete--The concrete objects that are required in order to successfully complete a process or procedure
Policies--Any policies--written or not, that govern a specific process or procedure
Steps--The steps in the flowchart
Business Rules--Rules describing the requirements of a process or procedure
Employee Knowledge Required--The knowledge that is required by an employee in order to complete the procedure or process
Customer Knowledge Required--The knowledge required by a customer in order for a given process or procedure to take place
Knowledge Created--The knowledge that is created through the completion of a process or procedure that did not exist before
Possible Conflicts--The possible conflicts that can occur in the process or procedure
FAQ--Those for an employee, customer or stakeholder
Orientation Materials--Any staff orientation materials connected
Exit Materials--Any staff exit materials connected
 ]]></description>
			
			<author><![CDATA[Lisa Moore]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 22 Jan 2007 07:07:24 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Reports of Our Demise]]></title>
			<link>http://blogs.isixsigma.com/archive/reports_of_our_demise.html</link>
			<description><![CDATA[Okay, okay. I know this has already been covered to death in other blogs and various discussion forums. But I am nonetheless compelled to offer my own take on the Wall Street Journal’s article concerning the departure of Home Depot CEO Robert Nardelli. And more specifically on the comments within that article suggesting that this is a substantial example of Six Sigma “not panning out as promised.”
The article prominently cites a study conducted by QualPro Inc. Before I get started, I’ll freely admit I haven’t read the study. I couldn’t find it on their website, or anywhere else online. (If anyone knows where to get it, please let me know.) So, I’ll have to rely on the words of the article’s author to describe it:

“Now QualPro Inc., a company that markets a competing process-management technique, has issued a study comparing the stock performance of companies that adopted Six Sigma with the performance of the Standard &amp; Poor’s 500-stock index. QualPro has done work for Lowe’s Cos., Home Depot’s main competitor. 
“Given that the study was issued by a Six Sigma competitor, it isn’t surprising that the comparisons aren’t flattering.”
They go on:

“A number of former GE executives -- including W. James McNerney Jr., former CEO of 3M Co.; Dave Cote, CEO of Honeywell International Inc.; and Mr. Nardelli -- helped spread the Six Sigma word but have seen their companies’ stock prices lag.
“Since announcing the adoption of Six Sigma on July 1, 2001, Home Depot shares are down 8.3% compared with a 16% rise in the S&amp;P 500 over the same period. The stock rose more than 2% yesterday on the New York Stock Exchange, to $41.07, after Mr. Nardelli’s resignation.
“Honeywell shares are down 7.2% since its Six Sigma announcement in early January 2000, compared with a 3.6% fall in the S&amp;P 500. Shares of 3M are off about 1% since late December 2003 versus the S&amp;P 500’s 29% climb. GE shares rose sharply in the 1990s, but they’re down 16% since July 2000, when the company adopted Six Sigma, compared with the 2.6% fall in the S&amp;P 500.”
First of all, I know I speak for most of us when I howl: correlation does not necessarily indicate causation. There’s enough material for several blog entries here, but I’ll restrain myself because there are more interesting things to quibble with here. For example, what to make of this?

“Of the 58 companies reviewed in the QualPro report, 52 underperformed the S&amp;P 500 index from the time they launched their Six Sigma programs through Dec. 5, 2006. Other underperformers include Lockheed Martin Corp., Ford Motor Co. and Xerox Corp.”
Yet the George group claims on their website that “our client index has tripled in value while the S&amp;P 500 has declined.” Further, on the back cover of this month’s iSixSigma magazine you can see their data indicating that “George Group clients outperform all major indices.” Presumably a large portion of those clients deployed Six Sigma. So what does it all mean? Is Six Sigma a good thing or a bad thing for stock price? George Group and QualPro both cite Xerox as an example – what are we to take from that? The point is, it’s impossible to tell. I’ve no doubt that QualPro and George Group both used accurate data analyzed correctly. And yet they report diametrically opposite conclusions. Clearly what was measured and how it was measured must be different, but none of that nuance is communicated. Again, there are several blogs’ worth of questions to ponder here.
More importantly, neither study asks the more interesting question, which is: what would the stock price of these companies have done over the period of the study if they had not deployed Six Sigma? And that’s a question that we can’t answer, because it requires an experiment that’s impossible to run. No one understands Y=f(x) for stock price (at least, no one worth less than 10 figures), so talking about single data points collected on a single x for a particular company doesn’t carry much weight. And given the massive differences company-to-company, I’m not sure aggregating 50 different companies together in a single study is any better. It just sounds better to the casual reader.
While I’m on the subject of QualPro, I found some of the statements on their website, um, interesting. For example, they say:

“Most of us were taught that the optimum process for gaining knowledge is to test one-thing-at-a-time and hold everything else constant. It is called the scientific method. MVT® (Multivariable Testing) proves that the scientific method doesn’t really work in the real world.”
I feel compelled to point out that the scientific method has been around for about 2900 years. Has QualPro suddenly discovered something that minor logicians like Aristotle, Descartes, and Gödel missed? Can QualPro seriously believe what they are saying? It’s ridiculous. In a sense they win by default, because I can’t even formulate a cogent argument to the contrary. It’s like trying to box with a swamp vapor – you can’t hit a bad smell. 
And don’t even get me started on marketing multi-variate testing as “better” than Six Sigma. What decent program doesn’t include muti-variate where appropriate? As for equating OFAT with the scientific method, I’m personally insulted by the comparison. What is it about the induction/deduction cycle that precludes testing more than one variable at a time? Nothing. The scientific method says nothing about how to go from induction to deduction. DOE or “MVT” is a great way to go. Fine, promote MVT, but why denigrate the scientific method to do it? MVT and the scientific method are perfectly compatible.
Finally, just to continue being picky, despite QualPro’s claims to the contrary you can learn about interactions via OFAT experimentation. If you don’t believe me, believe Daniel:

Factorial One-Factor-at-a-Time Experiments Cuthbert DanielThe American Statistician, Vol. 48, No. 2 (May, 1994), pp. 132-135doi:10.2307/2684266
In the end though, I guess none of this matters because:

“QualPro’s proprietary Multivariable Testing (MVT®) system uses more complex mathematics than is used in a Polaris Missile.”
Boy, I can’t think of a better reason to adopt a continuous improvement methodology than that.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 09 Jan 2007 00:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Another way of looking at things...]]></title>
			<link>http://blogs.isixsigma.com/archive/another_way_of_looking_at_things.html</link>
			<description><![CDATA[From a building in the centre of Glasgow a team continues to grow, spread and populate one of the world’s largest financial institutions. The team is ours, the mission (which we duly accepted) was to change the way things were done, to build and prepare for growth and to change an embedded culture of ‘that’s the way it’s always been’. 
Now, 2 years since inception, the comforting arms of Six Sigma change are morphing the team into a machine of financially prioritised change work which, although valid in today’s dog eat dog world, I personally have to ask the question – “how long can it last?” 
I mean, is Six Sigma change a large scale cost cutting exercise hidden under a veil of due process or is it a vehicle of full scale change in corporate culture? The question is one I, personally, believe is tending towards the former…and that is not a good thing! 
I believe the children are the future…oops, sorry wrong blog…ahem… 
I will admit, I am not a capitalist and have a tendency to show attributes that are sometimes described as idealistic or even ‘hippy’ but I know I’m not the only one that is beginning to believe that many Six Sigma deployments (for reasons of diplomacy I will not mention if our deployment is included in this statement) are missing their opportunity to change a business not from the account book but from the heads of the people contributing to the account book. 
A guy called Robert Dilts produced a model of change called the Neuro-Logical levels (based on earlier work by Gregory Bateson). This model explained how to produce the most profound change in individuals and groups of individuals. Now, the more I study this model and the more I hear about Six Sigma deployments, the fewer I realise are doing anything that is going to create the easily maintainable, long term change in an organisation that our jobs as BBs are initially created for. 
The model itself is structured as a hierarchy and I have reproduced it in its most basic format below:  
Spirituality Identity  Beliefs  Capabilities Behaviour Environment 
In summary of the model, to generate change in any given individual or group of individuals you can change their environment and it will work. For example, I know as BBs we have probably all been involved in producing trackers, posters, dashboards, team positioning etc. and it will work for a while...but eventually the old behaviours will start again because you’ve not changed them. So you can change the behaviour, change processes, remove steps, build systems and you will see the team themselves begin to change their environment to fit their new behaviours…excellent stuff, but it doesn’t change the fact if a group or individual is not capable to do a task then they will not perform. And so we can change the capabilities of a team/organisation through training and hiring new staff…I’m sure you’re getting the idea now - the higher up the hierarchy you go the longer lasting and more pervasive the change. 
Now we get into the tough stuff and where I believe the Six Sigma that I have witnessed lacks its real punch. How do we go about changing the beliefs of an organisation or even the identity of an organisation when all our targets, leadership and drive are coming from affecting the bottom line of the hierarchy – the financial environment. If we, as change professionals, want to create change in our organisations we have to start affecting the belief systems and corporate and team identities that hold our businesses back only then can we claim to be purveyors of long term change to an organisation. 
This is easier said than done. To make this type of change we need time, training, and strong leadership. We need the skills to inspire as well as manage. We cannot run a Chi-Square on a lack of belief or a confused corporate identity! I’ve got my ideas on some of the approaches we can take and I’ll stick up a post in a couple of weeks time as I’m hoping that this post may spark some debate. As a side note - if you have a way to bring Spirituality to your organisation through Six Sigma then go ahead however that may be taking it a step too far!! 
I believe Six Sigma is a great model for change. However, I also believe, if Six Sigma wants to survive, it has to evolve and I don’t know if it has the will or the want to do that. Therefore, as I said at the beginning, my questions remains ‘How long can it last?’ 
Happy New Year.]]></description>
			
			<author><![CDATA[Brian Costello]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 03 Jan 2007 02:57:16 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Mainstream]]></title>
			<link>http://blogs.isixsigma.com/archive/mainstream.html</link>
			<description><![CDATA[Middle manager of a mid-sized business with an average market share makes a New Year’s resolution, “I must improve our performance!”. Hits the Internet to discover what’s out there and is absolutely bombarded with the latest thinking and best practise in how to improve their business.
KISS…4P…5P…Burning platform…Blue Ocean…7S…PRINCE2…MBWA….Seven Habits…CMMi…Governance…Scenario Planning…Six Sigma….Innovation…Kotler…Activity Based Costing…Balanced Scorecard…Six Hats…ITIL….Results 1 - 10 of about 9,340,000
Given the number of options, it should come as no surprise that without clear executive sponsorship, managers looking for “home-grown” solutions could be reluctant to invest any time in Lean Six Sigma. There are any number of good reasons not to get involved. Gianna is currently on reason number 37 and still counting!
Even if they focussed on continuous improvement there is a lot to choose from e.g. Lean, Six Sigma, ISO, MBNQA, TRIZ, TPS, EFQM, TOC, TQM ….no, this is all too complex, not today thank you, I’ve got some fire-fighting to do!
Name a soft drink, quality automobile, or MP3-player and it brings to mind an immediate response. I think we have achieved a high degree of customer mind share. But in what categories should Lean Six Sigma hold mind share? Product Launch; Business Strategy; Performance Management, Innovation, Profit? 
Our technology is proven and the tools work. It seems a question of marketing. I’m reminded of the early works of Geoffrey Moore like Crossing the Chasm. How do you cross the chasm from being a product used by selected niches and specialist areas into a de facto business tool?

Product Adoption Curve
The move into mainstream is about making Lean Six Sigma easy to do business with. One aspect of this is standardisation. I will draw on a couple of examples from the IT industry. 


During the nineties there were a series of competing approaches to software engineering. Adoption of modelling techniques was slow as customers were not sure which methodology to back. The resolution was the creation of a single industry standard Universal Modelling Language (UML).

Again in the nineties there were a series of competing approaches to networking. Customers could base their networks on technology such as token-ring, IPX/SPX, DECNet, NetBEUI, SNA or TCP/IP. Now the industry has settled on TCP/IP.
This relentless standardisation has continued in spreadsheets, word processors, operating systems, databases, and ERP systems. Mainstream customers like a dominant player (800lb gorilla) with a second choice in case they fall-out with the gorilla.
Another aspect is simplification (I discovered there is a Six Sigma for Dummies). Mainstream customers like simple messages and easy to follow processes. What would constitute the core of Lean Six Sigma without affecting integrity? Would it be suitable for a mainstream audience?
I believe an industry designed “Sigma Lite” that is ratified by say ISO would be a step in the right direction for customer adoption. This would draw on all best practice (including ISO 9004) to produce a cut-down version for the mainstream. 
Of course every consultancy will challenge this to describe how they are better than the average. Not sure if the Six Sigma Green Belt is already the lowest level of abstraction to support continuous improvement? ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 02 Jan 2007 03:23:24 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Cookbook for Processes]]></title>
			<link>http://blogs.isixsigma.com/archive/cookbook_for_processes.html</link>
			<description><![CDATA[Our help desk decided this semester to start a project where we would create a cookbook of our processes and procedures. This cookbook would be in the form of a manual that would be in print and electronic formats and would serve as a basis for choosing Six Sigma projects and for training our staff and as a reference document.
First we categorized our help desk into seven major categories that we support: systems, operating systems, networking, security, IT services, help desk, and internal processes. Each of these categories contains from two to eight other items for a manual with 28 chapters.  Second we began collecting data from those who work closest with these processes. The data includes everything from the process in a flowchart to who are the process owners. This is still in the works. Now we’re also working on what format to put this work in. We’ve decided that our flowcharts will be put into Visio. Our cookbook will be written in LaTeX and put in PDF format for the web and printed as a paper copy too.]]></description>
			
			<author><![CDATA[Lisa Moore]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 06 Dec 2006 07:31:47 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Finish Line]]></title>
			<link>http://blogs.isixsigma.com/archive/the_finish_line.html</link>
			<description><![CDATA[I have been wrestling lately with the question of when a Six Sigma project should be considered “done”. From the perspective of the organization, it’s common to say that done means finished through the control phase or it’s equivalent, including process changes or other implemented solutions. From the financial perspective it’s tempting to say that done means solutions have been implemented, controls put in place, and savings documented for some pre-defined period of time.
But from the perspective of the Black Belt (or whomever is leading the project to begin with), these answers often don’t make sense. Rarely will the Black Belt have the knowledge, authority, or resources to implement and monitor process changes, or the bandwidth to stick around for a year to make sure that the dollars flow as expected. One could argue that perhaps the world would be a better place if Black Belts were truly accountable for these things, but in practice it is usually a process owner and/or finance rep who are responsible for ensuring that changes stick and dollars flow. And given what they are trained to do, we probably want Black Belts moving on to new projects anyway. Instead, we seem to be moving the finish line farther and farther away, and keeping Black Belts involved in more and more things.
For example, consider a classic Six Sigma project aimed at reducing scrap and increasing throughput on a high-volume manufacturing line. Any competent Black Belt ought to be able to do the basic work of defining and measuring, then using statistical techniques to sample and understand the process, and finally running the experiments necessary to arrive at a proposed solution. But if that solution involves re-training the operators, installing new measurement equipment, and reducing changeover times, then the Black Belt is probably the last person I’d want handling the implementation. Give me the process owner, a good trainer, a capital engineer, and an experienced SMED expert to do that. If that Black Belt is all of those things, fine. But in the other 99% of cases, I think a hand-off is by far the best path forward. Even if the Black Belt is accountable for these things on paper (as is often the case), in reality it seldom works out that way for successful projects.
In fact, once a Black Belt arrives at a proposed solution, I’d argue that there’s usually little “Six Sigma work” left to be done. More often that not the change to be implemented involves other tools and skill sets like SMED, Lean, kaizen blitzes, cellularization, training or re-training, capital installations, etc, etc, etc. And given that’s the case, there’s almost always a better person or group than the Black Belt to get it done. Let the Black Belt move on to another opportunity where Six Sigma skills are needed. Why train people up on one thing and then devote them to another?
One answer to this problem is to try to make Black Belts experts at, well, everything. Hence the proliferation of various hyphenated and hybrid techniques (DFLSS with an extra week for change management, anyone?). And as a result, we get what seems like a never-ending curriculum creep: 40 hours online plus five weeks in class for Black Belt isn’t uncommon anymore, and both the online and in class parts seem only to be growing.
But maybe a better answer is to move the finish line forward. Perhaps the job of a Black Belt ought to be to deliver one thing and one thing only: the knowledge necessary to make the improvement. Maybe past that point there are others who will always be better at executing.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 03 Dec 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: A Fun Exercise YOU Can Use to Aid Facilitation]]></title>
			<link>http://blogs.isixsigma.com/archive/a_fun_exercise_you_can_use_to_aid_facilitation.html</link>
			<description><![CDATA[I am trying to make Six Sigma meetings at my project in the UK fun and a little ‘different’ than the normal meetings there. 
I am gathering up fun exercises and video clips to play in between facilitation of the DMAIC tools.
I will share with you one GREAT team exercise (I got from my company) which is a team building exercise that will break down barriers in teams especially when the group have just met.
Cane Exercise
All you need is:
1.      A 2 metre bamboo cane. Get from DIY store. 
2.      6 people minimum
You get the bamboo cane and balance it just on your forefingers. (Your forefingers are under the bamboo cane).
You then state “All I want you to do as a group is lower the cane onto the floor”
With that, you lower the cane.
You then state “everybody stand up and get round the cane” In the case of 6 people; stand 3 people either side of the cane. 
Then you raise the cane to chest height and state “Now as a group, lower the cane using only your forefingers.” Each team member must have two forefingers on the cane at the same time. Only the forefingers can be used. For example NO THUMBS.
You also state, if anyone cheats you will take the cane off them and put it back to your chest height.
Outcome
No group I have tried this on can lower the cane straight off. The cane actually rises. It is then the task of the group to work out within the rules how to lower the cane. 
Purpose
One person can lower the cane easily. But, when others have their input, a simple exercise for one can for a team become impossible without planning and teamwork.
I would really appreciate sharing with fellow bloggers and readers any similar exercises or videos you have.]]></description>
			
			<author><![CDATA[J P Spencer]]></author>
			
			<category>
			<![CDATA[Buzz/Press&nbsp;,&nbsp;General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 13 Nov 2006 07:17:39 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Project Selection]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_project_selection.html</link>
			<description><![CDATA[I spent the afternoon with the North West Quality Forum (NWQF). Today's meeting took place on the Microsoft campus in Redmond, Washington, just North East of Seattle. It was my first time to Redmond, besides my house-hunting trip to the Seattle area a couple of years ago.
The NWQF is a group of Seattle-based deployment leaders that get together every other month to discuss their Six Sigma and Lean initiatives. Today's session was focused on project selection. Boeing, Washington Mutual, InfoSpace and iSixSigma presented their project selection processes. (iSixSigma presented the IDX process from the March/April 2005 issue of iSixSigma Magazine.)
Although the project selection processes varied in scope and detail, most of the presentations included the following key points:

Start with and understand your business strategy
Determine areas of the business that drive the strategy (the big Ys)
Scope potential projects in written form, quantifying the opportunity
Prioritize the list of approved projects]]></description>
			
			<author><![CDATA[Michael Cyger]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 08 Nov 2006 23:39:49 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Deployment Music, Part 2]]></title>
			<link>http://blogs.isixsigma.com/archive/deployment_music_part_2.html</link>
			<description><![CDATA[In my last blog entry, I wrote about the fugue as a model for deployment. A fugue is a  musical form in which one or two themes are repeated or imitated by successively entering voices, until eventually the entire orchestra is playing the same tune. I suggested that this might not be a bad way to deploy, especially in cases where human resources are tight but time is not.
But this won’t make sense for all organizations, just like it doesn’t make sense for all pieces of music. An alternative musical form worthy of consideration in this context is the symphony. A symphony is a relatively long musical composition with several interweaving themes. Symphonies are often  based on the sonata form, which comprises multiple movements in different forms and keys.
Symphonies are usually freer in form than fugues, and often feature different parts of the orchestra being used in different ways. Whereas in a fugue every plays practically the same tune, in a symphony different groups are depended upon to play different tunes. The composer develops and allocates separate but related musical themes according to the unique characteristics of the various sections. These tunes play off one another and combine to express more complex musical ideas. The tubas can do what tubas do best while the violas do what violas do best. Each group certainly needs to be cognizant of what others are doing, but the various groups are not doing the same things most of the time. As long as each plays their part and follows the conductor, beautiful music is made.
Mapping the symphonic form to Six Sigma deployment yields a familiar model. We start with some central themes but deploy them a differently in different areas. What we do in the supply chain can be different than what we do in manufacturing which can be different than what we do in IT which can be different…well, you get the idea. Or maybe what we do in business X can be different than what we do in business Y which is different that what we do in business Z. Not entirely different – there needs to be some degree of coordination through the composer and conductor –  but not the same either.
The point is that the program in each place doesn’t need to be the same, as long the themes and their relationships and well planned. And furthermore, we’re free to include different “movements” in our Six Sigma symphony – maybe we start out with DFSS, then move on to traditional Six Sigma, and finish up by modulating to Lean Sigma. We can do that without losing the overall structure of the program. This can work, and when it’s done well it’s a very powerful model.
The key for a symphonic deployment is that it requires excellent planning and coordination throughout. There needs to be a highly skilled composer to plan things ahead of time, and there needs to be a highly skilled conductor step up on the podium and lead all the diverse groups. Most organizations don’t have a resident Mozart who can put all the pieces in place. Most organizations don’t find and free up the resources to plan a deployment in detail well before it happens. And most organizations, especially large ones, aren’t good enough at communicating within and between silos to keep several different but related deployments playing nicely together.
In short, a lot of pieces need to be in place to succeed with this model of deployment. Organizations that have these pieces in place can and do run with this model and develop very powerful and successful programs. A few high-profile examples of this are probably why so many people gravitate towards this model. But woe to organizations that try it without having the enabling pieces in place first! Unfortunately, that’s most of us.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 24 Oct 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The 3rd kind of lie]]></title>
			<link>http://blogs.isixsigma.com/archive/the_3rd_kind_of_lie.html</link>
			<description><![CDATA[There are 3 kinds of lies: lies, big lies and … statistics.
Many news topics are based on so called statistical studies. In average … the conclusions are based on the average.In average … there is no mention of the data range or other variation metrics, like standard deviation.In average … there is no mention of sample size.
The other day I heard a great example of the above on the radio regarding the correlation of traffic jams and people working from their home office. The hypothesis attached to the story is : home working does not reduce traffic jams.Due to the difficult traffic situation, like in any other densely populated area in the world, and the opportunities offered by modern technology with virtual private networks set up over broadband internet connections, it becomes more and more popular that people work from their home office a couple of days per week.According to a study, in average ;-), people working from home use their car more often then if they would work in an office.  Compared to the latter, people that work from home use the car to go shopping and take their children to and from school, which coincides with traffic rush hours. As a result and conclusion the hypothesis is not rejected.
I don't know what bothers me most. The fact that these people need to go shopping and take their children to school, regardless the location from which they work or the undoubtedly incomplete and simplistic reflection of the study details. As usual, there was no mention of sampling strategy and size, geographical area where the sample was taken, if there was a significant difference in mileage or time people are driving (which is a different metric with higher environmental and society impact), etc …
For me, incomplete statistics really are a 3rd kind of lie, whether they are used in the news or to solve business issues.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 23 Oct 2006 22:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Defects!]]></title>
			<link>http://blogs.isixsigma.com/archive/defects.html</link>
			<description><![CDATA[When it comes to defects here is a great example I suspect other readers may have experienced. But as you will see it has made me question the Six Sigma approach. I would like to ask for guidance. It’s an example I find is happening with increasing regularity and seems to be linked to the proliferation of web-only businesses and poorly skilled call centres.
How it started: - I had a problem with my broadband connection at home. I called the provider and asked if an engineer could take a look. This was agreed and a date set.

Defect 1: - The engineer arrives, says he is a PSTN engineer, can’t help and leaves.
Defect 2: - A Broadband engineer arrives a couple of days later without any notice while I am at work. Concludes there are no problem with connection so must be my equipment.
Defect 3: - Telephone bill includes £45 engineer call out charge, which I was not informed I would incur!
Defect 4: - Call the number on telephone bill to complain. Spend 20 minutes listening to “thank you for holding, your call IS important to us” before I give-up.
Defect 5: - Call first thing next day and get through after only 10 minutes. But its the wrong department, am immediately transferred, “thank you for holding, your call IS important to us”.
Defect 6: - Call the new department and get through after only 10 minutes. But again it’s the wrong department, am transferred, “thank you for holding, your call IS important to us”.
Defect 7: - Call the new department and get told they will take 2 weeks to review the case and make contact when they have made a decision.
I lose it at this point and tried to call the CEO to complain. This has the desired affect and the £45 charge is dropped. As a customer I encountered defect after defect after defect. I felt that everything was wrong.
So lets take a look at Six Sigma.

What is Six Sigma?An approach that produces processes with 3.4 defects per million opportunities
What is a defect? A failure to meet one of the acceptance criteria of your customers
The way I have been taught is to use two methodologies, DMAIC to raise the sigma-level up to about 4 and DFSS to push onto 6. 
Now when you run a DMAIC project and are in Define, a key area is the Problem statement. I have been in meetings where we have taken hours to agree a problem statement. It should be SMART, refer to a process output, not attempt to describe the solution etc…
We know that everything is a process. So I encountered the “field engineer” and the “customer billing” processes both with defects.
So here is where I need guidance. 
I suspect I’m just the squeaky wheel so they probably wouldn’t.  But if by chance the telecom provider decided to launch a project they may start by defining the problem e.g.

We have received over 1000 complaints of customers being charged for engineering callouts in the last 3 months. 
And a few months later they would end-up with a message to the call centre to always inform staff to tell customers that they will incur a call-out charge. Great job done, problem solved. I suspect I am not giving enough credit to a potential Six Sigma team here, but it illustrates the point.
But I had loads of defects of which one may be improved. So the point I am coming too is this. If we get the problem statement wrong the whole project is liable to get a poor result. So it would seem that before we can rush into any DMAIC projects we need to do considerable ground-work to thoroughly understand our customers and the sheer variety and opportunity for defects. This could be through tools like Voice of Customer, CTQ-tree, QFD, and FMEA. Its as though there is a major stage pre-DMAIC where you invest in building the infrastructure and a clear understanding of the customer and all the issues they face in doing business with you. 
If so, this pre-DMAIC stage is not very well communicated in the training or literature. Please let me know what is wrong in my thinking. ]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Fri, 20 Oct 2006 09:07:08 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Lean Journeys - Part 2]]></title>
			<link>http://blogs.isixsigma.com/archive/lean_journeys_part_2.html</link>
			<description><![CDATA[(Continued from "Lean Journeys - Part 1")
There were two departments in the plant, and the press area served both with most of their raw material.  After about two weeks on the job, I found that my area was shutting down one assembly cell per day on average.  As you could imagine, my stress level was getting very high in a short time.  I started making daily schedules of what I wanted to run and when I wanted to run it.  I tried scheduling by piece count and by run time, but nothing I did worked.  I knew that I had considerable downtime, and my changeover times were considerable, but I was in a constant state of firefighting for weeks.
After consulting many references, I started to take a six-sigma approach to the dilemma.  What were the inputs?  Obviously changeover time was an input.  Running downtime was another....but what was the "Y" here?  I initially went with assembly stock-outs per day, since if I could keep the plant running, I could buy time to make the press area more efficient.
First, I had to figure out what my average customer demand was (takt time), and weather the demand was leveled.  Leveling of demand is very important, since this makes the production signals of a pull system stable and predictable.  As it turned out, my highest demand product was shipped as an assembly in one week quantities to Europe by boat with a two-week lead time....not good, but I considered it system noise since there was no way to immediately control that factor.  Luckily, the weekly demand for the product was stable.
As it turned out, taking a hard look at the operations, I found both good news and bad news.
The good news:
I had more capacity than I thought…on average I could run more pieces than my demand required.
The bad news: 1) My changeover times were astronomical.2) My unplanned downtime was also too high.
What was happening was that the min-max levels for the pull systems were so low, that the average press was almost spending more time changing over than actually running parts!  This was causing sheer chaos in the operation.
The improvement plan consisted of:
1) Re-setting min-max levels to reflect operations characteristics (aka “Take the initial hit”).2) Improve changeover times/reduce unplanned downtime using conventional problem solving.3) Lower min-max levels to the improved operations characteristics.4) Repeat the problem-solving process.
My next blog will discuss the before and after results of the activity, and will also discuss some of the conventional stumbling blocks for “going lean”. 
Please take a look at the following as they are really excellent references:
Kaizen for Quick Changeover: Going Beyond Smed by Kenichi Sekine, Keisuke Arai, and Bruce Talbot
Factory Physics Second Edition by Wallace Hopp and Mark Spearman]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 17 Oct 2006 17:58:18 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Transactional Kaizen]]></title>
			<link>http://blogs.isixsigma.com/archive/transactional_kaizen.html</link>
			<description><![CDATA[According to Wikipedia, the internet encyclopedia, Kaizen http://en.wikipedia.org/wiki/Kaizen is : “Japanese for "change for the better" or "improvement", the English translation is "continuous improvement” or "continual improvement." The goals of Kaizen include the elimination of waste (defined as "activities that add cost but do not add value"), just-in-time delivery, production load leveling of amount and types, standardized work, paced moving lines, right-sized equipment, etc.”
The above implies that Kaizen would only be applicable in a factory-like production environment. Too bad for all of you in service and transactional activities! 
But, Wikipedia continues “A closer definition of the Japanese usage of Kaizen is "to take it apart and put back together in a better way." What is taken apart is usually a process, system, product, or service.” This is interesting as it opens the door for trying it in service, transactional and/or IT driven environments also. 
And finally Wikipedia states “The only way to truly understand the intent, meaning, and power of kaizen is through direct participation, many, many times.”In other words, don’t hesitate if you want to experience the true power of a Kaizen event, just go out and do it, as I have done a couple of times just recently. It delivered us great results and learnings in just a couple of days.
Transactional Kaizen are focused, well scoped, time limited (a couple of days max), business improvement initiatives. The mere fact that one is focusing on 1 subject eliminates mental change-over time. This results in high participant motivation and satisfaction and most importantly, faster, better results then the traditional weekly 1-hour problem solving meetings that tend to go on for ever and ever as scope creeps away over time.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Tue, 17 Oct 2006 07:58:38 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Who’s doing who the favour?]]></title>
			<link>http://blogs.isixsigma.com/archive/whos_doing_who_the_favour.html</link>
			<description><![CDATA[When you help your neighbour to paint his fence, is he doing you the favour? NO
When you lend your friend 50 dollars, is he doing you the favour? NO
When you help a colleague fix his process, is he doing you the favour? NO

 
Make sure your colleagues understand this. If they think they are doing you a favour, you’re starting off on the wrong foot straight away.
OK, I know we get paid to do this, but I don’t know about you, but I can work with numerous departments on numerous ‘problems’. That’s one of the good things about being a Black Belt.
A new colleague spoke to me the other day saying “if you really want, I have a problem in my department that you can fix”. 
This attitude is wrong. It might not be his fault. The last Black Belt probably went round with his begging bowl asking “please let me help you, ohhhh please….” 
How do we change this attitude?
1. Get a good project pipeline flowing.
The more projects you have, the easier it is to ditch the project team with the wrong attitude. Sounds harsh, but a team with poor motivation is slowing you down, wasting your time and wasting the company money. A BB with a large pipeline, I argue, transmits an air of confidence. The BB has the attitude; I’m here to help if you want my help.
2. ‘Create a Burning Platform’ Kotter J ‘Leading Change’ 
Make sure you communicate the problem statement especially in terms of cash to the right people. People will soon shift once they know (or more importantly the bosses know) the gravity of the situation.
3. Create short term goals / milestones and 4. Communicate your success.
Keep your Six Sigma projects short and sweet. Projects that drag on for six months need to be carved up into key milestones to keep motivation at a maximum
5. Celebrate Success;
with plenty of beer, champagne, donuts or whatever your Six Sigma team deem to be a celebration. Remember, celebration is subjective to the individual.
I would be very interested in how you have established a culture of ‘pull’ (Colleagues at work coming to you for help) in your Six Sigma deployment.]]></description>
			
			<author><![CDATA[J P Spencer]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 16 Oct 2006 02:17:59 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Pay for Skills]]></title>
			<link>http://blogs.isixsigma.com/archive/pay_for_skills.html</link>
			<description><![CDATA[Implementing -Pay for Skills
I recently led an initiative to implement a pay for performance structure within my employer’s Production department. While management unanimously believed the idea was excellent, I was challenged as to whether or not this constituted a Six Sigma project.  “I though Six Sigma was about reducing costs. This project looks like it will increase our labor costs so it can’t be related to Six Sigma,” was the response I received from one manager. “But wait- are the costs to cross train a department less than the costs to recruit, hire, and train a new employee to perform a specific task?” asked the Human Resources manager. The challenge had started.
Establishing a cross training or pay for skills program has a lot of soft and hard benefits- improved employee satisfaction, better job coverage, greater employee retention through a more rewarding career with more opportunity for advancement,  reduced scrap and reduced down time to name a few. However, there are additional training costs that must be incurred. Do those costs and benefits outweigh new hire costs?  How can this be sold as a Six Sigma project? Listed below is my approach thus far:
DefineIn the define phase I stated some problems that production had over the prior year due to a lack of employees trained on certain machines and certain products. When unplanned absences or fully absorbed production capacity occurred the plant saw machine downtime, missed orders, and scrap product attributed to operator error.  I was able to put a dollar amount to occurrences and make a compelling case that by implementing a pay for skills program these occurrences would decrease in the future and any additional labor costs would be negated by improved quality. 
MeasureThere was a lot of data involved with this project. I looked at employee attendance records for the prior year, scrap rates, equipment downtimes (and root causes), missed orders and production schedules attributed to capacity causes, and customer returns attributed to human product quality.  AnalyzeI used several different tools. When looking at equipment downtimes, I did a Pareto by machine downtime as a % of overall run time and looked for the top machines that were down and then did a root cause Pareto for each machine. I used a regression analysis to determine what impact attendance had on missed production schedules and order shipments, given most employees were trained on very few tasks without backup coverage. 
ImproveBased on product and machine usage data, I worked with Human Resources to establish two job classifications in the fabrication department and three classifications in the electronics/assembly departments. The classifications were based on difficulty of machines, complexity of product, administrative responsibilities such as order paperwork, and safety risk. The headcount in each classification was determined by estimated product or machine capacity with a normal distribution graph of capacity used.  Formal work instructions were created for each piece of machinery and each mass produced item and training was conducted. Additionally employees were given copies of their new job descriptions and understand their responsibilities in their new cross functional work environments. 
ControlSince the pay for skills initiative was only recently implemented I am currently in the control phase. Tune in to a future blog entry to see my progress.]]></description>
			
			<author><![CDATA[Holly Hawkins]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 12 Oct 2006 11:04:52 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Data Collection in the Factory]]></title>
			<link>http://blogs.isixsigma.com/archive/data_collection_in_the_factory.html</link>
			<description><![CDATA[One of the toughest challenges that a manufacturing black-belt faces is institutionalizing data collection systems that yield project-critical information.  Whether the needed data is attribute or variable, it is still a tough challenge to implement the system.  Once the GR&amp;R issues are resolved, it doesn’t get any easier.  At this point, the black-belt has to “make it happen” on the floor.  Many of us have been there, standing on the line for hours training the personnel on the proper measurement procedures required. 
If you are an integrated black-belt, you have even less time to dedicate to the system implementation, yet the need for the system still exists.  I’ve found that in this case, it helps to obtain maximum leverage from resources at your disposal.
Some of the best sources of leverage are the front-line data collectors.  These people are typically team leaders or production team members that actually make the products on the shop floor.  They have a wealth of practical knowledge of the production process, and are, in most cases, willing to help improve the process in any way possible.  However, I’ve seen cases where data collection sheets are pushed onto the data collectors, without any input from them, without giving them any insight as to where the data is going, or how it will be used.  Naturally, the response from the data collector is less than enthusiastic, and since the system depends heavily on him/her, the system is likely to fail.
Here are some ways that I’ve found to leverage these very important team members to ensure data collection success:
1) Involve the people that build the product at the very start of your implementation.  In this way, they are involved and realize why the need for the data is important.  Remember, physically taking the data can be more of a burden to them, so it is absolutely important that they realize how important it really is.
2) Give the team members a chance to make the data collection system successful before going to their supervisor.  It may be very tempting when activities seem to stall to go to the supervisor for support.  Support the team members, and they will support you in most cases.  Of course, there will be cases where you will need supervision to help.
3) Let the team member collecting the data be a part of the data “report-out”.  Eventually, the data has to be reported on or used in an analysis.  Giving the team member the opportunity to see how it is used and analyzed is a learning opportunity for him/her, and will also give a feeling of being a part of the business. 
I’d really like to hear how your organizations’ have handled data collection at the front-line.  I look forward to hearing about your experiences.]]></description>
			
			<author><![CDATA[Kosta Chingas]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 10 Oct 2006 23:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Deployment Music, Part 1]]></title>
			<link>http://blogs.isixsigma.com/archive/deployment_music_part_1.html</link>
			<description><![CDATA[One of my favorite pieces of music is Benjamin Britten’s “The Young Person’s Guide to the Orchestra.” In it, Britten decomposes then reconstitutes a fugal work for orchestra based on a much older tune by Henry Purcell. The work is somewhat unusual in that at Britten’s request, a friend wrote narration that describes textually exactly what Britten was doing musically throughout the piece. Listening to a performance thus becomes not just pleasing, but also explicitly educational. You can learn more about this piece of music here, and elsewhere on the Internet.
Now don’t worry – I’m well aware that the business-as-a-symphony, leader-as-a-conductor, team-as-an-orchestra, and related similes are hackneyed and tired. In fact, as metaphors and allegorioes, they have been done to death. But in Britten’s work in particular there is something new that caught my ear relating specifically to Six Sigma deployment.
As the narration for “The Young Person’s Guide to the Orchestra” explains, each section of the large musical ensemble is approached separately at first, and asked to play a simple tune in their own way. The narration continues:

"After the whole orchestra has been taken in pieces, it is reassembled using an original fugue which starts with the piccolo, followed in by all the woodwinds, strings, brass and percussion in turn. Once everyone has entered, the brass are re-introduced with Purcell’s original melody while the remainder continue the fugue theme until the piece finally comes to an end after building up to a fortississimo finish."
To fill in some context, the dictionary defines a “fugue” as “a musical composition in which one or two themes are repeated or imitated by successively entering voices and contrapuntally developed in a continuous interweaving of the voice parts.” The term “contrapuntally” refers to the technique of counterpoint, which is defined as “one or more independent melodies added above or below a given melody” or “the combination of two or more independent melodies into a single harmonic texture.”
So, putting all that together, the fugue form involves approaching distinct subgroups within the larger organization and giving them a basic template to follow in their own way. Each embellishes and innovates as necessary according to their unique character, while still staying true to the template. This is done throughout the organization to develop and flesh out the basic framework in each place. Once this is done, some of the subgroups come together and repeat the exercise in larger groups. Finally, all groups play their individual variations as one, uniting to form the cohesive whole. The finale is beautiful and powerful, far more than the sum of its individual parts.
The preceding paragraph could, of course, also be describing one way of deploying Six Sigma (or any other program) in a large organization. You don’t even have to change any of the words to make the description fit. Any company big enough to have distinct silos, functions, units, regions, or other identifiable groups could deploy in this manner. It’s not hard to imagine (or find examples of ) deployments where a simple program is rolled out repetitively, with the same thing happening many, many times for various groups within the whole. The nice thing about such a modular or "fugal" approach is that it can go as fast or as slow as necessary – indeed, a very large deployment can literally be done by one person given enough time – and provides tight control over how much of the organization is involved at any time. Of course, if you need to get the whole company on board fast, this might not be the way to go.
Regardless, we have something to learn from Britten about Six Sigma deployment. And if the “organizational fugue” is an easy and apt metaphor and can teach us something about deployment, why not the “organizational symphony” or the “organizational tone poem”? Stay tuned for more on those ideas, and in the meantime, track down and check out a recording of “The Young Person’s Guide to the Orchestra”.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 10 Oct 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Waitlisted!]]></title>
			<link>http://blogs.isixsigma.com/archive/waitlisted.html</link>
			<description><![CDATA[Consider you require a service in August and get feedback that you are waitlisted 6th (with 5 requests before yours) due to lack off resources. The outlook is that somewhere in September you’ll be helped. You decide to live with this answer and patiently wait. The remainder of August and September pass by and off course…nothing happens! No communication, no delivery of the requested service, nothing….
At the beginning of October you pick up the phone and after 3 transfers to people that might know, you inquire politely about the status of your request. You find out you are still waitlisted and in 6th position. You get an unsatisfactory explanation why the situation is what it is.
Then you decide to change tactics and express your customer dissatisfaction and frustration. You might even ask for the manager….All of a sudden, you are no longer waitlisted, the service you required since August is available next week, because resources are available in another part of the supplying organisation.
What does this story teach us? 
1. This organisation would definitely benefit from a business process improvement program to sort out their business. 2. A kind, patient and polite customer seems not to be heard. The only VOC seems to be the loud and frustrated VOC in far too many cases.
I’m sure many more learnings can be deducted from this non-fiction story. Feel free to comment. ]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 04 Oct 2006 08:46:41 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What makes a satisfied customer?]]></title>
			<link>http://blogs.isixsigma.com/archive/what_makes_a_satisfied_customer.html</link>
			<description><![CDATA[Here is further article on the use of IT in six sigma projects.  
We are all familiar with using analytical tools such as DOE, regression, and control charts for inferential statistics to model and predict behaviour. One IT tool I have recently had the benefit of using being decision trees. Let me explain.
Take for example a mock-up satisfaction survey with a range of questions spanning relationship management, strategic fit, product quality, and after-sales service. Customers rate their expectation and your performance against each question. The final question of the survey being, what is your overall level of satisfaction? 
When it comes to analysis it is normal to develop descriptive statistics such as magic-quadrants and spider-diagrams. 



What if we asked the question, what makes a satisfied customer? Here we can use a decision tree to discover the answer. Imagine the conventional equation Y=f(x) where Y is the overall satisfaction and x the various survey questions. A decision tree will firstly, similar to regression, identify the statistical significance of each question.

In this mock-up strategic fit and after sales are significant to overall satisfaction. However product quality and relationship management show no impact on overall satisfaction. When we ran a real survey we found this type of result counterintuitive until you think about this from a Kano analysis standpoint. It doesn’t matter how good the offering is for these questions, the customer considers them must be factors not delight factors. For example a web site may be available 24x7 but a customer expects this, it wont get you an excellent satisfaction rating.
For this mock-up I have used just 4 questions. It is not unusual in this type of survey to have over 20 questions so having an IT tool immediately identify the significant questions is useful. So lets see the decision tree for Strategic Fit.

The root node shows the distribution of overall satisfaction scores and the child nodes show how Strategic Fit splits. This spilt can be described as English rules such as:

If Strategic Fit is Poor there is a 100 percent chance that Overall Satisfaction will be Poor.
If Strategic Fit is Acceptable there is a 95 percent chance that Overall Satisfaction will be Acceptable and a 5 percent chance that Overall Satisfaction will be Poor.
If Strategic Fit is Excellent there is a 3 percent chance that Overall Satisfaction will be Acceptable and a 97 percent chance that Overall Satisfaction will be Excellent.
So from decision trees we can identify the statistically significant factors that may affect customer satisfaction and the scores we need to obtain to impact the satisfaction level. We can even predict a customer’s satisfaction level by reviewing the answers to a vital few questions.
The decision tree software came from Angoss Software Corporation if you would like to take a look.]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 19 Sep 2006 14:14:59 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Good Process, Bad Process]]></title>
			<link>http://blogs.isixsigma.com/archive/good_process_bad_process.html</link>
			<description><![CDATA[I was in New York City on a busy summer weekend not too long ago. Me and a whole lot of other tourists. In fact, it was the busiest I have ever seen the city in terms of tourists.
Saturday night found me and my companions at one end of Times Square, fighting the crowds to enjoy one of my favorite treats: a smoothie. Sunday night was the same, except that we were at the other end of Times Square fighting the crowds to enjoy another one of my favorite treats: ice cream. You’d think the two experiences would have been similar, but in fact they couldn’t have been more different.
First, a little background. For those unlucky folks who have never had a smoothie, they’re a blended mix of roughly 5-6 fresh ingredients like yogurt, sherbet, fruit of various types, juice, ice, etc. Each ingredient type can be customized according to what the customer wants; one order might mix bananas, strawberries, vanilla yogurt, orange sherbet, and ice, while the next might have blueberries, raspberries, oranges, grape juice, plain yogurt, and ice. On top of that, various additives are available, supposedly for extra fiber, extra energy, extra protein, etc. The ingredients are all combined and then blended before being poured into a cup and presented to the customer.
On the surface, the particular ice cream process I experienced was very much the same. Customers select a base ice cream which is then combined 3-4 additives like fruit, chocolate, nuts, various syrups, whipped cream, etc. These ingredients are all mixed and then transferred to a cup or cone and presented to the customer.
In both cases I very much enjoyed the taste of what I got, and in both cases the total price was in the region of $5. But that’s where the similarities ended. My experience as a customer was sharply different.
When I ordered the smoothie, I entered the building and had to wait about 20s to reach a cashier. The cashier asked me my name, and then took my order, which took another 20s. The physical layout then guided me to a small waiting area where additional products and other information were displayed alongside large windows and other diversions. Meanwhile, my custom order was electronically transmitted to a second worker who put the ingredients in a blender cup. This was fast and easy because all the scoops were sized to deliver single portions of solids, while liquids were automatically dispensed in the correct proportion according to the information the cashier had entered. Approximately 120s later, another worker finished blending the smoothie, poured it into a cup, and called me to the counter by name to deliver it. The place was crowded, but the process was designed to handle it and get folks through quickly. They were serving a new customer every 30s or so with almost no lineups. Another entire cell remained empty and un-manned; presumably to accommodate periods of peak demand. Fantastic.
By contrast, ordering the ice cream was nightmare. We had to line up outside just to join the line up inside. No less than three workers were dedicated to managing the flow of people from the outside line to the inside line – and even then, we watched frustrated as several people simply skipped ahead of us to the inside line. Total time in the outside line was about 15min. As we got inside, it became apparent that the physical layout of the store was incredibly bad from flow standpoint. A single, large station took up so much space that the folks who had received their order had to wedge past those still waiting to get out. Menus on the wall were unreadable from a few feet away, necessitating long conversations once the first cashier was reached. That was difficult, because of very loud music and, bizarrely, singing by the staff that seemed to be mandated every couple of minutes. Worse, the cashiers didn’t know the menu at all – ours argued with us about an item that she didn’t believe was on the menu. (We checked, it was.) Total time in the inner lineup was approximately 30min. Once we actually placed our order, a bizarre dance of inefficiency began. The person making the order was apparently supposed to keep in her head the details of four custom orders. She failed at each, having to ask information to be repeated four times. Again, this was very difficult due to the music and singing, to the point where we left with incorrect products because we gave up. She had to run to several different places for the ingredients, causing more than one physical collision with others doing the same. Labels and scoops were unusable in some cases and absent in others. She apologized that at least one of the things we had ordered “tasted really bad.” When it came time to actually pay (why didn’t we pay the first cashier?), we faced a new person who had no idea what we had ordered. So, we had to explain it again…sixth time in the process…did I mention the loud music and singing? The whole experience took just under and hour. The place was crowded but they were only serving a new customer every 5-7 minute. And if those other customers were anything like me, they left not only vowing that they would never come back, but also determined to warn others to avoid the place at all costs as a public service. It was awful.
The smoothie process was, in my opinion, a thing of beauty. They had obviously borrowed heavily from a certain well-known coffee chain, more than one fast-food chain, and probably some others. And they had innovated where necessary. In short, they had done their homework and thought about it. The beautiful details were too numerous to mention…the consistent way they unwrapped the straws without touching anything but the wrapper…the physical flow of material…it all brought a tear to my eye.
The ice cream process made me cry for different reasons. And what bothered me the most about the experience was that so many potential improvements were obvious and easy. It wouldn’t take a process improvement expert to make things much better, it wouldn’t even take money, it would just take someone with some interest, initiative, and a three digit IQ. With a small budget and little bit of knowledge, I bet even the greenest process improvement effort could turn the customer experience around 180 degrees and cut the time down by 80% in a month. The work wouldn’t be hard. Indeed, if they walked a few blocks across Times Square they could learn everything they need to know for free from the smoothie folks.
My question is this: why don’t they do it? Why is the horrid process allowed to persist? The improvements are so easy, so obvious, and so within-reach. The best practices are so well-reported and well-known. Sure, it would take a bit of work and dedication to make the changes, but if they can hire three people to manage two lines, surely they can afford one to get rid of the need for  two lines in the first place. Why, oh why, does the bad process continue to exist?]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 15 Sep 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Let Them Eat Cake]]></title>
			<link>http://blogs.isixsigma.com/archive/let_them_eat_cake.html</link>
			<description><![CDATA[Our organization has just come through a phase that I've heard called "The Wave III Bump" by other institutions - the projects are all successful, but they just take so darn long, isn't there any way we can speed things up?  Our organization responded by moving to Lean in a big way; we've done Rapid Improvement Events (kaizen events by any other name) for many months now, and never got to a "Wave IV" for DMAIC projects.
But the pendulum is swinging back - we are finding that "just lean" is not the complete answer for our healthcare system either.  The part where you take only 5 measurements of a process never sat easily for our DMAIC-trained Black Belts who were looking at 24/7 departments where the process changes every shift.  And the lack of a control phase bothered us too, so we added it on after our RIE Report-Out on the last day of the event.  Our control phase lasts at least one month, with weekly report-outs by the Process Owner.
Now we find ourselves working out an amalgam of the DMAIC structure and Lean improvement tools.  OK, there are a lot of books out there called "Lean Six Sigma" but they spend most of their time telling you how wonderful it is without telling you how to structure your project to incorporate both philosophies.  A common presentation is to give all the DMAIC info then add a chapter on Lean tools.  That's not what we're aiming for; it feels like building a torte - a layer of this, then a layer of that.
I've been recently appointed lead BB for our educational process - for Black Belts, Green Belts, and system leaders - assisted in a big way by a subgroup of our Black Belts who are interested in spreading the word.  It's been challenging and fun to actually try to piece these concepts together seamlessly.  We want cheesecake, not a many-layered torte!  So far, what we've come up with is DMALC - Define (Plan), Measure (VSM), Analyze (Waste Walk), Lean (Improve), Control (Follow-up).  We're trying to keep the structure and the speed - eating your cake and having it too, so to speak!
Has anyone else worked on a seamless version of Lean Six Sigma?  I'd love to hear about it.]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 01 Sep 2006 12:34:28 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Peter Abilla to Interview Mary Poppendieck]]></title>
			<link>http://www.sixsigmacompanies.com/archive/peter_abilla_to_interview_mary_poppendieck.html</link>
			<description><![CDATA[Peter Abilla is conducting an interview with Mary Poppendieck, a thought leader in the Agile/Lean for software development space, over at his blog.  Pete has invited all interested to submit their own questions to Mary via the comments section of his post, Interview with Mary Poppendieck.
This is your chance to ask a guru your questions about Lean as it is applied to software development--and get guru answers.  Don’t miss the opportunity.
UPDATE: The interview has been posted. ]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 25 Aug 2006 08:35:12 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What is your destiny?]]></title>
			<link>http://blogs.isixsigma.com/archive/what_is_your_destiny.html</link>
			<description><![CDATA[In my last blog I asked readers to comment on the core reasons for project failure. Well having waded through the flood of 10 responses (thank you all) here is what you said. Projects were split 50:50 between manufacturing and transactional with improving satisfaction levels and reducing costs the main objectives. But what I was principally after were the reasons for project failure. These I have classified into three groups. 
The first two reasons were project issues (scope, time-frame, resources) and external events. But the main reason offered for project failure was buy-in from your management and colleagues. I was left thinking, “this is not enough”, I was looking for a root-cause. Why did they no have management buy-in? Could it be poor communications, lack of alignment to strategic objectives, insufficient benefits, manager moving job?
I was reminded of a story from one of the Star Trek films, can’t remember which one. When Captain Kirk was in star academy training there was a practical exercise all students had to do. The exercise was designed so you always failed no matter what strategy you applied. So when it was Captain Kirk’s turn he flew his spaceship hundreds of parsecs in the opposite direction and so completely avoided the exercise and certain failure. Could the same be applied? Could you predict project failure in the first place? Well possibly.
I researched the Internet only to produce no clear answer. It was my MBB who hit the spot with an article from the Harvard Business Review. A recent study of a few hundred change projects had identified the key dimensions that describe project success &amp; failure. The dimensions being:

D - Duration between formal project reviews (toll-gates?)
I - Integrity and skills of the project team
C1 - Commitment and support of senior management
C2 - Commitment and support of people affected in the process
E - Effort required beyond the normal day-to-day work
Score your project from 1 (Best) to 4 (Worst) in each dimension and use the formulae:
DICE Score = D + 2 * I + 2 * C1 + C2 + E
A score between 7 and 14 means you are likely to succeed, anything over 14 should ring the alarm bells. The original research came out of Boston Consulting Group. So if past experience can be used as a predictor for future performance it may be worth a look. I have started to score my project initiatives to see if it works. 
Still no nearer the true underlying root-causes for lack of commitment and support. Good luck with all your projects!]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 24 Aug 2006 08:08:21 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: DBR &amp; Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/dbr_amp_six_sigma.html</link>
			<description><![CDATA[Having worked a couple of projects combining Lean, Six Sigma, and Theory of Constraints over the past year or so, I've often been asked how these methodologies work together. This is still a point of great debate amongst the hardliners but generally I find most practitioners are open to learning and applying tools that improve business performance, regardless of the packaging.
One of the things I've found most useful is to use the systems perspective promoted by TOC experts to evaluate overall performance and identify where to work and then use Lean or Six Sigma tools to improve speed or reduce variation. Though my TOC experience is limited to a few projects over the past year or so, this approach seems to be working well.
My wife, who just completed her MBB certification (congratulations!), stumbled upon a great graphical explanation of the relationship between Drum-Buffer-Rope (TOC production scheduling) and variation. Take a look and see what you think.
http://www.agilemanagement.net/Articles/Weblog/VarianceandDrum-Buffer-Ro.html
More on this later, Michael]]></description>
			
			<author><![CDATA[W. Michael McBride]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Tue, 22 Aug 2006 13:46:46 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Anti-Hawthorne Effect]]></title>
			<link>http://blogs.isixsigma.com/archive/the_anti_hawthorne_effect.html</link>
			<description><![CDATA[I recently participated in a great discussion with a group of Black Belts in my SSBB exam review class.  We were talking about the importance of "walking the process" to understand it.  Several BBs had the experience of managers trying to create a process map in a back room somewhere - these managers swore that their map represented reality, until they actually were forced to go out onto the "shop floor" (however that translates to a particular environment) and had their "aha" moment.
One of the things we discussed was the so-called "Hawthorne" effect, which is generally used these days to describe the way workers will do their best, or the expected, while being observed for time studies.  This abnormal performance may skew observational data when only a few workers are being observed over a short period of time.
However, one of the BBs pointed out that they had seen the reverse - workers slowing down or doing things inefficiently while they were being watched.  Why would that happen?
It turns out that it hinged on the workers' perceptions of why they were being watched.  If they felt that their own performance was being rated, they tended to do their best to appear worthy of a possible raise, promotion, or other reward.
If, however, they felt that the management was doing time studies to try to increase productivity, or justify fewer employees, the workers tended to slow down so they wouldn't be responsible for layoffs of themselves or others.  In these cases, the workers assumed that the ultimate goal of the Six Sigma project was being done to reduce the number of employees, so why should they jeopardize their own jobs?
I'd never run into the second scenario before, in my experience in healthcare.  I wondered whether other Belts had seen different scenarios while making time studies or observations for their projects, and how it affected their "Measure" phase.  I also wonder how to be sensitive to either effect when measuring for my next project.
Would any of you like to share related experiences from projects that you have been involved in?]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 15 Aug 2006 08:44:46 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Process improvement gone mad]]></title>
			<link>http://blogs.isixsigma.com/archive/process_improvement_gone_mad.html</link>
			<description><![CDATA[I have recently moved to the east of England (Norwich) and one of the first things I did was join the library. Now, every library I have used had a simple process for borrowing books. The book details are recorded and the return date stamped at the front of the book. Sound straightforward? Well not if a process improvement team gets involved!
Here a new process has been deployed. The book details are recorded and a printed slip with the return date inserted at the front of the book. I asked the librarian, why change a process that works? She said this was to improve the speed of getting books processed. However she thought it slowed things down and a few librarians had resigned in protest. Of course when I got home I had lost the paper slip and had to phone the library to confirm the return date. 
This all got me thinking. I bet there are other unsuccessful process improvement projects out there. Projects that make ridiculous improvements or cost more than they save or just get abandoned and people don’t like to talk about them. I imagine even that model of business excellence, GE, has had projects that have been quietly forgotten about. What I thought was, what are the root causes for unsuccessful process improvement projects, the 5-why’s?
What better way to find out than to ask the readers. So I have designed a small online survey that is completely anonymous and allows you to describe an unsuccessful project and why you think it failed. If I get enough responses I will report the findings. Please take a few moments to follow the link below and describe your experiences. 
Online Survey Link]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 14 Aug 2006 11:04:41 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Triple Threat]]></title>
			<link>http://blogs.isixsigma.com/archive/triple_threat.html</link>
			<description><![CDATA[In my last post, about a recent Rapid Improvement Event (RIE, sometimes called a kaizen event), I mentioned that there were three Black Belts involved.  I’d like to expand on that a little further and see what you may think of our arrangement.
When a Rapid Improvement Event is chartered, a lead Black Belt is assigned to meet with the Process Owner to scope the boundaries of the event and hold pre-event team meetings.  During the RIE week, the lead BB is the primary facilitator of the group.
A second Black Belt is assigned as co-facilitator, who helps with data collection and process-mapping.  During the RIE week, the second Black Belt facilitates any subgroups that break off for special issues; calls out for ancillary department support (such as telecom or maintenance); and acts as a process-checker during the event.
The third Black Belt acts as a resource primarily during the RIE week.  As we are creating standard work, developing forms, revising procedures, etc. there is usually a need to create drafts that can come before the team quickly, so decisions can be made on the second and third days.
Now, this is a lot of "Black Belt resource" to use in a single event week.  Do we really need three BBs to run a lean event?
First of all, we’re fortunate to have enough Black Belts in our health system to be able to help out across sites.  So we have the resources available to do this for the majority of our RIEs.
Second, we’d rather have the team members focus on using their ideas to identify waste and come up with solutions - not typing for hours on a computer.  By having a Black Belt do these tasks, team members are free to be subject matter experts or general knowledge resources.
Third, we’ve found that we need relatively large teams to solve issues in healthcare.  There aren’t typical "work cells" where a select group focuses on one routine task.  No patient-related function is done in isolation, and representation from each stakeholder group is needed so we can have "the right people in the room."  These larger groups benefit from having at least 2 co-facilitators during the event week.
Should everybody use this model?  No.  But for our situation, and in our culture, this seems to work well.  We do vary the number of BBs according to the project scope, size of the team, and situation.  And we hope that as our number of Green Belts grows, we can start utilizing them on RIE teams in place of the second and third Black Belts.  I thought it might be interesting to share our approach, and even more interesting to get your comments on it.  What do you think about having multiple Black Belts on a Rapid Improvement/Kaizen team?  Please let me know.]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 10 Aug 2006 12:20:15 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Shazam!]]></title>
			<link>http://blogs.isixsigma.com/archive/shazam.html</link>
			<description><![CDATA[Having spent the last week in a healthcare Rapid Improvement Event (i.e. Kaizen), I continue to marvel at the power and resourcefulness of a dedicated team of people.  Our topic was "Patient Access" - in other words, how to get patients into beds more rapidly in a hospital that is typically at (or beyond) stated capacity.  The large team of 20 stakeholders and first-line associates was lead by two of my partners in crime - experienced Black Belts who facilitated the team discussions, kept the group on track, and ensured that we met our deliverable targets.  My role was "helper Black Belt" - leading subgroups, assisting with forms and procedure designs, and generally being the utility outfielder.  [Using three Black Belts for a Kaizen???  I’ll address this in my next post.]
Those of you familiar with Kaizen events know that Monday is the problem definition and waste identification day.  Wow, did we ever come up with problems and wastes!  So many, in fact, that the group was a little discouraged.  "We’ll never be able to do anything about all this!"
Tuesday, being solution day, was even tougher.  The group at first shied away from tackling "the elephant in the room" - physician behaviors and even some nursing or other associate behaviors.  One of our Black Belts quickly got the group back on track - challenging the team to work on the real issues wherever they might fall.  We developed a list of physician issues to discuss with our Vice President of Medical Affairs (VPMA) and he met with us to review the perceptions and barriers relating to physician rounding, writing discharge orders, and other issues.  For the process issues, the team broke up into two groups to work on "scheduled" admissions (OR, Cardiac Cath Lab, Chemo patients) and "unplanned" admissions (ER, Direct Admits).  We also worked on decreasing nursing dissatisfiers - primarily improving communication paths and decreasing delays in bed assignments. The team said, "This is too complicated - too many people affected - this will never work!"
On Wednesday we implemented our solutions - improved communications, an emailed "bed snapshot" report, and streamlined bed request pathways.  Almost immediately we started getting positive feedback - fewer phone calls, an easier process, more of a feeling that the process was controllable (as opposed to the former crisis mode).  The team said, "I can’t believe it, it’s working!"
By Thursday the process data was looking pretty good - a few tweaks were needed here and there.  The team said, "Wow!  What happened?"
The Friday Report-Out was very positive and enthusiastic.  The team said, "We never thought we could do this!  This is great!  When can we do another?"
The leadership who came to the Report-Out said, "We don’t understand how you got from Monday’s day of confusion to Friday’s success!  This Rapid Improvement Stuff is great!"  So, we’ll be inviting them to participate in future events so that each leader can understand how we go from confusion to efficiency - it’s not by saying "Shazam!" and out of the blue a magic lightning bolt of Lean efficiency strikes the hospital - but by the intensive and structured work of the Rapid Improvement Event team.]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 07 Aug 2006 06:46:14 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: CCPM &amp; Lean / Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/ccpm_amp_lean_six_sigma.html</link>
			<description><![CDATA[Over the past year or so I’ve had occasion to work several Lean projects in conjunction with the implementation of Critical Chain Project Management.  One project has been a huge success and the other was a bit of a goat rodeo which ultimately had the plug pulled on it before any real progress was made. I’ll throw out a few details on the two projects followed by my take on the synergy between Lean/Six Sigma and Theory of Constraints Project Management in the hope that some of you who’ve experienced similar project work will contribute your thoughts.
The first project in which I encountered CCPM was an attempt to implement it to schedule the overhaul visits for commercial aircraft. The environment seemed tailor made for such a tool but the organization struggled with it for a year before finally giving up. With upwards of 7 aircraft going at one time, there were a few program managers who used the tool with great success but others who just refused to commit to it. Those who used the tool effectively were able to focus Lean/Sigma efforts on the constraints identified by the software and were the most successful at turning their projects out on time. Those who didn’t remained in fire fighting mode and were constantly changing direction with regard to which area was the constraint. A turnover in leadership at the top generated a review of the success of the tool which, because it was never fully utilized, appeared less than stellar. The plug was pulled.
What I learned in the first project was that if CCPM implementation is going to be effective, program managers must not be given a choice of whether to use the new tool or depend on the old way of doing things. This is essentially the same leadership / change management issue I saw in the early days of Lean and Six Sigma implementation. CCPM represents a substantial change in philosophy relative to managing projects or scheduling work. If the leadership team doesn’t understand the tool and know the right questions to ask, it is destined to fail. 
The second project was in a manufacturing plant. This time the leadership team and the production and program managers were well versed in the use of the tool and they were fully committed. That said, one year after implementation, CCPM hadn’t delivered the desired improvement. Upon entering this situation, my take was that Lean would be the answer to unlocking the potential of the tool. Four months after beginning the Lean implementation I’m happy, and relieved, to say I was right. CCPM schedules the production areas which feed assembly cells which we are continuing to drive toward single piece flow. It appears to be a great marriage. Once again though, the leadership was committed to both the CCPM tool and the Lean efforts.
As I look back over the past few months at the plant, the takeaway for me is confirmation that CCPM is not a magic bullet (are there any?). The tool works well in conjunction with a committed and focused Lean / Six Sigma effort and it’s a great way to schedule production, but it won’t solve process problems for you. 
Okay, enough about my experience, I want those in the community who’ve worked with this tool to step up and share their thoughts. I see some great synergy between CCPM and Lean / Six Sigma, what do you think?
Meet you where the buffers turn Red, Michael McBride]]></description>
			
			<author><![CDATA[W. Michael McBride]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sat, 05 Aug 2006 14:09:49 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Sucks]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_sucks.html</link>
			<description><![CDATA[Over the past weeks and months I have become increasingly aware that there is a grouchy counter-Six Sigma-culture out there. As indisputable proof of this, a Google search on the phrase "Six Sigma sucks" returns no less than 111,000 hits. (See for yourself here.) Even discounting bitter G.I. Joe fans, this is a big number. 
I certainly didn’t read through all of the links, but I did peruse the first score or so. And I also spent quite a bit of time reading through the collected wisdom on a page ostensibly devoted to "The Truth about Six Sigma Quality...Fallacies, Faults and Errors" located here. Incidentally, I was directed to this site from, of all places, the forums on www.isixsigma.com.
Because there is a lot to read on the subject of "Six Sigma Sucks", allow me to paraphrase the vast majority of what is out there in the three points below. And, of course, to respond. Because behind the smarmy smarter-than-thou attitude that pervades most of these pieces, there is little more than a lot of unfounded assumptions, much plain misunderstanding, and no small measure of grumpy complaining masquerading as fact.
1. The math is wrong.
There seems to be a small but dedicated community of folks (mostly academics and consultants) who are obsessed with some or all of the following: the definition of defects; the focus on defect reduction; use of Sigma as a process measure; usefulness of DPMO as a process metric; whether using the normal curve as a basis for process improvement work is appropriate; whether Harry’s “1.5 sigma shift” is real and if so how it may be explained; whether Six Sigma is a reasonable goal in the first place; etc, etc, etc.
Such arguments, in my opinion, entirely miss the point regarding data-driven continuous improvement. Sure, math and statistics get tortured and misused all the time in the name of Six Sigma. And sure, errors are made. That’s not surprising - a few weeks of training and access to a lot of computing power does not make people into statisticians or mathematicians. But if we can get to the point of discussing and debating the problems and opportunities in an organization in a data-driven, consistent way, then the battle is already won. We don’t have to be right in every case, or even most cases, to make progress. Dwelling on the fact that the math is sometimes wrong is a bit like suggesting that we should never start jogging to lose a few pounds unless our running technique is already perfect. In fact, we make a lot of progress even if our technique is terrible. And not to start at all would be a much worse mistake than starting poorly.
Furthermore, "the math is wrong" is not only a weak argument, but also one aimed against a view long since discarded by most serious practitioners of continuous improvement. In my opinion and experience, the best Six Sigma programs today no longer focus on simple defect reduction. Many don’t even teach Z-scores or process capability indices. As the detractors are fond of pointing out, gurus like Deming, Shewhart, Wheeler, and many others have much more sophisticated and nuanced views than simple "Six Sigma quality" on the use of statistics to drive continuous improvement. What the detractors don’t seem to realize is that Six Sigma practitioners realize this too. We’re not dumb or close-minded. We all continue to learn, and Six Sigma curricula have largely moved on in their own cumbersome, evolutionary fashion.
2. Consultants vastly overstate the value of the program.
This one, of course, is often true. But it’s definitely not a Six Sigma-specific problem. And it’s not done by good consultants, consultants who understand the plusses and minuses of Six Sigma, and are careful to talk clients through both. There will always be examples of very expensive programs that start with a blizzard of flashy PowerPoint and end with no results, but that’s hardly the fault of Six Sigma in general. Where and when it happens, it happens independent of the program or subject matter. "Caveat emptor" always applies to any consultant services, and "garbage in, garbage out" always applies to any program or initiative. Six Sigma isn’t any different, but that’s hardly a serious knock against the subject matter.
3. Six Sigma isn’t anything new - [insert your favorite author here] had it right way back when they wrote [insert your favorite book here].
Well of course they did. You won’t find a bigger fan of Deming than me. And Shewhart was absolutely a genius. Every book that Wheeler has written has provided me with numerous light-through-the-clouds moments. Tufte is beyond elegant in his views on the graphical display of information. And yet Deming’s 14 points and PDCA methodology still aren’t common vernacular. The vast majority of people using Shewhart’s control charts still don’t understand them. Wheeler’s intuitive and eminently comprehensible explanations of basic statistics still get misunderstood regularly. And to what I can only assume is Tufte’s ongoing dismay, three-dimensionally rendered bar graphs showing one variable are more common than ever. So apparently just being right isn’t enough. We need a way to institutionalize those realizations across large organizations, a way to create a common vocabulary, a way to get everyone a company moving in the same direction. We need an excuse for everyone to read the magic book. And like it or not, programs that generate hype provide a means to those ends. If there’s a better, more efficient way to achieve the same cultural results, I haven’t found it yet.
What bothers me most about the various "Six Sigma Sucks" pieces I read is that their authors inevitably imbue their words with a certain the-Emperor-has-no-clothes self-heroism, subtly suggesting that they are cleverer than we Six Sigma lemmings who run blindly towards the sea. But what they fail to realize is that those of us on the inside are thinking about the same things they are, wrestling with the same issues, lying awake at night wondering how best to evolve Six Sigma going forward. We understand and worry over the shortcomings of the program more than anyone. The only difference is that we don’t let it stop us from doing the best work we can right now, even as we seek better ways.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 31 Jul 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Good Projects Gone Bad]]></title>
			<link>http://blogs.isixsigma.com/archive/good_projects_gone_bad.html</link>
			<description><![CDATA[Nayism 30:  The action taken as a result of the Six Sigma project has no basis.  Looks like this Six Sigma stuff is a scam for doing whatever management wants to do.
There is nothing worse than a good project gone bad.  How do you identify them and what do you do?  Here’s what I say . . .
Bad projects occur when a project team fails to apply the Six Sigma methodology to reach the answer but instead jumps to an unanalyzed conclusion.   These projects can be identified because the action recommended does not have a link to data analysis.  How does this happen?  Sometimes it is due to having an overzealous team that think they know the answer and want to hurry up and solve the problem.  In this case, bringing the team back to the data analysis usually gets them going in the right direction.  
The tougher issue is when this action is pre-meditated.  This is when a Project Champion (PC) or Black Belt (BB) uses the Six Sigma forum to accomplish a specific task that they want to get done.  Portraying the task as a Six Sigma project implementation recommendation may be the only way to sell their idea.   Addressing this issue is a difficult task.  You must keep asking the PC, the BB and the team "How does this solution link to the data analysis?"   Focus on the PC.  If the PC refuses to acknowledge the issue it means that he or she is the issue.   If the project is too far down the road, you may not be able to save it.  But keep a sharp eye on the situation and you may be able to halt the next project before it starts going bad.
Good projects gone bad can 'spoil' any deployment.  If given the choice, no project is better than a bad one. ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sun, 30 Jul 2006 18:24:04 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Which Comes First: Process or Behavior?]]></title>
			<link>http://blogs.isixsigma.com/archive/which_comes_first_process_or_behavior.html</link>
			<description><![CDATA[Fixing or otherwise improving a process usually involves changing it in some way. For this reason, Six Sigma projects almost always involve some element of process engineering or re-engineering. On top of that, folks in deployment leader roles or similar are often tasked with developing brand new processes like project selection, candidate identification, certification, and a range of others. And of course there are a myriad of situations outside the Six Sigma world that involve creating or altering processes.
One failing I see in myself (and in many new Black Belts) is a tendency to develop ideal processes on paper, without addressing elements of human behavior. I suspect it’s a by-product of being trained in a highly data-driven methodology. We expect that if we can use good data to demonstrate that a process change will result in an improvement, then people will automatically change their behavior. Put another way, if we ourselves are convinced by data, we assume everyone else will be as well.
In my experience there are a few problems with this view. One is that it does not hold for everyone: some folks are not, in fact, convinced by data. Another is that complicated statistical data are difficult to communicate effectively across large organizations. And finally, even those who are intellectually convinced will almost certainly need to be provided with additional motivation to change their behavior.
I’m not going to give a lecture on change management here. What I want to talk about instead is the relative difficulty of changing human process behavior versus standard Six Sigma process work. And more particularly, the order in which we address the two related areas.
I have been in many situations when, in response to a genuine gap or need, a new process is designed or purchased. Software implementations are a great example of this. The perfect process is laid out on paper, the process tools procured, and the process rolled out in the organization with the best of intentions. But I have seldom seen it work well, or even have any lasting effect, unless considerable work is done to change human behavior first.
Take, for example, project tracking systems. In more than one case I have been in organizations where there is basically no project tracking prior to Six Sigma deployment. It is identified as a need as part of the deployment plan, and software is purchased. But once the system is set up, no one uses it even though it is a great system.
It has taken me a long time to learn that in this situation, the most effective first step is to focus on behavior and implement something simple. A one-page template that is collected manually each month and rolled up into an offline project spreadsheet is a great first step. Work hard to get folks doing that and see what happens. Learn from the experience and iron out the kinks in the rudimentary process. Once you get good at that and folks are used to it, then take the next step; maybe a simple online database that everyone can access directly to enter their information. Take the time to tweak that database and figure out what reports are useful, as well as what functionality you really don’t need. The take the next step, and the next one, and the next one. Before you know it there will be a robust process that people are used to following. And even if the “home-made” process is clunky and hard to manage, it’s an amazingly short step from here to a beautiful, gleaming, streamlined process. If you grow the process yourself you’ll know what you need from a software vendor when the time comes, and you’ll know what to expect from the folks who interact with the system. In short, you’ll be automating something that already works, rather than trying to go from nothing to perfection in one step. And crucially, you’ll already have established the necessary patterns of behavior among the people interacting with the process. In my experience it’s a lot easier to map the process/software to existing behavior than vice versa. So it’s worth taking the time to get the behavior right before you decide on the software, even though it’s a very messy process.
Project tracking is just one example, but in my experience the general conclusion holds in most situations. “Process or behavior?” is not a “which comes first, the chicken or the egg?” question like I’ve often heard suggested. And designing or purchasing a new process won’t automatically create behavior, the claims of vendors notwithstanding. These days I find it most efficient to crawl before I walk, before I jog, before I run, etc. I live through the messy home-made solutions before I automate or even finalize process in the organization. I work on building the process behavior before I build the process itself.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 25 Jul 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Sam Decker on Six Sigma in Marketing]]></title>
			<link>http://www.sixsigmacompanies.com/archive/sam_decker_on_six_sigma_in_marketing.html</link>
			<description><![CDATA[This week Sam Decker gives a beginners course on Six Sigma and marketing over at his blog Decker Marketing.  I’ve been reading Sam Decker for about a year and a half now. He never fails to share the insights he’s learned from his work experiences from start-ups to managing Dell’s eBusiness.  As for marketing blogs, his is top-notch.  If you are in marketing, you’ve got no excuse for not reading his blog.
His latest post Marketing Bullseye 2: Think Six Sigma is part of a series where he gives tips for marketers to get the most out of their efforts.  In “Think Six Sigma,” he explains the concept of Six Sigma and its value in marketing:

“I think 80% of Six Sigma/BPI value in marketing is simply understanding the measures of your marketing process and executing continuous improvement projects on processes that effect these measures.”
He calls out two concepts that changed his way of thinking.  The DMAIC methodology and the Y=f(x) formula.  He goes on to carefully explain how Six Sigma can be applied to marketing and gives four steps, followed by a simple example.  Read Marketing Bullseye 2: Think Six Sigma and make a difference in your marketing efforts today.
(Sam has written a few earlier posts about Six Sigma and marketing as well.  Read Six Sigma Marketing...Made Simple and 7 Tips for "Getting" Six Sigma Marketing.)]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Methodology&nbsp;,&nbsp;Six Sigma Articles &amp; News]]>
			</category>
			<pubDate>Tue, 25 Jul 2006 14:14:25 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Sustainability of Kaizens in Healthcare]]></title>
			<link>http://blogs.isixsigma.com/archive/sustainability_of_kaizens_in_healthcare.html</link>
			<description><![CDATA[Ok, I have to pose a question for the general "Lean Thinkers" out there who are aware of how conservative healthcare is.  I have been reading so many articles that highlight the success of Kaizen events in healthcare settings.  However, I have to ask myself, do they really work?  Do the changes really sustain?  Is it possible to make dramatic changes to a setting within a healthcare facility in five days?  The team of implementers at my organization have never done what is defined as a "kaizen event," and we’re not sure we want to try.
The biggest concern for me is that there will be no staff buy-in as a result of a five day implementation.  Because healthcare is filled with skilled autonomous workers, change seems very difficult to overcome.  It’s quite ironic in an industry that constantly changes with new regulations and technology, but replacing complex thinking with common sense is overwhelming to healthcare workers.  Also, when you do have a group of the willing, there isn’t enough of them with enough time to devote to such a fundamental revolution.
Secondly, can you pull the resources needed in less than five days?  Can you have members from the IT department, facilities department, etc. on-board and able to assist the whole time?  Obviously, these people would have to be on hand working side-by-side with the implementers in order to achieve the results.  It’s almost like that home makeover show: everyone is working side-by-side to have a house built in a week.  It may work for them, but it has been my reality that these people aren’t always available at a great length of time.
Finally, are the champions, stakeholders, executives ready and willing to commit to such drastic policy changes in such a short period of time?  It seems, from the case studies I’ve read, policy changes happen on the fly and with little executive involvement.  How can these changes sustain? 
Of course, the optimist in me says that making such drastic changes in such a short period of time eliminates the opportunity for the "what if..." flag to be flown in my face.  Drawing out a plan and strategically implementing it over time has committed me to a life of "firefighting."  It seems I am perpetually stuck in a "one step forward, two steps back" routine.  So I can see how a dramatic overhaul would not allow enough time mull over the natural resistance to change.
Can anyone describe a typical Kaizen event in a healthcare setting, and how it was able to be successful in an industry that is bound and determined to maintain its conservative roots in an industry experienced in change?]]></description>
			
			<author><![CDATA[Andrew M. Hillig]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Tue, 11 Jul 2006 16:21:57 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Long Game]]></title>
			<link>http://blogs.isixsigma.com/archive/the_long_game.html</link>
			<description><![CDATA[In a world where I could call myself the Senior Master of the Highest Order of Black Belts, I have always been a little circumspect of using the Black Belt handle. So after 18 months the time has come. I can now call myself a Six Sigma Black Belt! I have been accredited by our businesses MBB’s and receive my award next week. 
Have I earned it? Well I think the answer is yes. I have helped implement the infrastructure (built the web-site, organised the conferences, managed the training etc.), provided project mentoring, assisted in delivering training and most importantly delivered strategic projects. But I think the single most important reason is the sheer amount of knowledge I have gained through studying, in my own time, the ASQ syllabus. I now feel I have a good grounding in the subject.
When I first started I thought gaining the ASQ certification was critical and went hell-for-leather to acquire as much knowledge as I could to fast track a certification. However I became much more relaxed when I realised that I was in this for the long-term. I could push hard and get an early certification or I could use the syllabus as a catalyst for doing deep-dives into complex material. There are parts of the syllabus that I know absolutely nothing e.g. axiomatic design, TRIZ, and response surface methodology. Is it stopping me being successful? No. Do I want to learn it? Yes, at some point.
So I hope there will come a point on my journey when I will take the ASQ exam. 
As the world’s greatest master black belt said: “It is like a finger pointing toward the moon. Don’t concentrate on the finger or you will miss all that heavenly glory.”]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 06 Jul 2006 09:00:08 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Use the Force . . .]]></title>
			<link>http://blogs.isixsigma.com/archive/use_the_force___.html</link>
			<description><![CDATA[Nayism 28: So much analysis, so little time.  The project needs to get moving - I need a fix now.
Ah yes, the analysis paralysis phase of projects can haunt even the best of black belts.  Is there ever a time to throw in the belt and call it "enough"?  Here’s what I say . . .
The dreaded sea of unending data is quite a site but drowning can be avoided.  
First, always check your scope and objective.  Is it too large (i.e. boil the ocean)?  Are there too many inputs or are the inputs at too high a level?  If so, working through a refined C&amp;E matrix or QFD may help you develop a more focused data analysis plan.
Second, stay focused on your objective.  It’s easy to get side-tracked by stray defects.  If the defects are not directly related to your specific objective, save them for another day.
Third, and most important, use the collective knowledge of your team to help keep you on the right path.  As experts in their field, they can more easily recognize correlation versus causation and keep you focused on the important stuff.  Ask them to help you find the exit door to this unending analysis loop.
Remember, your team may be the driving force to success.  "Use the force . . .Luke!"]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Tue, 27 Jun 2006 04:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Analysis using Maps (Part 1)]]></title>
			<link>http://blogs.isixsigma.com/archive/analysis_using_maps_part_1.html</link>
			<description><![CDATA[



Here is another example of the use of IT in projects. I would like to describe how useful mapping is in data analysis. I will use a fictitious scenario. 
Sigma Industries have a fantastic product that VOC research says should be a phenomenal success. But the problem is product sales are not meeting expectations. As part of initial analysis the project team wish to estimate potential market size and Sigma Industries’ market share.
They have one year of customer sales with details on each customer address. Using a mapping utility these addresses are converted into longitude and latitude and plotted.  This is a start but shows far too much information (thousands of customer dots). 

To see the wood from the trees these individual customers are aggregated into regional grouping using postcode sectors (like zipcodes). The customer hot spots are shown through colouring.

But we wanted to understand the overall market size and our share. So a 3rd party data set is bought containing all potential customers. A ratio is calculated of actual to potential customers. The information is displayed as a bar chart with market size in gold and the market share in black.

Hope this gives a good initial impression of the value of mapping in data analysis. I have found that once the core concepts are understood, it’s all very straightforward and new application keep appearing.
More to come in a subsequent blog.
  
 
 
]]></description>
			
			<author><![CDATA[Robin Barnwell]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 20 Jun 2006 10:20:01 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Week of a Black Belt Part 9: Challenges of Project Selection]]></title>
			<link>http://blogs.isixsigma.com/archive/week_of_a_black_belt_part_9_challenges_of_project_selection.html</link>
			<description><![CDATA[Why are we struggling with selecting the “right” Six Sigma Black Belt projects?  The “right” projects are the projects that are delivered on time, within the budget and generating or exceeding projected savings in a sustained manner. The “wrong” projects are by default all other. 
Now think about your own organization. What’s the proportion of “right” and “wrong” projects in your Six Sigma project population? You may just have found a new project idea: “Decrease the number of wrong projects for my organization.” 
It could be a nice to start a Six Sigma project out of this idea, but would it be a “right” Six Sigma Black Belt project candidate?
Let’s process this idea through a project selection filter, a series of 10 relatively simple questions that need to be answered before any more time and resources are spend . Forcing you to carefully think over the idea, a rule of thump is not to spend more then 2 man-hours on this exercise. A positive answer scores you +1 point, a negative answers scores -1 point, a neutral answer scores 0 points.
1. Does the idea fit to the company big Y?
What is the company’s big Y? What is your CEO’s and management team strategic agenda? Refer to internal communications, the company’s website, annual reports … or just ask them!
“Decrease the number of wrong projects for my organization” fits the big Y when you find statements similar to “improving business process using improvement methodologies like Lean or Six Sigma (or equivalent)” in any of the mentioned sources. 
Score:  +1
2. Is there direct Impact to the external Customer?
The Customer (with capital C) is the one that your organization exists for. Customers are buying your product and thus paying your salary and annual bonuses! It may be difficult to estimate any direct impact “Decrease the number of wrong projects for my organization”, however you may expect by achieving this project the customer will indirectly benefit from this project. This is a neutral answer.
Score: 0
3. Is there impact to the internal customers?
Probably the same answer as for question n°2, although you may expect a higher impact on internal customers. If more projects succeed, processes will be more robust and with less waste, allowing your internal customer to work differently and become more effective.
Score: +1
4. Is data available or can it be gathered in a reasonable time?
Probably, there is some kind of project tracking system, which should be a fairly reliable source of data for our project idea.
Score: +1
5. What is the cost of poor quality? 
If not identified score: -1.
What can you consider as cost of poor quality for our idea? What are the consequences of “wrong” projects? 
Consider this memory jogger to reduce the risk of forgetting important cost drivers: 
COPAFILT
Commercial: internal &amp; external customers, marketing, external communication …
Organization: structure, decision authority, internal communication …
Personal: number of employees, education, motivation, remuneration …
Administrative organization: processes, tasks, activities, support logistics …
Finances: budget, investment cost, financial costs …
Information: information systems, communication, data management, documents, reporting …
Legal: legal aspects, contracts …
Technology: computers, hardware, network, facilities, means of communication …
Consequences of “wrong” projects: decreasing motivation of the improvement teams (people may start to update their resumes and leave the organization: quantify the cost of replacement and training of newcomers), missed commercial opportunities (quantify missed revenue), failed cost reduction efforts (quantify missed savings) …
Score: +1
6. What are the potential cost savings?
Estimate the % the cost of poor quality will be reduced in achieving this project idea. What is the resulting estimated cost saving? What is the minimum potential savings your black belt projects should generate? Usually, depending on organizational decisions, it’s in the magnitude of 150.000 Euro/year.
Score: +1 if above the minimum required saving, -1 if below.
7. What are other consequences of doing this project?
Other improvements and benefits if this idea is achieved, but you can not attribute any cash flow improvement to them. Be reasonable, don’t start to make up. 
Score: +1 if identified. 0 if not identified. 
8. Is there an identified project sponsor?
Is the owner of the process the idea will impact identified? If no score: -1 and following questions not applicable. If yes, score: 0 and refer to following questions
Is he/she supporting the idea?  Yes: +0.33. No:-0.33.
Is he/she willing to allocate resources? Yes: +0.33. No:-0.33.
Is he/she willing to invest personal time to review project progress? Yes: +0.33. No:-0.33.
9. Should we start Six Sigma Black Belt project, are team resources confirmed and sufficiently available?
Yes: +1
No: -1
10. Should we start Six Sigma Black Belt project, is there a project governance process available?
How is project progress tracked? Is there a dedicated project progress meeting? Do you plan to have a regular meeting with your project champion and/or project sponsor? Are tollgate meetings planned with the team and your MBB at the end of each DMAIC phase?
If you recognize any of these elements: score +1.  If you don’t: score -1
Now sum the individual scores to a total score, between -10 and +10.  Total score &amp;gt; 7: this idea has high potential to become a “right” project! Total Score 0 =&amp;gt; 6: be careful, risks for Six Sigma project failure, resulting in a potential “wrong” project! Total Score &amp;lt; 3: drop the idea and continue with more valuable work!  If the minimum savings requirement (6.) for a black belt project is not met, but the total score for example still 6 or 7, consider if this could be a green belt project.  
Are you interested in successfully closing more “right” black belt projects? Then start at the beginning assessing project ideas with the suggested project filter. It’s not an absolute guarantee for success, but will significantly increase your success chances. It’s about setting your Six Sigma project teams up for success by providing them with good and carefully thought over Six Sigma project ideas.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 19 Jun 2006 13:05:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Stifles Innovation &amp; Creative Thinking]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_stifles_innovation_amp_creative_thinking.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.  What do you tell them?
Nayism 27:  Six Sigma is so structured that it stifles innovation and creative thinking.
This is a classic nayism which deserves a classic response.  So, here’s what I say . . .
Au contraire mon ami.  It is quite the opposite.  Six Sigma does not stifle innovation and creative thinking.  It facilitates it.  Many Six Sigma tools, such as the C&amp;E diagram and FMEA encourage free thinking and collaborative brainstorming.  A good facilitator coupled with a diverse team creates the perfect environment for new ideas to emerge when looking for possible causes or when identifying possible solutions.  And, once an innovative solution is identified, Six Sigma can help optimize the effectiveness of the solution.
Still not convinced?  Maybe the solution in this case is to commission a Six Sigma team to identify new and creative ways to deal with naysayers!
 ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sun, 18 Jun 2006 16:35:11 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: David Silverstein on TRIZ]]></title>
			<link>http://www.sixsigmacompanies.com/archive/david_silverstein_on_triz.html</link>
			<description><![CDATA[Innovate Forum has posted an interview with David Silverstein, President and CEO of Breakthrough Management Group and co-author of INsourcing Innovation.  In the interview, Silverstein talks about the TRIZ methodology for innovative problem solving.   

“Innovate Forum: TRIZ is a methodology that has traditionally been employed in product design. What prompted you to consider applying TRIZ to business innovation?
“Silverstein: Well, you just used the key word – methodology. TRIZ caught my eye initially because it involved such a methodical approach to problem-solving – which is something that is very palatable to people who are accustomed to Six Sigma. Furthermore, when people are talking about Six Sigma today, they’re not just talking about process optimization – they’re talking about things like design for Six Sigma and structured approaches to strategic planning. So TRIZ offers a very structured approach to innovation, and makes a lot of sense to Six Sigma folks.”
TRIZ has always fascinated me since I learned about it in course taught by Ellen Domb, editor of the TRIZ Journal and President of the PQR Group.  I have found principles of TRIZ creep into my everyday problem solving thought process (along with a few Lean principles as well). The TRIZ principles of abstraction and “ideal final result” are two that I have found quite easy to grasp and applicable to any kind of problem.  In the interview, Silverstein talks about these principles and gives solid real-world examples of each.  
If you haven’t heard of TRIZ, this interview will give you a taste.  If you’re a TRIZ advocate, please share a story (in the comments section) where you applied TRIZ principles to come up with an innovative solution to a problem - either in business or everyday life.]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[Methodology&nbsp;,&nbsp;Six Sigma Articles &amp; News]]>
			</category>
			<pubDate>Thu, 15 Jun 2006 10:42:56 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Why “How Many Samples Do I Need?” Is Not A Statistical Question]]></title>
			<link>http://blogs.isixsigma.com/archive/why_how_many_samples_do_i_need_is_not_a_statistical_question.html</link>
			<description><![CDATA[I recently read through a thread on this site’s discussion forum which started with the question “Sample Size…Why 30?” You can read it for yourself here.
It’s a question I hear a lot, except that 30 is sometimes another number. Like 2. Or 8. Or 156. Or 2068. The thread was intriguing in a number of ways, not least because it has remained active since mid-2002! Clearly there is a lot of interest in this topic.
How to sample a process is a favorite topic of mine as well, but for different reasons: in my experience it is one of the most abused topics in the Six Sigma canon. The “why 30 samples” question is, in my view, symptomatic of a root cause that involves a misunderstanding of enumerative versus analytical statistics.
(Fair warning: I am not a statistician.) Enumerative statistical techniques concentrate on understanding population data via various statistics. For example, we might want to estimate the average height of a 42 year old male in England, and to do this we could sample the population through a census. Enumerative statistics would help us understand how many people we’d need to survey from the population (and maybe something about how to choose them) to get an “accurate” estimate of the true average value at some level of statistical confidence. Techniques such as Chi Square and other tests of significance, confidence intervals, etc, are very powerful tools in the enumerative world for these types of problems. And questions like “how many samples do I need for…?” have well-defined answers.
Analytical statistics, on the other hand, concentrate on predicting the future. Which means the techniques vary considerably from those of the enumerative world. And in my view it should go without saying that the point of any Six Sigma project should be to predict the future in some way. What does Y=f(x) symbolize if not the ability to predict? Yet in my anecdotal estimation, about 95% of the Six Sigma projects I see at conferences, on the web, and in the open literature rely solely on enumerative techniques. Which is probably why there is such intense interest in questions of sample size. This is highly misguided in my opinion. Also in Dr. Deming’s, who has the following to say regarding enumerative techniques for continuous improvement in “Out of the Crisis”:

“Incidentally, Chi Square and other tests of significance, taught in some statistical courses, have no application here or anywhere.”
And later on:

“But a confidence interval has no operational meaning for prediction, hence provides no degree of belief for planning.”
(Note: I copied these quotations from an interesting exchange on this subject here.) 
From an analytical statistics point of view, the relevant question to ask is not “how many samples are needed for…?” but rather “how can a representative sample be chosen such that we can predict the future behavior of the system at a useful level of accuracy?” And the crucial point is this: that second question is not a statistical question. I’ll repeat: the question of how to sample appropriately such that you can accurately predict the future behavior of the system is not a statistical question. It is entirely dependent on your knowledge of how the system behaves, and no piece of software or statistical textbook will help you answer it. You have to study the system itself, and let it be your guide.
The advice we should give in answer to the query “how many samples do I need for…?” is to turn around and ask how much knowledge of process variation/behavior we have, and then discuss how to sample that variation/behavior in such a way that we feel confident that the results will predict the future variation/behavior. In the world of analytic statistics there is no magic number that answers the question of how many samples are needed – it depends wholly on knowledge of the process. 
For the same reason, I almost never recommend random sampling. To me random sampling as a strategy is a tacit admission that variation is not understood and cannot be sampled purposefully. I would rather sample in a very structured, non-random way and gain insights into process variation than sample randomly and mathematically remove the effect of “noise”. Random sampling might get rid of “noise” in the mathematical sense (and hence make enumerative calculations look better), but that noise is still there in the process. Better to sample it, study it, and deal with it than ignore it.
So when I am asked, as I often am, “how many samples do I need for this study”, my answer is always the same: “what is your sampling plan to capture the variation you are interested in seeing?” There is no single, easy answer to this analytic question – it depends completely and entirely on the specific situation.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Tue, 13 Jun 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Week of a Black Belt part 4-5-6-7 : Ready for Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/week_of_a_black_belt_part_4_5_6_7__ready_for_six_sigma.html</link>
			<description><![CDATA[Time flies! My last “week of a Black Belt” blog dates from May 12th already. Anyhow, when things are busy and interesting things happen, there are lots of ideas to blog about, but no time to actually publish them.
Six Sigma’s 20th anniversary will be celebrated soon. Since 1987 and its first success stories, it has not gone by unnoticed. The number of published books, consultant organizations, internet publications, are no longer countable …
However, many people I talk to remain with some burning questions “When is an organization ready to adopt Six Sigma?” In many cases followed by “Or should we do Lean first?” and “What about BPM, are we better of with that?”  
I also observe that the companies who adopt it are generally local representations to US based multinationals or their suppliers. Also the infrastructure associated with a full pledged Six Sigma deployment is (rightfully or not?) perceived as too heavy on the small and medium enterprise that account for about 70% to our local economy.  
Personally, I think it really doesn’t matter what name an effort goes under. In all methodologies are good tools that can bring a lot of value to any organization, whether it is big or small, in service, transactional or production environments. The best approach for the organization is depending on its level of maturity. Maturity here is not defined in terms of age or magnitude, but in terms of how well the organization knows its customers, their needs and how well the business processes are able to satisfy those.
Consider 2 examples:
1. An organization with low maturity. Typical characteristics of such an organization: strong functional silos, no continuous improvement culture (it works, so why change it?), no clear understanding of customer needs and wants, management cannot sum up core processes when asked …
This organization should start with the basics: get to know its processes, its customers and their needs. To achieve this, it should use VOC tools. It should use SIPOC, process maps or value stream maps to document its processes. Start documenting at a high level, e.g. core process level. Once this is done, it should look for the biggest gaps between the VOC and the process outputs. These should be this organization’s first improvement projects. The organization should be process mapping again to detail the (core) processes that most contribute to the identified gaps. It should use simple and basic quality tools to get to those improvements implemented. Along the way, it will surely find some waste in the processes. Eliminate it! After the improvements are in place and obvious waste is eliminated, the organization should reflect on the learnings and start again. All along the effort document everything. Look for possible (future) process measurements.
Some might call this endeavor business process management, some might call it lean, some may call it Six Sigma. It doesn’t matter! It’s about getting the basics right first and institutionalizing a continuous improvement culture. To get this in place, there is probably no need for advanced training, for Design of Experiment or Design For Six Sigma …
2. Consider the other end of the spectrum: an organization where core processes are defined and have owners at high management level. Key Performance Indicators (KPIs) to monitor the performance are in place. The customer’s needs and expectations are known and understood. 
Probably this organization has not just started a continuous improvement effort; they have started a while ago. However, the basic concepts of the improvement program are the same as in the low maturity organization, but this organization will need more sophisticated tools. This organization also needs to know its customers needs. The needs of customers today may differ of their needs tomorrow. Thus, by default, listening to the customers using VOC tools is a continuous ongoing exercise, for any organization. 
Having KPIs measuring process performance, implies that measurement systems are capturing process data continuously. This data is reported hourly, daily, weekly, monthly, quarterly … KPIs are use to manage the daily operational business. This requires quality measurements! The interest is in detecting and understanding variation in the processes and making the correct fact based decisions. 
Frequent gage R&amp;R exercises will need to sustain the quality of measurement and consequently the quality of operational management.  For improvement purposes, this organization will also need to identify its biggest gaps between its outputs and its customer’s expectations. This will create an improvement initiative engine as there is always room for improvement. As defect levels drop, the room for improvement by structured common sense will decrease as well, creating the need for more sophisticated tools and methodologies. This is the stage where e.g. DOE, DFSS, multiple regression, non-parametric tests and other come in. 
So, when are we ready for Six Sigma ?]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 12 Jun 2006 12:25:36 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma and Innovation]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_and_innovation.html</link>
			<description><![CDATA[The latest issue of Harvard Business Review features an interview with Jeff Immelt, chairman and CEO of GE. It’s an interesting article because after years of growth through acquisition, GE has now shifted their roadmap to that of organic growth. As part of the roadmap, Jeff Immelt lists innovation as one of the six key initiatives that are going to drive GE to grow organically two to three times faster than world GDP.
I’m personally interested in hearing what companies are doing to drive innovation. If you or someone you know is working in a research and development (R&amp;D) role, or has as one of their job description responsibilities -- to drive innovation within your organization -- I’d like to spend 10 minutes on the telephone with them. Please contact me to chat or recommend someone that I should speak to: michael (at) isixsigma dot com.
I look forward to sharing the learnings of my discussions very soon on this blog.]]></description>
			
			<author><![CDATA[Michael Cyger]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 07 Jun 2006 21:21:03 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Trends From Google]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_trends_from_google.html</link>
			<description><![CDATA[
A while back I stumbled on a new part of the Google website called “Google Trends”. You can view this website for yourself here. 
In Google’s words, the website allows users to “compare the world’s interest in your favorite topics. Enter up to five topics and see how often they’ve been searched for on Google over time. Google Trends also displays how frequently your topics have appeared in Google News stories, and which geographic regions have searched for them most often.” Basically it’s a service that allows you to see the number of searches on various keywords over time, broken out by geography, language, etc. All the values are normalized relative to the total number of searches – while that allows meaningful comparisons over time, it does remove the user’s ability to get at raw data, which might be more useful from a data analysis perspective. But it’s a free service, so I’m not complaining.
For example, the this link shows search patterns on the term “Six Sigma”.
I’ll freely admit I was blown away by the distribution with respect to geography and language, and I suspect others in our profession in North America might be as well. For those of you outside of North America, this is probably old news. I wasn’t too surprised to see India on top in terms of searches by country, but I certainly wouldn’t have predicted that Thai language searches for “Six Sigma” outnumber those in any other language. I and definitely wouldn’t have predicted that the USA would rank a mere seventh! (Admittedly Canada, where I live, doesn’t even rank in the top ten.) As with many things, it’s one thing to know what’s going on anecdotally, but quite another to be confronted with the data.
You can also use the site to compare searches on two or more terms, which lends itself well to all sorts of correlation/causation games. If you’ve ever been in a Six Sigma training course, you’ve probably heard some variation on the notion that “correlation does not necessarily indicate causation” (although it can certainly be a big hint!). One popular example of this fallacy is that sharks must like the taste of sunscreen because sales of sunscreen correlate well with the occurrence of shark attacks. The correlation turns out to be true, and apparently interest in sunscreen is not a bad predictor of reports of shark attacks. See for yourself here.
On a less frivolous note, this result shows searches on the term “Six Sigma” compared to “Lean Sigma”. It’s worth playing around with the “regions” and “years” drop down menu to see what has happened in various parts of the world over time. The trend for “Lean Sigma” itself is actually very interesting too – here we see Washington, DC on top, which I theorize may reflect the recent interest in “Lean Sigma” by military and government agencies in the USA.
Anyway, there’s lots there to play with, and it puts some data behind what had been largely anecdotal up to this point. Of course, any data-hound worth their salt will already be wondering where the data is coming from, what it really means, how it was gathered, what sort of processing done, etc, etc. These are all valid concerns, especially since Google takes the time to point out the following:

"Google Trends aims to provide insights into broad search patterns. As a Google Labs product, it is still in the early stages of development. Also, it is based upon just a portion of our searches, and several approximations are used when computing your results. Please keep this in mind when using it."
Elsewhere they go into a little more detail:

“Google Trends is a Google Labs product, which means that it’s still in an early stage of development. The data Google Trends produces may contain inaccuracies for a number of reasons, including data-sampling issues and a variety of approximations that Trends makes use of. We hope you find this service interesting and entertaining, but you probably don’t want to write your PhD dissertation based on this information. We’ll aim to update the information provided by Google Trends monthly.”
So have fun, but consider yourself warned!  If you are interested in Google trends, you can find out more about it here. ]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 31 May 2006 07:30:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The People Side of Lean]]></title>
			<link>http://blogs.isixsigma.com/archive/the_people_side_of_lean.html</link>
			<description><![CDATA[In the beginning… there is some valid concern expressed about the people side of lean and how individuals are affected by Lean initiatives in the public sector.  There is a common, prima facie response when lean thinking is first introduced in the public sector.   “We are about serving people not making cars”, they say.  This is a normal reaction that overtime is proven inaccurate as the benefits of lean thinking are realized through mapping of the work process, an increase of value added activity and a reduction of waste. This leads to a significant increase of morale among employees who have participated in the value stream mapping process.  Each response is certainly individual but most become owners of the future state that is created and as owners, continuous improvement becomes the natural order of things.   
Additionally, lean initiatives are in most cases introduced as a management initiative and thus suspicion is the first reaction from those representing labor’s perspective. It is easy to assume that lean metrics are an evolution of Frederick Taylor’s scientific management and thus a “top down” management initiative.  This certainly is part of lean thinking in that leadership must make a conscious decision to pursue lean thinking, however, there is a significant participatory aspect included since each value stream is completed by the people who do the work.  This is best understood by reviewing the three basic paradigms of public management, Universalism, Pluralism and Participatory management styles.  During my graduate studies I had the great opportunity to write a paper about the three basic paradigms of public administration. (see http://geocities.com/scrate/three_paradigms.html).  I have concluded that lean thinking and the value stream mapping process is a successful blend of universalism and participatory management paradigms bringing the best of both approaches to a wonderful evolution of employee satisfaction, high performance and a highly functional public organization.
Another critical factor regarding the people side of lean relates to its overall influence on individual performance.  No employee wakes up in the morning and says I will do a terrible job today. I plan to perform at my worst for the whole day.  That does not occur. Everyone would like to rise to their greatest potential at every opportunity possible.   Remember those NBA games when Larry Bird hit 10 for 10 from the foul line, 7 three-pointers and 9 from the field? It might be said he was operating in the zone, or demonstrating peak performance. (I know I am aging my self.)   This is an easy concept for most to understand.  But what of the administrative public employee completing a service request for a citizen or the professional technical staff person running that program analysis to compute federal statistics justifying units of service.  Do they regularly get any acknowledgement for top performance?  Does anyone even measure their tasks?  Do they have any personal goals or “stats” to work against?  If they did, their satisfaction would be increased and performance enhanced.  They would move from viewing their job as a chore to valuing their service to the organization.  So goes government. 
The Value Stream mapping process can provide this feedback, increase value and reduce waste resulting in higher employee performance.  When performance is increased employee satisfaction is increased, turnover is reduced and overall organization function is better. People (employees) are transformed to a more satisfactory view of their job and the public organization rises to citizen expectations and thrives in excellence.]]></description>
			
			<author><![CDATA[Stephen C. Crate]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sun, 21 May 2006 18:16:45 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma and Healthcare...  An oxymoron?]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_and_healthcare_an_oxymoron.html</link>
			<description><![CDATA[How many healthcare processes have you measured that are 2.0 Zst or higher at the start of the project?  I've never had one of these - most of mine have started at below 1.0 or in the negative Sigma range.
In every one of my projects, I've had to use lean tools to get where I needed to go.  Usually, I can't find a standard procedure (or there's a paper procedure that no one follows).  Or, there are such variances between shifts that there are 2 or 3 standard processes.  
In my very first project, Inpatient Discharge, we found that none of the x's were significant.  In my second project, Emergency Department Door-to-Doc, we found that all of the x's were significant.  In addition to these clues, in both projects, everyone we interviewed had a different version of what the standard process was.
In my most recent project, Admission through the ED, there were 12 "supplier groups" in our SIPOC process map (ED Nurses, ED Techs, ED Physicians, Admitting Physicians, Case Managers, Bed Control Managers, ED Unit Clerks, Nursing Unit Clerks, Nursing Unit Nurses, Housekeepers, Maintenance, and Registration Clerks.)  Each had a different time for shift change, with 8, 10, and 12 hour shifts among the various groups.  The process changed each time a group's shift changed.  You won't be surprised to find out that we started at a negative Sigma level.  We moved to lean tools almost immediately.  And yes, we did reach a positive Sigma outcome, although we also followed up by chartering two Standard Work Projects, one for housekeeping and one for getting the patient ready for departure to their inpatient room.  
This makes me think that perhaps we should not start a DMAIC project with a very low Zst score - we should do a standard work project first.  Is Lean - then Six Sigma - a logical approach?  Or should we start with Six Sigma / DMAIC and then incorporate lean in the Improve phase?  SHould I'd love to know more about your own experiences.  Thanks in advance for sharing.
 ]]></description>
			
			<author><![CDATA[Sue Kozlowski]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 08 May 2006 13:51:35 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What We Ask Our Black Belts To Do]]></title>
			<link>http://blogs.isixsigma.com/archive/what_we_ask_our_black_belts_to_do.html</link>
			<description><![CDATA[I am regularly asked what characterizes an ideal Black Belt candidate. Like most people in the field, I have a list of adjectives and descriptive phrases I can trot out at a moment’s notice. Mine comprises about 50 items under the following headings: 1) Aptitude For Change; 2) Education and Experience; 3) Intellectual Curiosity; 4) Leadership and Interpersonal Factors. If pressed, I have a PowerPoint version of my list that I can speak to. If really pressed, I have even organized my list into matrix that can be used to score candidates. But to be honest I find that one good conversation with their manager is usually more informative than completing the matrix.
Every time the question comes up, I have the same thought after answering it: in order to define what characterizes an ideal Black Belt candidate, we first need to understand what we expect Black Belts to do. And every time I try to do that, I’m struck by some basic problems. Because often, we seem to expect them to do everything.
Consider a basic tool taught in most Six Sigma curricula: the SIPOC, which stands for Supplier, Input, Process, Output, Customer. (Some organizations cleverly reverse the acronym – COPIS – to emphasize that the customer should come first. Others add additional letters in various spots.) The purpose of a SIPOC is noble – to understand the entire process at high level, beginning with the supplier and ending with the customer. And while the Black Belt normally has a team in place to help them formulate and develop the SIPOC, it’s the Black Belt who owns the tool and the project at the end of the day.
It’s right about here that I start to get confused about what we are asking Black Belts to do. The dogma is that projects need to start and end with the customer, plus include the entire value stream, plus reach out to suppliers, plus touch on multiple functions within the organization. And while there can and should be a project team in place, the ultimate responsibility for all of these things does lie with the Black Belt. But how many Black Belts are suitably qualified (via experience, positional authority, contacts within the organization, etc, etc) to reach out in all these directions effectively? Can you think of a single individual in your organization that you’d be comfortable asking to do all of those things – personally visit with customers, work with suppliers, cut across internal functions, etc, etc? In my experience those people are extremely rare, and many of them already have “chief” somewhere in their title.
So where does that leave us? We need to develop Black Belts through training and experience, of course, but that takes time a multiple projects. What to do on the first, second, and third projects? Picking the right team is one obvious answer, but if the Black Belt doesn’t know what they are doing to a certain extent in all areas, then picking teams members who are very good at their particular function may or may not turn out well in the end. And it’s not easy to do, because those people are typically in very high demand. Anyone who has seen a wave of 20-30 (or more) Black Belts all attack their first projects at once knows this firsthand.
My suggestion is that the organization in general, and the Six Sigma (or equivalent) function in particular, should bear some responsibility for managing the interface between generation of knowledge (i.e. finding out what to do) and the execution pathway suggested by that knowledge (i.e. doing it). Put another way, perhaps the role of the Black Belt ought to be to investigate, understand and recommend…but execution and other aspects of realization ought to be left to those who best understand the area where the activity will occur.
For example, why do we ask Black Belts to go out and listen to voice of the customer? Don’t we have sales and marketing functions that ought to be doing that? Presumably those folks will be much better at it than a newly minted Black Belt anyway because, frankly, they ought to be experts. And if the sales and marketing folks aren’t good at it, then perhaps we ought to focus on that problem rather than institutionalizing a workaround via Six Sigma training. Which I think is what we are really doing if we give Black Belts end-to-end responsibility for a project. We’re admitting that our functions don’t work well together. If we ask a Black Belt with an engineering background to go out and listen to voice of the customer, then we might win the battle for the specific project (although in practice I actually don’t think this happens very often), but we lose the war for organizational effectiveness as a whole. And that’s definitely not what we should be asking Black Belts to do.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 04 May 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Does It Actually Matter What We Teach Black Belts?]]></title>
			<link>http://blogs.isixsigma.com/archive/does_it_actually_matter_what_we_teach_black_belts.html</link>
			<description><![CDATA[In an earlier blog entry (here), I described my feelings on DMAIC and roadmaps in general. To make a long story short, I don’t believe they add much value to the core toolset of Six Sigma. A couple of folks quite rightly expressed their disagreement with my view via comments (here). I say quite rightly, because I don’t have data to back up my hypothesis that the roadmaps don’t matter. To get that data it would be necessary to run experiments at a program level comparing projects (or even entire deployments) done with and without a roadmap. I haven’t done that, and I don’t know of anyone else that has either.
Lack of data, however, generally doesn’t stop me from speculating. And in that spirit, while we’re talking about program-level and deployment-level experiments, there’s one that is even more fundamental that I have often thought about. It’s a scary one to consider about for those of us whose jobs, in whole or in part, involve arranging and facilitating Six Sigma training. The experiment essentially asks the question: does it really matter what we teach Black Belts?
Let me explain. Any Six Sigma program that I’ve ever seen or heard of (or any continuous improvement program, for that matter) starts off with a pitch to executives in which some version of the following conditions are laid out, either by external consultants or an internal champion:

We need your absolute best people;
We need to free up those people to focus exclusively on Six Sigma work;
We need the most important projects to work on;
We need to make sure those projects are properly scoped and resourced;
We need to ensure that the organization supports people working on these projects from top to bottom.
Conditions 1-3 are usually the toughest to satisfy for reasons which are perhaps obvious, although 4 and 5 aren’t exactly easy either. In fact, most deployment leaders will tell you that a high percentage of their time is spent on 1 and 2 alone for the first few years of a deployment. Nevertheless, assuming the program is agreed to and competently managed, we end up somehow bringing our best folks together for four intense weeks of training, during which the concepts, tools, and methodology of Six Sigma are taught. Projects gets worked, and results happen. Everyone’s happy.
My question is this: what if we did exactly the same thing, but didn’t teach Six Sigma? What if we got our best folks together in a room one a week for four weeks over four months, focused them exclusively on the most important projects to the business, and gave them the resources and support they needed to get the job done…but didn’t teach them any new methodology? Would the outcome be materially different than if we taught them some roadmap or program?
In other words, maybe satisfying the conditions 1-5 – which make no mention whatsoever of methodology, roadmaps, DMAIC, statistics, etc, etc – is what continuous improvement really amounts to. Maybe the “sexy” methodology and jargon only provide a to a way to get the organization to agree to conditions 1-5 in the first place. Maybe the whole Six Sigma ball of wax is no more than a means to create the will to satisfy conditions 1-5.
This is the experiment that I invariably run in my head each time I go to a training event. I am struck every time by how bright and energetic the participants are, and how quickly they come together and make progress on their projects. This occurs in spite of – or perhaps because of – the fact that they are usually drawn from different geographies and business units. I’ve been involved with training programs that I think are absolutely top notch, but nonetheless I wonder…would these folks make more progress if we just got rid of the obstacles and let them get down to it with out interfering? Do we really need to teach them anything?
My hunch is no. I suspect if we truly got the best people focused on the most important projects with the right resources behind them, we wouldn’t actually have to teach them a thing. The problem is that conditions 1-3 are extremely difficult (maybe impossible?) to produce in the absence of a program with a lot of “sizzle”. That is, it’s relatively easy at this point in history to sell a Six Sigma program with all the attendant hoopla, but for whatever reason it’s hard to sell the idea of simply getting our best people working on our most important projects with everything else cleared out of the way. Perhaps when it comes down to it, the only reason to have a Six Sigma program at all is to create conditions 1-5. Maybe what we teach truly doesn’t matter.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 20 Apr 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Key Performance Indicators in Strategic Planning for Six Sigma]]></title>
			<link>http://blogs.isixsigma.com/archive/key_performance_indicators_in_strategic_planning_for_six_sigma.html</link>
			<description><![CDATA[It is very important to understand how to create a good key performance indicator or KPI for Six Sigma.  This is also true when you add Six Sigma to your strategic plan, as I have.
The KPIs that you develop must first be a goal(s) of your organization, department, etc.  These should be agreed upon.  Remember, these will indicate the target performance levels and the guiding light for your work, so get consensus.
As a leader the KPIs will help you make decisions, guide you to where you need to collect data (baselines) so you can create targets and give you an indication of what improvement(s) have been gained/lost and how you should use that data.  Keep in mind that these should be flexible too.
Do not keep your organization set to such stringent KPIs that they are constantly failing.  After your first year, if you fail to reach your targets look at why, don't just press to do better next year, keeping with the same goals set at the beginning of your strategic plan.  
Remember that in our changing world, we need to be able to change too. ]]></description>
			
			<author><![CDATA[Lisa Moore]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Wed, 19 Apr 2006 14:08:16 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: 7th Apr '06 v1.21.35a(iii)]]></title>
			<link>http://blogs.isixsigma.com/archive/7th_apr_06_v12135aiii.html</link>
			<description><![CDATA[Hi,
Not one of my usual insightful articles on the world of Six Sigma today (!) more of a request for your assitance, guidance and input.
I've recently taken the job of restructuring the electronic folder structure for our rapidly exanding team and ensuring it is tidy, functional and usable by everyone. 
As with all projects and project managers we create many documents which go through countless revisions and are subject to many last minute changes. This in turn creates version control and folders with 12 versions of the same document some with wholesale change some with a spelling correction. I believe this to be absolutely required for us to ensure we are doing our jobs properly but it does create a space issue on shared drives when a lot of people are saving mutiple versions of large documents.
So, what is the best practice for managing all these old version of Solutions Reports, Charters &amp; Quick Win Implementation Plans? Once the project is finished and signed off can we delete them or is that an audit/compliance/regualtory risk? We could burn them all to CD but that just creates a different type of storage and location problem.
How is it worked where you are?  I'm interested in implementing best practice and I know you know it. Drop me a line and let me know and I'll publish an 'industry wide' best practice here once it's all done.
Thanks for your help
Brian]]></description>
			
			<author><![CDATA[Brian Costello]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 07 Apr 2006 06:40:45 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: What's The Point Of A Project?]]></title>
			<link>http://blogs.isixsigma.com/archive/whats_the_point_of_a_project.html</link>
			<description><![CDATA[
In a perfect world, every project would lead directly to financial gain. We’d draft a charter that, when well executed, produced savings or income that translated directly to the bottom line. And this would be good because we all like making money. We can put it in the bank, earn interest on it, add many small amounts together, and eventually buy the things we need and want. That’s true of both businesses and individuals. We like financial gain not for itself, but because we enjoy the benefits that financial gain can bring. So, we conceive of most projects along the lines of the structure below.

Trouble is, the link between project goals and delivering financial gain is seldom as direct as we’d like it to be. Although there are exceptions, most projects require an intermediate series of steps wherein it is necessary to learn something. In other words, although we’d all like to proceed directly to financial gain, we usually don’t know how. So the project ought to be about going out and gaining some useful knowledge, then turning that knowledge into financial gain. The picture ends up looking something like the structure below. As I said before, there are exceptions (a project to increase capacity on a known product or service in an underserved market, for example), but in my experience the vast majority of Six Sigma projects have to follow the knowledge gain pathway because it’s the most efficient route to financial gain. If this wasn’t true, then the project would probably be addressed through some other methodology.

This being the case, it’s worth thinking about what we teach our Black Belts, and what we demand of them in terms of intermediate and final results. Certainly we all want the benefits of financial gain in the long run, and every project ought to have financial metrics. But if we recognize that knowledge gain is almost always a necessary precursor to financial gain for Six Sigma projects (and particularly if we believe that knowledge gain is the most efficient route to financial gain), then we ought to include in our methodology and metrics a way to capture and evaluate what has been learned as well. In fact, I believe this so strongly that I often insist problem statements be re-worded to emphasize knowledge gain at least as much as financial gain. Just like money can be banked and accrue interest, so too can knowledge. If we emphasize and value knowledge gain in our projects we end up not only making money, but increasing the level of knowledge in the organization as well. And just like with money, we can store knowledge away, assemble small amounts into larger ones over time, and pull it when we need it on a rainy day. In others words, knowledge is a bankable currency in the organization, just like money. 

In fact, looking at the diagram above, one might take the view that stored knowledge actually has more much intrinsic value that stored currency, because well-managed knowledge can be converted into dollars more than once; that is, even though we can withdraw at will from the knowledge bank, our store of knowledge does not deplete. Further, we have control over when and how we convert knowledge into financial gain, so it is a very flexible currency as well.
This is certainly not an original observation - indeed, I’m fairly confident that diagrams like the ones above have been scratched out in many organizations for more years that I’ve been alive - yet how many Six Sigma projects have metrics that measure knowledge gain in addition to financial gain? It’s a continuous improvement truism that we need to measure what’s important to us. My contention is that our measurements should include an assessment of what is being learned in addition to what is being accomplished. Properly managed and focused Six Sigma projects ought to deliver both knowledge gain and financial gain, and to make that happen the project (and program) metrics need to reflect both streams.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 06 Apr 2006 22:01:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Lean Government Conference]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_lean_government_conference.html</link>
			<description><![CDATA[Just a brief note of a great conference coming up on May 18 &amp; 19, 2006 in Alexandra, Virginia. Sponsored by The Performance Institute, The Lean Six Sigma for Government Conference will provide first hand case studies about government agencies where Lean Six Sigma tools are being successfully used. 
You can review the details at:  http://www.performanceweb.org/CENTERS/GPM/Events/P596/P596.htm
 ]]></description>
			
			<author><![CDATA[Stephen C. Crate]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 06 Apr 2006 10:11:34 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Beyond DMAIC]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_beyond_dmaic.html</link>
			<description><![CDATA[There is a strong tendency for Six Sigma programs to forge an inextricable link between project management roadmaps, notably DMAIC, and statistical tools. This has never made much sense to me. In my experience, Six Sigma programs can not only exist and survive without the use of typical roadmaps, but prosper and flourish.
In the vast majority of Six Sigma environments, it borders on heresy to even ponder whether some, if not all, projects couldn’t perhaps be completed without the use of a roadmap. While it is probably the case that the DMAIC framework is efficient and appropriate for a certain subset of projects in most organizations, I have never been able to accept it as the panacea that most people in the field seem to. And by people, I mean consultants and executives. Not experienced practitioners, because by the second or third Six Sigma project most folks on the front lines eventually realize that toll-gate driven roadmap processes consume enormous amounts of time and energy in the form of meetings. In fact, I suspect the majority of seasoned Black Belts would abandon toll gate reviews in a hurry if they had the choice.
Consider a class of 24 Black Belts, all of whom will complete 2 projects in a year. Suppose (conservatively) that each project team has 5 members, and (again conservatively) that each toll gate review will take 30 minutes. That adds up to 120 hours of time spent in meetings involving those who are supposedly the best and brightest in the company. And what do those meetings produce? Certainly they gather stakeholders together to inform and discuss aspects of the project. But do they make a material difference to the outcome of the project? In other words, would the end result be better, worse, or the same if we gave the Black Belt responsibility and authority to organize the project and team meetings as they saw fit, as opposed to imposing a DMAIC structure? I submit that in my experience there are few negative consequences to abandoning the toll-gate-roadmap approach, and numerous positive consequences. Fewer meetings are one such benefit…admittedly one of my favorites!
It is undoubtedly true that DMAIC and other roadmaps are: a) easy to teach; and b) easy to administer. This makes the roadmap approach a darling of consultants (who see a consistent and portable program that can easily be taught in many different environments) and executive management (who see that DMAIC in particular lends itself to tidy dashboards and displays). But do the steps add value to a product or service? In most organizations I suspect the Lean folks would consider canceling toll gate meetings an easy, quick-win project. My hunch is that they would be correct in most cases.
What’s the null hypothesis here? If the tacit assumption taught by consultants and embraced by executives asserts that roadmaps and tollgates are necessary, the hypothesis that needs testing is something to the effect of “does a program without any toll gates or roadmaps result in any statistically significant differences compared to a program based on DMAIC or some other roadmap?” And if there were differences, would they be positive or negative? In short, what are we getting for all the time spent on toll gate reviews and roadmap compliance, if anything?
My own view is that there is an infinite variety of improvement opportunities out there, and it’s nonsensical to suggest that any single roadmap will serve a significant portion of them well. Tacit agreement with this view is provided by the flurry of supplemental roadmaps that have appeared (and continue to appear) over the years since DMAIC was first introduced. So the test for the null hypothesis is both simple and audacious: run a Six Sigma program that does not depend on any particular roadmaps and see what happens; teach the tools of Six Sigma without the framework of DMAIC (or any other framework) and evaluate the results; trust practitioners of Six Sigma to decide for themselves how projects should be managed, when meetings should happen, what stages are appropriate for a project. In short, let go of structure and embrace flexibility.
As organizations turn more and more to innovation as a wellspring for continuous improvement, what we ought to be creating is not wave after wave of people who can follow roadmaps well, but rather creative map-makers who can and do chart new paths to any destination. To do that, we need to explore Six Sigma beyond DMAIC.]]></description>
			
			<author><![CDATA[Andrew Downard]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 30 Mar 2006 07:16:28 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: A Brave New World]]></title>
			<link>http://blogs.isixsigma.com/archive/a_brave_new_world.html</link>
			<description><![CDATA[When Jack and the lads (and ladies I’m sure) started putting together Six Sigma they got together in many rooms over many months and slowly designed an effective and data based project management and process control structure. For many years now it has worked effectively in businesses across the globe from manufacturing to finance and even into Federal Government. Billions of dollars, Pounds, Euros and Yen and other currencies we wouldn’t recognise continue to be saved and businesses now work more effectively with less waste and world class client experiences through the work of all the Belts from Yellow through Green to Black and the almost mythological sounding Master Black Belt.
Well, it’s the 21st Century now and as a BB of a huge 13 months experience, I propose a radical redesign. I’ve been thinking about it and, to be honest, I’m fed up with Measure and Analyse. I say we replace them with two new phases called Gather &amp; Fudge. Hence we have the newly designed DGFIC cycle. I don’t want to even propose how that is pronounced.
My rationale is this – I am currently at the stages formerly known as Measure &amp; Analyse and to be honest I’m fed up with them. If I have to transpose another piece of data from a business-owned, roughly chucked together spreadsheet into a nicely formatted and data cleansed BB-owned spreadsheet, move it into Minitab, spend far too much time generating beautiful Data Summary charts, boxplots and Histograms that prove the root causes of the problem beyond doubt and then moving the fruits of all that labour into an attractive, and concise, PowerPoint slide for presentation to MBBs and interested Execs then I am liable to go a bit mental and I may even, and this is a big step…I may even take a day off. Harsh words I know. 
So, now I say we replace these phases with Gather &amp; Fudge. These new phases involve gathering together all the business-owned spreadsheets and taking a look at them in a room for, oh, about an hour. We then produce some charts using partially fictional data (which we will call ‘assumptions’) mixed with the rough stuff from the business (which we will call ‘raw sample data’) and produce some interesting and ultimately misleading looking charts through Excel and Minitab. We then prepare a 15 slide PowerPoint presentation using lots of big words that back up the hunches that we, as very experienced process improvement professionals, had at the start of the project while comparing them to the hybrid raw/assumed data charts. It sounds fantastic to me and a lot more stress free. 
Let’s look at the data. First, cycle time improvement. Measure &amp; Analyse cycle time averages anywhere between 4-8 weeks depending on your business. Cycle time for the new Gather &amp; Fudge, I would assume, would average in at about 4-5 days. Now, as Black Belts, how can you possibly argue with a cycle time improvement of up to 7 weeks.
Second, capacity. Subsequent capacity benefits that F&amp;G bring to Six Sigma deployments across the globe are mouth watering. Perhaps upwards of 2 BBs on an average programme.
And there it is. Gather &amp; Fudge not only explained but demonstrated.
I am willing to discuss the new DGFIC cycle at conferences, seminars and huge corporate events across the globe for a hefty fee. 
DGFIC is the future, people. You’re either with it or without.
P.S. I’m willing to discuss anything up to a three book publishing deal if anyone is interested. ]]></description>
			
			<author><![CDATA[Brian Costello]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 15 Mar 2006 02:50:54 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Unexpected Application of Lean Six Sigma Tools in Daily Operational Activities]]></title>
			<link>http://blogs.isixsigma.com/archive/unexpected_application_of_lean_six_sigma_tools_in_daily_operational_activities.html</link>
			<description><![CDATA[Sometimes operational people from my organisation approach me with “the” 1000-Euro-question: “Six Sigma guy, can you please help me analyze this set of data.”  Asking me to help, they usually have an issue they really can’t resolve themselves. Perceiving Lean Six Sigma too far away from daily operations they turn in despair to the Six Sigma guy, hoping he can help and his expensive training program can be justified after all… 
My standard answer is (of course, because I want to prove Lean Six Sigma is beneficial for daily operations) “Sure, let’s sit down for 10 minutes and discuss your question”.   Sometimes, I find there is no clearly defined purpose for the data analysis, or there is no clear answer to the simple, but fundamental question “What do you want the data to tell you?” In such case, Six Sigma guy can’t help either…
Luckily, many times, the purpose is clear, or the situation described above can be cleared out asking the 5 why questions. Then it sometimes astonishes what results you can get using simple tools as Pareto charts, histograms, run charts, box plots and/or scatter plots. 
Last week I even astonished myself when a manager approached me to help him organize price quote data from multiple subcontractors in such a way that decisions could be made. Each subcontractor quoted unit costs for more then 100 different specific tasks. You can image how that data matrix looked like in Excel… 
Together with the manager, I applied 2 different tools to organize the data and draw conclusions:
1. Box plots. The box plot outliers showed us clearly which quotes were unrealistically high and low. Using the brush function in Minitab, we could deduct that 80% of the high value outliers were caused by one subcontractor. On the low values, we saw a similar phenomenon. 
2. Using the characteristics of the normal distribution. Per task we have 8 data values available. Not all these data sets were normally distributed, but we did the following: calculation of the average x-bar and the standard deviation s. A characteristic of the normal distribution is that 68% of the data is covered by x-bar +/- 1 s. Or, 32% of the data can be found outside these values, meaning 16% at the lower end and 16% at the higher end. Guess what? 99% of the data points in this lower and upper end of the distribution also showed up as outliers in our box plot analysis.
In the past the decision would have been to grant the contract to the cheapest subcontractor without asking further questions. This has lead to quality losses and rework in the past. Today, we’ll invite the cheapest and ask clarification to ensure us of the understanding of our requirements, thus ensuring us of 1st time right quality at the right price. 
And I can assure you, by this unexpected application of simple tools, this manager is now 200% convinced of the value add Lean and Six Sigma tools can bring to the daily business of the organisation!]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Mon, 06 Mar 2006 10:24:01 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Change and Documentation]]></title>
			<link>http://blogs.isixsigma.com/archive/change_and_documentation.html</link>
			<description><![CDATA[In a business process improvement project, a critical factor is documenting the standard work or the "least waste way." One of the issues I have been dealing with recently is ensuring that documentation is in place and up to date. Unfortunately as the saying goes, "the only constant is change..." and as outside factors change (notably customer requirements), the "least waste way" changes as well.
A particular example I experienced recently was when one of our major customers changed to a new part revision number. This change caused one of our core manufacturing processes to change - slightly - but very critically to customer quality. The change was unplanned and pushed onto us very quickly. Our engineer and one of our manufacturing techs were more than able to quickly accommodate, but in the heat of the moment, documentation steps were skipped. One week later the engineer who received and translated the customer request to our manufacturing processes has left the company.
In the chance that our manufacturing tech originally tasked with the change calls out sick, goes on vacation, or just plain forgets, we will be forced into an expensive manufacturing line stop, and an embarrassing call to our customer for help on rehashing the revision change.
As the continuous improvement specialist in the department I am tasked with creating a way to ensure that the documentation steps are never skipped. We have a full centralized documentation system (WebDocz) in place, and virtually all employees are knowledgeable and empowered in the system. What methods are being used to ensure documentation without giving up or impeding customer needs/requests?]]></description>
			
			<author><![CDATA[Rick Maher]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 06 Mar 2006 10:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: A Slow Start...]]></title>
			<link>http://blogs.isixsigma.com/archive/a_slow_start.html</link>
			<description><![CDATA[Six Sigma started in our department slowly.  There were many factors that played into this, but mostly staffing issues:
1. I only have a staff of student employees (from 8-16 per year).2. This staff is in a constant state of change.3. Students come with various skills, many with no math or business or technical background.4. Knowledge transfer/capture had to be a major component of our setup.
At the onset I was lucky to be the only upper level individual who had to champion this idea and support it.  With that out of the way, I was on a quest to find a couple of student employees who not only possessed skills to help support our effort, but also a drive to do this since it went well beyond what any of them were hired to do.
At the time I had a strong set of level two techs who fit the bill so I enlisted their help.  They were both curious and anxious to work on this.  I had communicated what I wanted to do, why it was necessary, and what the benefits would be and they agreed. 
The first step was to train everyone.  This training would get them up to speed but would also become a test on how to train others that would follow.
Our university has a Blackboard system and I saw it as a perfect place for this training to occur. Blackboard is a web-based teaching/learning system which supports online documents, bulletin boards, tests, etc.  They could learn whenever it was good for them...it was perfect!  I developed the initial online site and began publishing documents/bulletin boards/quizzes and they jumped in and started learning.  As we moved along their feedback was invaluable to me on what worked and concepts that should be broken down more.
Once we had a good basic training program developed we began looking at these employees skills and I realized that I had a vast knowledgebase at my finger tips and that the iron was hot to start training others.  Until people could grasp some basic understanding about what we were about to accomplish how could they back this and help?
The remainder of my student employees began this online course and all finished by the end of the school year.
Great.  I had 8 people who had taken this basic training.  Two would not return the next year and I had three new people to train that next fall.   ]]></description>
			
			<author><![CDATA[Lisa Moore]]></author>
			
			<category>
			<![CDATA[Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 23 Feb 2006 05:48:10 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Way We Work! by Arthur “Roy” Johnson]]></title>
			<link>http://blogs.isixsigma.com/archive/the_way_we_work_by_arthur_roy_johnson.html</link>
			<description><![CDATA[An iSixSigma reader submitted the following article for publication on iSixSigma.com.  From time to time we receive excellent submissions such as this one that are perfect for publication on the iSixSigma Blogosphere.  
The way we work! By Arthur “Roy” Johnson 
As someone whose management career began during the era of quality management principles, I fear that yet again we are poised to repeat the mistakes of the past. The concern is that we will fail to adequately understand and embrace the benefits of Lean Six Sigma, just as we did the quality management programs of the 1980s. Company leaders then did not learn the lessons they insisted their employees embrace. And the followers of quality programs of the day were zealous, but they were not champions, who could create an environment of ownership, empowerment and most of all opportunities for individual growth. Now, roll forward 15 years or so and we see that Six Sigma combined with Lean is a powerful weapon in the battle to gain sustainable continuous improvement outcomes in processes.
Today we see efforts to embrace Lean Six Sigma gaining momentum and yet many appear to have embraced the Lean component alone.  There appears little or no regard neither for understanding and utilizing the benefits of Six Sigma nor for that matter of using them simultaneously in any continuous improvement approach.  Conducting a Kaizen Blitz and implementing 5S practices now seem to be the panacea of today’s line managers.   One wonders whether we are not once again taking the approach of change for change sake, brandished under the umbrella of a Kaizen Blitz and 5S!  Transformation of a process area, utilization of brainstorming practices and employee involvement all sounds well and good but again one wonders if these improvements are sustainable? 
How many companies have spent considerable time, effort and money with the implementation of Kaizen Blitz events, followed by much fanfare and initial success, only to find months later that the changes have fallen into a new state of chaos?  Rather than learning from the past I suggest that many of today’s managers, instead of using Lean Six Sigma Methodologies in a systematic and holistic approach to process improvement, have taken to picking the “eye teeth” from the methodologies.  In short it is my experience that some appear focused upon using only those components that bring immediate gratification.  Components that allow them and their teams to take immediate action and to make changes that allow them to be seen to be doing something proactive.  
I believe that the misuse of Lean Manufacturing, being seen by many as simply a never ending series of Kaizen and 5S events, will eventually prove to be counter productive and again the risk is that Lean Six Sigma will become seen as simply another fad.  The failure to fully embrace the need for accurate and focused statistical measurement and analysis, means that many are implementing changes within the workplace in an adhoc fashion without understanding the implications impacting the entire process.  For many this will be a familiar theme to that which we faced as line managers in the 80’s.  The truth is that Deming emphasized the need for Statistical Process Control as well as his 14 Point Management Plan yet all too often we only focused upon the people involvement components of TQM. 
Today we once again find that our focus appears drawn to Lean Manufacturing alone.  I contend that if we fail to understand and combine the Six Sigma components into our Lean Programs then we will once again fail, as we did before!  We need to combine Lean and Six Sigma methodologies in such a way that they become a way of life not a fad.  In my belief Lean Six Sigma should and can become the language of the business, "The way we work."
About The Author: Arthur “Roy” Johnson has more than 20 years experience managing manufacturing entities in a variety of fields including the plastic, chemicals, FMCG, retail and ophthalmic sectors. He is a qualified Industrial Engineer and has held a number of senior roles in his career, most notably as Director of Manufacturing with Amoco Corporation and was a Group Manager of OPSM Group Ltd.]]></description>
			
			<author><![CDATA[Blog Admin]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 16 Feb 2006 07:45:15 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Lean and Six Sigma in service and manufacturing industries]]></title>
			<link>http://blogs.isixsigma.com/archive/lean_and_six_sigma_in_service_and_manufacturing_industries.html</link>
			<description><![CDATA[Lean and Six Sigma applications are different between service industries and manufacturing industries. 
Is that statement really true? There is no straightforward answer. The answer is ambiguous. It can be: no, there is no difference. But it can be: they are the same to certain extend. The answer can also be: yes, the application is different. An additional possible answer might be : it depends on the  kind of activity.
No, there is no difference. Regardless if you are in a service of manufacturing environment, the work unit in progress is transformed from an input to an output ready to meet customer demands, using a process. Regardless if you are in a service of manufacturing environment you need universal “core processes”: a process to develop products/services, a process to bring them to the market, a process to produce them, a process to cash in revenue generated by them and a process to take care of your customers during use of them. Of course, you also need processes that support the “core processes”. If you have a process, you can apply Lean and Six Sigma principles and tools.
They are the same to certain extend. In theory the universal processes needed in service and manufacturing organizations are perhaps of a similar nature, in reality they are not fully comparable. An example: the typical life time of a car generation in the automotive industry is about 4 – 6 years. The typical life time of a communication product generation is a couple of months, 2 years maximum. There is clear difference in product generation turnover. Consequently, processes need to be designed and put into production a lot quicker, there is less time to optimize and lean them out to the full extend. This would suggest quick changing service industries should get their products and processes as defect free as possible before launching them. As this is certainly not always the case, service organizations may end up in endless loops of fire fighting. It might explain the current success of DMAIC and DFSS in service industries. (At least if success can be measured on the amount of white papers and book publications on this subject)
Yes, it is different. In manufacturing industries you can see the raw materials or semi finished product transform into the final product along the production line. In a service environment at best you can follow a paper flow, but in most cases you’ll need to trace the production history of the service in the computers. This creates certainly differences in the application of some of the tools. Take Value Stream Maps as an example. In manufacturing you can go see the shop floor and count the work in process in between the different work stations. In service industries you’ll need to dive into the computers and torture them until they give away their secrets and tell you where the work in progress is waiting to be processed. This can be a discipline in itself. The type of data is different. Sure, you’ll find continuous and attribute data in service and in manufacturing, but not in the same amounts. In manufacturing, most of the data is continuous. In service the data I come across mostly is attribute. This has consequences on the application of many analysis tools (graphical tools and hypothesis tests), determining process capability and control charts.
It depends on the kind of activity. There is no such thing as the service industry and the manufacturing industry. A car glass repair specialist with workshops and mobile workforces is a total different kind of service then banking or insurances. Chemical process industry is a totally different kind of manufacturing industry then automotive assembly. Consequently, there might be big differences in the application of Lean and Six Sigma principles in service and manufacturing industries, depending on the type of activity.
Please feel free to comment on my thoughts and elaborate further on them, especially if you have had the opportunity, like me, to gather experience in both types of industry.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Fri, 10 Feb 2006 07:42:02 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Maine Department of Labor Lean Initiative]]></title>
			<link>http://blogs.isixsigma.com/archive/maine_department_of_labor_lean_initiative.html</link>
			<description><![CDATA[Applying the Principles of Lean and Public Value to Reshape a Government Agency
In the fall of 2003, the Maine Department of Labor began a tailored change initiative to fundamentally alter the culture and work of the agency.  Combining time-tested “lean” principles from the manufacturing sector with the emerging public sector strategy of “public value,”*  the Department of Labor is improving the quality and efficiency of the services we provide, and doing so with less money.
Like many state agencies, the Maine Department of Labor faces flat or reduced funding streams at a time of steady increases in operations costs. The term “Bend the Curve” relates to the effort to alter the direction of charted projections, to eliminate a looming $9 million shortfall.
The term “public value”*  refers to an emerging public sector strategy to assess the value of government services, products, and regulations to the constituency served by each. Value can be determined only when a constituency “is willing to give up something in return for it.”

* Kelly, Mulgan and Muers, Creating Public Value: an analytical framework for public service reform, see  http://www.annual-report.gov.uk/files/pdf/public_value2.pdf
MDOL - Bend the Curve Goals

Provide the same or better customer service;
Shift the work of the department to match customer expectations and needs;
Achieve efficiencies by fundamentally changing how work gets done;
Improve intradepartmental collaboration and service integration; and
Decrease expenditures by at least $9M and significantly reduce staffing levels over three years while minimizing layoffs.
Better Customer ServiceBend the Curve also addresses the need to continue to provide public value in the services delivered by the department. With a focus on improved processes, measured outcomes, and service delivery from the perspective of the customer, BTC is changing the way we think about our work.
An Investment in LeadershipRecognizing the importance of empowering staff at all levels of the organization to work collaboratively in the change process, the department is investing in the leadership skills of both management and front-line staff.
Continuous ImprovementUsing formal continuous improvement tools, BTC teams address efficiency in service delivery by measuring the current state and planning and implementing a future state that eliminates waste and enhances services to the customer.
For more information about the Maine Department of Labor’s Lean Initiative see their website: http://www.maine.gov/labor/bendthecurve/index.shtml
 ]]></description>
			
			<author><![CDATA[Stephen C. Crate]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Leadership&nbsp;,&nbsp;Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Thu, 09 Feb 2006 06:35:39 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Healthcare is A Lot Like Manufacturing]]></title>
			<link>http://blogs.isixsigma.com/archive/healthcare_is_a_lot_like_manufacturing.html</link>
			<description><![CDATA[Lean Six Sigma’s application to healthcare has been slow at best. One reason for this is that healthcare professionals view manufacturing as an industry that deals with the simple process of making inanimate objects. Healthcare, on the other hand, deals with complex processes that improve and prolong the functionality of the human anatomy. Consequently, healthcare professionals believe that the methods used in manufacturing, such as Lean Six Sigma, are inappropriate for healthcare. The concept of "muda" (Japanese for waste) is a hard concept for many in the healthcare industry to grasp. In a system where the workflow is aimed at treating an ailment, waste can be hard to spot. With the frame of mind, eliminating this waste can seem like a disservice to clients and customers.
However, healthcare has some parallels to the manufacturing industry. The irony is that the patient can actually be thought of as a custom tool. Because of the uniqueness of each individual, the healthcare service must be appropriately tailored. Each person has to be treated differently, and healthcare workers must contend with differing procedures for patient-specific payers (insurance companies). In many cases, patients make multiple visits when their problem has not been resolved. In manufacturing, this typically referred to as "rework." This is where the analogy of manufacturing to healthcare falls short. A manufacturer is never compensated for rework, whereas healthcare providers are paid for incorrect diagnosis or botched surgeries. With the exception of malpractice lawsuits, the healthcare industry is typically reimbursed for rework. So, it is not surprising that there is little incentive to apply manufacturing methodology like Lean Six Sigma to the healthcare industry in order to reduce errors. In reality, it is estimated that the total cost of error or rework in healthcare is greater than ten percent of the total system cost. 
The industry must take a fundamental look at the way it provides care, ultimately acknowledging that the system is flawed. Using the techniques of Lean Six Sigma allows for periodic updates to reflect the ever-changing delivery and technology of healthcare. In an industry where expectations are a moving target, the principles of Lean Six Sigma can help to reach the highest possible performance. This may be the best reason of all to consider a proven manufacturing technique.]]></description>
			
			<author><![CDATA[Andrew M. Hillig]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Wed, 08 Feb 2006 09:42:52 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Communicating Process Capability]]></title>
			<link>http://blogs.isixsigma.com/archive/communicating_process_capability.html</link>
			<description><![CDATA[Have you experienced the following? Consider that after implementing an improvement the process capability has improved from 3.5 sigma to 4.2 sigma. Proudly you celebrate this very nice Six Sigma methodology success in your organisation. How many questions did you get after or during your presentation about how important this improvement really is? What does this mean for the participants in your improvement team(s) and your management or the process owner? And even more important, what are the true consequences for the internal or external customers of this process?
Especially at the beginning of a six sigma deployment not many people in the organisation can relate to the sigma capability metric. Yes, some might already know that a 6 Sigma process produces 3.4 defects per million opportunities and that a 2 sigma process is a bad performing process with important defect rates.  But do people understand the true impact of the improvement from 3.5 sigma to 4.2 sigma (regardless whether it is long or short term capability). 
In any organization that has traveled on their Six Sigma journey, there are a lot of people that have heard about the sigma metric and know what it is (from white, yellow or green belt training or because they have participated in an improvement team) but have no real feeling of the process performance reflected by it.
Here is how to solve that problem: I find it much easier to make myself understood describing process capability improvements by the DPMO metric. Take the same numbers as in the example above. Substitute the initial 3.5 sigma capability by 22,750 DPMO and the after improvement capability 4.2 sigma by 3,467 DPMO.  Participants in improvement teams, management and process owners will immediately sense the magnitude of the improvement made, defects reduced from 2.3% to 0.3%.]]></description>
			
			<author><![CDATA[Sven Saerens]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 19 Jan 2006 12:34:50 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Project Wheel of Re-invention]]></title>
			<link>http://blogs.isixsigma.com/archive/project_wheel_of_re_invention.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.  What do you tell them?
Nayism 16:  We’ve been working projects on the same processes for the past 5 years.  Just how many times are we going to re-invent the wheel?
This type of statement is frequently heard from folks that view improving a process as a one-time deal.  It may be indicative of the "I’ve fixed everything there is to fix so can I go home now?" syndrome.  You can approach this thinking by introducing the "Project Wheel of Re-invention" because it’s not about re-inventing the wheel; it’s about working your way through the "wheel of re-invention".  So, here’s what I say . . . 
At a macro level, a company or corporation has one huge process that begins with an external customer and ends with the shareholder.  This huge process is made up of an infinite number of sub-processes that span across numerous functions.  An organization is usually segmented into functional areas (i.e. IT, Accounting, Operations, Maintenance, etc) to facilitate the segmentation of work.  Initially, Six Sigma projects begin at the functional level.  This is usually the case because ’functional silo’ thinking still exists in many organizations. Processes within a function are improved to the point that additional improvements can only be obtained by addressing cross-functional interfaces. The cross-functional aspects of a process are then improved until the process is performing near entitlement.   The only way to get the next step of improvement is to redesign the process with DFSS.  Once redesigned and implemented, improvements to the new process again begin at a functional level.  Next cross-functional processes are improved and then they are again re-designed and then the functional processes are improved  . . . are you dizzy yet?  
This "Project Wheel of Re-invention" is constantly turning and must turn in order to move the organization forward.  The constant cycling of projects that address functional and cross-functional process improvements and then re-design the process only to have functional and cross-functional projects again improve the re-designed process is necessary in order to keep up with changing expectations.  Customers consistently expect more, technology facilitates better and faster results and expectations from shareholders constantly rise.    If your project wheel of re-invention is not keeping pace with these changing expectations then you should brace yourself for that big "whoosh" sound as your competitors pass you by.]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 05 Jan 2006 15:35:31 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Thanksgiving Design of Experiments]]></title>
			<link>http://www.sixsigmacompanies.com/archive/thanksgiving_design_of_experiments.html</link>
			<description><![CDATA[This week I bring you two delicious DOE’s (Design of Experiments) as a Thanksgiving treat. The First, Applying DOE to Microwave Popcorn, is a real favorite of mine.  Mark Anderson and Hank Anderson share a Design of Experiments that identifies what really matters when making microwave popcorn. 
In the second, Recipe for Pound Cake Experiment, Mark Anderson and Patrick Whitcomb experiment to give us the optimal recipe for pound cake derived by DOE.  Thanks to Stat-Ease Inc. for these case studies.  
So now all you Green Belts and Black Belts have something to share over Thanksgiving dinner when someone asks you, "What do you do for a living?"  Bon Appetit.
 
 ]]></description>
			
			<author><![CDATA[Michael Marx]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology&nbsp;,&nbsp;Six Sigma Articles &amp; News]]>
			</category>
			<pubDate>Mon, 21 Nov 2005 19:38:04 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Won't Work For Me]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_wont_work_for_me.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of  Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.  What do you tell them?
Nayism 9:  Six Sigma won’t work for my department because we really don’t have standard  ’processes’ and every client, customer or situation is different.
Process thinking is a new way of viewing how products and services are actually produced.  Sometimes, due to the type of product or service, people have difficulty visualizing that they actually have a process.  Many times this is caused by process steps that are done in parallel or in no specific order so it’s difficult to visualize a process.  But as you start looking more closely, there are steps and requirements.  Sometimes asking a series of questions can help people visualize their processes and understand how Six Sigma can help.   So, Here’s what I say (or rather ask) . . . 
What is your end product or what do you provide to the corporation?  Who’s your customer?  Does your product or service meet your customer requirements?  How do you know?   What are the critical aspects of providing an excellent product or service?   What do you measure to better understand how well you are doing? How do these measures compare to benchmarks?  What does it cost you to produce your service?  What drives this cost?  How many resources are involved?  How long does it take?  How does your product or service impact your organization’s bottom line?  Will improving your product or service quality or delivery reduce cost or improve revenue?   . . .
These types of questions are aimed at helping organizations understand what they produce (product or service) in quantifiable terms and to better understand the drivers of service quality and cost.  Drilling into how their product or service is produced (steps, inputs, etc.) helps define the actual process.    Once a process and a possible ’defect’ or improvement opportunity in the process is defined, a Black Belt can describe how the Six Sigma methodology can be applied to improve the outcome .   "Taa Daa’, instant buy-in.   OK maybe not, but at least an incremental learning activity that can position the organization to be willing to try it.  If tried and successful, the probability of buy-in should go up.]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Management&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 29 Oct 2005 05:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma &amp; TQM]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_amp_tqm.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.  What do you tell them?
Nayism 7:  Six Sigma looks like repackaged TQM.  What makes you think its ’staying power’ is going to be any different?
When people first hear about Six Sigma, some may see it as repackaged TQM.  Skeptics frequently draw conclusions based on ineffective TQM efforts. There are notable differences that should be discussed.  So, here’s what I say . . .
Although there are many similarities between TQM and Six Sigma, there are several standard and required key attributes that give Six Sigma more staying power.  These include having a more structured step-wise methodology, rigorous financial validation and documented accountability for process improvements.  
The structured methodology of Define-Measure-Analyze-Improve-Control (DMAIC) provides an organized method for applying tools and statistics to identify the root cause of problems.  The tools and statistics are not new, but the organized consistent methodology brings a more systematic approach to the problem solving process.
The intense involvement of the financial department in validating savings has added credibility to the hard savings that can be achieved by Six Sigma projects.  Done properly, this validation substantiates that savings are measurable, tied to the actual improvements and to the bottom line.  There are no smoke and mirrors here.
Control plans assure that gains are sustained.  Periodic monitoring of key variables is required by the "control phase" of a six sigma project and is an ongoing verification that process improvements are actually being maintained.  
Although some TQM initiatives had pieces of or possibly all of these attributes, an effective Six Sigma deployment will assure that these items are deployed with the rigor and standardization required to assure continued success.]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sat, 15 Oct 2005 05:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma Project or Just Do It?]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_project_or_just_do_it.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.  What do you tell them?
Nayism 6:  I already know how to fix the problem.  I really don’t need a Six Sigma project to tell me what I already know.
Sometimes people get confused between what’s a real six sigma project and what’s a "Just Do It".  Since they already have an answer to the problem, they believe that doing a Six Sigma project may be a waste of time.  So here’s what I say . . .
There are many answers to every problem.  The real question is have you identified your customer requirements and measured and validated data to identify the root cause of your problem?  If not, a Six Sigma project can accomplish this for you.  In addition, the project can provide a viable answer and validate that the answer will make a ’real’ difference (statistically).  And, by the way, the project can establish a control plan to make sure your fix stays in place.  If your answer does all this then I’d say, "Just Do It" !]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sat, 08 Oct 2005 05:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Six Sigma &amp; Business Success]]></title>
			<link>http://blogs.isixsigma.com/archive/six_sigma_amp_business_success.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.  What do you tell them?
Nayism 5:  If Six Sigma helps businesses be successful then why have some businesses that have implemented Six Sigma not done well?
This question is quite typical of questions you get at initial deployment.  Skeptics and "nay-sayers" are always looking for examples to challenge the effectiveness of Six Sigma.  It’s important to address these concerns head-on.   So, here’s what I say . . . 
Six Sigma is a business philosophy and methodology that contributes to a company’s success by providing the organization with new skills and techniques to better achieve their strategic objectives.  The Six Sigma methodology does this by looking at processes with a focus towards eliminating defects, reducing cycle time, improving customer satisfaction and bringing the benefits of these changes to the bottom line.  Deployed correctly, it also helps redefine the way people think, act and work.  It is not itself a ’strategy’ but a pathway for achieving a company’s strategic objectives.  If a company’s strategic direction is off target, Six Sigma may be of little help.
Here’s an example to help further explain this point.  If a company wants to make beepers, Six Sigma can help them make the best performing and cost effective beeper in the world.   But if everyone wants a cell phone, having the best performing and most cost effective beeper won’t help the company’s ultimate business outcome.     ]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[General&nbsp;,&nbsp;Methodology]]>
			</category>
			<pubDate>Sat, 01 Oct 2005 05:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Project Cycle Time]]></title>
			<link>http://blogs.isixsigma.com/archive/project_cycle_time.html</link>
			<description><![CDATA[Benchmarking results consistently identify examples of Six Sigma success.  Even so, getting "nay-sayers" on board is a continuous challenge.   What do you tell them?
Nayism 4:  Six Sigma projects take too long to complete.  I need to get this fixed now.
Actually, they should have probably had the problem fixed 3 years ago.   And maybe they did.  A long-standing problem has probably been fixed a couple of times, but since the solution did not address the root cause, they get to fix it again.   So, here’s what I say . . . 
Properly scoped Six Sigma projects can be easily completed in 2-3 months if several things are in place including good data and team resources.  Good data is usually the culprit that drives up project cycle time.  Once an organization is using Six Sigma they frequently find that good measurements and good measurement systems are not readily available.  It may take some additional time to get these measurement systems in place but once established, data gathering, analysis and ultimately the right fix can be put in place in a relatively short period of time.  Need to get it done faster? Then you should accelerate the project time-line and resource commitment.  The bottom line is that it is going to take a certain amount of time and resources to gather and analyze data.  If you skip this step, then you can look forward to fixing the same problem next year.]]></description>
			
			<author><![CDATA[Gianna Clark]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Sat, 24 Sep 2005 05:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: Are All Six Sigma Deployment Models Equal?]]></title>
			<link>http://blogs.isixsigma.com/archive/are_all_six_sigma_deployment_models_equal.html</link>
			<description><![CDATA[Do all Six Sigma deployment models return the same results – proportionally – to the resources and time invested? The topic of deployment models can be a thorny issue among Six Sigma practitioners. Many claim that the best model is to initiate a Six Sigma program from the "top-down" (ala GE’s Jack Welch, who mandated that every person would be Six Sigma-trained and many would be certified). Others argue that equally enviable results can be obtained from "middle-out" or "bottom-up" deployment models.
On June 28, 2005, I had the opportunity, along with Michael Marx, to hear both William Swanson, chairman and CEO of Raytheon, and Timothy Tyson, president and CEO of Valeant Pharmaceuticals, at the ISSSP Leadership Conference in Scottsdale, Arizona, USA. Listening to these articulate business leaders, it became clear that a "top-down" approach to deploying Six Sigma has significant merit. Both set a clear vision and defined strategy for their businesses, and are committed to using Lean Six Sigma to execute. They allocate resources, plan well, complete projects tied to their strategy, expect results and reward accomplishments. They aggressively tackle any roadblocks because they believe Six Sigma will help achieve their ultimate business goals and objectives. This type of deployment is the typical Jack Welch or Larry Bossidy model that led to success at both GE and AlliedSignal, respectively. It takes significant resources, but can often achieve payback within 12 months and return two to three percent of revenue per year (Cyger, Michael [2005]. The Missing Link? Why CEOs Can’t Afford to Ignore Six Sigma. Executive Decision, 40-49).
At the leadership conference I also had the pleasure of speaking with Jens Hansen, director of continuous improvement at Microsoft. Jens described a Microsoft culture of creativity dominated by engineers and programmers where "top-down" initiatives are anything but the norm. Instead, the continuous improvement team at Microsoft focuses on specific and strategic areas for improvement. Microsoft CEO Steve Balmer is unlikely to ever mandate Six Sigma training for the entire organization, but key leaders in strategic roles have experienced the value of Six Sigma in their organization. Terry Burton, consultant and author, would define this type of deployment model as "scaleable" where building blocks of a whole deployment are assembled in such a manner as to transition the organization to a Six Sigma culture at a manageable pace and scope. I call this deployment model "middle-out." Because it is usually initiated by leaders within one to three organizational layers of the CEO who have credibility, budget authority and the drive for the type of improvement Six Sigma can deliver, this model, too, has the potential to achieve very good results.
The last type of deployment model works from the grassroots or "bottom-up" within an organization – starting with the employees working on the line or in the process itself. These efforts are typically isolated from any political or top-level support. They often take the form of a single group of employees attending Black Belt training, or a small team assigned to Six Sigma efforts within a division or business unit. The results vary greatly depending on how well the project is tied to the business imperatives. Historically, the failure of many grass-roots TQM or continuous improvement efforts to achieve permanence does not bode well for this deployment model.
Perhaps the question of deployment models is not which one is right or wrong, but which one provides the optimal results given the current business conditions, industry environment and corporate culture. For Jack Welch in 1995, a maximum financial benefit in the shortest time period possible was a requirement of doing business. Return on investment was achieved quickly and benefits accelerated every year, but it required a culture that embraced rapid change. William Swanson and Timothy Tyson would most likely agree.
Experts may debate the model issue, but one thing everyone agrees on is that the main purpose of a Six Sigma deployment is to achieve financial results. Which returns us to the opening question: do all Six Sigma deployment models return the same results – proportionally – to the resources and time invested? Six Sigma teaches us to go get data before we make a decision. I think I’ll do the same and work with the iSixSigma editorial team to determine when we might be able to schedule this type of research – although I have a hypothesis on what the results will show. In the meantime, do your own research, understand your unique business culture and environment, and make the choice that fits your needs. Let me know how you make out.]]></description>
			
			<author><![CDATA[Michael Cyger]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Thu, 14 Jul 2005 22:00:00 -0800</pubDate>
		</item>

		<item>
			<title><![CDATA[Six Sigma Blogs: The Other Six Sigma: DFSS]]></title>
			<link>http://blogs.isixsigma.com/archive/the_other_six_sigma_dfss.html</link>
			<description><![CDATA[The Last Word from the July/August 2005 issue of iSixSigma Magazine, entitled "Designing for Perfection: Six Stories of Innovation with Six Sigma."
One of my pet peeves is when people refer to Six Sigma as a cost-cutting or productivity methodology. That definition tells only half of the story, focusing on the DMAIC improvement methodology and completely ignoring the method by which new products and services are identified, conceptualized and delivered – Design for Six Sigma (DFSS).
It's easy to see why this happens. People equate Six Sigma with DMAIC because DMAIC is employed far more often. Companies may strive for continuous improvement, but they're not as willing to take the leap to develop something entirely new. They apply DMAIC to problems and happily report the benefits attained. That's what gets the attention, both within an industry and in the media.
So how does DFSS fit in when DMAIC is doing so much for companies by increasing productivity and improving existing products worldwide? It's simple. Designing new products and processes that will delight customers leads to increased customer satisfaction and loyalty, generates higher profit margins, and even may elevate a company to a "market leadership" position.
Management guru Peter Drucker once noted, "The only definition of a leader is someone who has followers." That holds true in every business marketplace. But how can a company become recognized as a leader by both its customers and its competitors? The answer is found in a single, nuanced word: innovation.
Innovation is the act of introducing something new, whether it's a simple idea or a complex solution. Innovation is "cutting edge," the "latest thing." When innovative products and services are introduced, a common reaction is, "Now why didn't we think of that?" Take, for instance, 3M's Post-it® notes. A simple idea, they allow people to attach reminders, to-do lists or schedules to a variety of surfaces, increasing the attention the notes receive.
At the other end of the spectrum are innovations like the GE Healthcare LightSpeed CT scanner, introduced in 2001. This diagnostic tool captures multiple images of a patient's anatomy simultaneously, at a speed six times faster than traditional single-slice scanners. When speed is of the essence, being able to make a more conclusive diagnosis can make a life-saving difference. GE became a market leader in medical imaging not by incrementally improving their products, but by taking large, innovative steps using DFSS.
Innovation can happen sporadically – without the use of any formal methodology – and still result in business success and market leadership. But is that the way any of us want our companies to be run? Is that haphazard type of operation one that shareholders will appreciate? Developing a systematic way to launch new products and processes can help a company become a sustainable market leader.
So the next time someone boasts about their costsaving Six Sigma deployment, be sure to ask them why they're not growing their revenue with Design for Six Sigma.]]></description>
			
			<author><![CDATA[Michael Cyger]]></author>
			
			<category>
			<![CDATA[Methodology]]>
			</category>
			<pubDate>Mon, 20 Jun 2005 00:40:00 -0800</pubDate>
		</item>

	</channel>
</rss>
