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.

How iPods in cars is like process improvement

I have a 15-year-old son who is also a talented musician. Whenever he's in the minivan he assumes he's in charge of the sound system and grabs the long cord we have plugged into our auxiliary port, plugs it into his ever-present iPod, and begins blaring Led Zeppelin or Pink Floyd (fortunately he has good taste!). Now I like loud music from time-to-time, but not ALL the time like he does. So we play this little game where he slowly cranks up the volume on his iPod and I slowly notch it down via the volume controls on the steering wheel.

Process improvement is a lot like that.

It used to puzzle me to no end how I could go into a given functional area, reduce the required man-hours to process a given widget from dozens or hundreds down to a handful, and then watch as no discernable impacts made it to the bottom line--or even downstream! Then I discovered the Theory of Constraints (TOC). Now I know it's all about the iPod example.

TOC teaches us to think systemically and see the organization as a whole. It then gives you the lens to see that the parts that make up the whole come in two flavors: those that have a capacity equal to or greater than the demands placed upon them, and those with a capacity less than their respective demands. Then, you're able to look at the latter group and find the bottleneck, the constraint.

If you improve the throughput of a resource upstream or downstream of a bottleneck it's like you've just turned the volume up on the iPod but then the bottleneck turns it back down on the radio dial; it cancels out the benefit. In fact, improving the throughput upstream could actually be making things worse--you're just building the pile of work in front of the constraint higher faster.

The Integrated TOC/Lean/Six Sigma (iTLS) approach most notably outlined by Robert Fox in his new book (as well as by others such as the book Velocity) uses TOC as a focusing mechanism to first see where should we focus our improvement efforts. Then we can bring in Lean to reduce waste, Six Sigma to reduce variability, and technology to automate and streamline (maybe that should be changed to iPIT for Integrated Process Improvements and Technology? Or maybe TiP for Technology integrated with Processes?) . Taking this approach gives you the comfort of knowing anything you do will have an immediate systemic effect and that someone else doesn't have their hand on the volume control downstream.

4 Questions to ask for any technology implementation

Taken directly from speech by the founder of the Theory of Constraints (ToC) Dr. Eliyahu Goldratt:

Dr. Goldratt based his entire speech on the premise that technology is only valuable to the extent that it eliminates or diminishes a limitation. He argued that the following four questions should be explored before any technology implementation:

1. What is the power of the technology?
2. What limitation will the technology diminish?
3. What rules, business processes, procedures, etc. have we put in place in order to accommodate the limitation?
4. What should the new rules, business processes, procedures be after the technology is in place.?

He also argued most software vendors, business sponsors, and members of the IT implementation team stop at question two.