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.