Of course, the impact on the management team is striking.  Leaders that only two years ago were praised for their ability to improve the company are suddenly gone.  New leaders, often from the outside, are brought in to shake up the company.  Existing leaders, who are not happy that they've been bypassed for promotion, begin to look for jobs on the outside. The end result is that leaders seem to have an expiration date on them.  Every two years, you have to go into the refrigerator and throw out all the leaders who have passed their expiration date.  It's not unusual for employees to wonder if the corner office has a revolving door, since they see a new face in that room every two years.

I came to realize this is my career with General Motors when I was assigned to a leader that I didn't really think I could work for.  When I brought this up to a mentor of mine who worked outside of General Motors, he asked if I could put up with the person for two years.  “Why two years?” I asked.  He described this phenomenon, and predicted that in two years I would have a new boss. As I look back through my career, I had to admit the data supported the prediction.  It did seem that the average time I worked for a boss was about two years.  By then, either he had a new job or I have a new job. Sure enough, after two years, another reorganization happened. The boss I was concerned about ended up in charge of another organization.  Since the new organization was smaller, it was viewed as a step backwards in their career. A few weeks later that boss disappeared and ended up working for a competitor.

The term I end of using for this phenomenon is Management Churn.  Now that I'm consulting on the outside, I realize that I have to take management churn into account as I develop a strategy for implementing continuous improvement in a company.  I have to make sure that I secure several management champions, not just one or two.  I have to make sure that my network includes potential future leaders, who can become my management champions for my improvement process after the churn occurs. And I have to remind myself that I cannot be disappointed or fustrated when management churn occurs.  It's as much of a corporate "tradition" as downsizing and outsourcing. And the only way to lessen or reduce its impact is to develop strategies and tactics that will allow my continuous improvement process to become sustainable. Thus, in order to eventually reduce the amount of management churn that occurs in the company, I must set up a continuous improvement process that can survive management churn.

It's also the reason that Eli Goldratt tends to avoid large companies.  Smaller companies seen to have much less management churn, and it appears to happen much less frequently. This allows a Viable Vision implementation, which typically lasts three to five years, to have some chance of success. When Eli eventually gets to the point where he wants to implement Viable vision in a large company, he'll have to put tactics in place that will allow him to overcome management churn.  Hopefully, I'll have a few answers for him when he gets to that point.

From a Theory of Constraints perspective, the reason is fairly clear.  The structure of the organization is not the root cause problem.  The root cause problem is probably the conflict that exists between local optimization and global optimization.  If the constraint happens to be in the organization that is limiting the performance of the company, there is a possibility that results will get better.  Since the organization of the company is very large, the chances of actually correctly identifying that part of the organization that has the constraint is small, certainly less than 33%. Even if we do add more resources and money to that part of the organization that has the constraint, improvement will only occur if the constraint can be positively influenced by money and resources.  Unfortunately, this will only last for a short period of time.  The constraint will eventually move to another part of the organization, and the rate of improvement will slow down and eventually become zero. 

The best we can hope for in every Reorg is a small amount of improvement, followed by an extended period of stagnation.  This stagnation is only tolerated for so long before leadership becomes frustrated again and demands changes.  Then another Reorg occurs.  Thus, Reorgs appear to be a cyclical process, and the time period appears to be about two to three years.

In my next entry, we'll take a look at the result of these constant Reorgs - Management Churn.

Most of the presentations I see lately start with the answer.  Typical statements run something like, “We have this great process (or software) – let me tell you how it will make your life easier.” Or, “Here’s what you doing wrong, which is pretty dumb, by the way, and here’s our smart, intelligent answer. No, we haven’t worked in a company like yours before, but trust us, this is the answer.”  Sometimes they plunge into the technical side of a software process – “Here the screen for order entry (show incomprehensible screen with 6 point font).  You can see how user-friendly it is.  You can POP data to this screen from SAP through an API, or drive it to a SCADA system using a TLA.”  Huh?

Then comes the frustration and disappointment from not getting the business from this client.  As we try to figure out why, we start by looking at others. “We weren’t talking to the right group – should have had more IT people in the room.”  “I made it pretty clear how much better our solution is than what they are doing now.”  “Now I know what they mean by the ‘Frozen Middle.’  Those guys must really fear change.”

It’s much harder to look in the mirror and ask if we could have done something different ourselves. The TOC Thinking Process taught me to start with understanding the problems the organization is facing, and then to search for the root cause problem.  For this TOC process, this first step ended up with the Current Reality Tree (CRT), which listed the problems you gathered from the client (the Undesirable Effects, or UDE’s) and logically connecting that to the root cause.  At the heart of the root cause was usually a conflict that a person or group of people where struggling with. The lack of resolution of that conflict was causing all the problems.

When covering the CRT logic with your client, you had better get agreement on all the UDE’s first – gain agreement of the problem before you go any farther.  If you did not have that, stop! Then you logically went through the process of describing the root cause and the conflict.  Then you start working on the solution.

One you have the solution worked out (another part of the Thinking Processes that I won’t cover, for now at least), you had to test that it addresses sufficiently the root cause, did not cause other major problems, and resolved the UDE’s.  I’ve taken that method (reinforced with Solution Selling) to the sales process when I work with clients.

I try to establish those UDE’s from the first contact.  I like to ask a question like, “What are the three things you find yourself worrying about at 2 in the morning?”  No doubt about it, UDE’s keep you up at night.  While there can be many different types of root causes from many types of business, the 80-20 rule seems to apply – we have tools that address about 80% or more of the problems our clients face. These UDE’s point to the solution.

When pitching the solution I thing will work, I go back to the UDE’s and ask for them again, or restate them, until I gain agreement on the problem.  Then I talk about likely root causes, and make sure I get head nods and agreement on that before I start the next step.  Then I talk about the solution, and demonstrate how it addresses the root cause, and then the UDE’s.  After ensuring clarity on this, we usually get the nod to put together a proposal.

Failure is still a possibility, but you can’t get any work without a proposal.  Using this methodology, at least for me, seems to have worked pretty well.  It also can help me avoid pitching solutions to clients whose problems I can not solve, saving them time and me frustration. 

The downside is that I am starting to get pretty busy – and I don’t have as much time to blog. That is especially true now that I have Guitar Hero III, but that’s another story.  Keep on rockin’!

Faster machines could, according to their cycle time, produce more parts than the bottleneck.  In reality, they spend a lot of their time waiting for Herbie – blocked or starved, as well as down.  Over time, they made no more parts than the bottleneck, but had a higher capacity, thus their efficiency had to be lower.

And the two machines we were studying?  I dubbed them the “anti-bottlenecks” – the fastest machines in the plant!  The stock cutting machines was really fast – it ran hundreds of parts in an hour.  The press, too, had a cycle time of a few seconds.  The bottleneck cycle time was just under 60 seconds, so these machines were several times faster than the constraint.

And what was the biggest delay for both of these machines?  If you guess “Waiting for baskets,” go out an buy that cupie doll you have always wanted.   What, then, was the action plan to improve the efficiency of this plant?  Buy more baskets!!!

But I had a hard lesson to learn that day myself.  After collecting the data from delay studies and a quick study on the bottleneck, I entered into the bottleneck analysis program C-Thru.  Of course, it confirmed my analysis, and demonstrated that improving the stock cutter and the press would have no impact on throughput or efficiency.  Further, buying more baskets would only improve efficiency during the time it took to fill those baskets.  After that, efficiency would return to today’s level. 

Fixing the bottleneck, however, would have a huge impact on throughput.  That area had to be the focus of improvements.  Studying the bulletin board further, I found that most of the action plans resulting in INCREASING the cycle time of the constraint, thus reducing what little blocking and starving there was, AND increasing efficiency.  Of course, throughput for the plant went down as well, but that was not obvious to them. It was clear to me that those changes would have to be removed.

Armed with my analysis, I went to the plant sponsor (who was also the efficiency program champion) and, in front of my folks and the other central office people there “to help” told them he was doing EXACTLY the wrong thing.  This program was damaging the plant, not helping it.  He would have to undo all those award-winning suggestions on the bottleneck.  He would have to stop worrying about the least efficient machines and focus the plant’s efforts on the most efficient machine. 

I think he listened for about a minute and then tuned me out.  After my report out, he thanked me for my analysis, and said that they were going to continue push the efficiency program as the way to save the plant.  I was stunned.  All I could think to say was, “Then I come by on the day they close the plant.”  He gave me a funny look, shook his head, and left. 

Of course, the plant’s performance continued to suffer, until the plant was eventually sold.  It then closed, but not officially under the GM logo.  For a while, I blamed the sponsor’s ignorance and politics for not following my advice  But after going through Jonah training and Clouds, I realized that in my rush to tell him the answer (and prove myself right, of course) I had not resolved his conflict.  That was a tough lesson.  Could I have saved the plant?  Probably not – those skills and experience would come with time, and much of my learning at this point in my career with TOC was trial and error.  But I still wonder about it just the same.

I use this example in my training classes all the time, for it reinforces several key points:

• The bottleneck is usually the most efficient machine (or has the highest utilization or highest OEE).  I often use this as a quick quiz to see if someone really understands TOC as much as they say they do. 

• Use inventory to find the bottleneck, especially the first time through.

• You have to understand the conflict your client faces to be able to solve it for him, thus shifting his paradigm to one that includes your solution.

• Efficiency measures have a very limited usefulness, and probably could be set aside, for all intents and purposes.

• You have the ability to save your plant, or elevate it to the next level or performance. And it’s your job to do that, so don’t wait for someone to tell you it’s your job.

We were just getting started in the Throughput Improvement game, and the “green” team that we had put together from various parts of the corporation was lacking some basic IE 101 skills.  When I heard that one of the experienced IE’s in our department was giving a class in delay studies at a local plant, I jumped at the chance to get a few of my folks in the training.

Despite being an EE, I had a wealth of experience in IE studies, since I was sponsored by Industrial Engineering at the Cadillac Clark Street plant (now a weed-filled lot).  Riding freight elevators to document usage, performing cycle time studies, chasing AGV's for downtime info, etc., were all part of my co-op experience, so I had a solid foundation. But I wanted my folks to see how it was done in the plant, and thus the emphasis on getting out of the class room and on to the plant floor.

It was fairly well known that the plant we were visiting was in trouble – poor throughput, long lead times, etc.  There was a lot of “outside help” in the plant trying to improve the situation, but we were only here for the class, so I doubted we’d be able to see or do much.  As we walked through the plant it was obvious that there was a huge efficiency push going – banners and signs were located throughout the plant extolling workers to be more efficient and productive.  In the middle of the plant we passed a bulletin board with pictures of a team of operators smiling out of photos whose backdrops were a pizza parlor, a baseball game, etc. Along with the photos were cheap ribbons indicating they were #1 in the plant in efficiency. Lists of successfully installed action plans rounded out the board.  I was starting to get a sick feeling in my stomach. 

After a review of the basics, my folks were broken down into teams and asked to collect data on the worst machines.  One was a fairly simple machine that cut metal stock into lengths for leaf springs.  The other was a press used to stamp out parts needed for the suspension.  Why these machines?  Because the data showed that these two operations were the least efficient in the plant. 

Did these machines have problems?  Certainly – parts jammed inside the machine, dies had to be replaced, tools sharpened, etc.  Were the operators working hard?  Yes and no – when they worked, it was like watching industrial athletes.  But all too often they had to stop and wait.  Why?  Well, the delay study showed they both had the same root cause delay.  Any idea?  Read on.

My TOC background and my reading of The Goal told me that we should be doing a delay study on the bottleneck.  Was one of these two machines the bottleneck in the plant?  The simplest method was to do what Jonah showed Alex to do in his plant – look for the inventory!

While the others slaved over their stopwatches and clipboards, I hunted for inventory.  It didn’t take long, because I was pretty sure I knew where to look.  There, near the middle of the plant, right next to the bulletin board, photos, and ribbons, was bay upon bay of inventory, stacked floor to ceiling in baskets, right before the most efficient area in the plant – the bottleneck!

(Continued in the next Blog Entry!) 

Oh, they want to learn more, but I find I have to be VERY patient with this client, even though I want to point out their situation will get better the faster they learn about the solution I am proposing.  But scheduling a meeting with the right people takes weeks or months, and then when I go to do the pitch, another emergency has arisen, and they ask if I can come back another time (at my own expense, of course) to make another presentation. 

Working with these clients is a tough decision.  I usually have to set a limit on my involvement, to make sure I am not taken advantage of.  I look for several things in making this decision.  Clearly, one of the factors is communication.  If they are actively engaged in a two way discussion, and understand their Undesirable Effects, or they can admit the pain/problems they are experiencing, that’s a plus. Another is their willingness to work with me. If they offer to pay for my trip the next time, or set aside time on a weekend to hear a pitch, that’s also a step in the right direction.

Finally, I look to see if this potential client has the ability to realize that they will be better off if they take the time to take swimming lessons.  To that end, they must be able to draw a line, and say that this presentation I am going to give is just about the most important thing this company has to do to improve.  I have to see this type of behavior at some point to keep working with this client.

A few never get there.  They don’t even get the joke within the title of this blog.  They often take about all the emergencies as “one time events,” but then admit they occur two to four times a month.  Their management system creates emergencies at a predictable rate as a side effect of their process. Tougher still is the fact that my contact is usually a middle manager who “gets it,” and wants to get off the treadmill. But they are having trouble convincing their leadership and other managers.  

This may be due to the fact that a number of these managers are essentially professional “fire-fighters,” and enjoy the challenge that comes with these emergencies.  They may actually fear the stability that might be generated by a new process, because their fire fighting skill will not be valued.  I look for these signs when faced with “drowning” clients.  For these clients, I have to justify it as a “cycle of life” in the business world, and move on.  

Lucky, most get it, and with a bit more patience on my part, they set aside the time for swimming lessons, and even for swim practice.  For a few, I have dreams of the Olympics…

In the consulting world, I run across a lot of potential customers that would be great to work with.  They have an interesting product, they have a lot of sharp people, they are poised to grow significantly, etc.  Many times the need for the solution I am offering is very apparent, at least to me.  But the question I ask myself now is, “is there enough pain?”

It has become a filtering process to help me decide who I am going to spend time with, and who am I going to push farther down the list of prospects, especially for follow up work.  Many of my potential clients are interested in the Theory of Constraints, simulation, data collection, scheduling, project management, etc.  But often it is just that – curiosity.  They don’t really feel enough pain to change their paradigm to the solution that I am describing to them.   

For some of these clients, I could rattle off a list of Undesirable Effects that are due to one conflict or constraint.  I could then follow that with a proven solution that I can clearly explain will have benefit to them.  I could go through a list of clients that would be willing to sing the praises of that solution in their company.  But for this client to make the change from where they are to the new process I am proposing is a tough choice for them, because they fear the solution more than their current situation.  For most of my clients to make the jump, they have to feel that of pain from their current situation is so bad that they are willing to try any solution that makes sense.

Some of the consultants who I work with get stuck on this – they see a client they would REALLY like to worth with, and who they think they can provide a lot of benefit.  But they are frustrated that the client doesn’t want to move to the new solution.  These consultants keep going back to these clients, constantly trying this method or that method to get the client to buy their solution. But their target clients are fairly comfortable with their current situation, and see little reason to move.  Like in the Mermaid situation in a previous posting, they are okay dealing with the problems they have.  I have to advise these fellow consultants to move on to other clients, because if their potential clients don’t feel the pain, the chances of your solution being adopted are slim to none. They are better off quickly moving on to the next potential client, and hope that this one is squirming with pain.  Then they might see a client “getting off the pot,” and adopting the proposed solution.

As we caught up, he told me about his success and failures, a lot of the past battles and lessons learned were revisited.  Soon, a list of common obstacles came up, and with it, a fresh set of choopchicks.  The one I would like to spend a few minutes on today is “The Check Box Mentality (CBM)”

Definition

Easily one of the commonest ailments in the frozen middle layer of middle to large size companies, the CBM is subtle cancer that is difficult to detect, unless under direct examination.  It happens when a task is deemed complete, even through the true intent of the task has not been accomplished.  An example from my past follows – feel free to post whatever examples you have seen. 

Example

The task is simulation for the new manufacturing line.  The boss/project manager asks, “Is this task done?”  The answer from the task owner is “Yes.”  There is a long stare from the boss/project manager, as s/he ponders whether to ask a follow up question.  Decision made, s/he moves to the next assignment and asks the next owner for an update.

No direct lies where told, but the intent of the task probably was not fulfilled, if we look more deeply at the conversation above.  The task is really intended to valid that the new manufacturing system will run approximately to the original requirements.  It turns out a simulation has been done, but it actually shows the line will run far less than the design spec.  But the simulation has been done, and the task owner, if faced with this conflict, can “check the box” and say the task has been completed. 

This can be more apparent when an upper level executive ties a reward to this box being checked – You cannot get funding for this project unless it has been simulated.  The task owner can say with confidence that the design has been simulated, and the task is complete.  S/he can rationalize that the project is late already (See Mutually Assured Lateness) and we’ll fix the design once we secure the funding.  Or that the plant will have to run better (say at 105% uptime) to reach the design target, etc., etc.  Fill in whatever rationalization you might have seen (or used yourself) to help justify why the box should be checked.

The boss/PM hesitation is not for the sake of the story – this person has probably done this task or one similar to it in a prior job.  S/he has to decide how much they want to know.   If they have been through that prized corporate ritual called “The Scapegoat Hunt” before, they may already be thinking about who they want to throw in front of the bus first.  Knowing the rules of the Hunt means that when they asked the question, they meant it based upon the intent of the question – has the system been validated by simulation or not.  They can blame the task owner for not living up to the intent of the task, and point the finger at them if they themselves come under fire for problems that (enviably) come from the new manufacturing system.  

In defense of the task owner, they are probably overworked and heavily mult-tasking on several projects already.  Getting the simulation box checked off is easy, since the results of the decision to check the box may not been realized for months or years. Plus, this task owner will probably not have to live with the consequences of the decision.  Many changes will come to the design between now and then, so if will have to be re-simulated anyway.  Continue rationalization as required.

A Choopchick?

CBM is the effect, not the cause, of why some many things seem to go wrong with new programs or projects.   Is it a Choopchick?  In my opinion, yes.  There is a lot of effort being put forth by employees to “get your boxes checked”, versus working across silos and focusing in on the constraint in the company.  The amount of effort spent on checking the box with so few (or negative!) results make CBM a triviality.  What’s the root cause?  That will take another blog or two!

One of the most futile efforts I have had the pleasure of working through in my career is the budget and headcount process in a large company.  This process is essentially a shaman's ritual  - gaze into the crystal ball and determine how much money and resources we will need for the next 12 months.  It's about as accurate as marketing's forecast for the next 12 months, except we have one piece of data - what was your budget and headcount last year?

Worse still is that budget’s and headcount are broken down to very small groups – a supervisor with 10 people will have a budget and headcount target.  The assumption is that going down to this level will be more accurate, and make the supervisor more responsible for the decisions impacting his group.

Now it seems fairly obvious that there is a tie in between headcount and budget.  The budget depends to a great extend, especially in engineering operations, on how many people you have in your department and group.  But this logic didn’t fly in one company I worked for, and they made no real attempt to keep the two in sync.  Why?  Because those two numbers have to be approved by two separate organizations in this large company: financial for budget approvals, and HR for headcount approvals.  To avoid excessive thrashing on this problem, they simple took last year’s budgets and headcounts and slashed them by a certain about (5-10%) from the previous year to determine this year’s budget.

That didn’t end the debate, however, since some groups end up with a legitimate reason to increase head count – safety, throughput, program-of-the-month, etc. Thus, you could get approval for a head count increase in HR, but due to budget limitations, end up not receiving any budget increase.  Thus, if you did not want to overrun your budget, you could not hire these two people. And over spending your budget in tough times was a sure way to have your own name end up on a cost saving list.

Likewise, when a manger ended up in charge of two groups that had been consolidated into one to reduce headcount, you could find yourself with a large budget, but with the total headcount significantly reduced.  Suddenly, in order to keep your budget for next year, you had to find a way to spend that money on something beside headcount. 

My first (and turns out, only) advice from the department financial person in the department where I was a manager was, “There are only two rules – 1. Don’t overspend your budget, and 2. Don’t under spend your budget.” This usually leads to the punch line of a Dilbert cartoon, like the one where the pointed-haired boss buys a giraffe at the end of the year to make sure his budget is consumed. For Consultants and contractors, this can be a boom time, since they usually (emphasize usually) end up with a bunch of contract work, since this expense had no impact on headcount.

In my case, I had contractors who worked for me for years, since I had budget for them, but not the headcount.  I am sure I paid for the equivalent of three employee salaries for every two contractors that I had, but it was the only feasible answer.  Even worse, since most of these contract engineers were young kids out of college, they somehow thought their great work (and much of it was great) would lead to an eventually hiring.  It did happen, when the fates allowed for a favorable change in the budget to headcount ratio, but it was pretty rare.  Still, it was those rare occurrences that keep the hope alive for these engineers.

Beside all of this chaos comes the constant battle between groups for people and headcount.  How do you get a 5% reduction in headcount when you have two groups each with 10 people.  Only one person has to go, but which supervisor will take the hit?  These two supervisors will begin to campaign to keep their headcount, and cast doubt on the effectiveness of the other supervisor’s ability to manage his people, the lower importance of the work the other group is doing, etc.  More conflict and chaos.

In the end, about half way through the year, the budget and headcount meetings will wind down, and the organization will pat itself on the back for slashing costs.  But like the previous choopchick of cost savings, the same problems apply here.  Because the organization has little clue of where the constraint is, they probably reduced the budget and headcount of the constraint department, which could lead to less revenue.   Net Profit, despite the company’s best effort, continues to go down.

Some thoughts on how to resolve could go in several directions.  My recent improved understanding of Viable Vision, however, makes me conclude that budget and headcount targets are choopchicks, and the company needs to figure out ways to increase revenues much quicker than operating expenses.  There is a much stronger impact on Net Profit by undertaking a Viable Vision than arguing about a few thousand dollars here, and an employee or two there.  Headcount and budgeting becomes trivial, and burning as much time as most companies do on this subject takes their focus often the more important elements of creating a competitive advantage and then being able to capitalize on it. 

So that makes the budgeting and headcount target process my next favorite choopchick – any comments?

Kevin

Identifying a constraint means that we already have some appreciation of the magnitude of its impact on the overall performance. Otherwise we might also have some trivialities in the list of constraints, or as I call them, some choopchicks.

Every now and then, I’ll blog on some of my “favorite” choopchicks, which usually appear not only with past clients, but seem to keep appearing with current clients.  Today’s blog will be on what I feel is perhaps the biggest choopchick:  cost cutting, or what a current client calls, the “War on Costs.”                     

I think cost cutting is the biggest choopchick because most of the companies who are on a cost cutting binge are frustrated that despite all their fine efforts, profits are not increasing.  Often, the company actually is losing more money that when they started the program!  If they are spending so much time on it, and it is yielding such poor results, then the actions may be focused on a “trival” cause and thus can be classified as a choopchick.

The cost measure is one management loves, because it looks to generate results quickly.  Cut a head here, slash a budget here, reduce inventory over there, sum up the total, and just like that, a manger has hit his cost cutting goal for the year.  In reality, most of these cost cutting actions have no significant effect on the bottom line, and many, especially if they impact the constraint, may actually have a negative impact on the bottom line.  The lost head may have been a problem solver on the throughput team, the budget was for a change to modify a bottleneck to reduce it’s downtime, the inventory was the buffer that was protecting the constraint from periodically running out of parts.  

Since most companies have no idea where their constraint is, they are blissfully ignorant, and assumed all these pennies saved will eventually add up to dollars.  Worse, this negative effect is often not even perceived, since the actual undesirable effect of adversely impacting the bottleneck may not be seen for quite awhile, and the connection between cause and effect may not even be realized.

My favorite example is the case of a manufacturing company who was working with two suppliers to supply dies for a production operation.  Both suppliers must be used; because neither of the two has enough capacity to supply all of the large number of dies required. The names have been changed to protect the guilty.

I was part of a team that was asked to come in to this company and figure out why a particular line wasn't running up to design rates, which was causing a tremendous loss in revenue. We were confused at first, because the machines that appeared to be the constraint (look for the buffer) seemed to be running to their designed capacity. Also, the data that production and maintenance provided our team was confusing, because there did not appear to be enough "down" time to justify the loss in production.

We soon figured out that the lost time was due to a machine that was down waiting for a die.  It was not considered machine down time by maintenance or production, because there was nothing wrong with the machine.  It was not considered set up time by the die setters, because a set up was not actually underway.  It turned out that there was actually no die to put into the machine!  We tracked the issue back to Purchasing, who had not acquired enough dies from their suppliers. 

We eventually ended up talking to a purchasing agent with a huge award plaque on his back wall for his contributions to the "War on Costs."  It turns out he has squeezed most of his suppliers for first one 5% reduction, and then followed that up a few months later with a second 5% reduction. 

One of the two suppliers for the dies could no longer make a profit on the manufacturing of these dies, and complained about the mandatory price cuts.  Of course, Purchasing was upset about this pushback, and placed the supplier on the "black list," preventing other purchasing agents from using this supplier.

Meanwhile, the other die supplier did not have enough capacity to supply enough all the dies, even though they, by default, got all the work.  Pressuring them for improved performance proved fruitless, since the slim profits did not justify investing in extra capacity to make more dies.

Thus, for a 5% reduction of a die (less than a few thousand dollars), the company ended up with a shortage of dies, and that resulted in constraint machines sitting idle waiting for dies that would never be supplied.  The lack of parts from the bottleneck machine resulted in a lost of production - the revenue from each product turned out to be easily twice as much as the savings from the cost cutting effort.

But the purchasing agent had won an award, gotten a bonus, and the long deserved recognition of his superiors.  He was, needless to say, reluctant to reverse this decision and admit that he might have made an error. But the weight of the numbers and the crush of the crisis caused him to cave in.  The supplier was taken off the black list, the dies ended up in the bottleneck, and the throughput of the system significantly increased.

In the end, I wish I could say the company learned from this example, but the reality is that is was an extreme case.  Unless the cost cutting decision has disastrous results which can be traced both quickly and directly back to the decision, most cost cutting still stands, no matter how trivial.  The result is companies pushing cost cutting to the extreme limit – like requiring admins to dole out color printer sheets, or making employees empty their own waste baskets.  It should surprise no one with a TOC background that these efforts are “trivial,” and have no significant positive impact on the bottom line.  And any Jonah would predict that these companies still cannot figure out why all of their cost savings never really hit the bottom line.

What’s your favorite choopchick, and why?  Do you have an example and/or story you would like to share?  Let me know!

Kevin

Mutually Assured Lateness dictates that no matter how early or late you submitted a task to a constraint (or a resource on the Critical Chain), it would be released late by that resource by a fairly constant amount.  In other words, if you delivered a task two weeks early to the resource or two weeks late, the task would always come out 4 weeks late.

The key to understanding why this occurs is the impact of multi-tasking.  The resource itself was reacting to how it was being measured, rewarded, and punished.  If the task came in early, then the resource reasoned that it could afford to wait, especially with the large number of tasks that it had to work on that were already late.  Calls from the project manager could be easily deflected: "I have a lot of work that is much later than your stuff – it will have to wait – unless you can convince another PM to give up their spot on my To Do list to you.  Which, by the way, has never happened since I took this job."

After this conversation, the project manager may elevate the issue.  But his boss faces the same issue when trying to resolve the problem: "Hey, if you want to give up some of the extra budget or headcount to help out the other department, let me know."  That’s a lose-lose scenario – if you had enough extra budget and/or headcount to begin with, you probably have been hiding that “fat”somewhere in your department, and can afford to lose even more in the future. 

More importantly, everyone now has a viable deflection shield: "Hey, the constraint can’t seem to run his area well, nor can his boss.  It’s not my fault if they can’t run their area as effectively as I can."  Thus, the early tasks end up waiting in the queue.

The late tasks are already in trouble, and how late they are gives them some leverage on the constrained resource.  Often the PM on this late project, since it has lasted several years, has already been replaced, with a professional “Squeaky Wheel,” who calls the resource every day (or more often) to get his or her work done.  While this task is not completed early, it probably ends up happening earlier that other late tasks.  The early task, if the PM is not as aggressive as the Squeaky Wheel, may just have been passed!

In the end, each of the tasks ends up being late by about the same amount – which resulted in the term – “mutually assured lateness.” 

While browsing the CMSIG over at Yahoo!, I came across this entry from Jack Vinson:
 

We often talk about TOC being "common sense." And we always follow that up with some version of, "but it isn't common practice." I have a funny feeling about this. Is this idea being used to tell our clients how smart we are -- and how dumb they are? If we show them that they haven't been following "common sense" are we telling them that they are dumb?

So, the question is, are we insulting our clients when we show them how "simple" things are? Are we damaging our own reputation by providing "easy" solutions? What is the balance between providing complicated-seeming solutions and solutions which are simple-yet-not-common-practice?

I think the following cloud begins to address a few of Jack’s points.  It’s from a story Eli told at TOC-ICO, which I have taken a few liberties with.   You are at the bottom of the cliff at a beautiful seashore.  With you is a beautiful mermaid that you really like.  At that same time, there are an ever increasing number of alligators appearing, and you have had a few close calls.  (They don’t seem interested in the mermaid, if that’s a concern, but you look like an all-you-can eat buffet to them).

Along comes a consultant, and he points to the top of the cliff.  "Look up there - that's a pot of gold!"  You look and are amazed you haven't seen it before - it IS a pot of gold, and it looks huge.  The consultant continues, “Ah, its simple and its common sense! Build a ladder and go get the pot of gold!  You’ll avoid the alligators as well – it’s a win-win to me!  Where do I send the bill?”

But the consultant can’t really see the mermaid.  Oh, he understands she’s there, but he keeps pointing at the alligators and the cliff and palm trees, and says you should get busy, and he's probably right.

But you don’t get started.  You’ve seen other people build ladders to get coconuts or bananas, and a lot of them seem to fall (or get pushed).  And there always seems to be an alligator at the bottom of the ladder when that happens.  Plus, that cliff is high!  Can I build a ladder that big?  Will the sand support it?  Is there stuff on the cliff that could attack me, or my ladder?  It looks cold up there, and all I have are a t-shirt and shorts.  Hmm, well, I’ll think about it some more, but for now, my mermaid is singing, and she has a nice seafood chowder on the stove.  Plus, I’ll have to whack that alligator who is sitting at my place at the table.  We’ll look at it tomorrow….

But tomorrow is full of alligator fighting, and the chief show up with unreasonable demands for coconuts, and then the hut caught on fire. Plus, no one else is building a ladder to get up the cliff  – I’ll start building mine once they have shown they can get it working.  Yes, building a ladder and getting the pot of gold is simple, and it makes perfect sense, but there’s a different between simple and easy!

That’s the different – simple vs. easy.  The VV process is not meant to be easy.  In fact, one of the key steps at the beginning is to convince the client that cliff is much higher than they thought!  But the VV process also points out the potential hazards, and the solutions (here’s how you make sure the base will support the ladder, here’s how you make a ladder that big, once you get to the gold, you can buy new clothes, etc)  It also acknowledges the Mermaid, and makes sure you are willing to leave her behind.  If not, let’s not start the VV process. 

So here’s this week’s cloud – hope it makes sense!

1. In order to A I must B because...

·         Wealth allows me to acquire basic needs – food shelter, clothing.

·         It allows me to help others.

·         It will allow me to purchase things to make me happy.

3. In order to B I must D because...

·         There are plenty of palm trees to make a ladder.

·         It’s a HUGE pot of gold.

·         Climbing the ladder will also allow me to escape the ever increasing number of alligators that are coming to where I am.

2. In order to A I must C because...

·         An injury would make me very unhappy, and be very painful. 

4. In order to C I must D' because...

·         Ladders can be dangerous, and I have seen other people fall (or be pushed) off a ladder many times before.

·         No one else seems to be building a ladder – they must be smarter than I am. .

·         The mermaid is VERY beautiful and likes me a lot.

·         I’ve been able to handle the alligators so far  -- it’s a risk I understand.

·         I don’t really know what other risks beside falling off that there are building and climbing that ladder, but my intuition tells me that there are a lot. 

5. I can not do D and D' because...

·         The mermaid cannot climb the ladder, and I cannot carry her.

·         There is no other way up the cliff.   

The cloud below reflects a conflict from a popular movie.  I'll use it as a reference on how clould should be used and examined.  

Comments should be directed to one of the entities 

Situation: 

In the movie, Beauty and the Beast, Belle finds herself faced with a conflict.  She has just escaped from the Beast and his castle, but on the way back to her village, she is attack by vicious wolves.  The Beast has appeared from nowhere to save her and driven off the wolves, saving her life.  But he has been injured, and has collapsed unconscious on the icy ground.  Should she get on her horse and leave the Beast to die, or take the Beast back to his castle.

In order to A I must B because...

• The beast has imprisoned my father and has been mean to me.

In order to B I must D because...

• The beast will probably imprison me if I do not leave.
  

• The Beast will be angry with me for leaving his castle.

   

In order to A I must C because...

• I will not be able to live with myself if I intentionally cause someone to die.
  

• My father will be upset if the Beast dies, even if he was imprisoned by the creature.I need a predictable cash flow to reduce the money stress on my family.

In order to C I must D' because...

• I will not be able to live with myself if I let someone who save me from death die in turn because of my actions.
  

I can not do D and D' because...

•  I cannot both leave the Beast in the woods and take him with me.

Reserve your comments to each one of the assumptions or one of the boxes - no whining. complaining or sniping!

In order to A I must B because...

• I will be happy working on things that I am passionate about.

• There is a general believe that if you work on things that you are passionate and skilled at, you will make money. 

In order to B I must D because...

• I am passionate about and skilled at TOC. 

In order to A I must C because...

• I need a predictable cash flow to reduce the money stress on my family.

• According to Tipping point, you must be skilled, passionate, and work in an area that will generate profits.
  

In order to C I must D' because...

• GC will continue to require me to put the money “upfront” for this process - and it will be a SIGNIFICANT investment of my time and money. 

I can not do D and D' because...

• I cannot join and and not join TOC at the same time.

• I can work part time for a while, but sooner or later I will have to make a full time decision, so working part time will only delay the decision.
  

 Reserve your comments to each one of the assumptions or one of the boxes - no whining. complaining or sniping!