For any CIO, getting the board’s approval for an IT project can be a tough task, especially when there are ever-tighter budgets. But there are ways to make a business case more effective — some tricks that CIOs can utilise. Having an understanding of what makes a winning business, how to present it to the board and the common mishaps to watch out for can be key to getting a project across the line.
What should a business case contain?
A business case structure can vary with each project and organisation but it must at least contain the following, according to Jed Simms, founder of Totally Optimised Projects and founding partner of Capability Management:
- Rationale – why you are looking at this?
- Value proposition – what’s the value for the business, the benefits?
- Cost – what it is going to cost in terms of money, resources, people?
- Delivery – how it is going to be delivered and is it doable, what is the approach and risks?
- Accountability – who is accountable for the project such as sponsors, term committee, project manager, etc?
- Controls – what controls are in place to ensure the project will deliver and achieve value such as reporting, health checks, etc?
Out of all the components of a business case, Simms says the most important is the value proposition. He says even though cost is usually considered a high importance to business executives, the value of the project is what really determines its success.
“They’ve got to shift the focus from cost to value,” he says. “Our whole focus, and this applies to management as well, is on cost. Everybody is focussed just on what is it going to cost, how we manage the cost, how much money have we got left? And there is the hope that the benefits will follow. But you can’t cost control your way to success.”
Kaylene O’Brien, a technology partner at Deloitte Consulting, says getting a sponsor on board to help support the business case is key to success.
“The key to a successful business case is having it not just owned by the IT department, that you have a business unit sponsor who is willing to champion the business case and to influence the key decision makers, and is the person who is effectively stumping the table saying that they desperately need this IT investment in order to satisfy their strategic plan for their part of the business.”
Another important component to emphasise, according to O’Brien, is the benefits realisation plan.
“For example, reducing inventory costs if you’ve got a supply chain solution. Explain the benefits realisation plan of what are the steps, particularly around the processes and the people impacted, and the steps you’re going to put in place to make sure the organisation will extract those benefits once a system goes live, and that you’ve got a process for tracking, monitoring and reporting that.”
Speak business not tech
“Phrase your business case in business language not technical speak. We know that most [businesses] have very limited IT expertise within the board and it’s critical to express the business case in business terms not IT terms,” O’Brien says. Simms points out that words such as ‘essential’ and ‘important’ don’t mean much to the board if you don’t articulate in business terms what your project will do for the business.
“You’re saying this is essential and is important and everything else, but they can’t understand what it’s going to do for them as a business.”
It’s more difficult for the board to reject a project if it is shown that it will drive business outcomes than if a project is shown to just be for the IT department, he adds. “It’s the business outcomes you are trying to achieve; the project is only a means to an end.”
CIOs need to think as if they were the CEO, Simms says. “If I were the CEO of this place, why would I invest in this? What value is this going to give me?
“They really need to understand what drives their business and be able to communicate in those terms.”
Explain the risks of doing nothing
Not explaining the risks that may be involved in stalling a project or a change in an organisation in a way the board can understand is a common mistake CIOs make when presenting a business case, according to O’Brien.
“Quite often CIOs or program directors will describe things such as, ‘We’re on an ageing platform and we need to get off an ageing platform.’ That often doesn’t set a concrete enough view in the minds of decision makers about what exactly are the risks of the ‘do nothing’ case,” she says.
An example of how this situation could be better phrased, says O’Brien, is to present the case where if the organisation is to do nothing and continue down the path of using an ageing platform, especially if there are limited skills available in the market to support that platform, then the risk could potentially be an outage in the business, which could potentially impact revenue.
Tackle issues early
Don’t set yourself up for major objections. Stakeholder input throughout the process of developing a business case is important to help prevent any major objections further down the track, says O’Brien.
“You don’t want to get to the end of the process and find that the stakeholders have got radical options that would be an alternative or have got major concerns.
“So the business case shouldn’t be seen as a document that pops out at the end. Really, there’s an ongoing process that is about stakeholder consultation to gradually build people’s confidence and buy-in that this is the right way to go ahead. And making sure that all of those options are understood and they are described with their pros and cons, and you’ve got that stakeholder input earlier on rather than wait to the end and find that you’ve got objections.”
Simms says having a validation process in place for the business case where “any sizable investment is looked at independently and critiqued” can help CIOs find and solve any problems early, and avoid major conflicts or clashes later on.
Focus on tangible benefits
“All benefits need to be measurable,” says Simms. Direct benefits such as revenue growth have more weight than indirect benefits such as employee productivity. However, the indirect benefits still need to be tangible for the board to see full value, he says.
“Tangible actually means measurable, it doesn’t mean financially measurable. Management will always look for financial benefits first, albeit sometimes the non-financial benefits are actually the main reason for doing it, but that’s not how management think. So you’ve got to have tangible or some financial benefits, as well as tangible non-financial benefits. But the key thing is it’s all got to be measurable where you’ve got to be able to say, ‘Have we achieved that benefit or not?’”
O’Brien says that CIOs must also look at the benefits in terms of how the project will change the way people in the organisation will do things.
“It’s not just a technology solution; there are process changes and people changes that go along side that, and that you have a business sponsor who is willing to drive through those elements of the change to make sure you extract the full benefits.”
Follow Rebecca Merrett on Twitter: @Rebecca_Merrett
Download the CIO Australia iPad app CIO Australia for iPad