I have never personally sewn, but I’ve heard that one of the most difficult aspects of sewing is deciphering the pattern and following its directions. I learned this, and many more important lessons, from observing my mother, who made dresses for my sister when I was a child. Looking back, whoever created these patterns for a simple dress must have thought they were creating a blueprint for rocket scientists.

With sewing, patterns are essential; all of the pieces need to be the "right" size in order to fit them together. In today’s times patterns are produced in mass quantities and you can find a "standardized" pattern for anything you might want to sew. However, back in the day, patterns were not so readily available so folks were relegated to taking apart old clothes and using the pieces as a pattern to reproduce a copy with new cloth. Over time, the original pattern suffered from errors, such as over snipping the sleeves or under snipping the hem, leaving an observable difference from the "standard". The further removed from the original pattern, the less the outcome resembled the blueprint.

So what does sewing patterns have to do with Six Sigma? During my many years of continuous improvement experience, I have learned from many good teachers who demonstrated methodological expertise and the startling ability to relate the philosophical to most any functional application. It is very tempting to live off this teaching and rely on it to energize my organization without ever returning to the source. I could easily be successful doing so without ever personally studying any of the original works of Deming, Shewhart, Juran, Shingo, etc. But without such study, my understanding of the methodology and the concept of Six Sigma that is transferred to anyone who learns from me will eventually get farther and farther away from the original ideas, potentially giving rise to "the blind leading the blind" syndrome.

Take advantage of the fact that you don’t have to use an old worn out coat as a pattern for a new one. Go to the source and get the original blueprint. Preserve the spirit of the archetype, you’ll be a better Black Belt and nobody will make fun of your clothes.

After an extended holiday from the blog and from work in general, I have to say I’m glad to be back. I hope everyone out there in isixsigma land enjoyed the season as much as I did.

I started a project in the U.K. this week. I’m fascinated by the differences in culture one finds when one travels outside his or her home territory and I always make point of watching the local news to try and gain insight into the top concerns of the locals. This trip has proven to be particularly interesting relative to such observations.

Most Americans are probably familiar with reality television and some are certainly viewers of a show titled “Big Brother”. If you’re not familiar with this show, its premise is to assemble a group of strangers in a house and have them engage in a strange sort of competition to see who can outlast the others. While I’m not a viewer of the American version of the show, the U.K. version got my attention this week as it has created a firestorm of controversy. It seems one of the contestants made some derisive remarks about a housemate who is Indian. The comments have drawn cries of protest across Britain, provoked street marches in India, and even created a political rift to which both Indian and British government officials have been forced to respond. Having heard the comments I certainly think they were inappropriate but the ignorant and perhaps prejudicial comments of a single individual on a reality television show hardly strike me as justifiable cause for an international “racism” crisis. It’s TV people, get a grip on yourselves!

What is most fascinating about this is the thought that while it appears easy to get the international community stirred up about an issue based on a single incident, we never see protests when bad statistics are used in the media, or most anywhere else for that matter.

First of all, it strikes me as incredible that we’re continuously bombarded with the notion that singular events apply universally to the entire population. Such extrapolation can be seen on news channels world wide on most any given day. Ice melts in Antarctica and we’re all told we’ll be overcome by the rising tide of global warming in a matter of years. One prejudiced remark, on a television show designed to create strife between contestants, and suddenly the whole country is labeled racist. Based on reports, I guess we can safely assume the record snows in the Western U.S. this year indicate the ice age is upon us; right?

And what about correlation? Does an increase in the number of shark bites off the coast of Florida indicate that sharks have developed a taste for human flesh? Or could it be that sharks have always been there and now that more people are entering the water annually, we have more shark bites. Better yet, maybe the species is determined to exact revenge for not being paid royalties from the movie “Jaws”.

The point is, why do we always have to have a fantastic explanation for events which are most often quite within the range of probability for a given set of circumstances? I guess the proliferation of news channels competing for advertising dollars drives the sensationalism but they only sell what the general public is willing to buy. Maybe the answer is to design TV’s that require a 15 minute math lesson when you turn them on before you can move on to other programming. Or maybe we just need to turn off the television altogether. After all, statistics confirm that everyone who watches TV will die.

Who will join me in this battle against Statisticism? Let’s coordinate events in cities across the country and burn our remote controls in effigy. Even better, write in to the blog with your statistical abuse stories. We should at least make an effort to share a chuckle over the matter.

I was up late practicing one of my favorite hobbies, web surfing, and after a chain of clicks on tonight’s topic of interest, optimization, I stumbled upon something I thought I’d share.

I’ve been a practitioner/advocate of simulation for some time now and recently I’ve decided to educate myself beyond what the typical software packages provide. Not that these products aren’t sufficient, most of them are more than I’d ever need, I just want to know more about the science behind them. Anyway, in my exploration I came across a mathematical programming (optimization) technique for solving computational problems called ant colony optimization. I’ll save you the trouble and give you the wikipedia summary of the idea here:

In the real world, ants (initially) wander randomly, and upon finding food return to their colony while laying down pheromone trails. If other ants find such a path, they are likely not to keep traveling at random, but to instead follow the trail; returning and reinforcing it if they eventually find food.

Over time, however, the pheromone trail starts to evaporate, thus reducing its attractive strength. The more time it takes for an ant to travel down the path and back again, the more time the pheromones have to evaporate. A short path, by comparison, gets marched over faster, and thus the pheromone density remains high as it is laid on the path as fast as it can evaporate. Pheromone evaporation has also the advantage of avoiding the convergence to a locally optimal solution. If there were no evaporation at all, the paths chosen by the first ants would tend to be excessively attractive to the following ones. In that case, the exploration of the solution space would be constrained.

Thus, when one ant finds a good (short, in other words) path from the colony to a food source, other ants are more likely to follow that path, and positive feedback eventually leaves all the ants following a single path. The idea of the ant colony algorithm is to mimic this behavior with "simulated ants" walking around the graph representing the problem to solve.

What struck me as cool about this was not so much the technical aspect of the idea as it relates to mathematical programming, but the simplicity of the idea itself, especially when it comes to problem solving in an organization. The ants find the simplest solution, have built in feedback loops for the rest of the organization, and proceed with their work in a standardized fashion. Amazing!

Now I’m wondering if the ants are looking up at us as we pass by and questioning why we need computers to find simple solutions. Maybe I need to do a search on ant psychology or possibly run out and buy myself a copy of A Bug’s Life.

March on, Michael

Okay, time to pick up where I left off last month. You may or may not remember my post about assessing organizational maturity in order to discern the appropriate scope and/or starting point for continuous improvement efforts so I’ll refresh your memory with a quote from the post:

“Our target end state for an organization is that of a mature populace which has taken the tenets of Lean / Six Sigma and woven them into the everyday fabric of the business. One which communicates problems in a common vernacular, uses data to develop solutions, and ultimately develops a relentless pursuit of perfection.”

Obviously that statement reflects the goal but what is the reality? Well, I did some research on how experts in various fields go about the process of gauging organizational maturity and this is what I discovered:

• The software development industry surpasses most every other industry I could find information on when it comes to tools employed to conduct such an assessment. In this industry, which I’ll admit is quite foreign to me, there appears to be widespread recognition of the need to gauge organizational maturity prior to the development of applications specific to the organization. I found more journal articles and scholarly research on the subject as it relates to software development than for any other industry by a wide margin. In fact, the Software Engineering Institute developed a “Capability Maturity Model” in the 1980’s which is still in use today, albeit revised. Do a search on CMM to find more.

• Project management was another field for which I found some information. On the surface it appears the practice of gauging organizational maturity as a part of project risk assessment is common. That said, I’ve been around project work for quite a while and though most projects I’ve seen have a risk assessment component, I don’t recall ever encountering an organizational maturity profile. Maybe it’s a part of the BoK that doesn’t get used much outside academe.

• Another discovery I made was that the CMM (capability model) I mentioned before was the foundation for the organizational assessment process currently used as part of ISO9000. Once again I find myself outside my area of expertise so maybe some of you quality guru’s could help me out. I’ve seen some of the ISO assessment tools but I don’t recall one that relates specifically to organizational maturity.

I’ll leave it here for now but I’d really like to see some input on this one. My brief research indicates that there are a number of different approaches to how this can be done and I’d love to hear of your experience with such tools if you have it. In the meantime, I will do some more digging to see if I can come up with some links to specific assessment tools.

More later, Michael

Gauging organizational maturity is one of the most critical tasks undertaken prior to the implementation of Lean / Six Sigma. Not only is it important relative to determining where to start, it’s also an indicator of how much of a cultural shift will be required to make sure the methodology sticks.

The U.S. military seems to understand the need to match the mission with the appropriate resources, be it people, equipment, support, etc. Not that they always get exactly what they’d like to have to accomplish a mission, but at least it is in their DNA to lay out a plan for said resources and then go about modifying the plan to determine what their probability of success will be. Special Forces are required for some missions and regular infantry for others. If they don’t see that they can accomplish the mission with the resources available, they will modify the plan until they develop a reasonable probability of success. Do their plans always come to fruition as expected? Of course not. But they don’t quit assessing capabilities and planning missions because one such mission fails. And thank goodness for that.

Keeping a finger on the pulse of the organization to understand its readiness, capabilities, morale, etc., is vital to military strategists. Likewise, it should also be important to corporate strategists planning a Lean / Six Sigma effort. Just as the military would be unwise to use tanks & infantry when they really need an aerial attack, so too is the corporate sponsor unwise if he/she tries to shoehorn an advanced methodology on an incapable and unprepared employee base.

Our target end state for an organization is that of a mature populace which has taken the tenets of Lean / Six Sigma and woven them into the everyday fabric of the business. One which communicates problems in a common vernacular, uses data to develop solutions, and develops a relentless pursuit of perfection. That said, most companies, even those we as practitioners worship as companies that “get it”, will admit they are a long way from such an end state ideal. Thus, even for companies several years down the road on their Lean / Six Sigma journey, it is important to understand exactly where you are before you can figure out how to get where you want to be.

If knowing where to start is the first key to successful implementation then understanding organizational maturity has to be the single most important factor in finding the appropriate starting point. But how does one go about gauging organizational maturity? Tune in to my next post to find out…

Balance is one of those tricky concepts which appears on the surface quite simple yet is often deceptively difficult to grasp. In its more common forms, like standing up and walking about, we never give it a second thought. There are scant few of us however who would conclude that because we can walk we’re qualified to perform in the Cirque du Soleil. If reading is one of your hobbies you’ve no doubt encountered reverence for the notion of balance from the likes of Aristotle, Leonardo da Vinci, Ben Franklin, and W. Edwards Deming, to name a few. And just why is that?

My personal take on why some of the brighter individuals who’ve graced this planet recognized the majesty of balance is that they, through years of study and reflection, realized that a system is more than the sum of its individual components. Systems, regardless of whether we’re talking about the human body, manufacturing, or the chow line in the cafeteria, are driven not only by the individual components comprising them but also by the interaction of these internal components and the external forces acting upon them.

I mention this because today I encountered some “tips” written by a well respected leader in the operations management field deriding the principles of one improvement philosophy in favor of another. His favored approach, a GOAL oriented project management approach which coincidently is where his paycheck originates, emphasizes technology while the other is more of a manual approach developed through years of practice (at Toyota, hint, hint). The funny thing about his comments is that both of these systems have a lot to offer and work very well together; particularly if one is knowledgeable about one discipline and chooses to cross-pollinate some brain cells by engaging an expert in the other. In fact, save for differences in terminology, they are philosophical, though maybe not identical, twins.

What I’m trying to say is that a one size fits all approach to improving systems and/or processes is very limiting and short-sighted. I’ve been doing the Master Black Belt thing about ten years now and along the way I’ve learned as much about things not specifically “Six Sigma” as I have about the discipline itself. I don’t know many true experts and I don’t consider myself one. What I do know is that if you are committed to the role, you have signed up for an intellectual journey that never ends. True expertise in this field is elusive and only comes with years of exploration and experience. As soon as you close the door to new ideas or alternative theories you risk losing your balance. I don’t suggest jumping every bandwagon that comes along but I don’t suggest setting them on fire without consideration either. Just as a system requires the right balance of inputs and timing to produce the desired output, your effectiveness as a Black Belt requires a balanced skill set.

Explore intelligently, Michael

P.S. – Cirque du Soleil won’t hire you for tying yourself up in knots over missing data points; I guess they’re just not ready to push the entertainment envelope.

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

Coast Guard Station Cape Disappointment, situated at the mouth of the Columbia River, is the largest Coast Guard search and rescue station on the Northwest Coast of the United States. This area is regarded as one of the most treacherous river bars in the world and because of the large number of shipwrecks near the river entrance it is often called “The Graveyard of the Pacific.” During winter storms, wind-driven ocean swells range from 20-40 feet at the entrance of the bar.

In addition to the 300 to 400 annual search and rescue sorties undertaken by the Cape D crew, the Coast Guard uses the area to conduct advanced rough sea rescue training for its seasoned Captains. Learning to maneuver a rescue boat in these conditions is not for the faint of heart, or the novice. In fact, the boats these individuals pilot are capable of being rolled over by breaking swells and re-righting themselves, sustaining minimal damage.

I learned these interesting facts about Cape D from a documentary on the Coast Guard which aired on the A&E network recently. As I watched the show I was in awe at the seamanship displayed by the individuals piloting the boats and it was readily apparent that all of them were seasoned veterans whom the Coast Guard had chosen to take their game to the next level. Sort of a “Top Gun” for rescue boat captains. As interesting as all of this is, I was particularly intrigued by a comment made by one of the instructors when he explained that the success or failure of each person in the program often depended on the confidence they had gained through their previous experience.

That’s when it hit me! Could it be that the success or failure of a Six Sigma project often turns on the prior experience of the Black Belt? Surely not, for if that were the case it would be much less commonplace to throw neophyte Black Belts into the knarliest projects in the company! But maybe, just maybe, this is why detractors of Six Sigma reference a growing “graveyard” of project failures to make their point.

The truth is, freshly minted Black Belt certificates are nothing more than a license to learn. Organizations must continue to develop Black Belts long after the certification hurdles have been crossed if they’re going to develop Captains who can navigate “Cape Project Disappointment” without sinking to the bottom. Additionally, MBB’s and company leaders have to consider project selection relative to the capability of the potential project leader. Some Black Belts can float, some can swim, and some can steer the boat, but patience, development, and discipline are required if an organization wants “Top Gun” Black Belts whom they can call on when the surf is overwhelming.

“Negative Ghostrider, the pattern is full”, Michael

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

Hi All, Sorry for the long delay since my last post. I’ve been neck deep in my project out in California and it seems every time I sat down to write, something else came up.

Anyway, this project has been a real eye-opener. Essentially, I’ve been leading the transformation of an old school batch & queue production system into a single-piece-flow model. We emptied the assembly building out into the parking lot about two weeks ago and totally reconfigured the line. We’ve implemented flow cells which take raw materials in one side and flow completed sub-assemblies out the other side, which of course is right where they are installed on the line. I’ll spare you the rest of the details since I’m sure most of you can probably relate to how much work we’ve put in to get to this point. The good news is that within a week of restarting the line we are already seeing that our labor is bearing fruit.

That said, one of the interesting aspects of this project is that many of the individuals invloved are not particularly fluent English speakers, which wouldn’t be a problem if I spoke Spanish but I don’t. Luckily most of the leadership is bi-lingual but I’m never quite sure if words like Jidoka or acronyms like SMED actually translate very well. Sometimes I see heads nodding agreement but I could be confusing that with weariness since the team has been working so hard.

The project has been a great learning experience for me as it has forced me to focus on communicating the ideas without relying strictly on language. I guess I shouldn’t be surprised but the fact is that the concepts encompassed in Lean translate quite readily. Ideas that make sense usually do.

I’ll keep you posted.