Zero to Success in 60 Days or Less: How to Build a Successful Lean Six Sigma Program From the Ground Up (Part II – Revisiting the Rules in Use)

In 1999, Steven Spear and H. Kent Bowen published their article “Decoding the DNA of the Toyota Production System”. In this article, the authors articulated the fundamental nature of the Toyota Production System through the definition of four principles, which they called the “Rules In Use”. If you work in the area of operations management or continuous improvement and you haven’t read it, I really believe you owe it to yourself to do so. You can obtain a copy from the Harvard Business Review, or if you look hard enough you should find one floating around the internet.

Spear and Bowen’s article speaks to the Toyota Production System following these rules:

Rule 1: All work shall be highly specified as to content, sequence, timing, and outcome.

Rule 2: Every customer-supplier connection must be direct, and there must be an unambiguous yes-or-no way to send requests and receive responses.

Rule 3: The pathway for every product and service must be simple and direct.

Rule 4: Any improvement must be made in accordance with the scientific method, under the guidance of a teacher, at the lowest possible level in the organization.

According to the authors, it is through the continuous response to problems via the scientific method that allows Toyota to introduce changes and improvements to its operations without negatively affecting productivity. The way people improve their work and the processes they support is through quick, “get-in-and-out” changes at the source of the issues.

Think about how many of your organization’s deep-rooted problems you thought were insurmountable would simply resolve themselves if these rules were in play? Issues with the way things are done would be undeniably…issues, and treated as such. Standardization would be inherent by design. Most of all, continuous improvement would be organic – instituting itself where it is needed at the time it is needed.

It is understood that many organizations would consider themselves operating so far from these four rules that putting together a road map to get there would be a daunting task. I am sure you could spill out ten or more reasons why these rules could not get implemented at your organization, and do so rather quickly. From our experience, my consultancy’s contention is that there are really only two hurdles you need to truly address:

Hurdle 1: Currently, both workers and their supervisors don’t have the know-how to engage in directed problem solving

Hurdle 2: Standard, simple and direct ways for things to be done don’t exist and pose an obstacle to best servicing the entire book of business.

Directed problem solving isn’t a prerequisite for managers in most organizations. At Toyota, this skill is instrumental for not only reaching the solution to problems, but for evangelizing the four rules. Hence through the problem solving exercise, workers get a better appreciation and understanding of problem solving through the scientific method. I will also contend that through these exercises (under the right tutelage) they will appreciate and understand the need to institute to the best of their ability the first three rules within their radii of influence.

Having a group of folks who are both knowledgeable in the four rules and capable of teaching the rules through well-ordered problem solving is instrumental into transforming workers and supervisors into implementers of this road map of change. Who are these folks? In your organization, it can (and should) be the Lean Six Sigma team. Realigning the way you look at your LSS team’s role (if required) in such a manner offers your organization the opportunity to transform itself one department at a time. I have a difficult time believing that playing such a critical role in instituting a “four rule” transformation can be considered anything less than a success for your program, even in the face of those who believe LSS is all about “big game” projects each with million dollar wins. Most of all, you CAN be successful in instituting this transformation one department at a time when you start with the departments that have the attributes listed in my previous post.

So now I’ve finished discussing WHAT needs to be done, but I haven’t touched on HOW. I also haven’t discussed how to address hurdle #2. Hurdle #2 will be addressed in due time, but in my next posting I will discuss the tool you will use if you want to put this theory into practice.

-Russ

Zero to Success in 60 Days or Less: How to Build a Successful Lean Six Sigma Program From the Ground Up (Part I – Rounding Up the Usual Suspects)

In my last posting I wrote about how a company’s ability to execute on LSS project improvements was much more important to a program’s success than executive buy-in. You can still garner successes without the latter, but it is much harder if not impossible without the former. Does your company have a fundamental execution problem? If you are not quite sure, here are some of the symptoms to look for:

• Your executive team uses project report outs and strategy meetings to pontificate and posture rather than to lead and mentor.
• Your company is hell-bent on collecting metrics on anything and everything, yet does not have the capability or motivation to act on what they are telling them – or better yet, they don’t know what they are telling them.
• Your company’s project managers will spend more time and energy trying to prove to executive leadership that their projects are “green” rather than “yellow” than actually managing the projects. In many cases this occurs in companies that lack any true reaction to changes in project status. As if when a project manager’s project turns “yellow” the PMI fairy comes down a swipes their “green status” merit badge.

To be fair some shops aren’t indifferent to all projects, just the LSS ones. This usually correlates to indifference to the program at the top. There are many small, little signals that may point to the fact that executive leadership isn’t really in tune with what you are trying to put together. One of my favorites? When you introduce a newly minted or hired Black Belt to the CEO and he strikes a pose like Bruce Lee.

This post starts our series on how to get a successful LSS program started in spite of such problems. The Black Belts and Master Black Belts at Exceptional Outcomes have utilized this method at different companies – though only in transactional settings, since this is where our expertise lies. I would love to hear from any readers who implement our steps in a manufacturing setting, since I believe this would work in such an environment as well.

The first step in this process is to find the department or function that will act as your vanguard in implementing your first quick wins. I call this step “rounding up the usual suspects” since over time folks at your organization have probably pointed to one or more candidates for you and your team to engage. The attributes of a good vanguard are:

• The department handles many transactions a day, such as in the case of a claims processing department at an insurance company or agents in an outbound call center.
• There are metrics and measurement systems in place to measure productivity and efficacy – such as average handle time of a call or in the case of a claims processing center, the number of reworked claims.
• Variation in process has been minimized already through some amount of standardization. If this hasn’t been done yet, this is your true starting point.
• Both front-line workers and their supervisors are empowered to make changes in their daily workflow.

The last attribute is probably the most critical. In shops that have execution issues, resistance from the organizational hierarchy grows exponentially upwards as well as sideways. We aren’t looking for the ability to incorporate paradigm shifts, just changes that when scaled across the department will show a significant impact.

In my next posting we will discuss how to engage your newly appointed vanguard and get the ball rolling. Until then, good luck with your search.

-Russ

Do You Think Executive Buy-In is the Most Important Factor in Determining a Lean Six Sigma Program’s Success? You Couldn’t be More Wrong.

I have read in several Lean Six Sigma books, blogs and training materials that executive buy-in is the paramount factor in determining a Lean Six Sigma program’s success. Although such buy-in helps, I have worked with several organizations that have implemented a successful program in the face of an indifferent executive team. In such cases, the employment of a bottom-up, “grass roots” approach led to eventual executive buy-in, since ultimately they weren’t buying into the program, they were buying into the results. The steps in installing a grass-roots program will be coming in a later blog entry, but for now if you want to know the single most important factor in determining a program’s success, keep reading.

A few weeks ago, I was having lunch with one of my clients who happens to be a Lean Sensei. We got into our customary banter of “If Lean fought Six Sigma, which would win” as if one was Godzilla and the other Rodan. He brought up an interesting point when he asked ‘Name one Six Sigma tool that actually fixes something?” Think about it – the tools associated with the Six Sigma toolbox really don’t fix anything. They may help you define a problem, or measure a problem or even help you isolate the root cause and inputs – but you simply can’t ask a Black Belt to plop down a tool that would deliver an improvement that is both elegant and sustainable. It can sure identify it – but not deliver it.

Although there are Lean tools that actually improve something, such as 5S and Kanban – my point is the same. The single most important factor that determines a company’s success with continuous improvement has nothing to do with buy-in. It has to do with the company’s ability to execute a project’s derived improvements. I suggest that this is the reason why there are scores of companies that had executive buy-in to their program and came up empty handed.

If you have ever worked for or engaged with a company with an execution problem, you probably know the symptoms. They include middle managers who put themselves and their own ambitions ahead of the company by chasing “big-game, big-win” initiatives that have no real chance of success; poor prioritization of initiatives; lack of detailed planning; poor communication and coordination between departments; and my personal favorite – the lack of accountability for missing planned goals.

What is the best way get your process excellence program over this execution hurdle? I can tell you from experience, it isn’t through addressing the company’s execution problem. You could spend all your energy tackling this issue alone, only to come short when you hit the brick wall put up by the C-level players who allowed the company to dig itself into this hole. It is similar to the case of the 400 pound former high school quarterback. He didn’t get to be 400 pounds overnight and he sure isn’t getting back to his playing weight overnight either. This is a monster issue your company is facing, and in this case process excellence isn’t the silver bullet.

So what to do? Give up? Absolutely not. In fact, there is a system you can put together in a few weeks that can succeed from the get-go, and deliver “big-game” results. I’ve put it in place in several organizations, and so can you. I will cover that in my next article.

-Russ

Tips on Installing RapidMiner’s R extension on a Windows Machine

Although I use both R and RapidMiner in my work, I have been “late to the party” in installing RapidMiner’s R extension on my Windows machine. The primary reason being that over time I have built a regular workflow that uses these two tools separately. Also, I am one of those folks who don’t go looking for trouble. After reading several postings on how after installing the extension users couldn’t get RapidMiner started again, I figured I should let this integration fad pass or at least wait for Rapid-I to address the issue.

Well, curiosity took the best of me and I installed it. Actually, I believe I jerry-rigged it, but if you are one of those folks who are wishing to get the R extension working and you haven’t had any luck yet – here are your rude, crude but quick tips to get it working.

It is worth noting that I use a 64bit box running Windows 7. I have the latest-and-greatest R installed (at least at the time of this posting, v2.13.0).

Follow the instructions given by Rapid-I, but also note the following:

TIP ONE: SET YOUR R_HOME variable to the R “root” directory, NOT to the bin directory.

On my machine it is C:\Program Files\R\2.13.0

TIP TWO: SET YOUR JAVA HOME variable to the jre ASSOCIATED WITH RAPID MINER. Don’t know why this is important, but I couldn’t get the extension running using the jre installed in C:\Program Files\Java. Just saying……just do it.

On my machine that is C:\Program Files\Raid-I\RapidMiner5\jre

TIP THREE: (OK – Here is the crude, Mickey Mouse, Fisher-Price, fix to get this thing working…) COPY ALL THE FILES IN

C:\Program Files\R\2.13.0\bin\x64

to

C:\Program Files\R\2.13.0

Yep, sounds pretty silly, but hey – I am running the extension, thank you. I think it has something to do with not having a LD_LIBRARY_PATH variable, like on UNIX setups. If this was the case, I think adding C:\Program Files\R\2.13.0\bin\x64 to
LD_LIBRARY_PATH would have fixed this. One thing I didn’t try is adding both
C:\Program Files\R\2.13.0\bin\x64 AND C:\Program Files\R\2.13.0 to the PATH environmental variable – maybe try that out, and see what happens.

Best of luck, and let me know how it worked for you!

-Russ

Welcome to Our Company Blog

We hope to have some entries soon!