IS managers need to put a price tag on productivity

IS managers need to put a price tag on productivity

Billions are spent on technology each year and no-one knows why. If you ask IS professionals why they're installing systems at the cost of tens of thousands of dollars, half of the time they'll tell you that the company needs to move either to object-oriented programming or to a three-tier architecture. Not surprisingly, within the past five years the top office in many IS departments has become a revolving door as corporations try to remedy the situation. Resellers dealing with corporate customers are, as a result, finding themselves caught up in this dilemma as well.

Economists have suggested many explanations for the lack of correlation between investment in IT and improvements in productivity: companies haven't figured out how to make the organisational adjustments necessary to reap the benefits of technology; technology is changing too fast to give a payoff; or benefits exist but are difficult to measure. Whether you contribute to the productivity of the company or sap its resources has a lot to do with doing an effective cost-benefit analysis before undertaking a project. Everyone has heard about new systems that were years late, millions of dollars over budget and didn't help the business meet its goals. Even an informal cost-benefit analysis can help you avoid such failures. Successful projects will win you accolades from users and the trust of management. Taking the right approach can also make your job easier.

The most important thing is to prioritise projects in a valid manner. To put it simply, you should look for projects that will make your organisation more money while costing relatively little to implement. To do this, you must also accurately predict the cost of a project as well as its potential rewards. Although that may sound obvious, in practice it is often difficult; it is becoming even more so as companies attempt to re-engineer projects that involve changing business processes and technology at the same time.

First of all, the business side of the house - not IT - should decide which projects are most important based on the benefits that they will give the company and how much they will cost. Estimating the cost and communicating that information to the rest of the company is the job of the IT department.

Mastering the basics

If you do it a different way, the company can wind up making large investments in projects that aren't that important. By letting users know how much features will cost, you can weed out unimportant projects and put a brake on unreasonable demands and escalating costs in your department. You may even get a bigger budget because suddenly costs will be tied to what the business leaders want to accomplish rather than some arbitrary yearly percentage of revenue. One large US telecommunications company follows this model and frequently modifies user requests after a cost analysis is done, says a network analyst at the company.

"It's always the last 10 per cent that's most expensive," he says, explaining that users often opt for less performance or reliability after they are quoted the price of perfection.

When estimating the cost of a proposed project, you should include one-time charges, such as the initial cost of buying hardware and software, as well as life-cycle cost, such as training and maintenance.

What exactly you include will vary according to the project. Life-cycle costs may include upgrades, support, staffing, telecommunications, and facility costs, for example. If you are planning to hire consultants or outsource part of the project, make sure you include that in your estimates.

Typically, companies underestimate the cost of training and converting to new ways of working, according to Lee Sproull and Sara Kiesler in their book Connections: New Ways of Working in the Networked Organization. To figure out the cost of training, you might include the cost of classes, manuals, more classes for people who later join the company, and the loss of productive work time.

Other subtle costs of technology include the disruption to the business process of prototyping, and higher wages or the increased staff required to support more sophisticated technology, says Ken Knight, consultant and author of Investing in Information Technology.

A handy fact to keep in mind is that studies have shown that hardware accounts for only one-third to one-fifth of technology costs. The rest is spent on software, maintenance, support, training, and so on. Use what historical data you have, such as how much you have spent on the help desk in the past, to help estimate costs.

And if you are comparing the price of keeping an existing system vs moving to a new one, be sure to include estimates of maintenance and future upgrades for both. In particular, don't forget to include the cost of rewriting old systems to deal with 2000, says Lockheed Martin CIO, Joan Cox.

Be as comprehensive as possible in your estimates. Failure to include the costs of hiring outsiders in the analysis or wildly inaccurate estimates have destroyed many projects, experts say. This is a danger particularly when corporations are undertaking large projects with technologies they don't understand well, says Steve Helper, a senior consultant with Hewlett-Packard's professional services organisation.

"What we've witnessed is more failures, because in adopting a new system a company introduced a new way of developing software such as SAP or PowerBuilder," says Ko Suzuki, vice-president of IT practice for SRI Consulting, a research and development organisation that is part of SRI International. Many companies will buy an outside service to make up for their lack of experience with a particular technology, and the cost of the service becomes much greater than they anticipated.

"Instead of assuming $US2 million in software development, they spend double," Suzuki says. "Then maintenance costs of the software two to three years down the line should be cheaper, but on the contrary, they increase as well, because they are relying on an outsider that may charge twice the price of an insider. And they expect to finish in six months and it takes one year. I've seen overruns of maybe 300 per cent."

The good part: benefits

There really are only a few types of benefits or reasons to undertake a project: cost cutting, cost avoidance, revenue maintenance, revenue enhancement, entering a new market, and gaining market share. The business value of improving customer service, for example, might be to keep a company from slipping in the market or to help it gain more market share. Many of these are "soft" benefits, which are hard to quantify but still important. Market share is particularly difficult to place a value on, for example, unless it's expected to correlate with increased profits. Nonetheless, for the purposes of a cost-benefit analysis, try to quantify benefits as much as possible. Either way, be sure they're listed in the report. What kind of benefits should you expect to see? Many experts say the major value of computers is that they let companies create strategic applications and gain market share while not lower- ing the cost of production or staff via greater efficiency.

"I'm sure you will find few cases where putting in PCs takes people out of an organisation, even though many projects are cost-justified based on head-count reductions," says Tom Thompson, a system architect with Computer Sciences. "Typically people stay but are given new responsibilities. What they are doing is probably different and more valuable than what they were doing before."

If you are installing a system to improve productivity, make sure you focus on cutting time to market - the product-delivery cycle - not on reducing the time it takes to perform individual tasks.

The importance of this point is illustrated in the following example: Computer Sciences replaced the State of Minnesota's sales-tax-processing mainframe system with a client/server setup that slowed the apparent system response time but dramatically improved overall efficiency. Both systems double-checked every registration to make sure a taxpayer wasn't already registered.

On the mainframe, terminals had a one-second response time but the whole search process took 15 to 20 minutes because operators had to search through several screens. On the new system, the whole search process was automated, but users had to wait 30 to 45 seconds for the search query.

"The first time they did this, they said it was terrible," Thompson says. "But we came back and said we had at least doubled or maybe tripled the number of applications they were able to process in a day because of the new system. We got no argument from anybody."

Computer Sciences has developed a methodology to help customers decide what to cut. First examine the technical condition of an existing system, figure out the business value, and then how much money you're spending to support it, Thompson says.

Ask yourself whether the business would stop dead if you eliminated this application or if you hardly used it. If you're spending a lot of your budget and it's giving you marginal business value and it's in poor technical condition, you will want to throw it away or meld it into something else that gives you more value, Thompson says. A thorough review is bound to turn up some unnecessary jobs, he says.

"I don't think there's been an assessment we've done where we haven't found at least two to three applications a company never uses but is still paying to support," Thompson says. "At one company that was changing systems, the only things left on the old system were the little programs nobody knew what to do with or who owned. We found several that were originally meant to be one-time jobs and somehow got into the job stream and were run every week. At another company, they were paying licensing fees to support a product they didn't have anymore."

If you can't find the owner of an application, try turning it off and see if anyone screams.

"Oh, it feels good," Thompson says. "IS doesn't have to support that anymore."

Another pitfall is to estimate the amount of time that a system will save on performing an individual task, add up all of the hours for the year, and conclude that the new technology will save the equivalent of six people's salaries when you have no intention of firing anybody.

At Federal Express the company actually subtracts such dollar amounts from the budgets of the affected business departments to ensure that the company saves the money it planned to, says Winn Stephenson, Federal Express' vice-president of network computing. Of course, the business group will accept such a cut only if it agrees up front that new technology will save it money.

Building infrastructure

More commonly, such improvements allow an individual to spend more time focusing on tasks that are most important to a company. In that case, it's the business benefit of performing those tasks that should be calculated in the analysis, not the money saved from cutting tasks or eliminating a position.

A project rarely can be justified for a technical reason, such as the perceived need to move to object-oriented technology or to a three-tier architecture. Companies shouldn't buy systems because they are faster, but because the old ones are more expensive than the new ones to get the job done.

Routine infrastructure upgrades should not be included as part of a business case, but should be separately planned for out of the regular IT budget. There's always a certain amount of annual upgrade required, and it's become a bigger chunk of the business with the advent of client/server and desktop machines, because hardware now becomes obsolete in three years instead of in 10 years, according to Computer Sciences' Thompson.

This doesn't mean that everyone should get the fastest new hardware or the latest version of every application.

"The speed at which software catches up to hardware causes you to rebuy," says Bruce Stewart, a business-management analyst with Gartner Group. Each business must determine for itself how often it will upgrade software, balancing the cost of purchase, deployment, and training against the cost of supporting various versions and dealing with outdated drivers.

Sometimes a business-case project will require an infrastructure upgrade, in which case it's valid to put that cost in the business case. New hardware may be needed to process larger files, read CD-ROMs, or display information in a certain format, for example.

In the end, which projects should you fund and which should you kill? Knight suggests funding revenue-enhancing projects that return two times the investment within two years.

He gives the green light to cost-avoidance projects that return three times the investment in the same period.

And when the project is over, it's a good idea to evaluate whether the business benefit was achieved and at what cost. It may not be politically popular, but it will help you to avoid future mistakes. And if by some fluke the project was a success, then it won't hurt to have a formal study saying so.

Cost-benefit analysis for dummies

(1) Add up costs, including one-time and life cycle costs (2) Describe or quantify benefits, such as maintaining or increasing revenues (3) Describe or quantify risk of project failure (4) Adjust numbers to account for spending and earning over time (net present value) (5) Fund projects that give a 30 per cent return on investment within two years (6) Eliminate projects with return that's less than what the company could earn by investing the money in securitiesFighting feature creep Changes in user requirements midway through a project can throw budgets and schedules out of whack and, in the worst cases, cause projects to fail. To keep this from happening, do a casual cost-benefit analysis on any proposed changes. (Hint: the shorter and smaller the project, the easier it will be to estimate new costs.) Demonstrate the economic value of the change to the company, compare it to the cost of taking delivery on what was already planned, and add in the change at a subsequent date. This is how a commercial software developer would manage a project, says Bruce Stewart, a business-management analyst at Gartner Group. In the commercial world, changes keep a product competitive in the market, but it's very rare when a project has to be altered in midstream, he says. "But when a challenger like Netscape Navigator comes along, the economic value of adapting can outweigh the cost of the delay," Stewart says.

Federal Express: a case study in IT funding Federal Express puts IT projects into three categories: strategic, required, and return on investment (ROI).

"In 1982, we decided to track all our packages and we had to put a significant investment into technology to do that," says Winn Stephenson, Federal Express' vice-president of network computing, in Memphis.

"It was strategic, because there was no way we could figure out the direct ROI of the project, but it was the way we wanted to market our services. It had to do with how we wanted to grow our business, how we were perceived in the marketplace, and how to give our customers 100 per cent satisfaction - all things that are the hallmark of our service," Stephenson says.

Required projects are things Federal Express must do to stay in business. They include payroll, billing, and anything related to safety or government regulations. The third category of projects, ROI-based investments, goes through a very structured evaluation process and must either capture additional revenue, improve a product in a way that's measurable, or avoid a cost in a way that can be quantified, Stephenson says.

Any project that does not produce a 30 per cent ROI will not get approved. Interestingly, Federal Express doesn't eliminate projects that don't make the cut; it just puts them on the back burner until costs go down.

"A lot of projects are tied to technology costs, and technology costs tend to improve every year," Stephenson says. "We might put a project back on the shelf and bring it out a year later."

Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments