≡ Menu
Pawel Brodzinski on Software Project Management

The Cost of Too Many Projects in Portfolio

The Cost of Too Many Projects in Portfolio post image

I argued against multitasking a number of times. In fact, not that long ago I argued against it in the context of portfolio management too. Let me have another take on this from a different perspective.

Let’s talk about how much we pay for introducing too many concurrent initiatives in our portfolios. I won’t differentiate here between product and project portfolios because for the sake of this discussion it doesn’t matter that much.

Let’s imagine that the same team is involved in four concurrent initiatives. Our gut feel would suggest that this is rather pessimistic assumption, but when we check what organizations do it is typically much worse than that. For the sake of that discussion and to have nice pictures let’s assume that all initiatives are similarly sized and start at the same time. The team’s effort would be distributed roughly like that.

Portfolio planning

The white space between the bars representing project work would be cost of multitasking. Jerry Weinberg suggests that for each concurrent task we work on we pay the tax of 20% of the time wasted on context switching. Obviously, in the context of concurrent projects and not concurrent tasks the dynamics will be somewhat different so let me be optimistic with what the cost in such scenario would be.

If we reorganize the work so that we limit the number of concurrent initiatives to two we’d see slightly different picture.

Portfolio planning

Suddenly we finished faster. Where’s the difference? Well, we wasted much less time on context switching. I assumed some time required for transition from one project to another yet still, it shouldn’t be close to what we waste on context switching.

In fact, we can move it even further than that and limit the work to a single project or product at the same time.

Portfolio planning

We improved efficiency even more. That’s the first win, and not the most important one.

Another thing that happened is we started each project with the exception of the first one in presence of new information. We could have, and should have, learned more about our business so that we are better equipped to run another initiative.

Not only that. It is likely that technology itself or our understanding of technology advanced over the course of running the first project and thus we will be more effective building another one. These effects stack up with each consecutive project we run.

Portfolio planning

The total effect will be further improvement of the total time of building our projects or products. This is the second win.

Don Reinertsen argues that the longer the project is the longer the budget and schedule overrun. In other words, if we decided to go with all the concurrent initiatives we’d likely to go longer that we assumed.

In short it means that we do end up doing more work that we would do otherwise. Projects are, in fact, bigger than we initially assumed.

Portfolio planning

The rationale for that is that the longer the project lasts the bigger the incentive to cram more stuff into it as the business environment keeps evolving and we realize that we have new market expectations to address.

Of course there’s also an argument that with bigger initiatives we have more uncertainty so we tend to make bigger mistakes estimating the effort. While I don’t directly refer to estimates here, there’s an amplification effect for scope creep which is driven by overrunning a schedule. When we are late the market doesn’t stand still. To make up for that we add new requirements, which by the way make the project even later so we add even more features, which again hit the schedule…

A bottom line is that with bigger projects scope creep can get really nasty. With fewer concurrent initiatives and shorter lead times we get the third win.

Let’s assume that we’ve had deadlines for our projects.

Portfolio planning

What happens when we’re late? Well, we pull more people from other teams. Well, maybe there was one guy who said that adding people to the late project makes it later but, come on, who reads such old books?

Since in this case all our projects are late we’d pull people from another part of an organization. That would make their life more miserable and their project more likely to be late and eventually they will reciprocate taking our people from our future projects in a futile attempt to save theirs. That would introduce more problems in our future projects. No worries, there will be payback time when we steal their people again, right?

It’s a kind of reinforcement loop that we can avoid with fewer concurrent initiatives. That’s a fourth win.

Finally, we can focus on economies of delivering our products or projects. A common sense argument would be to bring time to market as an argument in a discussion. Would we prefer shorter or longer time to market? The answer is pretty much obvious.

To have a meaningful discussion on that we may want to discuss Cost of Delay. How much it costs us to delay each of these projects. It may translate to the situation when we don’t generate revenues or the one when we lose the existing ones. It may translate to the situation when we won’t optimize cost or fail to avoid new costs.

In either case there’s an economic value of delivering the initiative later. In fact knowing the Cost of Delay will likely change the order of delivering projects. If we assume that the last project had the biggest Cost of Delay, the first the smallest (4 times smaller) and the middle ones the same in the middle of the spectrum (a half) we’ll end up building our stuff in another order.

Portfolio planning

The efficiency of using the teams is the same. The economic effect though is vastly different. This is the biggest win of all. Including all other effects we roughly cut down the total delay cost by two thirds.

The important bit of course is understanding the idea of Cost of Delay. However, this couldn’t have been enabled if we’d kept running everything in parallel. In such a situation everything would be finished at the same time – at the latest possible moment. In fact, if we avoid concurrent work even the ultimately wrong choice of the order of the projects would yield significantly better economic results than building everything at the same time.

What we look at is a dramatic improvement in the bottom line of the business we run. The effects of limiting a number of concurrent initiatives stack up and reinforce one another.

Of course, it is not always possible to delay start of specific batch of work or limit the number of concurrent projects to very low number. The point is though that this isn’t a binary choice: all or nothing. It is a scale and typically the closer we can move toward the healthy end of it the bigger the benefits are.

in: project management

8 comments… add one

  • Szymon Pobiega March 4, 2015, 11:20 am

    All good but it assumes a collocated team. In a team distributed across time zones there is value in buffers. Work flows as Earth rotates and each person needs to participate in 2-4 initiatives to be able to work smoothly. Of course there needs to be a limit on concurrency that introduces slack into the system. My point is that the optimum seems to be bigger than 1 when work flows through time zones

  • Rick Bollinger March 4, 2015, 1:16 pm

    I enjoyed your article. Especially, the next to last diagram and discussion. It needed simplicity to make its point. But, I fear that people see too many of such diagrams and think this is reality. Its not. Reality is much more dirty. In fact, the cost of time and resources is much higher following a deadline than before it. Finishing early means people free up and can wander around looking for new project to join. The few remaining budget dollars find new homes, too.

    But, after a deadline, these resources become very dear. Late projects compete for them. Penalties and overtime run rampant. This asymmetric condition has a role in risk management, as well. (See http://www.pmi.org/learning/lean-based-approach-risk-management-6580, if you can.)

    Rick

  • Pawel Brodzinski March 5, 2015, 2:34 am

    @Szymon – You slice the work on different levels, not only initiatives run within portfolio but also feature sets within each initiative and features within feature sets. On each level limiting work in progress makes sense.

    You’re right in a way that frequently going extreme and achieving one piece flow isn’t the most optimal way of working. I would, however, point that the more coarse granularity of work the more extreme the reasonable limit would be. The reason is that you can still balance work fairly well on more fine-grained levels of work.

    By the way, you may look at this as a reference model: http://brodzinski.com/2013/09/options-options-options.html

    And the general rule of thumb works here: we normally are in such a dire situation that limiting work in progress is a safe choice.

  • Pawel Brodzinski March 5, 2015, 2:38 am

    @Rick – Such a model, as every model, is an oversimplification. Indeed, what happens after deadline is never a pleasant situation and people acting under pressure rarely choose their options wisely.

    This argument, in fact, multiplies the effect of long projects getting bigger overruns.

  • marco March 12, 2015, 3:32 am

    Thanks for this. Very easy to read and good visual aids.
    I am wondering whether anybody is aware of papers/examples that back this theory with documented cases. I think it is difficult to disagree with the theory, and in fact most of us probably have empirical evidence that this works, but it would be interesting to read about real-life cases, including more complex scenarios including multiple teams (e.g. project involving various departments and therefore skill sets).

  • Pawel Brodzinski March 12, 2015, 3:58 am

    @Marco – I’d point you to Don Reinertsen Flow book (http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009) which provides specific stories as well as models that back that up.

    In fact, Don’s product development workshop was an inspiration to write the post.

  • Maciej Świętochowski March 20, 2015, 4:10 am

    And there’s a fifth win: Project-specific knowledge is widely spread among all teams, so you’re avoiding knowledge silos. That’s especially important if teams are very small (2-3 people). This fifth win scales down when it comes to individuals working on projects as well.

  • Bill Duncan March 23, 2015, 8:56 pm

    I think the alleged impact of “context switching” is greatly exaggerated: most of the examples come from manufacturing and similar environments.

    The real cost of multiple projects comes from the impact on management of the need to coordinate team member schedules across multiple projects.

Leave a Comment