Lessons From the Field: Beyond ROI

So how do you make a good business case for a project? We recently canvassed managers at enterprises large and small, from diverse industries spanning health care to banking, and found some common ground.

Credibility Building

One key theme permeated our interviews: If your business credibility isn't established, you will have a tough time building any kind of case for projects. Simply put, business credibility means the folks in charge know you're not just a geek, that you have "business value add" (see "Stupid IT Manager Tricks," for a list of don'ts).

First and foremost, you must understand the underlying business that your IT department is serving, says Jim Kennedy, information systems and technology manager for United 1st Federal Credit Union, St. Marys, Ga. "If you don't," Kennedy says, "you're automating things blindly."

Kennedy says he keeps a list of business problems he's noticed. In any organization, of course, this list can be endless; the key is bringing up the problem when you can do something about it. For example, when there's a technology development Kennedy thinks will fill a need, he lets management know he's noticed a business problem and then presents the technology solution. In IT, as in comedy, timing is everything.

One technique typically used by IT managers is the old "save a couple of minutes" routine--that is, save line workers a few minutes here and there, and when you scale it to thousands of workers, you save a huge amount of money. But you must understand the business well enough to know when time savings might not translate into dollar savings.

"People try to come up with funny numbers and save 15 minutes of time booting up to justify a project, but ultimately, that isn't what sells those projects," says John Fuhrman, a project manager who has worked in both the airline and banking industries.

Indeed, you must take any type of measurement like this with a grain of salt. Top managers may look askance at the desirability of "saving time" in the morning while employees are already multitaksing--checking voicemail, making coffee or having their morning meetings--all while booting their PCs. We're all for dealing with staff time problems, but you must do so in conjunction with line managers, who have a good idea of how slack time is used. If you pitch throwing precious IT dollars and resources where there's no clear-cut business problem, you're eroding your credibility.On the flip side, if numerous errors are causing the workers to stay late at the end of the day, even if they don't get paid overtime, you have a huge business-efficiency problem on your hands, albeit a hard one to measure. If you can solve problems like this, says Kennedy, "It's Tylenol--it relieves the pain. Nobody thinks of the cost of Tylenol when they've got a headache." Noting business problems like this and proposing a solution may not pay the company back big time--at least at first--but it will certainly bolster your credibility.

Here's the easy part: Managers should recognize that IT has business value only insofar as it helps business units cut costs or produce additional revenue. Risk avoidance is simply a variation on the "cut costs" theme: Just ask finance how much it would cost to go through and sanitize all the books if an intruder creatively modified a couple of line items. The hard part is recognizing that we can't do it alone. We must partner with other business units to make those cost cuts happen. For example, before talking about labor savings, partner with the business-unit manager whose labor will be saved, and find out if technology will indeed cut head count. Once you get past that, it's easy to be a hero.

If business success were only a matter of installing a certain type of server or software or management application--or any deterministic tool used in business--we'd all be stinking-rich entrepreneurs. Instead, we as IT managers must come to grips with the fact that business success and, ultimately, IT success involve due diligence, risk and judgment.

Getting buy-in is as much art as science. It has to do with relationships and history, so you must build both. Most of all, as one manager told us, "There is no silver bullet. If there were, we could teach a monkey to do it."

Speaking of business credibility, one way to strengthen yours is to understand where IT fits into the corporate jigsaw puzzle from a profit-and-loss standpoint. To do so, you need to understand a couple of managerial accounting concepts. Managerial accounting is the subdiscipline of accounting that helps your business maximize profits, minimize expenses and operate more efficiently. When the decision is made to outsource your IT department, it typically comes from someone playing the MA game, so pay attention.

• Responsibility centers: From an MA standpoint, upper management judges departments based on the type of responsibility centers they are, because the type of center indicates what type of fiscal performance is expected. For example, IT is usually considered a cost center, where the manager is fiscally responsible for containing cost. The sales department typically is considered a revenue center, where the manager is responsible for total sales but not necessarily for profitability. A profit center, naturally, is responsible for making sure that revenues outstrip expenses, thus turning a profit; the manager of a consulting practice is, in effect, in charge of a profit center. Finally, an investment center is responsible not only for profitability but for making wise capital investments.• ROI: An investment center is typically judged on its ROI: return on investment. The mathematical definition of ROI = i/c, where i is income and c is invested capital. Saying that IT generates ROI is semantically null from an MA standpoint, since IT typically isn't in the business of making investments that generate profit. To truly generate ROI for the business, IT would have to partner with an investment center. Our advice? Use the ROI moniker sparingly. Instead, concentrate on benefits and savings by working with business unit leaders.

Because ROI tends to be misused by various marketroids, it's not surprising that we heard cynicism and skepticism about ROI everywhere we went.

"I'm very jaded about ROI--every project always seems to come down to non-financial measures for justification," says a network infrastructure project manager in a large manufacturing company, whose attitude typified that of many managers we interviewed. The CEO must be convinced that there will be intangible benefits even if there aren't financial returns, he says.

"The CEO has been making that judgment for other departments anyway, like marketing. So 'if it positions the company' or 'makes things easier,' you get a green light. It has nothing to do with ROI. ROI is this idea that's come up to try to give 'measurability legitimacy' to IT," he says. "Well, no. We're not engineers the way manufacturing engineers are. ROI is some sort of MBA reaction to 'you can't manage what you can't measure.' There's all this value placed on measurables, and ROI is a stand-in for that. People say, look we've got this project, and we've got this number. Therefore I don't need to exercise judgment, I just go ahead and do it. But you've got to remember, the success of the project may not be in the numbers!"

As an IT manager, you need a practical knowledge of MA and a sprinkling of consultation with those who practice it daily. One interesting tidbit from a recent reader poll: Although 76 percent of you track the returns of a project and 39 percent do so with financial staff, many of you never consult financial staff before you start preparing a business case for a project, and when you do prepare it with them, about 30 percent of you consult them dead last. Our fieldwork indicates that those of you who do consult or partner while you're building the business case do pretty well. (If you're interested in boning up on MA, we recommend Managerial Accounting: Creating Value in a Dynamic Business Environment, by Ronald W. Hilton, McGraw-Hill/Irwin, 2001).Show Me the Savings

Another strategy: Concentrate on cost avoidance rather than ROI. After all, revenue minus cost equals profit, and if you minimize cost, you are contributing to the bottom line in a tangible and important way.

There are some projects for which a large purchase makes sense if it will spare you from decreased quality of service and increased cost. For example, it's smart to upgrade to a new technology because the old one will cost far more over its useful life. One common example is the investment in Ethernet switches and NICs because of the high cost of maintaining aging token ring gear.

An example of a cost-avoidance strategy that might strike close to the hearts of the folks with the checkbooks is the purchase of software--for example, document imaging, or perhaps a data-conversion package--that lets a department avoid hiring temporary employees during a seasonal rush.

When you are looking at ways to save a department money, it pays to think about fixed costs versus variable costs, too. Fixed costs are those where unit volume doesn't matter--for example, a factory building or your Internet connection. Variable costs are those that increase as your unit volume goes up--software licenses and hourly labor, for instance. You're probably already pretty good at identifying ways to save money within IT--for example, switching to incident-based support where it makes sense. But as you start looking at the way departments work, think to yourself, "How could I save some money for these folks by applying IT to their problems?" Visit the departments. If you see users manually converting images to the format their database supports, clue them in to automated conversion tools.

You can strut your fly managerial accounting knowledge by showing that you know which situations require financial payoff analyses versus a more amorphous business benefit breakdown.Doing a quick spreadsheet on tangible benefits--and nonbenefits when appropriate, like the "saving 15 minutes of bootup time" scam--can pay off big time. But doing a "dollars and cents" comparison doesn't mean you have to chuck your judgment out the window. One interesting example that Kennedy cited combined business judgment and cost comparisons. He went through a cost-savings exercise much like many of us do, showing how embarking on a new telecom contract could save his company significant dollars, both immediately and over several years.

The spreadsheet, however, did not ignore the business risk: One of the company's locations might be closing, and the telecom contract didn't have an exit clause for this possibility. However, the immediate savings were so compelling that embarking on this contract was a clear win.

Doing a quick spreadsheet on why you should get rid of an IT system can cure a headache and make you look good to boot. Consider United 1st Federal Credit Union's five-year-old "Loan Line" IVR (interactive voice response) system. It cost $10,000 over five years, which sounds reasonable. However, the bank was getting fewer and fewer calls on the system, and more important, the folks calling in seemed to have no hope at all of getting a loan. Kennedy asked the loan officer what the approval rate was on this system; it turned out to be just 10 percent. Kennedy then created a spreadsheet based on internal costs, and it turned out the IVR system cost the bank around $150 per successful loan, a much higher cost than the other methods the bank used. Naturally, 20 minutes after this spreadsheet was created, the death warrant was signed (see chart "A Compelling Argument for Decommission").

Geek Skills

Lest you think that we're discounting your hard-won IT skills, let us assure you that pure-geek--such as infrastructure sizing--absolutely do matter, both from a dollar standpoint and a business credibility standpoint.Consider these cautionary tales from reader Steve Ruger, an independent project manager in North Carolina. One client, a large computer-chip manufacturer, was replacing its ERP (enterprise resource planning) system, and the first round of infrastructure sizing--done after the budget was prepared--indicated that the original $22 million budget needed to be closer to $30 million.

"As I walked in there, the CIO's career was flashing before his eyes," Ruger says. "He was going to have to ask for an additional $8 million." Fortunately, after going through the vendor's sizing algorithms, which didn't take into account usage patterns, Ruger was able to determine that the sizing for the network was more like $21.5 million. Lesson: Get input on sizing from more than one source.

Ruger also saw a horror show at an international train manufacturer, where data load was calculated on a small system and then predicted in a linear fashion on the huge production system. The team couldn't do a system conversion simply because "that big of a slug of data across at one time would take a week, and we couldn't shut down both systems for a week," according to Ruger. It ended up taking the team a month to do a parallel conversion.

Lesson: To successfully create a project budget, be careful how you measure needs. Don't think of scalability as being necessarily linear. And by all means, be reasonably sure of your sizing before creating the budget.

But what do you do about infrastructure upgrades--you know, the stuff that no one department owns and doesn't have a definite return, but that you believe would make a big difference for the entire company?

Unfortunately, unless your company is flush with cash, the only responsible thing to do is not upgrade unless you can identify a business benefit. There is, after all, a fine line between a benefit and a rationalization.We spoke to managers who got upgrades funded through special improvement projects, but others told us they've seen CIOs build slush funds for out-of-budget items, simply because projects that don't have an immediate and direct payoff don't get funded.

"From an accounting and stockholder point of view, it's bad," says project manager Fuhrman, "because that CIO is tying up resources in the slush fund that might have gone to another part of the company and gotten a real return on its investment." On the other hand, if you're in a pure ROI mode--that is, the company won't sponsor anything without a definite payback, "you won't get those projects done," he says. Obviously, that's bad, too.

Don't yield to the temptation to put forth fuzzy numbers--doing so will damage your credibility. Good managers will listen to benefit studies, even if there is no immediate and direct payoff. Simply indicate the potential long-term or indirect payoff, cost avoidance or time savings you'd feel comfortable explaining to someone while looking them in the eye.

Again, top management is used to listening to--and funding--projects that don't necessarily have 100 percent payoff potential. Just look at any advertising campaign, the opening of a new branch office and staff expansions. Legislative mandates, such as Graham-Leach-Bliley (for financial privacy), the Patriot Act (which affects intelligence-information gathering) and HIPAA (Health Insurance Portability and Accountability Act), might turn into a repeat of Y2K's "kid in a candy store" days, but be careful: The economy isn't what it used to be, and more top managers are becoming IT savvy. Whatever the initiative, the key is to be disciplined in how you present your case.

Even in a legislative environment that places many mandates on the banking industry, Ron Trent, vice president of network services and chief information security manager for Hudson United Bank, still must carefully justify his upgrades. With 2,500 desktops, 290 servers, 215 remote offices and an IT staff of 13, Trent says he relies on a cookie-cutter approach to keep levels of service and security high.This need for standardization is part of what's pushing Hudson United's desktop upgrades in the next 12 months. As vendors supply fixes and updates, "more and more of the departmental applications aren't supported on Windows 95, like our AP and loan-approval applications," he says. "We're forced to move to Windows 98 at the very least for that department. Little by little we end up with a hodgepodge of different areas with different platforms."

In a case like this, an IT manager faces with a difficult decision: Hire more staff to deal with the increased complexity of support workload, which is an ongoing expense, or make the case for standardization. From the perspective of a very small staff supporting a large network, Trent thinks they've made the correct decision. Some managers try to compare the variable and ongoing costs of hiring more staff to the fixed cost of the upgrades, but be careful: When you compare costs, you assume that you have the choice of hiring more staff. Obviously, that's not always true, and if you make that assumption, you may get snickered at (or worse). In this case, it might be better to simply focus on quality of service.

Death by Committee

If you do not manage your IT dollars well, expect them to be managed for you; that's the dysfunctional management trend that's been surfacing at some large companies. By way of warning, we relate what an insider at one large New York-based investment bank tells us about a new process where IT requests must make their way through two virtual "gates," or committees.

The committees make decisions about whether the request is "strategic" and gets funded or "non-strategic" and doesn't get funded."Right now," says our source, "there's a lot of money going into Microsoft Project, and reams of paper, PowerPoint presentations and very expensive people working on this." To fund the initiative, IT dollars have been taken away from basic needs, such as coding and system administration, and long-term IT employees have been let go in favor of consultants who will ostensibly heal the funding pain.

The problem with working on a purely strategic, consulting-oriented plane (the "36,000-foot view," as the consultant buzzword has it) is that it's hard to get things done when resources are taken away from tactical areas. As our source says, "You've got to eventually land the plane and get it done without resources and without good people."

Worse, "Users can make requests, but if it's not deemed strategic, it's deemed contract outside of IT's duties. Then the users feel they're getting ignored." And when users feel ignored, that's the first step in an IT department's death spiral because, ultimately, IT is about business, and business is about making profits, and profits don't ever happen without filling the needs of real people.

Jonathan Feldman is chief technical manager of the Chatham County Government in Savannah, Ga., and a Network Computing contributing editor. Write to him at [email protected].

Post a comment or question on this story.It's a brave new world for IT. While your expertise is as critical as ever, technology for its own sake won't fly. You need to incorporate business considerations and be as comfortable with concepts behind ROI and TCO as you are with those of VoIP and HBA.At least, that's the case with the IT managers we interviewed for this special report.

Building a business case involves fostering business credibility, some skill with numbers, and a hefty dose of judgment and flexibility. In "Lessons From The Field: Beyond ROI" we tell you how to put these elements together to get your initiatives off the ground. As one manager points out, "There is no silver bullet. If there were, we could teach a monkey to do it."

"Projects That Defy ROI," looks at your safety nets--IDSs, hot backups, firewalls--and projects that provide unquantifiable but vital benefits, such as customer satisfaction. Don't be one of those companies that, in the words of Phil Mogavero, CEO of Data Systems Worldwide, become interested in intrusion detection only after their systems are compromised.

Finally, in "Technology ROI: The Siemens Formula," Klaus Stegemann, Siemens Corp.'s CFO, offers insight and examples of how his company evaluates IT projects. Bottom line, he says, the need must drive the technology.

Users and experts we interviewed cited these as top reasons that IT managers end up in the doghouse with top management. Avoid these and you'll have a lead on business credibility.

We hate it when IT managers and staffers:• Don't go out of their way to understand the business side of their companies.

• Don't communicate clearly.

• Talk 'geek speak' at management meetings, thus guaranteeing that they will always be viewed as outsiders.

• Justify projects based on cost savings associated with replacing a system but fail to decommission the old system.

• Get too friendly--or not friendly enough--with end users.• Take sides in political wars.

• Advocate the sexiest technology over the best solution to a business problem.

• Ignore the rudiments of accounting, purchasing, accounts receivable and accounts payable.

• Call 'them' the Bean Counters. Only in BOFH-land can you get away with not playing by 'their' rules.

• Tell users that a technology will be nirvana, only to be confronted by the grim technical reality--and the lousy job of having to readjust user expectations.