Four Reasons for a Business Case – And Why Three of Them Are Wrong!
Most Business-IT initiatives require some type of Business Case (cost-justification) to be prepared. This is an important Business Relationship Management (BRM) activity—typically undertaken as a joint activity between the BRM and their business partner, the common purposes for Business Cases include:
- Clarify the initiative
- Justify the cost
- Prioritize the initiative against other activities competing for limited resources (e.g., funds, people)
As sensible and worthwhile as these sound, the dirty secret is that most business cases fail to achieve their highest purpose—to help drive value realization from IT investments! Let’s explore this phenomenon.
1. The Business Case as a Clarification Tool
Most (but by no means all!) business cases do a good job at clarifying initiatives. For example, Alan Weiss suggests thirteen questions for establishing value with the buyer in his book Value-Based Fees (Ultimate Consultant (Pfeiffer)) (Kindle Locations 260-266), Wiley Publishing:
- What will be the difference in your organization at the conclusion of this project?
- What if you did nothing?
- What if this project failed (or have these attempts failed in the past)?
- What will you be able to do that you can’t do now?
- What will be the effect on revenues (sales, profits, market share, and so on)?
- What will be the difference for your reputation (image, standing, stature, and so on)?
- What are the three greatest impacts of the result of this project’s success? (People love to think in threes.)
- What will your boss’s reaction be to this success? (Even economic buyers have a boss; sometimes it’s the board.)
- What will this mean to you personally?
- What peripheral and secondary value do you see accruing to this project?
- What will you be proudest of at the conclusion of the project?
- What will be the legacy of this project?
- What will it mean to be on the leading edge, the thought leader in the field?
2. The Business Case as a Cost-Justification Tool
Here is where business cases typically start to fall down:
- Costs are often short-sighted, failing to really anticipate ongoing maintenance, operating and retirement/decommissioning costs.
- Costs are often narrow-minded, failing to really anticipate the cost of change to business processes, competencies and unintended consequences. Most initiatives cost more than you think they will!
- Benefits are often unrealistic, hard to quantify and make all sorts of unstated or unrealistic assumptions.
3. The Business Case as a Prioritization Tool
Given the weaknesses in the business case as a cost-justification tool, it is not surprising that the business case typically does a poor job in helping prioritize initiatives:
- Prioritizing one case against others might be very misleading. Individual projects often become (by initial intent or in retrospect) parts of overarching programs. It is as if my auto service shop tells me I need my front right tire replaced—it will cost me $50 but give me another 5 years of safe driving for that wheel. Oh, by the way, you need your front left tire replaced as well, another $50 for 5 years of safe driving. And so on for the rear tires. Oh, by the way, you will need a wheel alignment—that’s $50. But, we’re running a special: buy 3 tires and get the 4th free, plus we will throw in the wheel alignment for free. Now, do I prioritize 5 separate investments, one for each of the 4 tires plus the option of having all 4 done? Obviously not. The deal would be pitched to me not as 5 investment options, but as one integrated safety “program.” IT business cases, however, are often pitched as “separate tire” investments with the logic that it might be an easier “sell” or because each “wheel” is the responsibility of a different business unit!
- Prioritization at the project level often means juggling and evaluating hundreds of projects. Most business-IT governance bodies are unable to reasonably evaluate so many initiatives.
- Investment prioritization is better handled at the program level—interdependent projects that together achieve an important set of business outcomes. But many Project Management Offices (even if they bear the name Program or Portfolio Management Offices) don’t really work at a program level—they work with laundry lists of individual projects.
- While prioritization at the program level is significantly better than at the project level, even then, program level prioritization often ignores portfolio implications. For example, what I really want from my business-IT investments is some sort of balance between short and long term investments, between high risk, potential high reward and low risk, low reward opportunities. I want some sort of strategic balance—which business units or product lines do I want to be investing in and which am I harvesting? Rarely is the portfolio perspective taken into account—a technique that is just about universal for the personal investment portfolios of all of the business and IT folk involved in the initiatives!
4. The Business Case as a Value Realization Tool
And the most valuable reason for the business case is the one that is almost always absent—value realization!
- What are the tangible sources of value this initiative or program will enable?
- How will these value sources be felt?
- How will we track, measure and report them?
- Who owns the measurement plan?
- How will we account for them on the books?
- Who is accountable for them?
- What are the consequences of achieving them or failing to achieve them?
- Who are the key beneficiaries and what is their commitment to value realization?
- How will we capture and incorporate lessons learned?
How are you using business cases to drive value realization?
(This post is an expansion of my post that first appeared on IT Organization Circa 2017.)
Leave a Reply
You must be logged in to post a comment.
This is a great post! The companies I have worked for knew they are not quantifying the value of each project and/or program correctly, but they still did it. I have been apart of organizations that will “fudge” the numbers of a “business case” just to get the project off the ground and worry about the value realization (or lack thereof) post implementation. Very sad, but true.