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.