“Why don’t we grow at the rate projected by our approved business cases?”
It is a known best practice to use business cases as a means to evaluate potential investments or projects. I have blogged about how this can play a pivotal role in portfolio management, when it is done right. By using business case thinking to properly forecast costs, benefits, and risks, projects can be compared, and a portfolio can be composed that optimizes the organizations “bang for buck”, at acceptable risk.
As an initial maturity step, it may be more important to get the business cases comparable than to get good forecasts. This already helps to rank projects relative to each other. However, in the portfolio context, this is not good enough for long. Besides the question “Are we doing good projects?”, an even more relevant question becomes: “Do we have the right portfolio?”, “Does it bring us the expected benefits (in terms of strategic and financial value)?”. Wouldn’t it be great if that question can be answered by adding up the benefit forecasts (the business cases) of the selected projects? Technically, adding up is easy, although one must not forget to adjust the totals for risk. Statistically, if your projects have a 50% chance of success, you should expect to get 50% of the cumulative benefits. So why don’t we just add up all (risk-adjusted) benefit forecasts and compare them to the portfolio targets?
Maybe it is no so simple; there are a lot of situations in which adding up business cases does not lead to a meaningful total…
Business cases yes, but at which level?
In several portfolio analyses we have run in the past few months, the key challenge is to decide at which level a business case should be prepared. It turns out this question is best answered by checking at which level the benefits can be added up in a meaningful way.
Let me start with an example. In the software development process of one of our clients, the Agile Method prescribes to build a benefits estimate at the level of individual stories: small chunks of meaningful IT system functionality. In each of their systems, several hundred stories come together to serve the users. We have changed this to discussing Value (for users and other stakeholders) at the qualitative level, and to build a business case for each IT system’s major release.
More examples should give some suggestions for various portfolio compositions:
- In case of a New Product Development portfolio, the benefits are likely to come from revenue of new products. If these new products are relatively independent (targeting different markets, customer groups, or geographic areas), adding up these revenues makes sense. In case of some overlap, a correction for cannibalization is in order. But if numerous new products address the same customers, maybe it is better to build one business case for such a product family.
- In a Life Cycle Management portfolio, the focus is generally more on reducing product costs. The savings of projects that aim to remove or replace expensive product parts can be added up (as long as they do not address the same product components). However, redesigning a range of products so they can all be manufactured with a cheaper process requires a portfolio level cost saving business case. IT business cases usually come in one of these two shapes, so a careful analysis is needed here.
- Developing features for complex systems can be focused on increasing the sales volume and/or the price point. Adding up feature-level volume and price increases is one of the big mistakes of business cases: these feature sets address the same customers, that decide for the complete system. The 10 new customers that buy the system because it now has feature X ware likely to overlap with the 10 that buy it because it now has feature Y. These customers were already on the edge of buying, they needed “just a bit of” extra value. They also have their budget limitations that severely constrain their willingness or even authority to spend more. Two exceptions apply here:
- The stratified case: adding up extra volumes is allowed if the target customer segments are really independent (stratified), let’s say the Japanese and the Chinese edition of a system.
- The second exception that works in practice occurs if customers choose these features individually: this happens when they are sold as options or accessories.
Where business cases can add up, they can be the portfolio building blocks
From this experience, I learned that determining the building blocks that can have more or less independent benefits estimates, is the key to determining the resolution for portfolio management. These building blocks should then be aligned with cost, resource, risk, and time estimates, to develop complete business cases around the benefits.
Can you give more examples of good and bad example of portfolio building blocks?