Business cases are still a topic that attracts lots of interest amongst CIOs and their staff. But why such continued interest in this old chestnut? The awful truth is that most IT business cases are still mediocre – and some are just downright dreadful.
Gartner EXP took a close look at a large number of business cases and the processes used to develop and execute against them, as part of a recent study we called: Building Brilliant Business Cases.
Common characteristics
We found some business cases are very successful – quite brilliant in fact. These share common characteristics, and have no problems at all in getting widespread stakeholder support.
Brilliant business cases contain the best thinking of all stakeholders. Writing a brilliant business case is a thorough process that involves the right people, uncovers all of their concerns and issues, and then addresses them. It can take months.
That’s fine because presenting the case to the decision-making body to get approval for funding is then just a formality.
Many of the merely ordinary business cases are not approved because they lack sufficient financial justification. Brilliant business cases identify and quantify all benefits. They reflect the views of people close to the problems the proposed solution will solve. They are constructed through benefits-discovery brainstorming sessions with the business and IT, use consultants, trade associations and vendors to leverage benefits experiences of other companies, and use value frameworks to record them.
Identifying the pain points
Brilliant business cases describe projects in the context of business goals, strategies and plans, and the enterprise’s existing and planned portfolio of projects. They reflect business or IT “pain points” where things are not working properly.
Many ordinary business cases fall into disrepute when foreseeable problems occur during the project. These risks must be presented in the business case, up front – not to dissuade decision makers from funding the project, but to improve the chances for success by showing how risks will be reduced ahead of time. Ignoring risks hurts credibility.
Many business executives find business cases difficult to understand. The case should have an executive summary of a few pages. The main body of the report should be less than 20 pages, with the financials presented in the standard company format. Appendixes should support all the detail and there should be sufficient evidence to support all the key points. It should use business terminology, not IT, and use graphics to convey complex information.
You can also improve credibility by providing context. Document key assumptions and ensure they are considered reasonable. Identify sources of all data and estimates. Have an independent group prepare the financial analyses. Provide ranges of estimates rather than single points. Clearly define each benefit in terms of processes affected, with before-and-after performance metrics. Identify the executive accountable for realizing each benefit stream and demonstrate that the benefits can be audited.
Guiding the project
Using a business case to get the initiative approved is simply the beginning. It should also guide the project execution and institutionalize the benefits.
Introduce new executives to the project using the business case to present its intent and rationale for being approved. New mangers often want to make changes. A well-crafted business case can keep that work on track. Review the business case at the sign-off of every phase to ensure continuing alignment with the business objectives.
Creating brilliant business cases isn’t intellectually hard – it just takes time and dedication. If you were to review how you create and use your existing business cases, what would you see? Are you using brilliant business cases – or the other sort?
Andrew Rowsell-Jones is vice president and research director for Gartner’s CIO Executive Programs.
