Which would you rather do: prepare a business case for your latest project or sit for a root canal? No surprise if you chose the latter; most CIOs hate everything about business cases?the politics and the mystifying financial lingo. But these days, the ability to put together a compelling business case is a core competency for CIOs.
A strong business case is critical for effective IT governance, and having one is more important than ever with the increased scrutiny on corporate decision making. “There’s real urgency to get this right. Decision making is much more visible than it used to be,” says Jack Keen, president and cofounder of IT consultancy The Deciding Factor, coauthor of Making Technology Investments Profitable and a CIO columnist. “CIOs have an unusual opportunity to come to the rescue in terms of defining the business value of IT.”
That opportunity is key, since many CIOs are finding their credibility is at an ebb. If you can’t demonstrate technology’s worth to your organization, you risk losing your spot in the boardroom. The good news: CIOs who succeed at building solid business cases attain greater visibility. It is undeniably positive for your career to lead a successful project backed by a sound business case and with proven benefits. How do you know if your business case skills need improvement? If you’ve been turned down on any of the major projects you proposed in the past year, chances are you haven’t done your homework. By adhering to the five essential rules that follow, you can sell your project as a winning initiative.
1. Know Your Company’s Needs
Before you start to build a business case, you need to obtain some financial information about your company. For instance, most companies have a hurdle rate, or the rate of return required by the organization to fund a project. “If a project has been diligently reviewed and can achieve a 12 percent or 13 percent or better rate of return, then it’s in the best interests of our shareholders to pursue,” says Doug Horton, vice president and director of strategic technology initiatives for $2.6 billion LandAmerica Financial Group, a title insurance company.
Hurdle rates don’t change much in the short term. Except in the case of a technical infrastructure investment (such as a network upgrade), you’re going to have to prove you can meet this threshold or there’s no point in continuing.
Sometimes IT leaders make the mistake of believing the corporate hurdle rate does not apply to IT projects. Or they assume there isn’t one. “In many cases, people don’t even bother to find out what the hurdle rates are,” says Keen.
You also need to know what other corporatewide projects are vying for funding. “I assess the financial value of each project as if it were a machine tool because that’s what I’m competing against,” says John Nordin, vice president and CIO at A.M. Castle, a $538 million distributor of specialty metals. There is no separate pot of money labeled “IT.” The CEO sees technology projects as going head-to-head with mainline business projects; you should too.
That same competition for resources also happens within IT. Prior to deciding which IT projects to undertake for the year, Bob Weir, vice president of information services at Boston’s Northeastern University, interviews his business counterparts, asking them 60 questions that get at the heart of the project’s value to the institution. Based on the answers, he derives a numerical score. “The point of the exercise is to get a score relative to the other opportunities that we could undertake,” says Weir. In 2003, there were 36 potential IT projects. Of these, the top 17 were selected, and the rest were put on hold. That is an example of IT portfolio management, in which the CIO, in conjunction with business leadership, categorizes the proposed projects (such as those that will help run the business, those that aim to grow the business and those that have the potential to transform the business) and sets targets for how many projects the enterprise will undertake in each category (see “Portfolio Management: How to Do It Right,” www.cio.com/printlinks).
It should be clear that in most cases CIOs shouldn’t undertake technology projects without the active involvement of the business managers. “It’s very difficult for the technology group to build a business case unless there’s a partnership with the business management team,” says Debra Still, executive vice president and chief operating officer for Pulte Mortgage (a subsidiary of Pulte Homes). “We have an IT representative, a business representative and a project manager put together every business case.”
The IT person lays out the technology alternatives to the problem, providing data on features, costs, and training and support implications. The business representative reviews the alternatives and determines which one is the most beneficial and makes the most sense for the business. The project manager lays out the time line, sets scope, identifies milestones and analyzes project resources. Last March, Still and Pulte Mortgage CIO Rod Hardin followed this process in building a case for a $1.5 million business process management initiative. Pulte senior management approved the project, which will have projected cost savings of 10 percent to 20 percent in its first year while also improving customer service.
Niel Nickolaisen, CIO at Deseret Book, a book publisher and retailer, has his business partner present the case to the executive steering committee, and he provides the details about project cost and approach. “I’m there to answer any questions on the technology side. My partner makes the case for the business benefits,” says Nickolaisen. This approach demonstrates that IT is aligned with business objectives. It also encourages business heads to treat the CIO as their trusted internal IT consultant, which goes a long way toward avoiding rogue IT projects.
At Fidelity Wide Processing, a unit of Fidelity Investments, the IT staff consults on every business case, whether or not the project is primarily technology-oriented. “There are very few investments that do not have a technology aspect,” says Douglas Sutton, president of Fidelity Wide Processing. Each case is a collaboration put together by IT, finance, operations and the line of business that the case will directly affect.
3. Build a rational cost-benefit picture
In conjunction with your business sponsor, categorize the project by type and then drill down into its anticipated benefits. Benefits can be both tangible and easily measured (hard benefits), or difficult to quantify and measure (soft benefits). Project advantages can vary and include financial benefit, strategic alignment, improved customer satisfaction and risk reduction.
Be sure to include different scenarios to ensure an element of risk assessment. If your ROI is riding on increasing sales, for example, you need to take into account the fact that the increase may be less than anticipated or may not occur at all. If the benefits don’t materialize, you’ll have to spring into gear, either explaining why they didn’t pan out or doing the additional work to make them happen.
Sutton was dismayed recently when he discovered that only 12 percent of Fidelity’s business customers were using a new Web ordering system while the promised adoption rate had been 80 percent. The IT team had done all the work gathering customer requirements and rolling out a technically sound solution?which cost in the high six-figures. But the IT team failed to take into account the need to reeducate customers and internal users on the value of using the system. “I told my technology group, ’You dropped the ball,’” says Sutton. Now, the IT team is working on educating users to boost the adoption rate. Sutton expects to see 80 percent business customer usage within 90 to 120 days, an additional investment of staff time, not money. From this experience, he has learned to always include in the business case the change management implications of any project.
In addition to risks associated with users’ behavior you’ll need to assess risks inherent in your industry. For example, when Pulte Mortgage undertook the business process management project last year, the business case identified a number of discrete phases in the project and prioritized them. If economic conditions tighten up, Pulte can elect not to fund the phases with the lowest priority ratings.
Being conservative in this cost-benefit phase will go a long way toward preserving your credibility. Joe Lacik says of his experience at a large telecom company, the game would go something like this: “People would come and ask, ’How much would it cost to build this system?’ I would say, ’It will cost $1.2 million.’ Amazingly, no matter what number I said, they were always able to write a business case that would make money.” Lacik, now vice president of information services for Aviall Services, an aviation parts distributor, changed the process so that one party would assess the potential benefits while a second person would assess the costs to see if the two matched up favorably.
4. Don’t ignore soft benefits
Traditionally, one of the thorniest business case problems is quantifying soft benefits such as increased brand image and customer satisfaction. When you are lucky enough to have hard numbers on your side, your tendency might be to leave out discussion of soft benefits altogether.
But it’s a mistake to leave out the soft benefits because you can’t know in advance what will sway the decision-makers. “People make decisions based on intangibles much more than tangibles,” says Keen. You may think you have an airtight business case based on hard benefits, but the CEO may not agree. “Put the intangibles in as a buffer,” he says.
Use the soft benefits to tell a story in the business case. To hedge against unpredictable soft benefits, Deseret’s Nickolaisen breaks up the business case for a large implementation into distinct phases. “The benefits are sometimes pretty iffy. We don’t move on to Phase 2 if we haven’t received the benefits from Phase 1,” he says. “In this case, we spend less time on ROI and more time on how we’re going to verify the benefits.” This approach lowers risk as decision-makers can elect not to continue with a large project if benefits don’t meet expectations.
Some projects are necessary to further strategic corporate goals. These are often tough to quantify in terms of hard numbers. For example, in the early days of the Web, there were no metrics to measure the value of creating a website. Companies simply believed the Internet was the future of business.
5. Make the business partner own the benefits
Don’t make promises you can’t keep. In other words, make sure the business unit that will benefit from the new system takes formal responsibility for making the benefits happen. For example, if a new software package will reduce headcount in HR, be sure the head of HR agrees to make those cuts. If not, the organization will never realize the value of the investment.
“We hold people accountable; there has to be a sponsor for each initiative, and that sponsor is responsible for ensuring that the results are delivered,” says Sutton. “The goals must be set up front and agreed to before any investment is made.” When that goal involves productivity gains and headcount redeployments, Sutton makes sure the business leaders will follow through before committing the dollars. “We identify the individuals who will be refocused once a system is implemented, or we want to know how much more volume we’ll be doing without adding people.” There’s a natural tendency for function heads to hold onto their people, even though they built their business case on anticipated headcount reductions.
As CIO, you can provide cost-effective, useful technology, but you can’t single-handedly generate the benefits. Your business case must reflect this basic fact by?at the very least?getting the business leader to sign the part of the case that discusses the benefits.
Nickolaisen learned this belatedly. After a project failed to achieve its promise, “the business units would come to me and say, ’Niel, I thought this was going to reduce inventory by 15 percent.’ And I would say, ’I manage a bunch of programmers; I can’t make that happen.’ That was one of my big lessons learned.” Now, when preparing a business case, Nickolaisen goes to his business partner and asks, “Which benefits are you willing to take responsibility for?” This puts the onus where it should be, on the person who can effect the required change.
Preparing a business case is more art than science. But once you get the hang of it, it can be fun. Says Nickolaisen, “I kind of like preparing a business case. [The business sponsor] leads me through the case, and I lead him through the case. It improves my credibility and access.”