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.

Agile and Critical Chain Similarities

In my previous post I shared slides from my recent remarks at the Utah Technology Council CTO P2P Forum. I used a three column planning model with "Backlog" on the left, "Work in Process" or "WIP" in the center, and "Done" on the right.

One of the principles I outlined was to keep the WIP column "clean" so when project work comes in, all (or at least sufficient) resources are deployed to get it completed ASAP. I mentioned that too often we load up the WIP column with as many projects as humanly possible thinking that's a virtue. Author, speaker, and consultant Alistair Cockburn who taught me this model believed (as do I) that getting things to the "Done" column is what really matters--not how many plates we can keep spinning. How many staff meetings have you sat through where the PM essentially itemized the baby steps he's taken with all 23 projects he's juggling but he has nothing to demo, nothing Done!

I was watching a video, recently, of a speech author, speaker and consultant Lawrence Leach gave at the 2009 Continuous Process Improvement Conference. He pointed out how counterintuitive two tenants of Critical Chain Project Management are:

1. Waiting to start some projects actually helps them get done faster; and
2. Reducing the WIP increases overall project throughput

Obviously, Agile and TOC have some very similar philosophical roots. One of the first principles of Lean Project Mgt (LPM) and even Covey's Four Disciplines of Execution is to provide those you manage with the luxury of clear focus. Tell them that for a given period of time they can just put their attention on this module, this problem, this functionality and at the end of that period of time we'll be demonstrating it live in production to a client.

This principle works for a number of reasons which I might attempt to enumerate in a future blog post, but suffice it to say, when you provide clear focus on who needs to get what done by when, and you give your folks a transparent scoreboard where everyone can see how everyone is doing, things get done. When you tell your team to work on these 12 "priorities" all at once, you paralyze them and create what David Allen calls a rapid refocusing nightmare for them.

I'd like to clarify (as they do in the Four Disciplines seminar) that this principle applies to each team or resource in an organization. If an enterprise has a dozen teams, it will have a dozen or more projects in its collective WIP. But if you were to ask a given team what they are working on, their three columns are very clear--with only one or two items in WIP.

I'll post another time about what happens when an organization tries to matrix individuals to multiple teams and implement this model (hint: not pretty). I'll also post in the future about how giving each team a secondary item and sometimes even a third relates to the "buffer" concept in TOC production theory.

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.

Six Sigma Net Promoter Metric and Tom Peters TGR/TGW

I was listening to episode six of the Six Sigma Pointers podcast by Thomas Pyzdek, this morning, (which I highly recommend, btw) and he was talking about the Net Promoter metric. Essentially, you ask a customer if they would recommend your product or service to a friend or colleague--asking them to respond on a scale from zero to 10. If the customer marks a nine or 10 they are considered "promoters." If they mark a seven or eight they are considered neutral. And if they mark a six or less they are considered "detractors." The metric is derived by subtracting the detractors from the promoters.

The podcast elaborates on how closely this metric correlates with business performance and on how many of the Fortune 500 have adopted it. But what I found most interesting was when Mr. Pyzdek mentioned how one goes about improving this metric. Obviously from a pure math perspective one can either increase the number of promoters or decrease the number of detractors. But each group seems to respond to a different driver. Detractors seem to respond to just getting the basics right and not doing things wrong. Promoters tend to respond to providing a "Wow!" level of service and doing things right.

I think Tom Peters has the clearest description of this distinction in chapter eight (Beyond TQM Toward Wow!) of his book The Tom Peters Seminar. He gives some great examples and insights which I won't attempt to recite here (it's really worth picking up the book!) but his thesis is basically that we need both sides of the equation and when Americans began really looking at quality as a competitive driver we were almost entirely focused on eliminating the "things gone wrong" (TGW) from our systems and processes. And that's important. He makes the point you shouldn't have crumbs on the floor and missing towels when you walk into the hotel room. But that's not enough. We also need to look at "things gone right" (TGR) and find ways to "delight and provide even the unexpressed needs of the customer" (e.g., such as Tom walking into a hotel room where he would be giving a speech the next morning to find a projector and screen set with cables carefully taped down so he could practice his presentation.)

Dr. Goldratt mentions a similar paradigm in Beyond the Goal when he says there are really only two things to worry about:

1. Things that shouldn't have happened but did; and
2. Things that should have happened but did not.

It's simple, but hard to pull off. And it becomes even harder when you consider that Tom will probably expect a projector the next time he stays at that hotel chain for a speaking engagement. So now today's "Wow!" is tomorrow's expectation.