Battling the bean counters--and winning
Despite what you might believe, corporate bean counters were not put on this earth to shoot down your IT projects. But if you want the CFO to approve your proposal, you have to show how your technology investment is going to help the company move forward.
Angelo Tomasello is a former financial services CIO and currently director of healthcare solutions for Interactive Business Systems, a nationwide IT consulting firm headquartered in Oak Brook, IL. "It's my experience," he says, “that bean counters love to hear right out of the chute, 'I can save you X amount of money.' If you can save them any kind of money, I think they’re willing to listen.”
Due diligence is key. When you put forth a business case for an IT project, you need to cover all your bases. According to Tom Pisello, CEO and founder of Orlando, FL-based Alinean, a developer of ROI tools for information technology, any investment that requires executive approval outside the CIO's office—typically anything with a $50,000 price tag or higher—is going to need a complete ROI analysis. That means not only all the costs and projected benefits, but the risks as well. With major analyst firms like Gartner and Forrester Research indicating that about two-thirds of all IT projects are destined for failure, Pisello observed that “it’s pretty obvious that IT is a risky proposition compared to other investments the company makes.”
Here are strategies that won’t guarantee funding, but will definitely improve your chances for approval.
Use the right language for your business case
Make sure your financial metrics jibe with the way the accounting department likes to see project cost justifications:
- ROI calculations
- Net present value savings calculations
- Payback calculations
- Internal rate of return calculations
- Whichever measures your company uses
Outline potential risks and responsibilities
Pisello also recommended that you work with the business unit that has requested the project and put together a risk analysis. What are the potential risks? What is the probability that those risks will occur? What effect will those risks have on the company should they occur? Who’s assigned to mitigate those risks and what strategies will be involved? “Pick the top 10 or 15 risks and document them as part of the project,” Pisello suggested.
It’s also key that the business unit stands up and stakes its P&L on the outcome. “A majority of the costs—the training costs and the business process reengineering costs—are going to come out of the business unit’s budget, not IT’s,”explained Pisello. “And almost all of the benefits are going to be the responsibility of the business unit, too—whether it’s improved productivity, improved selling effectiveness, or whatever. It’s all about user adoption and user application of the technology to the business.” So unless the business unit commits to achieving the goals, and builds its business plan around it, it’s not likely that finance will approve the expenditure.
Be conservative in your estimates
Hughes volunteered another important strategy in selling an IT proposal. “Never take all the savings when you do your calculations,” she shared. “If you think you’re going to have seven categories of savings out of a project, only put three or four of them in your business case numbers.” Holding back on soft savings, or ones based on industry statistics that may or may not be achievable, demonstrates to the accounting department that you’re being fiscally conservative in your projections. If those additional savings do occur, they’re gravy. But you’re not counting on them in justifying the value of the project.
Tomasello shared the example of a large-scale project he implemented for Everest Healthcare, where providers used PDAs to take patient information at bedside during acute dialysis treatment. He focused his ROI analysis strictly on improving workflow and reducing labor costs. Hospital billing information was captured as patients were being seen. At the end of the shift, the PDA could be set in a cradle and the information downloaded automatically to the hospital billing system. This saved countless hours of typing, improved data accuracy, and shortened the billing cycle significantly.
What Tomasello did not include in his calculations—the gravy—was the marketing advantage of tracking the success of bedside treatments. Because the health services provider was measuring it constantly, Everest discovered that its rate of infection was extremely low and continuing to drop. At the time, the company was the only dialysis vendor to track this kind of information and was smart enough to use it to market its services to prospective client hospitals. “It was enough of a differentiator that it won them a number of clients,” said Tomasello. “So the true ROI on this project was much higher than we even estimated.”
Look at all the alternatives
With the economy so tight, finance isn’t eager to spend money on technology for technology's sake. Chris Hagler, a former manager at Deloitte and Touche and now national director of IT at Resources Connection, recommends that before you suggest investing in new systems and applications, you take a look at what you already have in place. You may find that you’re really not using the current system to its full potential or that improper training is derailing the anticipated benefits. “CIOs are going to have more credibility with the finance department,” said Hagler, “if they’ve first explored better utilization of what they currently have in place.”
Along those same lines, Hughes said to be sure to include three to five alternatives in any IT proposal to demonstrate that you’ve really explored all avenues. “And do a full evaluation of those alternatives,” she insisted, “so that you’re prepared if someone should question the investment and ask if you’ve looked at other possible solutions.” If you can’t intelligently discuss why you considered and ultimately rejected those alternatives, Hughes said, there’s a good chance the approving body will delay any decision until you’ve gone back and looked at them anyway.
Watch out for multiple projects claiming the same benefits
Peter Faletti, a former CFO and now principal for North Highland Company, cautioned CIOs to avoid a common mistake when building a business case: multiple projects claiming the same benefits. “I’ve seen it happen a lot,” he said, “where double, triple, and quadruple counting of the same benefit for different projects trips them up later on because they just can’t find those savings.”
“You have to be very careful to understand if you’re proposing truly incremental savings or whether you’re simply saying that a project is necessary to lay the foundation for future ones that will save the money,” Faletti explained.
Consider all the costs
According to Hagler, it’s important to document not only the development costs, but the ongoing maintenance for whatever you’re planning to deliver. “A lot of CFOs today are looking more at the lifecycle costs, the actual costs,” she said. “So CIOs need to think all the way through a project—not just what it’s going to cost today, but what it’s going to cost in five years.”
“A lot of times, the IT department will overlook some of the more hidden costs,” said Pisello, “like user training. They’ll factor in the cost of training people they have today, but forget about the 10 percent turnover every year that means you have to budget training for new recruits.” Other hidden costs? Process reengineering, reentering data into the new system, and ramping up time for the learning curve.
You don’t have to have an MBA or Ph.D. in finance to calculate costs and benefits, but it does help to have an understanding of what the CFO wants. Pisello said it could be as simple as getting a spreadsheet from the finance department that shows exactly how they’d like the costs, benefits, and risks to be quantified. Or it could be as sophisticated as an advanced portfolio management system that tracks costs, benefits, and risks, managing the IT investment project as if it were a stock portfolio. Pisello also mentioned specialty providers of ROI tools who could provide some of those cost-justification templates, or analyst firms like Gartner, Forrester, or IDC, which could offer some of the typical frameworks and worksheets used to do this type of justification. Consultants like Ernst and Young or Deloitte and Touche, or vendor-related professional services groups like IBM Global Services are other resources you can turn to to help the IT team build the business case for the solution.
Vendors are another avenue. “Right now, a lot of companies rely on vendors to do a lot of the financial due diligences on whether to invest in the solution or not,” said Pisello. The IT team can build their own business case by looking at four or five proposals and picking and choosing elements from each. But Pisello cautioned that relying completely on vendors rather than augmenting the research with your own independent analysis could be dangerous. He recommended that building a business case should be a collaborative effort, one that involves all of the project stakeholders in the process—IT, the business unit, vendors, the CFO’s office, perhaps even value-added consultants who can validate the business case and make sure the results are achievable.
Offer ideas early
Another trick of the trade is to float your ideas early: the old run-it-up-the-flag-pole-and-see-who-salutes strategy. “Most companies have a process you have to go through to get capital justification for a project,” said Hagler. “Instead of that being the first time the finance department even sees the capital request, I think the IT group would improve its chances if they started to sell their ideas a bit earlier in the process.”
Hughes agreed. By floating ideas early, she suggested, you can find out if the finance department is predisposed to reject or approve specific kinds of IT investments. “Particularly if you’re a new CIO or new to the company, you may not know the full history,” she said. “The finance person can be a good source of information to help you understand what does and doesn’t work in the company, and whether or not something similar has been tried before and failed.”
Faletti concurred and added that sitting down to lunch once a month to talk about what’s going on would do a lot to build rapport and trust. “A lot of people underestimate the value of that,” he said. “But I can tell you that if you can set up a regular time to get together—-CIO and CFO, or IT manager and controller-—you’ll find that you begin to understand each other. And it’s worth the investment.”
Faletti also recommended regular briefing sessions with the finance people to keep them abreast of changes in the industry and technology that might affect the business. For instance, say a major vendor just announced that it’s planning to stop supporting a particular platform that just happens to be the backbone of your company. The issue of infrastructure must be addressed, and soon. Or, three new applications have just come on the market that are far superior to what you have in place and are being adopted by your competitors. You need to look at them. “It shouldn’t be a techy talk,” he cautioned, “but a heads-up on upcoming issues the company is going to have to pay attention to.”
Increase the likelihood of approval
Even if you proposed the most advantageous IT project that ever was, there are no guarantees it’ll be funded. The money might not be available. Priorities might shift. Or one of a countless number of reasons may cause the finance people to table your recommendation. But from their years of experience, former CIOs and consultants agree on a few principles that might increase your chance of success. When you put forth your business case:
- Be complete.
- Be realistic.
- Present a range of assumptions—optimistic, realistic, and pessimistic.
- Test the reasonableness of the project.
- Link the project to specific business objectives or strategies.
TechRepublic originally published this article on 26 November 2003.