Portfolio Management: Stop Starting, Start Finishing

Whenever I end up discussing project portfolios with people representing or knowing specific organizations out of curiosity I ask a couple of questions. How many projects? How many people running those projects?

Note, most of the time I don’t ask these questions in the context of completely random organizations. The most common case would be asking people who are a part of Agile and Lean community. People who understand the concept of limiting work in progress and its implications.

Disturbing news is that, even among the most mindful people, the answers I would get are pretty much shocking.

Kanban Leadership Retreat is an occasion to meet people advancing thinking for a community that painted limiting work in progress prominently on their banners. One would expect that these people, if not anyone else, would be ahead of the rest of the crowd in addressing the issue of too many concurrent projects.

Well, maybe we are. At the same time the ratio of a number of projects run by an organization to a number of people who work on those projects reported at the last Kanban Leadership Retreat in Cascais is terrifying.

1.0, 2.1, 4.5 and 6.0. Let me rephrase what this number is. This is how many projects per person an organization runs on average. In fact, it does mean that some people are in a situation that is much worse than that.

I didn’t gather that data in any consistent manner. I just asked my question any time the context would pop up in a discussion. It isn’t by any means proper research. It shows, however, a very interesting trend. The best result is a project per person, and we are talking here about an organization with a hundred engineers in this case. Few of those projects, if any, require attention of a single person only.

From that point though we go downhill. I can’t imagine any situation where a single person runs concurrently a few projects and they are at least a tiny bit effective. This means heavy multitasking for those initiatives that get any progress and lots of others where progress is nil. Effectively, they are parked even if management believes that they are active.

Let me repeat. It wasn’t reported by a random community. It is the community that calls their user group meetings Limited WIP Society. Not Visualization Society or Flow Society. Limited WIP Society. We do care. We do pay attention. Yet still, we do suck at that. Big time.

Larry Maccherone in his talk at Lean Kanban North America reported that teams that work on a single project are significantly better in terms of defect density. We can use that as a proxy for quality of work. It’s not anecdotal evidence. Larry bases his research on raw data from almost ten thousand agile teams.

By the way, Larry also reported that team size of 5-9 people is by far the most popular one. In other words, ideally, we should be looking as projects to people ratio of 0.2 and below. Of course it is contextual and shouldn’t be treated as the true north. In organizations that typically run tiny projects that require attention of 2-3 people such ratio may be unachievable. At the same time we do have companies that typically run huge initiatives that involve dozens of people.

In either case anything above 1 is obviously crazy. In fact 1 is crazy already.

We can’t make this possibly work.

The easiest way out is obviously reviewing the portfolio and putting on hold or abandoning a big chunk of ongoing initiatives. This would mean that the active remainder would get more, hopefully enough, attention so that these projects can be completed in reasonable time.

Sad truth is that I know such an expectation is unrealistic.

If we understand that potential projects are options that we can execute and once we decide to start them it means commitment we should also understand the consequences. Commitment means that there’s a price to be paid for abandoning an initiative. What’s more that cost isn’t easy to assess. How much would reputation of a company suffer for letting a client down? How much bad word of mouth would be triggered?

Another way is to go with the theme of Lean Kanban Central Europe conferences: stop starting, start finishing.

In other words make it hard to start new stuff. Discuss the cost and risks attached to adding one more thing to your plate. I don’t expect an explicit WIP limit. On portfolio level it is rarely a feasible option anyway. The strategy that you can use is WIP limits by conversation.

There’s not much guidance needed to shift these conversations to a broader context that is frequently ignored. It’s not only how much a new project would cost and how much we are going to get in revenues. It is also about available capabilities: can we staff a project appropriately for its whole lifecycle? What is the cost of delaying the project? What risks are we going to introduce by starting a new initiative both to that initiative and to all ongoing ones? And what is ultimately value of completing the project?

The value question goes way beyond simple financial outcome. In fact, it is a very deep discussion as one needs to understand the goals of an organization. Otherwise discussion about value is pretty much irrelevant. Also discussion about value doesn’t happen in isolation. Remember how hard it was to let down current clients breaking our commitments to them? Well, that’s clearly negative value for the company. If that’s the cost you pay you better have a damn good reason to do so.

I do admit that WIP limits by conversation is a concept that seems vague and fuzzy. However, given that people understand what is effect of too much of work in progress I find it a surprisingly powerful tool. It simply shift the focus of a discussion and thus influences how decision making process looks like. It is like a facilitation tool that helps us to use knowledge that we already have.

Then we stop starting and start finishing.

If we do that in a continuous manner we evolve toward more effective way of working. Not only does it mean fewer emergencies or better reliability but also choosing the right initiatives to run. It would be a nice situation to be in, wouldn’t it?