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.

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!

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.

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

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?

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!

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

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” & “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…..

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?

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