2/26/2006

When Bad Things Happen to Good Concepts - Part Two

In Part One, you saw how good concepts can be turned into great applications through definition of proper context, and how those same good concepts could be horribly disfigured by confusing concept with context. In particular, the problem of taking other people's context to be part of the core concept and preserved at all cost is the one that dooms more initiatives than any other. Most of the failed TQM initiatives of the 80's followed just this pattern.

I contend that most great concepts can be explained in a single well-written page (or like the old crib sheets we were allowed to bring into college finals - tinily written). Or a few pages at most. Of course, most book publishers want a bit more than that, so authors add filler to create a viable product.
Some, like Taiichi Ohno, write a slim volume outlining the concept and its applications in specific situations. At only 163 pages, it's a fast read, and when you're done you truly understand the concepts behind the Toyota Production System. It's not designed as a paint-by-numbers guide to implementing lean manufacturing, but you could do a successful implementation reading only this book. You'd just have to create all the contextual information yourself. Of course, if you're looking to apply the concept in another domain (for example, creating lean production in legal services), this is exactly what you want. All the specifics of various manufacturing practices only get in the way of understanding the concept of lean processes.

Less frequently, the author will embed the new concept in a novel. The best-known of these is Eli Goldratt's The Goal, in which he introduces the Theory of Constraints in the gripping tale of Alex Rogo and his mentor Eli Jonah. At 384 pages, it's not as succinct as Ohno's book, but it's not a bad read. Nevertheless, the very powerful concept of the book is simple and straightforward.

According to Goldratt, in a system with any sort of complexity, there is a very small number (usually one) of real constraints of the throughput of the system as a whole. This could be an actual physical constraint (the machine named 'Herbie' in the book), a policy constraint, or a market constraint. The process for improving the throughput of the overall process is as follows:
  1. Identify the system's constraint
  2. Decide how to exploit the system's constraint (since updated to include eliminating the constraint completely if it doesn't require a huge investment, such as with policy constraints)
  3. Subordinate everything else to the above decisions
  4. Elevate the system's constraint
  5. Go back to step one and see if there is now a new constraint. Don't succumb to inertia. Repeat until the constraints are appropriate.


Yes, I know there is a lot more to TOC, but at the time of the book's publication, that was it. You'll have to wait for a different post to discuss the wonders of the Thinking Processes and Critical Chain, because today's discussion is about mangling concepts, and we have enough with those 5 steps and 3 types of constraints.

One key aspect of any good concept is that it has been refined so that all of its parts are necessary, and they constitute a sufficient set to be effective. In other words, it is fairly atomic. If you take anything away, you lose the power of the concept. In our pencil sharpener example, the Bowie knife is an example of omitting one of the key facets of the concept (a guide for the pencil). In the hands of an expert the knife can achieve the same results as a real pencil sharpener, but you wouldn't mount one in the corner of a kindergarten class and expect good results.

A short while ago, Matt posted about Constraints for Lawyers, which pointed at this post which said the concept of the Theory of Constraints was:
“In any complex system at any point in time, there is most often only one aspect of that system that is limiting its ability to achieve more of its goal. For that system to attain any significant improvement, that constraint must be identified and the whole system must be managed with it in mind.”


The post then went on to say that in service-based businesses the lack of constraints is the real problem, and advocates imposing artificial constraints to improve productivity.


I'm not sure it's that bad, but I was initially dumbstruck by the notion that the problem for service-based businesses is a lack of constraints. In every service-based business I've ever worked in, from IBM to a two-man start-up, there were always constraints. Sometimes they were physical constraints - "We could get that new project if only we could clone Bob or get him on a polyphasic sleep schedule"; sometimes they were market constraints - "Remember 2003? Yes, and now I'm going to have nightmares about it."

I think the post's author failed to identify the system they were trying improve using TOC principles. Was it a project team? An entire service group? Without defining the system, you can't really identify the constraints.

In the case of a law firm, each practice group might be the appropriate system. If there are synergies between practices, then a group of them may be the right system definition. When in doubt, focus on your customer. How can you maximize the throughput of value to them from your "system"? Not sure? Then you've probably got a market constraint. Get out and find out what you can do! Are you in a firm that doesn't believe in "marketing" and market research? Then you've got a policy constraint, and you need to convince some level of management to let you do it.

Service-based businesses will occasionally have physical constraints, but physical constraints generally involve large capital expenditures. Sure, there are times when filling slots in the "white hot technical skill du jour" category took major capital investment-type dollars, but professional service practice constraints are more often market or policy constraints. In the case of the white hot skill, what looks like a physical constraint is really policy constraint. If you really can't find enough people with that skill set, are you valuing and pricing it appropriately? Many a service-based business has learned the odd lesson of raising prices, doing less work, and making more money all at the same time. Like the Great Zucchini.

Defining the system in question also allows you to correctly identify the real constraints. You can then take the appropriate steps as listed by Goldratt. He doesn't say "manage the whole system with the constraint in mind". He says "Decide how to exploit the constraint if you can't practically eliminate it. Then subordinate everything else to the constraint. Elevate the constraint. Once you've done that, go back and see what the constraint is now." The former is not nearly as specific as the latter, and thus it loses the power of the concept.

This watering down of the concept leads the author to suggest several artificial constraints that might be appropriate for service-based teams, such as artificial deadlines with teeth and limiting design freedom. Of course, these have spotty results, as the author notes at the end of the piece. I am once again reminded of the drunk-looking-for-keys-under-street-lamps joke. Artificial constraints are like the street lamps. Sometimes the lamp happens to be right over the drunk's car, but more often than not, it isn't.

The guys from Juice Analytics are experts in their
domain. But they fell into the trap of not understanding the full concept of TOC before thinking about implementation. While not as bad as confusing context and application with concept, the results can be just as disappointing.


Final note: your staff's imagination is VERY SELDOM the appropriate constraint.



posted by Mike at 12:28 AM


2 Comments:

Anonymous Anonymous said...

One of the issues with the blogosphere is people reading blogs for arguments rather than reading for comprehension. I'm afraid that is what has happened here.

I'm the author of the Juice Analytics post on "Re-thinking Constraints" (http://www.juiceanalytics.com/weblog/index.php?tag=constraints).

If you had clicked through to my post, I think you'd recognize that I wasn't positing a new Theory of Constraints. Nor was I trying to comprehensively summarize Goldratt. Instead, I was asking my readers to consider the other side of the coin -- the benefits of constraints, particularly in the area of innovation (not on productivity, as you suggest).

The concept that leaves you "dumbstruck" is something that is being widely embraced in the web services arena (e.g. www.37signals.com). Even Google is talking about the value of constraints -- check out this article in BusinessWeek (http://www.businessweek.com/innovate/content/jan2006/id20060131_531820.htm)

Ms. Mayer from Google does a better job of summarizing the value of constraints argument than I could: "Constraints shape and focus problems, and provide clear challenges to overcome as well as inspiration. Creativity, in fact, thrives best when constrained."

That's all. We aren't trying to replace "The Goal" or suggest that most instances of constraints will benefit your company. Typically more people, more money, more space, and more time will enable more output. However, there are instances where speed, creative thinking, and quality do benefit from fewer resources.

7:44 AM  
Blogger Mike said...

Zach,

Thank you for your thoughtful comment. You can be sure that before I wrote my post I read your full post, the link in it to FocusedPerformance.com, and a good deal more of your blog. I read the article you suggested over at Business Week, and I think that it underscores my point. Ms. Mayer doesn't say she's applying the Theory of Constraints, just that constraints can provide focus and thus spur productivity in creative endeavors. I agree wholeheartedly; necessity is the mother of invention. But that has nothing to do with Goldratt's Theory of Constraints. If I was a reader of your blog and knew nothing else of TOC, I might get the impression that your post was a a good practical introduction to TOC. Matt Homann did. And his readers may now be similarly misinformed about the concept of TOC.

What left me dumbstruck is that someone would mention the Theory of Constraints and then say they’re not sure that one of its central tenets – that in any system there is a small number of constraints to throughput – applies to service-based businesses. That’s flat out wrong, and that’s why I used your post to illustrate my point. I then discussed the details of my disagreement with that line of thought. I have no doubt that rigorous application of the Theory of Constraints will always identify real constraints to system throughput, and that removing/elevating those constraints will improve throughput. I guess I’ll have to spend more time discussing how to do that in a future series of posts (it’s a bigger topic than a single post can do justice to). And I’ll need to use the Thinking Tools of TOC, not just the base throughput concept.

11:44 AM  

Post a Comment

<< Home