Capacity Planning and the Project Portfolio

I was problem-solving with a potential client the other day. They want to manage their project portfolio. They use Jira, so they think they can see everything everyone is doing. (I’m a little skeptical, but, okay.) They want to know how much the teams can do, so they can do capacity planning based on what the teams can do. (Red flag #1)

The worst part? They don’t have feature teams. They have component teams: front end, middleware, back end. You might, too. (Red flag #2)

Problem #1: They have a very large program, not a series of unrelated projects. They also have projects.

Problem #2: They want to use capacity planning, instead of flowing work through teams.

They are setting themselves up to optimize at the lowest level, instead of optimizing at the highest level of the organization.

If you read Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, you understand this problem. A program is a strategic collection of projects where the business value of the all of the projects is greater than any one of the projects itself. Each project has value. Yes. But all together, the program, has much more value. You have to consider the program has a whole.

Don’t Predict the Project Portfolio Based on Capacity

If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it.

First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways.

When you have component teams, not feature teams, their interdependencies are significant and unpredictable. Your ability to predict the future based on past velocity? Zero. Nada. Zilch.

This is legacy thinking from waterfall. Well, you can try to do it this way. But you will be wrong in many dimensions:

You will make mistakes because of prediction based on estimation. Estimates are guesses. When you have teams using relative estimation, you have problems.

Your estimates will be off because of the silent interdependencies that arise from component teams. No one can predict these if you have large stories, even if you do awesome program management. The larger the stories, the more your estimates are off. The longer the planning horizon, the more your estimates are off.

You will miss all the great ideas for your project portfolio that arise from innovation that you can’t predict in advance. As the teams complete features, and as the product owners realize what the teams do, the teams and the product owners will have innovative ideas. You, the management team, want to be able to capitalize on this feedback.

It’s not that estimates are bad. It’s that estimates are off. The more teams you have, the less your estimates are normalized between teams. Your t-shirt sizes are not my Fibonacci numbers, are not that team’s swarming or mobbing. (It doesn’t matter if you have component teams or feature teams for this to be true.)

When you have component teams, you have the additional problem of not knowing how the interdependencies affect your estimates. Your estimates will be off, because no one’s estimates take the interdependencies into account.

You don’t want to normalize estimates among teams. You want to normalize story size. Once you make story size really small, it doesn’t matter what the estimates are.

When you make the story size really small, the product owners are in charge of the team’s capacity and release dates. Why? Because they are in charge of the backlogs and the roadmaps.

The more a program stops trying to estimate at the low level and uses small stories and manages interdependencies at the team level, the more the program has momentum.

The part where you gather all the projects? Do that part. You need to see all the work. Yes. that part works and helps the program see where they are going.

You don’t. You see the demos the teams provide, and you reassess on a reasonable time basis. What’s reasonable? Not every week or two. Give the teams a chance to make progress. If people are multitasking, not more often than once every two months, or every quarter. They have to get to each project. Hint: stop the multitasking and you get tons more throughput.

4 Replies to “Capacity Planning and the Project Portfolio”

Interesting. I’ve done some work on this in the past, but I come to a slightly different conclusion, and one that may not surprise you.

Having applied Cost of Delay (proper, quantified cost of delay, not some weird relative magic) across a $100m p.a. portfolio at a Fortune 500 company, it’s obvious that the distribution of value in the portfolio is non-linear. Applying Cost of Delay to projects, and managing the flow of projects actually hides the value. The real value is predominantly at the feature level. In short, it’s quite possible to deliver 90% of the value in a “project” in the first few features you deliver. As a result, you really want to flow features, not projects – and use CD3 to schedule them for the highest ROI.

We presented data from this at #Agile2013 and wrote a paper called “Black Swan Farming using Cost of Delay”. You can get a copy of the paper here:http://blackswanfarming.com/experience-report-maersk-line/
The more relevant parts are actually in the last few pages where we make some observations and conclude.

This doesn’t surprise me at all. This is why using estimation of all the features is a really bad idea. (You and I are agreeing, right?)

In Manage Your Project Portfolio, and in other places, I say to flow work through the team. Set up the cross-functional team, and flow work through it. Your findings say that.

I have experienced the same thing. When my clients (and I) worked in an agile or incremental way, either releasing or ready to release on a feature-by-feature basis, we always ended the project earlier. Always. Somehow, we just didn’t need those last “few” features, where few could actually be a substantial number. The value of the project was so great, it was worth it to release earlier. Then, the other projects were more valuable than what was in the backlog for this project.

(Let me know if I have put words in your mouth. I am sure you will.)

This is why estimation doesn’t work for the project portfolio. Value works.

Gentle readers: Deliver working software, according to value. Now, assess the remaining features in your portfolio by value. Do the most valuable ones first. Release your product as early as possible.