Eli Letters

Letter to members #2

July 99
To POOGI forum members,

You probably know that I‘m retired. Retirement is the period of life when people are supposed to do the things that they like to do, rather than devoting significant time to things that they are required to do. In my case, things that I like to do are not typified by playing golf or fishing.

Two years ago, when I retired, I was planning to write a book (or two) a year and entertain myself by leading one or two interesting projects. That is also what I actually started doing. I‘d written "Project Management the TOC Way," I started to move on the GM book, I took one project that was aimed toward finding out how to implement critical-chain in a complex, multi-project environment, and another project aimed at finding how to increase the chances of success of start-up companies. But it didn‘t take long to realize that I cannot find enough satisfaction in dealing with chupchiks*. So, I started to look into a much bigger issue: HOW TO ENABLE TOC TO SPREAD MUCH FASTER.

Here is my analysis, my solution and my plan of action. Please send me your own observations.
________
* Chupchik is a slang word in Hebrew that describes a situation where a person is busily working on something which does not count much. Or more vividly: "Pissing in the wind and feeling very proud about it".


ENABLING TOC TO SPREAD MUCH FASTER

The problem.

I think we all share the opinion that TOC - as a body of knowledge - is unique in its ability to improve organizations. When we compare the need of organizations to improve to the ability of TOC, it is no wonder that we expect to see an exponential spread of TOC among companies (not just awareness, but real implementations). Is it the case? And if not, why?

Why don‘t implementations spread from one plant to another, from one function to another, from one division to another? Why do so many implementations die? Why do so many new TOC licensees give up after a short while?

We all know the answer. It is because of the nature of TOC. The things that give the unique abilities to TOC are exactly the same things that limit the spread of TOC; making its implementations fragile and also causing it to be difficult to sell. It is the fact that TOC in general, and each of its applications in particular, are a "paradigm shift product".

Let‘s explain this last concept in more detail. The performances of superior conventional products are, at best, only a few tenths of a percent better than those of the competitors. This is not the case for a "Paradigm shift product" whose performance are an order of magnitude better than the competitors. The exceptional performance is a result of the fact that it is not based on perfecting the already established methods. It is based on a "paradigm shift"; on challenging at least one of the fundamental assumptions on which all competing products are based.

But its strength is also its weakness. When we try to convince people to adopt a conventional product we can safely assume that our audience is already familiar with the product. Therefore the conversation can start directly with the offered solution; with the explanation about the superiority of the specific conventional product. That is not the case when dealing with a "paradigm shift product". Starting by praising the product is a proven recipe for failure. Our audience judges what we tell them according to the established paradigm and therefore our claims raise deep skepticism or even resistance.

To convince a company to embark on any TOC application requires that it be introduced following rigorously the buy-in process (getting first a consensus on the problem, then on the direction of the solution, etc.). Most people, including experienced internal advocates of TOC and new licensees, do not follow the buy-in process. They are captured in the mode of praising the solution.

It‘s no wonder that new TOC licensees find it difficult to get new business. And after two or three unsuccessful attempts, they give up and revert back to selling the more traditional methods.

Also, it‘s no wonder that people who successfully implement TOC in their section of the company find it almost impossible to convince other sections to join. And this, as we learned the hard way, will always lead to stagnation and often even to the destruction of the section which did implement TOC*.

_______
* The undesirable effects that stem from confining the TOC implementation to one section can be classified into a few depressing categories:

- The improvements in the section that implements TOC lead to negative impact on the performance of the company. Examine for example a company where Production is feeding a large distribution network. If distribution is not adopting TOC, it is likely that improvement in production lead time will not be translated into a drastic cut in the desired levels of inventory in distribution. The increased throughput in production will result in inflated inventories in distribution - sometimes to the extent that the company might suffer from cash shortage.

- The ongoing improvements in the section that implements TOC do not, after a while, contribute to the bottom line. Simply, after a while, the constraint of the system is no longer in that section. Then the impact of this section‘s superior subordination is wasted since the other section does not know how to manage the constraint.

- The most frequent case: The TOC implementation is squashed. This happens when the head of the section is promoted and a new "cost world" manager takes over.

- The most devastating case: The constraint is no longer in the section that implemented TOC. The section continues to improve. The outcome is not an increase in throughput, but an increase in excess man-power. Then corporate decides to trim the excess. People are punished for doing the right things, and as a result the section folds.
_______

We all recognized that the problem lies in the difficulty of moving people through a paradigm shift. It is not easy to cause a section of an organization to go through the paradigm shift needed to embrace one application, it is not easy at all. But it is by far easier than causing all the top management of an organization to go through the mammoth paradigm shift needed to embrace TOC as the strategy and tactic of the entire organization.*

_______
*There is also a big difference in the required knowledge. We can teach (quite thoroughly) one application to experienced people within a period of two to four weeks. But to teach TOC to the level that a person can safely guide an enterprise-wide implementation takes much longer. I doubt if, after so many years, there are currently in the world more than 150 people who can safely guide any enterprise wide implementation.

_______

Baring in mind the difficulty of moving an organization to embrace TOC in full, what do you think is the common reaction of a TOC expert when he/she is approached by an organization that wants help in implementing a specific TOC application? And the application the organization wants is actually needed? And the people who approach the experts are in charge of just a section?

Yes, it is a rhetorical question. Rarely will a TOC expert insist on a full implementation. Moreover, when an organization is asking for TOC in general, the common practice of the experts is to do a brief analysis to identify the current constraint so that they can recommend the specific TOC application which should be implemented.

Even though it is the prevailing practice of TOC experts, most feel uneasy with this approach. Simply because reality has taught us that penetrating an organization through one application has a long term problem. The problem is that it increases the chance of locking TOC into one section of the organization, creating a fragile implementation. Yes, we have many examples of organizations which started with one application and successfully spread TOC to all functions until the organization firmly established itself on the red curve of POOGI. But let‘s face it, for each such an example there are at least five where the opposite happened.

Moreover, the best time to try and sway a company to embrace TOC as the overall philosophy is at the beginning, before the detailed (narrow) implementation starts. That is the opportunity to cause top management to do the full analysis, to agree on the direction of the long-term solution, and to place the first implementation steps in the proper context. This way, good results achieved using one application provide a natural step for expansion, rather than (as happens so often) an impediment. But, how many of us can pull off such a ‘sale‘? How many can turn almost any opening into an excellent opportunity to achieve such a grand enterprise implementation? Not many. Actually the word "many" does not fit this context. The answer is: too few.

Now our conflict is clear - can you picture the cloud? The objective (A) is to enable TOC to spread much faster. To do it properly, we have to (B) increase the rate of new implementations and (C) ensure long term successful implementations. However, in order to (B) increase the rate of new implementations we should (D) start with the TOC application that is desired and needed by the organization. But in order to (C) ensure long term successful implementations we had better (D‘) not start with the implementation of any specific applications but rather concentrate first on persuading all top managers to fully embrace TOC.

I‘m interested in learning how many of you experience the above conflict, so please take the time and answer the following question:

For POOGIforum Members who are not top managers of a business unit: Do you feel that approaching top management after you demonstrate results in your section will significantly improve the chances of persuading the business unit to embrace TOC? In your situation, what do you think are the dangers, if any?

For POOGIforum Members who are top managers of a business unit: Do you feel that approaching all top managers of your business unit, after  emonstrable results in one section have been achieved, will ease the efforts of persuading them to devote the time to construct the strategy and tactic for the business unit in the TOC way? In your situation, what do you think are the dangers, if any?

Please elaborate.

Next week: The direction of the solution.