I’ve written articles for Techrepublic on developing business cases and influencing decisions and will probably write quite a few more, but just for a change of pace, this piece is about evaluating or reviewing a business case.
So, why is this discussion necessary?
Professionals and managers are often asked to review a business case and provide a recommendation to the senior management. “It looks just fine” is not really going to cut it, trust me, especially if it transpires that it really isn’t fine at all. A major CLM (career limiting move) may be in the making. If you happened to be an executive whose job is to approve or turn down the case, the stakes are obviously even higher.
While these considerations may appear to be obvious to you and me, in the past twelve months alone I have seen several C-level executives readily sign off on business cases, which contained material errors, were based on incorrect assumptions or suggested actions that were not viable. I believe that such waste of resources and endangering of people’s careers is simply unnecessary.
Before we delve into the discussion, I would like to make the framing of this article clear. First, it’s written to enable people to become more effective in reviewing business cases, not to teach them how to shoot down a business case. In other words, it assumes that the reviewer is genuinely interested in the subject and wishes the author to succeed.
Second, this brief guide is a strictly practical tool that is not going to be concerned with how the case should have been written in the perfect world, but how to make a decision based on what you have in front of you (if at all possible). Third, there is not a ghost of a chance that we will be able to explore the subject in detail in the confines of a brief article.
Now, let’s get started. In all likelihood, the case you’ve received for review contains an executive summary, which is where you should start to gain a general understanding of what it is all about. Then you should read the rest of the case, which should tell a story. Then, ask yourself the following questions. If you are unsure of the answers, I recommend talking to the author.
What is this case all about?
After reading the executive summary and certainly after reviewing the body of the case, you should be in a position to reflect on the objective of the proposal. Is there a legitimate business concern or opportunity that it identifies and addresses? Are you tempted to shake your head say “So what?”
There are several common problems you may encounter here. First, you may find that there’s no clear objective. Second, you may find that the author does not understand the issue he or she is trying to address. Third, you may find that the problem is misdiagnosed which often leads to attempts to address not the cause but the effects. The latter includes the infamous sin of “let’s throw technology at it,” which invariably leaves the core problem unresolved.
If you’re clear on the objectives and they appear to be legitimate, read on.
How can we get there?
The next checkpoint is this: the business case must be advocating some course of action, but does it discuss alternatives that have been considered? My standard advice to business case developers is to discuss several good viable alternatives and recommend one of them.
If the case presents only one alternative and especially if it positions it as the only way to do it, it is prudent for the reviewer to reflect very carefully whether other viable alternatives may exist. If they appear to exist, while the objective has a merit, send the case back to the authors, encourage them to take a broader view and suggest that it may be appropriate to involve others. There is rarely only one way of doing things. The same course of action is also appropriate when you discover that the presented alternatives are weak bordering on silly. Please note that in keeping with our good-natured framing, I’m not suggesting to simply toss the case out, although that option is always available.
What are the costs and benefits?
Perhaps your business case was authored by someone who heeded my advice on firmly recommending one of the alternatives. Here’s the key question: What were their criteria for making this recommendation?
The business case should present to you a comparative analysis of pros and cons, cost and benefits of each of the alternatives. Sometimes the options are so closely related that it makes sense to discuss the common attributes and the deviations, and sometimes it makes sense to discuss them completely separately. Whichever way it is, you, as a reviewer, should have a feeling that someone has explained to you their thinking on the matter and it makes sense.
Here are some key items that you should expect to see:
- Fit with mission, vision, values
- Fit with strategy and other projects
- Risk profile
- Non-economic benefits and costs (qualitative, capacity)
- Economic benefits and costs
The last bullet point can be so much of a problem that I intend to discuss it in detail in my next blog here on Techrepublic. There are concrete established methods of economic analysis that need to be followed and done well if this important portion of the business case is to be worth more than the paper it’s written on. There are actually rules that need to be followed, but in my observation, neither the author nor the reviewer always possesses the requisite skills. My advice is to learn the most commonly used methods of financial analysis, such as Payback, IRR and NPV and be able to identify issues. If you’re not familiar with these, seek an opinion of a professional. Please remember that financial analysis and accounting are two distinctly different skill sets. Do not simply give it to a CA, but check with an expert in financial analysis.
The fine details of these methods aside, you should expect to see the following two critical points addressed:
- Assumptions. Being a projection of the future state, business cases involve assumptions. To judge whether the case is reasonable, you must be able to judge whether the assumptions are reasonable. As such, they should be clearly identified.
- Sources of data. You want to know whether the supporting data has come from. Otherwise, how can it be trusted.
Once you’ve gone through the cost-benefit analysis, you should be in the position to state that you understand all the pros and cons of each alternative and know why the author made his or her recommendation.
What is involved?
Many business cases include draft implementation plans because, to cost out a project realistically, one has to think about the resource requirements and the project schedule. It’s not always warranted to delve into the detail, but often the author will have the implementation figured out to get the costs right, and since it exists already, why not include it into the business case.
If the business case in front of you includes the implementation plan, check it for realism and completeness. If you find that it lacks provisions for certain implementation activities that come at a cost, you will know that the financial analysis is also incomplete. But don’t sweat over the small stuff.
Is it both legal and ethical?
I’m not kidding! Check with the legal counsel if you have any doubts. If it seems to fall below the ethical standard of your organization, confer with your peers or those who may be better equipped to make this judgment.
There’s likely not such a thing as a perfect business case, nor is there the best ever way to review it. But I believe you will be in a good shape if you ask these questions each time you evaluate a business case.
Ilya Bogorad is the Principal of Bizvortex Consulting Group Inc (www.bizvortex.com), a management consulting company located in Toronto, Canada. Ilya can be reached at ibogorad@bizvortex.com or (905) 278 4753
