GM's Broken Axle

GM's Broken Axle is American Axle & Manufacturing, which it spun off in 1994. Now labor's on strike there, and GM is finding that its monopsony on axles does not compare to their monopoly:

GM relies heavily on parts from American Axle, buying about $2.6 billion of them, including axles and key components in most of its trucks and some passenger cars. Currently, 28 GM plants are either idled completely or have cut production thanks to the strike, which started on Feb. 26. At least one more — a factory building the Cadillac DTS and Buick Lucerne sedans, just outside Detroit's city limits — will go down next week.

As of last week, GM lost 80,000 vehicles' worth of production as a result of the strike, says one company insider. Because carmakers book revenue as soon as a vehicle leaves the assembly line and heads to a dealership, the strike is hitting GM's top line. At least one analyst has dropped his first-quarter profit expectations as a result. Deutsche Bank (DB) analyst Rod Lache issued a report earlier this week boosting his forecast for GM's quarterly loss from about $600 million to almost $1.4 billion.

"Richard Dauch [American Axle's chairman and CEO] isn't just locking out the UAW," says Sean McAlinden, chief economist at the Center for Automotive Research in Ann Arbor, Mich. "He's locking out GM."

Lache says the strike is costing GM about $890 million a month. The only mitigating factor is that the truck production being lost probably would have been cut anyway, because sales are falling. So Lache didn't cut his earnings expectations for the year. But a two-month strike will start to have more permanent effects, he says.

Note two key points:

• Because carmakers book revenue as soon as a vehicle leaves the assembly line and heads to a dealership, the strike is hitting GM's top line.
• The only mitigating factor is that the truck production being lost probably would have been cut anyway, because sales are falling. So Lache didn't cut his earnings expectations for the year.

Goldratt (of Theory of Constraints fame) would have a field day with this. The makers mistake shipping a car with selling a car. The dealer does not assume the risk of selling or not selling the car — the maker does — so all those cars on the lot are just thinly disguised finished-goods inventory. They're not true throughput.

On a lighter note, the strike probably isn't hurting throughput, because axles are not a meaningful constraint on sales right now — demand is — and GM needed to cut production anyway.

Planning Fallacy

When I recently discussed project management — in Critical Chain 1, 2, 3, 4, 5, and 6 — I touched on the planning fallacy:

A bigger issue still is that people are notoriously bad at estimating task durations, and they are notoriously overconfident in their ability to estimate. The optimistic and pessimistic estimates are supposed to book-end a range that covers almost all possibilities — 99 percent — but far more than one percent of tasks fall outside those estimated ranges.

Eliezer Yudkowsky discusses the Planning Fallacy in much greater detail:

Buehler et. al. (1995) asked their students for estimates of when they (the students) thought they would complete their personal academic projects. Specifically, the researchers asked for estimated times by which the students thought it was 50%, 75%, and 99% probable their personal projects would be done. Would you care to guess how many students finished on or before their estimated 50%, 75%, and 99% probability levels?

• 13% of subjects finished their project by the time they had assigned a 50% probability level;
• 19% finished by the time assigned a 75% probability level;
• and only 45% (less than half!) finished by the time of their 99% probability level.

As Buehler et. al. (2002) wrote, "The results for the 99% probability level are especially striking: Even when asked to make a highly conservative forecast, a prediction that they felt virtually certain that they would fulfill, students' confidence in their time estimates far exceeded their accomplishments."

It gets worse:

A clue to the underlying problem with the planning algorithm was uncovered by Newby-Clark et. al. (2000), who found that:

• Asking subjects for their predictions based on realistic "best guess" scenarios; or
• Asking subjects for their hoped-for "best case" scenarios...

...produced indistinguishable results.

So what's the solution?

Unlike most cognitive biases, we know a good debiasing heuristic for the planning fallacy. It won't work for messes on the scale of the Denver International Airport, but it'll work for a lot of personal planning, and even some small-scale organizational stuff. Just use an "outside view" instead of an "inside view".

People tend to generate their predictions by thinking about the particular, unique features of the task at hand, and constructing a scenario for how they intend to complete the task — which is just what we usually think of as planning. When you want to get something done, you have to plan out where, when, how; figure out how much time and how much resource is required; visualize the steps from beginning to successful conclusion. All this is the "inside view", and it doesn't take into account unexpected delays and unforeseen catastrophes. As we saw before, asking people to visualize the "worst case" still isn't enough to counteract their optimism — they don't visualize enough Murphyness.

The outside view is when you deliberately avoid thinking about the special, unique features of this project, and just ask how long it took to finish broadly similar projects in the past. This is counterintuitive, since the inside view has so much more detail — there's a temptation to think that a carefully tailored prediction, taking into account all available data, will give better results.

But experiment has shown that the more detailed subjects' visualization, the more optimistic (and less accurate) they become. Buehler et. al. (2002) asked an experimental group of subjects to describe highly specific plans for their Christmas shopping — where, when, and how. On average, this group expected to finish shopping more than a week before Christmas. Another group was simply asked when they expected to finish their Christmas shopping, with an average response of 4 days. Both groups finished an average of 3 days before Christmas.

Likewise, Buehler et. al. (2002), reporting on a cross-cultural study, found that Japanese students expected to finish their essays 10 days before deadline. They actually finished 1 day before deadline. Asked when they had previously completed similar tasks, they responded, "1 day before deadline." This is the power of the outside view over the inside view.

A similar finding is that experienced outsiders, who know less of the details, but who have relevant memory to draw upon, are often much less optimistic and much more accurate than the actual planners and implementers.

So there is a fairly reliable way to fix the planning fallacy, if you're doing something broadly similar to a reference class of previous projects. Just ask how long similar projects have taken in the past, without considering any of the special properties of this project. Better yet, ask an experienced outsider how long similar projects have taken.

You'll get back an answer that sounds hideously long, and clearly reflects no understanding of the special reasons why this particular task will take less time. This answer is true. Deal with it.

Critical Chain 6

The folks of the Theory of Constraints Center have a little project game to demonstrate how task and resource dependencies combine with a bit of unpredictability to create a cascade effect.

Imagine you have a simple project with five tasks, each of which is expected to take seven days. Since Tasks A and B can be done in parallel, and Tasks C and D can be done in parallel, we should expect the whole project to be done in 21 days.



But those five tasks don't take exactly seven days each — they take roughly seven days each — and for our little game we roll a pair of dice for each task to represent that uncertainty.

Let's say our random task durations come out as follows:

Task A — 5 days
Task B — 9
Task C — 3
Task D — 8
Task E — 6

Then our whole project is done in 23 days, not 21.




Hey, that's not so bad, right? You roll high sometimes; you roll low sometimes. We expected 21, but it came out 23.

But let's take another look. Our average roll was just 6.2 — less than 7. We rolled better than average, yet our total was worse than average. In fact, if we look at each color — I'm assuming each color represents a different resource dependency — then each color scores better than average too.

Delays accumulate, while advances do not.

Critical Chain 5

It has been a while since I last discussed Eli Goldratt's Critical Chain and project management, but there is one more element to Critical Chain Project Management that I haven't touched on.

Critical-path analysis assumes that a task is either dependent on another, or it's not.



But what if two tasks require the same limited resource? What if they require the same expert's time, or the same expensive piece of machinery? The two tasks aren't dependent on one another, but they can't be performed in parallel.



Suddenly our wonderful critical-path analysis goes out the window, and we have to tinker with the schedule until our resource isn't in two places at once.



With a toy problem, this is easy enough to do by inspection. With a larger program, let a computer do the work.

Of course, if you don't have this all plotted out ahead of time, you find out the hard way that Task B is wildly behind schedule, and that your critical path has shifted from Tasks C and F to Tasks B and E.

It's no wonder why project leaders build a lot of safety into their schedules...

Critical Chain 4

I've been discussing Eli Goldratt's third business novel, Critical Chain, which explores project management.

Goldratt's primary point is that padding individual task estimates with safety just means that a lot of time gets wasted. All that safety should get pooled into a few strategically placed buffers.

But Goldratt makes a secondary point about multi-tasking — namely that it does terrible things to lead times.

Imagine that you have three tasks to get done — X, Y, and Z — and each takes 10 days to finish. Your lead time should be 10 days for each task.



If, on the other hand, you start each task, get it half done, then flit to another of the tasks, get it half done, then work on the remaining untouched task, and get it half done, before returning to the first and finishing it, then your lead time will double to 20 days for each task.

Now, Goldratt only hints at this in Critical Chain, but how bad is extra lead time? Does it matter? Well, yes and no. For any task not on the critical path, no, it shouldn't matter, not as long as there's enough slack. For any task on the critical path, yes, of course, it matters a great deal.

To play devil's advocate for a moment though, when would it make sense to switch away from Task X to Task Y? Goldratt asserts that workers multi-task simply to keep busy — and I'm sure that's often the case — but what happens when you can work on Task X, but Task Y is critical? You work on Task X until Task Y is ready for you, then you switch to Task Y, leaving Task X half done. What happens when Task Z, which is even more critical, is ready for you? You switch to it.

The problem comes when you switch back to Task X without finishing Z, then Y, because those were the more critical tasks; otherwise you never would have — or never should have — switched to them in the first place.



In such a case, starting a low-priority task early, to keep busy, might inflate lead time numbers, but it doesn't hurt the project's progress at all.

The key is always knowing which tasks are critical or threatening to become critical — to have buffer-driven task priorities. By looking at each path's relative buffer burn rate — the percentage of the buffer penetrated versus the percentage of work completed on that path — we can immediately see which paths, and thus which tasks, deserve priority.

Critical Chain 3

I've been discussing Eli Goldratt's third business novel, Critical Chain, and established project management techniques, like PERT.

One subtle issue with charting the critical path of a project is that the individual task estimates, which start out as distributions — defined by optimistic, most likely, and pessimistic estimates — get boiled down to one-dimensional expected numbers.



This lets us define a critical path, but — for simplicity and clarity's sake — it ignores the potential for other paths to become critical.

Let's say we add up all the variances along our critical path — Tasks A, C, and F, in our example — and they're fairly small, so that our critical path has a duration of 7 ± 1 days. From that me might assume that our project has a 98-percent chance of finishing in 9 days — but what we've calculated is the chance that the original critical path will finish in 9 days.

What if the non-critical path along Tasks B and E takes 6 ± 2 days? We only have a 93-percent chance of finishing that path in 9 days.

Perhaps that seems academic in our toy problem, but real projects with many dependencies can demonstrate an alarming cascade effect, where every task seems to be waiting for something else to get done.

Returning to our toy problem, what happens if we replace Task A with three identical tasks, Tasks A1, A2, and A3? Our PERT analysis does not change at all, but clearly the fact that they average three days each does not mean that the dependent Task C gets to start after three days. It has to wait for the slow-poke.



Another academic complaint about PERT analysis is that it uses beta distributions, which may or may not reflect the actual distributions, and that it assumes that those beta distributions are numerous enough to sum to a fairly normal distribution, via the central limit theorem.

Less academic is the concern that the task durations are not independent. If it takes longer than planned to design a component, that might very well imply that it will take longer to develop a prototype, to produce it, to test it, etc. If that's the case, then pooling all the safeties into one buffer at the end won't reduce the total safety needed — but it should still reduce the threats from Student syndrome and Parkinson's Law.

A bigger issue still is that people are notoriously bad at estimating task durations, and they are notoriously overconfident in their ability to estimate. The optimistic and pessimistic estimates are supposed to book-end a range that covers almost all possibilities — 99 percent — but far more than one percent of tasks fall outside those estimated ranges.

Critical Chain 2

As I mentioned earlier, Eli Goldratt's third business novel, Critical Chain, deals with project management, which has existed in its modern form since the 1950s.



One obvious issue with charting the critical path of a project is estimating all the task durations. Sure, for some projects all the tasks are well understood, but for many the tasks are new and untried.

In fact, complex design work that "should" take one month might take two, or three, or four months. Less likely, it might resemble an old, already-solved problem, and it might only take two or three weeks to finish.

So when the project manager asks a team member how long a task will take, what should the worker say? A young hotshot might give the mode of the distribution — "Yeah, I should be able to get it done in a month." After a project or two, our chastened young worker starts giving numbers closer to the median of the distribution — estimates with a 50-50 chance of being long enough.

What the project manager probably wants is something closer to the mean of the distribution, or the expected duration of the task, which is greater than either the mode or the median in our skewed distribution.

On the other hand, the grizzled worker probably gives an estimate with plenty of safety — anyone who has missed a deadline knows it's better to under-promise and over-deliver.

In fact — turning toward Critical Chain — that is one of Goldratt's key points: each individual task estimate has plenty of safety built in. In fact, each layer of management adds its own safety, too — no boss wants his team to come in late. Then upper-level management doesn't like the cumulative estimate, so it has all the task estimates cut — but the workers know to boost their own task estimates even more to account for that.

So why doesn't the project come in on time? Because no one finishes early. Either they procrastinate, because they have "more than enough time" to finish the task — Student syndrome — or they use the extra time to add bells and whistles — Parkinson's Law.

Delays accumulate, while advances do not.

So what does Goldratt recommend? He recommends cutting out most of the safety from individual tasks, then pooling the collected safety into a project buffer — which does not need to be as big as the collected safeties, because delays and advances will cancel out.

Goldratt also recommends a feeding buffer anywhere a path merges with the critical path — but our sample project is a bit of a degenerate case, with no paths merging into the critical path until the finish pseudo-task.



I don't know if Goldratt thought that this notion of using accurate estimates and pooling safety buffers was a new idea, but it's found in old-school PERT — the real version, if not the version most people use — where each task is assigned not an estimate but three estimates: optimistic (or best case), most likely, and pessimistic (or worst case).

These estimates are then fed into formulas based on the beta distribution, which, with the right parameters, looks an awful lot like the log-normal distribution pictured above, but with the appealing attribute that it has a well-defined minimum and maximum.

The formulas assume six standard deviations between optimistic and pessimistic:

Expected = (Optimistic + 4 x Most likely + Pessimistic) / 6
Variance = [(Pessimistic - Optimistic) / 6]²

It's the expected times that determine the critical path and the cumulative variance — or the square root of the cumulative variance — that determines the project buffer. (PERT assumes that there are enough tasks in the critical path that the many beta distributions sum to a fairly normal distribution.)

Whether it's new or not, the takeaway message is this: Don't ask for a single-number estimate but for a distribution, and don't pad each estimate, but pool the safety buffers into larger feeder buffers and project buffers, so that advances can cancel out delays.

Critical Chain

As I mentioned earlier, when I read Kevin Fox's Blue Light anecdote, it spurred me to go back and read some old Goldratt books I hadn't read yet, including his third business novel, Critical Chain.

Critical Chain doesn't look at production or logistics but at project management.

Modern project management goes back to the 1950s, when Booz-Allen & Hamilton developed the Program Evaluation and Review Technique, or PERT, with Lockheed for the Polaris missile submarine program, and DuPont developed the Critical Path Method, or CPM, with Remington Rand for plant maintenance projects.

The basic idea behind these methods is to diagram out the various tasks within the larger project, along with their interdependencies and durations.

Two pseudo-tasks, start and finish, make the analysis clearer but don't represent real work.



The first step in the formal analysis is to compute the early start and early finish dates for each task — the earliest it could start, given all its dependencies, and the earliest it could then end, given its duration — starting with the start pseudo-task and working to the right.



The second step in the formal analysis is to compute the late start and late finish dates for each task — the latest it could finish, without delaying the larger project, and the latest is could then start, given its duration — starting from the finish pseudo-task and working backward to the left.



Once you've done all that — or have made a computer do all that — you can see which tasks are on the critical path, with no slack. Any delays to any task on the critical path will delay the larger project. Any delays to any task not on the critical path will not delay the larger project — until all the slack for that task gets used up.

Haystack Syndrome 4

In The Haystack Syndrome, which I thought I was done discussing, Goldratt presents a production and marketing problem with a less-than-intuitive solution:



If you read much Goldratt, you know he's always talking about constraints, which is a clue to how to solve the problem — it's a thinly disguised linear programming problem.

In this day and age, solving linear programming problems is remarkably easy — if you know how to formulate the problem for Excel's Solver add-in. This Google spreadsheet lays out the basic problem, but Google hasn't built a Solver analog into it's spreadsheet tool just yet.

It's Not Luck 3

So, I've been discussing Eli Goldratt's It's Not Luck, in which our hero desperately seeks out-of-the-box ways for his three companies to dramatically improve their profits. What do the three companies do?

When last we looked, Pete was lamenting the fact that his printing company did not have the bigger, better, faster machines of his competitors. The obvious solution to his problem: focus on small jobs. The bigger, faster machines are only better for big jobs; they have a longer setup cost.

The not-so-obvious solution goes further. It involves recognizing that customers don't actually want to order candy wrappers in huge quantities; they just want the low prices that come with ordering in huge quantities. In fact, Pete digs up some statistics from an industry journal showing that customers who order a six-month supply of wrappers only use the whole six months' worth about 30 percent of the time. Most of the time, something changes — an ingredient, a promotion, a legal labeling requirement — before they've used up their whole stock.

So Pete's company can offer its customers a two-month supply of wrappers, which gets completely used 90 percent of the time, for less per usable unit than the big printers can provide a six-month supply, once obsolescence gets factored it.

And that's the deal that saves the company.

Bob's cosmetics company, meanwhile, comes up with a solution based on the fact that its customers, the stores, have to discount obsolete products, are often out of the products that consumers want, and have difficulty making payments to their suppliers — companies like Bob's.

Since these stores are given discounts for ordering in bulk, they tend to order in bulk — which explains why they didn't take advantage of the new distribution system. So Bob shifts the discount policy to work off of the dollar amount the store orders per year, not per order. Further, Bob shifts to daily replenishment. The stores were ordering two to six months' stock.

But that's just the beginning. The big change is giving the merchandise to the stores on consignment — no obligation when it ships, just when it sells. The stores, which are perpetually short on cash, are delighted, but they actually end up paying sooner, because they have to pay to get their stock replenished.

Stacey's pressure-steam company comes up with its own solution: selling pressure-steam as a service, for a monthly and per-unit-of-steam fee, not as a machine with high-margin spare parts. This means that they bring all spare parts in-house, rather than asking clients to pay huge mark-ups on a lot of safety stock. After all, it costs the pressure-steam company much, much less to maintain aggregated safety stock for all of its clients.

Ah, another win-win deal.

It's Not Luck 2

As I mentioned earlier, I just read Eli Goldratt's It's Not Luck, and I found the concrete business solutions more intriguing than Jonah's abstract and jargon-laden Thinking Processes.

As our story opens, Alex Rogo, our hero, has just turned around three companies — divisions within a larger conglomerate, really — and he has to take them from barely profitable to very profitable. They are a printing company, headed by Pete, a cosmetics company, headed by Bob, and a pressure-steam company, headed by Stacey.

The printing company prints cereal boxes and candy wrappers, and Pete has just turned it around by implementing the changes Alex learned about in The Goal — letting non-constraint resources go idle, reducing work-in-process inventory, elevating constraints, etc. At this point Pete is lamenting that his competitors have bigger, better, newer machines that have much greater economies of scale. (Hmm...)

At the cosmetics company, Bob has just turned things around by rationalizing his distribution system — just in time too, because the cosmetics industry is changing, and they're expecting to introduce a new product line every year, which would be a disaster with three months' obsolete product in the distribution pipeline.

Under the old system, even with three months' inventory, with over 600 products, they were always missing something from a customer order, to the point that they were only able to deliver complete orders 30 percent of the time, and they'd have to ship missing items later.

Under the new system, they can respond to customers in one day, and they are able to deliver complete orders 90 percent of the time — all while holding just six weeks' inventory in the system, half as much as before.

Under the old system, plants were treated as profit centers, and they recorded any production as a sale as soon as it was shipped to the regional warehouses, where it became somebody else's responsibility.

Under the new system, stock stays at the plant, which acts as a central warehouse, with just 20 days' stock at the regional warehouses, replenished every three days. This allows the plant to aggregate the forecast demand across all 25 regions — and when you aggregate demand across 25 regions, you do not get 25 times as much volatility (standard deviation); you get five times as much volatility. (Five is the square root of 25.) When demand is higher than expected in one region and lower in another, those errors cancel out — but only when aggregated.

Reducing inventory in the distribution pipeline doesn't just reduce your carrying costs and obsolescence costs. When you have three months' inventory in the distribution pipeline, that means you're producing based on three-month-old forecasts.

Anyway, although the company has moved to its new distribution system, its customers, the shops, are still ordering in bulk, which puts a bigger strain on the system than if they ordered in smaller, more frequent batches.

Bob notes that they choose their inventory buffer size in the same way they'd set a buffer in front of a bottleneck in a manufacturing plant, based on expected consumption and expected replenishment time. What he does not mention is that real-life goods often have very different demand volatilities — or, more specifically, very different coefficients of variation of demand — so that 20 days' average demand in one good may offer more than enough protection or far too little. Also, different goods present very different ratios of costs of overage (from holding too much inventory) to costs of underage (from holding too little inventory), especially when you realize that you're not supplying independent goods but whole orders. You might want 99.9-percent safety on cheap parts that might hold up larger orders.

Which brings us to Stacey's pressure-steam company. The pressure-steam company, like others in its industry, sells its pressure-steam equipment to manufacturing plants at cost, or thereabouts, and makes its money buy selling spare parts at high margins later — because the customers are locked in then. The pressure-steam company keeps the necessary spare parts at the client site, and it requires over 95-percent safety on those parts, because, when it needs a part, that means the client's whole plant is down until the fix gets made. (Hmm...)

I wonder what the three companies will do...

It's Not Luck

As I mentioned earlier, when I read Kevin Fox's Blue Light anecdote, it spurred me to go back and read some old Goldratt books I hadn't read yet.

When I got to It's Not Luck, his second novel, it reminded me why I liked The Goal so much: a narrative is a surprisingly good way to explore ideas and convey technical information. Science fiction authors have known this for years, but it also works for more down-to-earth ideas.

In The Goal, our hero desperately tries to save his factory by following the cryptic advice of his Yodo-like mentor, Jonah — who bears a striking resemblance to the author, Eli Goldratt.

In It's Not Luck, our hero has moved up in the organization — after saving the plant, of course — and he now struggles to internalize the greater lessons of his mentor and to use his methodologies to solve problems in logistics, marketing, and strategy, not just production. In fact, he has to come up with miracles to save three different divisions in the conglomerate before they're sold off to Wall Street sharks.

It's Not Luck is not great literature, but it has its strengths. First, the solutions our hero and his team come up with are solid, interesting solutions, and reading about them might inspire a manager to come up with similar ideas closer to home.

Second, Goldratt has worked as a consultant long enough to write convincingly about resistance and apathy from within an organization — like Scott Adams (Dilbert), but not funny. His character don't ring particularly true in other ways — they are quite wooden — but the "change management" portions of the story feel grounded in reality.

What does not work is the constant advertising for Goldratt's jargon-laden Thinking Processes. Our hero routinely explains the great importance of drawing a Cloud, or spelling out a Current Reality Tree, when it's not at all clear that these formal tools are what allowed someone to come up with the intriguing business solutions Goldratt put in the book.

One last point: Perhaps I've spent too much time thinking like a Finance Guy, but when our hero and his colleagues realize that they can save their companies by making them vastly more profitable, but accepted accounting practices will make them look less profitable in the short term, I couldn't help but think, Why aren't they arranging a management buyout? The real reason: Goldratt isn't a finance guy.

Haystack Syndrome 3

In The Haystack Syndrome, which I was just discussing, Goldratt expands his original example by supposing that the marketing director visits Japan — the book was published in 1990, remember — where demand for Products P and Q is almost the same as in the states — but at a price 20 percent lower.

We previously calculated that each P sold was worth $3 per minute on Resource B, the bottleneck, and each Q was worth $2. Now, each P sold to Japan is worth less than $3 per minute. In fact, each P sold to Japan is worth just $27 — costs didn't decrease by 20 percent, just the selling price — which is less than $2 per minute. So we don't want to sell any product to Japan.

What happens if we increase our capacity? Let's assume that we can buy another B machine for $100,000, and we can pay another B worker for $400 per week. (These numbers obviously aren't real, even for 1990.)



Now we can sell 100 of Product P and 50 of Product Q in the states for a total contribution (or throughput) of $7,500. Even after we subtract out our now-higher fixed costs of $6,400, our net profit is $1,100, or $800 higher than the $300 we were making before. That machine will pay for itself in 125 weeks.

Right?

Oh, wait, maybe we can sell to Japan now. We've lifted the constraint on Resource B, but now Resource A has become the bottleneck. By selling 100 of Product P, we're using 1,500 minutes of Resource A. By selling 50 of Product Q, we're using 500 more minutes of Resource A. We only have 400 minutes left to throw at Japan. With 400 minutes at Resource A, we can produce about 26 more units of Product P, for another $700 in contribution (or throughput). That almost doubles our previous improvement.

It's a good thing we didn't stop our analysis too soon; it almost cost us a lot of money.

Wait a minute, our constraint shifted from Resource B to Resource A, and we didn't recalculate everything, even though changing our constraint changes everything. If Resource A is our constraint, then Product P has a throughput of $3/minute, and Product Q has a throughput of $6/minute! Product P sold to Japan now has a throughput of less than $2/minute, and Product Q sold to Japan now has a throughput of $4/minute.

With our 2,400 minutes of Resource A, we should be making Product Q for the states (500 minutes), then Product Q for Japan (500 minutes), then Product P for the states (1,400 minutes). We should produce no Product P for Japan. Then we can bring in $3,000 + $2,000 + $4,200 = $9,200 in contribution (throughput), for a net profit of $2,800, which dramatically improves our profit again!

Inertia can cost you a lot of money.

Haystack Syndrome 2

In The Haystack Syndrome, which I was just discussing, Goldratt jokes about an enthusiastic process engineer who races to his boss to explain that he has a new way — for just a few thousand dollars — to produce a part not in 20 minutes, but in 21.

This "disprovement" certainly won't earn him accolades; by the measurements used at the plant, he has reduced efficiency by five percent.

But what he has really done is "elevate the constraint" on the system. He has found a way to offload some of the work on the bottleneck, Resource B, to the "less efficient" Resource C, which has excess capacity, because it's not the bottleneck:



Under the new system, a part that used to take 15 minutes at Resource B and 5 minutes at Resource C now takes 14 minutes at Resource B and 7 minutes at Resource C — one more minute, but one less minute where it counts.

A plant that has been producing 100 of Product P and 30 of Product Q can now produce the same 100 of Product P — that's all the market demands — and 55 of Product Q.

Not bad for reducing effiency.

Haystack Syndrome

When I recently read Kevin Fox's Blue Light anecdote, it spurred me to go back and read the stack of old Goldratt books I'd inherited. I loved The Goal, but, frankly, I wasn't impressed with his Theory of Constraints (the book, not the idea), or The Race (which is little more than a proto-PowerPoint), or The Haystack Syndrome.

On the other hand, The Haystack Syndrome does have one good demonstration of Goldratt's key point. Suppose we have a company that produces two products, P and Q, from three different raw materials and one purchased part:



How much money can our hypothetical company make in a week? Eyeballing the numbers, we see that it can sell 100 of Product P and 50 of Product Q.

Each P brings in $90 but costs $45 in materials, so it contributes $45 to covering overhead. Each Q contributes $60.

If we sell 100 of P, that's $4,500. If we sell 50 of Q, that's $3,000. If we then subtract out our $6,000 in overhead from salaries and the like, that leaves us $1,500 in profit.

Simple, but wrong — because we've ignored all our internal constraints. We can't actually produce 100 of P and 50 of Q per week.

OK, so we produce some fraction of that. Naturally, we want to maximize the number of Product Q we produce; those are more profitable — $60 versus $45, 60-percent margins versus 50-percent margins.

Simple, but wrong again — because we're still ignoring our constraints.

Well, how expensive are P and Q in terms of resources used? If we add it all up, each P requires 60 minutes of effort from various resources. Each Q requires just 50 minutes.

So Q requires less labor and less allocated overhead, too?

Sure, but none of that matters.

Our bottleneck is at Resource B. If we produce 100 of P, that uses 1,500 minutes of B's time. If we produce 50 of Q, that uses another 1,500 minutes of B's time. That adds up to 3,000 minutes per week, but we only have 2,400 minutes.

Our goal is to maximize the dollar throughput of our system, which means we need to maximize the dollar throughput of our bottleneck. In this case, our bottleneck is Resource B, so we need to look at the dollar throughput of producing Product P versus Product Q at that bottleneck.

Product P contributes $45 for 15 minutes at Resource B. Product Q contributes $60 for 30 minutes at Resource B. That's $3/minute versus $2/minute.

There's no comparison. Produce as much Product P as you can!

This may all be clear when you walk through a nice diagram, but imagine how a large organization tackles a problem like this. How is the sales team rewarded? Based on sales (revenue) over some threshold? Or revenue minus product cost (which includes labor and allocated overhead)? Or contribution margins?

Blue Light

Kevin Fox is a disciple of Eli Goldratt (The Goal) and an expert on his theory of constraints. As a young consultant he devised his Blue Light heuristic as a way to spot opportunities to create extra capacity on the plant floor:

The plant produces heavy metal bumpers for semi-trucks, and they had a major bottleneck in their welding department. Orders were backed up, and they were running at capacity around the clock seven days a week. The space in the plant was already tight, and they had plans to expand the building to add room for 3 more welding bays, doubling the current capacity.

The plant manager informed me early on that they were running at 93% efficiency in the department, basically telling me there was no room for me to help them improve. It was my experience that there was always at least 25% more capacity that could be exposed in any plant. Moreover, I was young and brash enough to tell this 30-year manufacturing veteran this and that sight unseen it was true in his operation too. He must have thought my math skills were pretty bad because he reiterated that they were already at 93% efficiency, so this wasn't possible.

I wasn't fazed and finally convinced him to take me out to at least look at the welding operation, since I had driven out to see them. Whenever I go out to look at an operation I had made the habit of formulating in my mind a simple picture or image of "what good looks like." In other words, what you would expect to see if an operation really was working to its maximum performance capability. As I am a completely non-technical person the image I put in my head as we walked onto the shop-floor was "blue light".

I was pretty sure that if the welding torch wasn't turned on, emitting its funky blue light, that the welders couldn't be welding anything. So I decided to look first for how much of the time there was blue light coming from each of the three welding stations. (Yes I know that even this is not yet the indicator of optimal performance, but as you will see, it was way more than good enough in this case.)

When we got to the welding area we watched for a few minutes quietly. The first thing I saw was one welder turning off his torch, taking off his protective gear and walking over to his buddy in the next booth. He waited until he got his attention and then he too stopped and took off his gear. Together they went back to the first guy's booth and lifted the heavy finished bumper off the welding table and onto a pallet, and then put a new un-welded one from the queue onto the welding table. The other welder went back to his booth.

I then watched the first welder begin to peel the protective plastic coating off the bumper in the places he had to weld. It took a good bit of time picking with his fingernails to get it done. Then he grabbed the parts and clamped the onto the bumper, put on his gear and welder for no more than 30 seconds. before he was done. I looked at my watch, we had been there almost 5 minutes and he had welded for 30 seconds of it.

Meanwhile another welder had just returned to his empty booth pushing a trolley, which he used to jack up and move his finished pallet to the next operation. He returned after several more minutes and consulted his schedule to see what job was next for him to do. Of course it turned out to be the skid of bumpers located against the wall blocked in by two other skids he had to move. After finding the right skid he moved the two other pallets out, got his to his booth and then moved the other two back out of the aisle. All this time zero blue light.

He disappeared again with the trolley to go and get the parts he had to weld onto the bumpers from the store room, returning only several minutes later with them. Meanwhile the other two welders had repeated several times over the two-man bumper lifting dance described above. Just from this casual observation I estimated that the "blue light time" couldn't have been more than 10% and was probably far lower.

As I watched all I could think about was "wow, did I sand bag this guy" (meaning the plant manager), I told him 25% more capacity. I missed it by one or two ZEROES! Just about then the plant manager turned to me and said something I have never forgotten. He said, "you see, they're busy all of the time!" And he was right, the guys were working all of the time and working steadily and hard at that.

What amazed me is how the two of us could be looking at exactly the same things and see it entirely different. He had in his head an assumption of what good looked like that was based on the people being busy, whereas I looked at it from the perspective of the operation and the work it did, the blue light. His perspective totally blocked him from seeing any solution other than adding people, which was going to require him to invest in expanding the plant and worse still take months to implement during which they would anger more customers and lose hunderds of thousands in potential profits.

To make an already long story a little shorter, we ultimately brought them to implement a very simple solution. They had a summer worker in another department (a non-constraint area of course) who knewnothing about welding, that they moved into the department to be the "helper" for the welders. We gave him a simple image to know if he was doing a good job. We told him we wanted to see more and more blue light from the welders' torches. His job was to lift bumpers with the welder, move pallets of bumpers around, stage the next jobs for each welder, and get all of the parts they needed ready for them. If he had extra time after this (which it turned out he did) he was to peel the plastic for the welder, and do anything else that would generate more blue light time.

In less than three weeks they had totally cleared the area of work-in-process. This big backlog shipped out along with the on-going flow that was coming to welding, producing a record shipping month. I don't know how much capacity was actually created but it was more than enough to break the bottleneck, and if more had been needed it could have been generated just as easily.

What limits us as individuals and as organizations are the assumptions we hold, and are failure to recognize them as just that "assumptions" and not facts.

The Personal MBA 40

Josh Kaufman has finalized The Personal MBA 40, the 40 books he thinks you should read to learn what you'd learn in business school (instead of wasting all that time and money):

1. Mastery by George Leonard
2. Now, Discover Your Strengths by Marcus Buckingham & Donald O. Clifton
3. Getting Things Done by David Allen
4. The 7 Habits of Highly Effective People by Stephen Covey
5. What the CEO Wants You to Know by Ram Charan
6. Profitable Growth Is Everyone's Business by Ram Charan
7. On Competition by Michael Porter
8. Blue Ocean Strategy by W. Chan Kim, Renee Mauborgne
9. Seeing What's Next by Clayton M. Christensen, Erik A. Roth, Scott D. Anthony
10. The Essential Drucker by Peter Drucker
11. First, Break All the Rules by Marcus Buckingham & Curt Coffman
12. The One Thing You Need to Know by Marcus Buckingham
13. The Essays of Warren Buffett by Warren Buffett & Lawrence Cunningham
14. Poor Charlie's Almanack by Charlie Munger
15. The McGraw-Hill 36-Hour Course in Finance for Nonfinancial Managers by Robert A. Cooke
16. Essentials of Accounting by Robert Newton Anthony and Leslie K. Pearlman
17. The Goal: A Process of Ongoing Improvement by Eliyahu Goldratt & Jeff Cox
18. Lean Thinking by James Womack & Daniel Jones
19. The Substance of Style by Virginia Postrel
20. The Design of Everyday Things by Donald A. Norman
21. Economics in One Lesson by Harry Hazlitt
22. The Marketing Playbook by John Zagula & Richard Tong
23. Purple Cow by Seth Godin
24. Free Prize Inside by Seth Godin
25. The Art of the Start by Guy Kawasaki
26. The Bootstrapper's Bible by Seth Godin
27. Crucial Conversations by Kerry Patterson, Joseph Grenny, Ron McMillan, and Al Switzler
28. On Writing Well by William Zinsser
29. How To Win Friends and Influence People by Dale Carnegie
30. Influence by Robert B. Cialdini
31. The Little Red Book of Selling by Jeffrey Gitomer
32. Flawless Consulting by Peter Block
33. Real Estate Principles for the New Economy by Norman Miller & David Geltner
34. Getting To Yes by Fisher, Ury, and Patton
35. Principles of Statistics by M.G. Bulmer
36. A Primer on Business Ethics by Tibor Machan & James Chesher
37. Brand New by Nancy F. Koehn
38. American Business, 1920-2000 by Thomas K. McCraw, John H. Franklin, and A. S. Eisenstadt
39. The Little Book of Business Wisdom by Peter Krass (Editor)
40. Re-imagine by Tom Peters