Capacity Allocation

Realize Value Faster
If you work in a large enterprise, you have to balance competing requests from many business units, products, and product owners. You need to manage powerful personalities to achieve two goals.
  1. Prevent your teams from being overloaded with too many projects at the same time. If they are overloaded, they can't take any new requests. If they have a bit of spare capacity, or have slots that open up frequently, they can respond to new requests and provide fast turnaround.
  2. Motivate your product owners to divide their requests into small projects that deliver value quickly. You want them to learn to think incrementally.

In this chapter, Damon Poole explains how to achieve these goals. Damon understands how to use a lean philosophy to get more value out of large organizations. He introduced me to Kanban and continuous processes when he was the CTO and founder at code management pioneer AccuRev. He now works with Eliassen Group, consulting with enterprise customers and helping them become more Agile.

How to Realize Value Faster

Most enterprise software and IT groups are pressured into taking on too many projects at once. Even using Agile methods at the team level, they fall into the trap illustrated in the figure below. Here, two teams take on six projects and generate no value, and no revenue, for 18 months.

One solution is to limit the number of projects in process, ideally to the number of teams available. Each team focuses fully on one project, finishes it quickly, and starts generating revenue. Later, the teams move on to additional projects.

However, you may get huge arguments about which projects should go first. The business stakeholders for the second and third-ranked projects may object to being losers in a winner-take-all battle on priorities.

But there are ways to engage everyone in a constructive discussion - and to start generating value and revenue even sooner.

The first step is to work with the product owners to divide the projects into Minimum Viable Increments (MVIs). A Minimum Viable Increment is the smallest subset of a product which can be released, with a focus on the highest value. Viable in this case means that users will welcome its release rather than complain that there is not enough value.

Breaking projects into MVI's usually reveals that some sections of each project are bells and whistles that won't actually provide enough value to justify their implementation. When you are down to low-value functionality, it is better to drop those items from your plans and focus on other projects.

The next step is to set priorities among the MVIs. In the diagram below we see that although Project A and Project B, considered as a whole, are higher priority than Project C, there is a chunk of Project C that is a higher priority than some chunks of Project A and Project B.

Now everyone is motivated to think in terms of MVIs. The smaller the MVIs, the more value the organization can provide and the more stakeholders can be satisfied over a given period of time.

You are now in a position to assign the prioritized MVIs to the available teams.

The resulting plan starts generating value as early as possible, maximizes revenue, and minimizes waste.

In this example everyone gets something. Projects A, B and C all start producing revenue after 3 months, and even Project E releases an MVI in 9 months.

This approach calls for flexible budgeting. It doesn't make sense to set project budgets annually if the mix and priorities of MVIs change frequently. You should work on shortening your budgeting cycles to semi-annually, quarterly, or even monthly. That gives you the chance to capitalize on the best opportunities for realizing value faster.