Another business lesson from the kitchen: the order matters

I mentioned in a previous post how I love to cook and often have a cooking show on while I'm preparing dinner at night. I was watching Emeril as he made a bolognese sauce (which I tried along with him and it turned out fantastic!) and he commented that when you start by putting the olive oil and bacon into the pot you need to wait to add the onions and garlic and other ingredients. If you add everything all at once the moisture from the vegetables will prevent the bacon from crisping which needs to happen in order to get the full desired flavor.

In other words, using the proper order matters just as much as using the right ingredients.

Let's switch gears. Business. You're trying to make something work better, cheaper, faster. You've got a gal that's a black belt in Six Sigma. You have a guy who did a stint at Toyota and loves Lean. And you've got another gal who loves the Theory of Constraints or TOC. Do you throw them all at the problem all at once and say, "have at it"? You can, but I wouldn't.

If you have those three skill sets in-house you're fortunate. You have the ingredients you need. But the order in which you deploy these resources matters just as much in business as it does in cooking. The research that's coming out in the continuous process improvement literature strongly suggests using TOC as a focusing mechanism to determine the optimal place to start. You can't work on everything all at once and you need to know where to focus first. Bring in your TOC expert. Then bring in your Lean SME to reduce waste, then your Six Sigma person. These results will typically yield far better results than trying to "cook" the approaches all at once.

What works even better is to have a person, a firm, a team that not only knows each discipline well but also how they work together--the Integrated TOC/Lean/Six Sigma (iTLS) approach pioneered by Bob Fox and others. Instead of having one person cook the pasta, someone else come in to make the sauce, a third to make a salad, and someone else to plate it, you just bring in a chef who can do it all. Ideally, bring in a chef that can teach you how to make the dish yourself the next time.

Which Projects Should We Work On?

So you've adopted some form of the three column planning model and you have a pool of proposed projects you could work on at some point, a select project or two you're actively working on (your work in process or "WIP"), and now a regularly-growing list of completed projects. You're about to wrap up the main project in your WIP and need to move something from the pool over to the active column. How do you know what to move over? What criteria do you use?

Traditional wisdom says to pull out the trusty HP calculator and start doing some NPV/IRR calculations to see which project is likely to give you the best ROI. I agree you should have the HP handy, but these numbers and estimates (educated guesses in many cases...come on, be honest) should be put into context.

Suppose you have five possible projects you could work on from four divisions. (I know, wouldn't that be nice if it were really that simple?) Let's call them A, B, C, D, and E. And let's further suppose you bring in your 27-year-old newly-minted MBA who just started in Finance to run all the calculations on each. The numbers are solid (or as solid as estimates can be) and let's say B comes out on top. What else is there to consider? You pick the one with the highest return right?

Hold your horses. We need to consider context and constraints. Systemically.

Now the book Let's Get Real or Let's Not Play: Transforming the Buyer/Seller Relationship does a decent job overviewing these two concepts from the sales angle. Goldratt and in particular Bob Fox deal with this directly better than anyone out there. But here's the gist for my already overly-nice-and-tidy example: suppose you map out what Bob and Kevin Fox call your organization's Throughput Operating System or TOS so you know what type of flow you have (they come in four basic flavors). And you also know where your constraints are. (There's about 20 blog posts or more of material in those last two sentences.) Now lay your proposed projects out on the TOS. Suppose proposed projects A and B are upstream of your main constraint. Proposed project C would work directly on your constraint. And proposed projects D and E would be downstream of the constraint/bottleneck.

This changes things. We learn from constraints management that if we increase capacity upstream of a bottleneck we're probably going to make the overall system worse and whatever improvements we gain locally will be cancelled out (see my post on how process improvements are like iPods in cars). Improve a downstream process and there may be no systemic impact at all. Improve the constraint and the whole system is better off.

In the real world this is awfully messy and complicated. But this notion of thinking systemically and including lessons from constraints management along with your trusted calculations when you try to determine what to work on next is super important.