How can a practice that makes so much sense be distorted and abused to the point of losing whatever credibility it had left? The idea of forecasting the benefits and the investments, considering the risk and the alignment with corporate strategy before approving a project has such a high stature in the organizational project management world, that seeing it in ruins is like watching an old movie star, who used to be a knock-out, looking like your favorite aunt, but for different reasons.
The idea makes sense, but like most things, cannot be applied to every situation. When you are dealing with operational projects required to run the business or grow the current business, a business case can be put together with no problem. However, it can still suffer from some common ailements:
- Benefit Creep: (1) With a legitimate intention to get the project approved (of course, this is the best idea ever, isn’t it?), benefits start to pile-up, getting to a list of things that save 3 minutes here, 5 minutes there, another half a minute here, and at the end you have so many minutes times so many employees and voila, this will generate $XXXX a year. These benefits may appear legitimate, but some qualify as BS Cases. Once I got my hands on a business case for a multi-million program that had a list of over 30 benefits of this type, which all saved minutes of the key resource in the organization. At the end they got a good number of millions saved, enough to justify the program. What they didn’t do, and I did, was add up these savings and translate the result into headcount reduction. In this case, savings accounted for half of the key resources, who by that time should have been let go. How many positions were actually shaved? You guessed right, none.
- The Benefit is Right: this is a popular game in project management circles, in which the person in charge of justifying the project starts trying numbers of potential savings, until a credible but attractive number is achieved. For example, what percentage of reduction in lost accounts will this produce? Let’s try 1%: oh my, it gives a return of 350%, that’s too high; how about 0.4%, still to high. At the end they settle on 0.024%, which generates a return of 19%. This game is frequently used when the results of projects have to combine with other results to generate value, the norm in transformational scenarios, in which benefits cannot be estimated for individual projects nor verified in production. Under these circumstances, you do not have any other option but to guess.
- The Dukes of Hazard: In this case, the person trying to justify the project is honest, and assesses the delivery risk of the project as very high. However, the business case is based on an estimate of schedule and cost that doesn’t consider risk. Hello? If your project is high risk, there is no uncertainty, it is a fact, that it will take longer and cost more. So why in the world are you using an estimate based on things happening as planned? Sorry, I forgot, you like strong emotions.
- The Multiplication of the Bread and the Fish: Many of you probably know the story, that seven loafs of bread and 2 fish fed over 50,000 people and at the end the leftovers filled 12 baskets. Quite a miracle. The surprising thing is that these miracles happen in our organizations quite often. When you add up the BS Cases of all the projects that will reduce headcount, you may end up with a negative workforce. And when you add up the benefits from all the projects that will increase sales, the revenue of the company is twice the expected forecast. The miracle here is that these BS Cases get approved and funded.
In addition to all these ailements in the estimation of value, there is the question of alignment, which again makes perfect theoretical sense. Of course, projects should be aligned to the goals and strategy of the organization, but there are two problems here: the first problem is that, in too many cases, the strategy is a collection of vision, mission, goals, feel good statements, mantras, tactics and whatever else the executives want to get in the document. I personally call this a “wishion”, a strategy document that defines where the organization wishes to go, but doesn’t define how it will get there. True strategy should define, as in a recent HBR article, “the what and the how”: what do we want to achieve, which defines the results, the business outcomes, and how we will get these results, what are the things we will do that we are not doing today, will do differently or stop doing, represented by capabilities. If the strategy is described in these terms, alignment makes sense and can be done. However, if your strategy sound like: “we have to grow no matter what” or “reduce expenses at any cost”, every project can claim alignment, as every project will do one or the other. The second problem is that certain projects are required to run the business, which have very little freedom to invest. These projects cannot be aligned to anything, they are just required to keep the lights on. Of course, if they save costs, we get into the first problem, and the project gets the alignment points.
I still consider the business case a venerable institution that, when used properly, can provide decision makers with the information they need on the expected value of an investment, alignment to strategy and the associated risk. However, it is my opinion that the abuse of the business case is not a problem of bad behaviour, but a result of governance that does not recognize the difference in types of investment and requires business case to be prepared for projects for which it cannot be done.
The good news is that there is an alternative, top-down portfolio management, which solves the problem for transformational scenarios. In this approach benefits are based on the relative contribution of the project to the overall results of the business, and alignment is black or white, as the strategy is used to build the portfolio, so if your project is aligned to the strategy it will be in the portfolio, if not, it is either operational or you have to take it to another company. A top-down approach is a valid option for reapplying the concept of the business case, not a BS Case.
Notes:
- The term Scope Creep is not mine. I saw it first in a LinkedIn discussion started by Frank Ramser from Australia. I don’t know if the term is his, but he used it in that discussion.
- More information on Top-down Portfolio Management can be found at http://p3mconsulting.ca/index.php/solutions/brmtool
