I had a very nice phone call today, from a colleague who had chatted with me earlier about a current project. She called to say thanks for allowing her to bounce ideas around, which helped her clarify some things about her approach to the process.

Naturally I felt good to receive this feedback, and it made me think about my many associates who are in the process improvement community with me. Sometimes it feels like skiing downhill, but sometimes it feels like I'm trying to go uphill without the ski lift. It's during the tough times that I really rely on my fellow improvers to help me see a clear direction.

My colleague said that she had felt lost in the trees and confused about the path out of the forest. I know I've felt like that sometimes too, and I told her that I'd probably be calling her soon so she could return the favor!

And, it reminded me to say a heartfelt "thanks" to the many people who have helped me to see more clearly when my own path seemed confused.

And also to say a sincere "thank you" to those of you who have read, and contributed to, this blog over the past three years. It's hard to believe that this will be my 100th post, which milestone I would not have reached without your continuing support and responses! I hope that you will keep on giving me your feedback - your conversations have been spirited, inspiring, generous, truthful, and above all educational!

With thanks for your time, your sharing of feedback with the iSixSigma blogosphere, and your efforts on behalf of your customers,

Sue K.

"One of all and all for one!"

Or, in the original French, "Tous pour un, un pour tous!"

In the story by Alexandre Dumas (1844), the three musketeers, Athos, Porthos, and Aramis, were joined by the musketeer-wannabee D'Artagnan, without whom the first three would have led very boring lives.

I was reminded of this the other day, when discussing the elements of a successful process improvement deployment. You will recognize the top three that were mentioned: focus on the customer; front-line engagement; structured methodology. I'm going to submit to you that the concept of the Three Musketeers can serve as a metaphor for those three. And, then, add the fourth (which you have already thought of anyway), which is committed leadership - without which, you will not be having many grand adventures in improvement.

So in your improvement experience, how many times have you gone into a project doing an assessment for these four issues - whether the organization knows how to focus on the customer effectively, or not? Whether they treat their front-line workers as knowledge resources and Subject Matter Experts, or not? Whether they have, or are willing to adopt, a structured methodology and all that is implied? And, perhaps most importantly, whether the leadership is truly engaged and committed to process improvement as a way of life - or whether they just think it's the next best thing to try? And, are these four elements integrated so that they can proclaim "One for all, and all for one?"

Please share your thoughts on this. How many Musketeers do you have, where you work???

I used to be really annoyed with people who took a wait-and-see approach to change. They're not resistant, exactly, and they might be classified as "late adopters." But I could understand active resistance better than passive indifference.

Now, however, I have a little different take on things. Because I have realized that if you wait long enough, you may find that whatever was changed comes back around again!

Such as...

• Centralization vs decentralization of departments or functions
• Use of consultants vs hiring internal resources
• Outsourcing vs insourcing

This reminded me about the lines from the Disney movie, "The Lion King," where young Simba gets the explanation about how the antelopes eat the grass and the lions eat the antelopes, and then the lions die and their bodies turn to grass (OK, you knew it would be a PG version) which is then eaten by the antelopes. So everything comes back to a big circle of replaying the same scenarios.

For process changes, it's easy to see how this becomes just another bright idea to wait out, to someone who's been around a long time. Especially when you're in an organization that promises that every change is NOT just the flavor of the month, and then six months later it's disappeared. So how can I criticize someone for saying, "Well, go ahead with this Lean thing, I'll just wait and see what comes of it before getting enthusiastic about it." After all, they've probably been right about all the other wonderful new initiatives and changes that have come and gone before.

Maybe you are fortunate enough to work in a place which has solved this circular pattern, or maybe you are trying to break out of that. Would you care to share your experiences, to help us put some perspective on the issue?

A quote from Alice's Adventures in Wonderland by Lewis Carroll (Charles Lutwidge Dodgson), 1865:

"The White Rabbit put on his spectacles. 'Where shall I begin, please your Majesty?' he asked. 'Begin at the beginning,' the King said gravely, 'and go on till you come to the end: then stop.'"

I am sure I'm not the only one who as asked, "Where does this process begin?" only to find a dozen or so different answers, depending on who is asked. Just how far back doyou go into the decision-making that may trigger a process, and the factors that influence the decision, and the issues that led to the factors being important, etc. etc. etc.?

And, where does the process stop? For a product, is it when the customer receives the goods? When they use the item for the first time? When they finish using the item? Or, for a service, when they receive the service, or when they utilize the benefits of the service if that's at a later time?

This may seem simple, but, in practice I've seen a lot of conversations get into a circular mode about just what step should be considered the start or trigger for the process. I'm just wondering if anyone has any words of wisdom, from their experience with process mapping and process analysis - and would you like to share?

When I was leading a department, I never thought of myself as a process owner. It wasn't in my job description, and I never heard anyone used the term. It's one of those useful concepts that I wish I had known, prior to my Six Sigma and Lean education.

Here's my working definition: The process owner is that leader who is closest to the process itself, who has responsibility for achieving the expected outcome of the process, both before and after an improvement project.

So now, I try to introduce the term right away and use it frequently so that everyone knows what the role is, in respect to a project (and afterwards). I also try to spend extra time with the process owner if they are new to the role. Even then, though, it's hard sometimes to get across the continuing expectations. A statement that I hear frequently is, "I'm glad that the project is over - now I can quit being the process owner!"

Have any of you faced this challenge, or is it more clearcut in some industries than in others? Have you had to do extra education or mentoring of someone who was not sure they were a process owner - for either a project or a process? Do you have a different definition of process owner, that's been helpful for you?

It would be great to hear your thoughts.

Well, maybe I have more than one favorite tool - but there are 2 that are fun to use with a group.

One is sticky-note brainstorming. It avoids the perils of the regular "everybody call out their ideas" brainstorming, because (a) you get 100% participation; (b) you can get LOTS of ideas in just a few minutes; (c) you don’t need a scribe to try to capture everything as multiple people are speaking quickly; (d) you avoid people being worried about "what will my boss think" about an idea; (e) it’s anonymous so people are braver; (f) you can put duplicates on top of one another and categorize with ease, just by moving them around. Also (g) you can use colorful sticky-notes and make a cheerful impression rather than a boring one!

Secondly, if I’m using the group’s ideas to capture possible solutions, I really like to use an Impact/Effort Matrix. You may have heard of this under another name - it’s a 2x2 matrix with Impact along one axis (High, Low) and Effort along the other (Easy, Hard). I ask the group members to place the sticky notes in the appropriate category - if there’s doubt they can place them on the dividing line. Then I can facilitate the group to ask, "Does this idea belong here? Do we all agree that it’s High Impact (or whatever) and Easy to do?" If not, we have a good discussion and end up with consensus. It’s amazing how this helps to prioritize the efforts - we will definitely pursue the "High Impact, Easy" ideas; think about a plan for the "High Impact, Hard" ideas; see if we can catch some low hanging fruit with the "Low Impact, Easy" ideas; and forget about the "Low Impact, Hard" ideas.

These ideas can then be turned into action plans or placed in a parking lot as appropriate. Using the sticky-note brainstorming to get 100% participation, and the Impact/Effort Matrix to prioritize ideas, results in better decision-making and better buy-in to the resulting plans.

What are your favorite change management / process improvement tools?

While the iSixSigma.com site has been down, the rhetoric about "fixing healthcare" in the US has dramatically heated up. "We need to take the waste out of healthcare!" "We're paying too much for healthcare!" "Everyone should get all the healthcare they need regardless of cost!"

Without getting into the political debate, let's just touch on these points from a quality perspective.

There's a balance between cost, speed and quality that's quite a challenge in healthcare. For example, if I order $5000 worth of tests on day 1, and can tell you your diagnosis on day 2 and start treatment, what's that worth to you and your health (even if it turns out that 5 tests out of the 30 ordered didn't help with the diagnosis)? How about taking the cost-effective route: I'll order one test per day, evaluate the results, and then order the next test. It may take me 21 days to figure it out, while you are waiting all the while, but hey! it did cost less! So, in which example was there more waste???

Paying too much for healthcare... does that mean we are paying more than the value we receive, or just more than we desire to (or can afford to) pay? Most of us a) don't know how much our healthcare actually costs; b) can't judge the quality of the medical care we receive; and c) won't haggle over the cost of an IV solution when the care of a loved one is at stake. There's an emotional element of this debate that is not susceptible to logical reasoning. We see this in all the stories of people who have gotten poor care or ran out of money or their insurance wouldn't cover a certain procedure. If we try to "ration" care in the most logical way possible, we immediately run into the emotional (or moral, if you prefer) discussion about denying care to those who need it on a purely financial basis. The factual and emotional issues are entangled as we debate this topic.

Should everyone get the healthcare they need regardless of cost? It's my personal opinion that provision of basic services, including healthcare, should be a function of an organized society. But, it's not a "commodity" service like garbage collection, is it? Since we do have to look to our tax-paying citizens and employers to pay for "healthcare for all" - the question of course is, how much should each of us contribute to this worthy cause? And who decides how that money is to be used?

Having stirred the pot this morning, I will close by saying - it's a complex system!

• There are no "specifications" for inputs (patients who need care come in all conditions and with variation in their genetic, mental, physical, experiential, cultural, economic, and social backgrounds);
• Processes are highly complex with many stakeholders and overlapping responsibilities
• There is an expert-based culture of physician caregivers (now expanding slightly to other medical professionals);
• Outcomes may not meet the patients' goals through no-one's fault (you can mostly blame our biologically-based life processes, I guess) but which may in some cases be due to poor care or non-compliance on the part of the patient (for example, not taking medications in the way they were prescribed).

So I just caution you to think carefully about all the proposals that will be floated to "fix" the healthcare system, and don't jump to solutions too soon on this one.

Is healthcare in its current form in the US perfect? NO! But first I think we have to go back to quality basics and agree on who are the customers, and what is value-added to those customers. I've seen many more "solutions" floated, than thoughtful consideration of just what it is we want to get to. I encourage everyone to join this debate from the quality improvement perspective, and to lend your expertise to the discussion!

p.s. It's good to be "back on the air" again! Kudos to those at iSixSigma.com who have been working to resolve the issues that interrupted service over the past several weeks.

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!

When I begin a new project, I include a Communication Plan as part of my team work. That is, we take the stakeholder list and think about who we need to be in communication with, as we move through the project phases. Some of you may do this based on an ARMI exercise (Approvers/ Resources/ Members/ Interested Parties) or Stakeholder Analysis exercise (List of key stakeholders and their estimated level of commitment to the project). We include activities like face-to-face conversations, presentations in department meetings, newsletter articles, postings on the web site, etc.

But even though we try to heed the mantra, "communicate 8 times, 8 ways" it seems like we always have a gap in our communication.

For example: Our team invites a key department leader to our project meeting; we discuss our project and get agreement as to next steps. We plan an elevator speech and ask the leader to discuss it at his/her next department meeting and get agreement to do that. We talk about possibly sending an email or posting information on the department's bulletin board for those who can't attend the meeting. All good so far!

Then, a week later - after the department meeting, and having seen for ourselves that the information is posted on the bulletin board, a few team members stroll through the department to gauge the level of buy-in. And - do they find that everyone is informed, interested, and enthusiastic about the project? Or, do they find that people are negative toward the new process that's coming their way?

Why, no! We find that most people remember vaguely hearing something about some new process, and others just give us blank stares. When the bulletin board is mentioned, we get the response "Oh, I know it's there but it never changes so I don't look at it."

So, what are our learnings from this type of situation? We only communicated once or twice, one or two ways - so obviously we would need to keep our communication plan active! But are there other ways that you have been successful communicating outside of your project team, as you make progress? Thanks in advance for sharing!

You've completed your planning phase - whether it's specifying value and mapping the value stream, Defining / Measuring / Analyzing, or Planning - and you're ready to move into Creating Flow, Improving, or Doing. Hooray! The pilot plan has been finalized, the Process Owner says it's fine, the team is ready to move forward. And then...

Little cracks start appearing in the plan. "We forgot about..." "One of our team members says the plan won't work because..." "We thought the computer system did THIS and instead it works like THAT so our plan needs to be changed!"

How many times have you gone through these pre-improvement jitters? Is it a matter of staying calm in the face of chaos, staying the course, trusting the process? Have you ever had an experience where you really did have to call a halt and regroup, because you found out that there was a major roadblock in your path?

As an optimist, I try to stay flexible and reassure the team that we can address issues as they appear, usually by obtaining additional information and clarifying the issue before deciding that we need to make a change. But I have had to halt a project just as we were moving into Improve, because the hospital decided to implement a new computer system in the department just at that time, rather than waiting for the project to be completed. And in fact, if we had completed our project without the new system, we probably would have had to re-do the process following the system implementation anyway. Plus, the same people who were on our team were also the people who were wanted for the design of the new system, so there was a resource conflict as well.

What we did was to put the project on "hiatus" for three months. Then, we re-measured and re-analyzed, to see if we still had the same critical factors, tweaked our Improve plan, and proceeded. It didn't feel very good at the time, but it all worked out in the end.

Have you had this experience? How did you handle a halt or delay in a project that was in full swing? Please share your stories!