The fourth dimension

justifying information technology projects


On time, on budget, within scope? Your IT project still hasn't succeeded unless you can quantify the benefits to the organization on the bottom line.

by Jolyon E. Hallows

IF YOU ASKED a room full of project managers what constitutes a successful project, the overwhelming answer would be “on time, on budget, in scope.” Meet these three measures and your project is successful, miss even one and it's not. For most project management practice areas, these criteria define success. However, for information technology projects, there is another standard that is almost universally overlooked: the realization of benefits.

Organizations engage in IT projects because they expect to receive a benefit. If the benefit is not achieved, the money spent in financing the project is wasted. Yet at the conclusion of many IT projects, organizations cannot tell whether or not they realized their benefits and are painfully aware in most of the rest that they did not.


However, the failure to achieve benefits does not deter IT project staff from proclaiming a project a success irrespective of whether or not the sponsoring organization got what it paid for. “On time, on budget, in scope” is all that counts. Furthermore, this attitude of indifference to benefits is fostered by the project management literature. In a recent survey that I conducted of 14 IT project management books, 13 had no index entries for “benefit,” “cost/benefit analysis,” or “justification.” The reference in the 14th was trivial, simply averring that projects should be justified. I contend that this reflects a massive delusion shared by IT project managers and shaped by an unswerving drive toward the traditional triad of budget, schedule, and scope. This delusion is understandable; “IT project” and “overrun” have come to be synonymous. There is enormous pressure to get projects on track. Nevertheless, any effort that does not focus on delivering benefits and value to the sponsoring organization is doing only half a job.

The problem with IT project justification is not that the process is ignored, but that it is not well understood. While most projects pay lip service to justification, it is common to find “benefits” that cannot be achieved side by side with a standard list of “intangible benefits,” such as “The system will be user friendly.” In my experience, most statements of project justification ignore four fundamental requirements: benefits must be financial; benefits should be stated as goals, not predictions; benefits are different from effects; and benefits cannot be intangible.

Benefits Must Be Financial. The only valid benefit to an IT project is its impact on the organization's finances: The project will either increase revenues or reduce costs. Nothing else counts. Any “benefit” that is not financial cannot be compared to the project costs, cannot participate in a cost/benefit analysis, and cannot, therefore, be used to justify the project. Furthermore, most nonfinancial “benefits” are not measurable, meaning that there is no way to tell whether or not the project actually delivered the expected results.

This point of view is not widely held; there are several nonfinancial sources of benefit that are routinely offered. One of the more popular ones is necessity. For example, the government may introduce new legislation requiring a change to a company's systems, or a major customer may switch to electronic data interchange and insist that its suppliers do likewise. In such cases, there is no choice; the company complies or shuts down. But this is the ultimate financial benefit:You get to keep your business. That such a benefit is easy to identify does not diminish the need to do so. The company may find, for example, that it is more cost-effective to shut down the part of its operations affected by the new demand and focus its energies elsewhere, but without a cost/benefit analysis, such an option will be swamped by the knee-jerk response to comply.

Another popular nonfinancial “benefit” is improved customer service. But why would any organization want to go to the expense and effort of improving customer service? The obvious answer is to increase (or to protect) sales revenues. But where a benefit is identified by such an ambiguous term as “customer service,” not only can it not be used in a cost/benefit analysis, nobody will ever know if it has been achieved. Improving customer service may be a powerful motivator for a project, but it needs to be restated as, for example, “Sales to existing customers will increase by 5 percent and sales to new customers will increase by 2 percent.” Given the current annual sales, the benefit from the project is easily calculated.

However, this type of justification applies only to commercial organizations. How does a government department quantify the effect of improved customer service? It cannot use increased revenues—a Department of Motor Vehicles cannot expect to attract more customers for its drivers' licenses by shortening its queues or pasting smiles on the faces of its staff. Unless the improvement to customer service leads to increased operational efficiencies, the “benefit” of improved customer service is financially empty. Does this mean that governments cannot justify improving service to their constituents? Not unless there will be reduced costs or the project is required to deliver a mandated service. Government departments that initiate IT projects because their staff's (usually legitimate) concerns over service delivery ignore fiscal responsibility are unfortunate contributors to the massive deficits that characterize many public sector agencies.

The third widely used nonfinancial benefit is the corporate infrastructure project. For example, a company decides that it must link its staff by a set of corporate databases and a companywIde groupware system. Such projects are usually “justified” by arguing that the company needs to “enter the twentieth century,” “adopt state-of-the-art tools,” and “realize the full benefits of modern information technology.” Failure to do so will condemn the company to be marginalized in some technological purgatory.

There is no doubt that providing better tools improves work efficiency or quality, and sometimes both. The point is not that such projects are intrinsically worthless, but that, like any other major expenditure, they need to be properly justified. The real benefits of justified infrastructure projects are increases to efficiency and quality, which lead, respectively, to lower costs and higher sales. The fact that it is hard to put precise dollar figures on these benefits does not obviate the need to do so. Otherwise, the organization, in assessing whether or not to proceed, will not know if the benefits outweigh the costs.

Benefits Are Goals, Not Predictions. One of the disincentives to stating benefits is that they are normally treated as predictions. “If we can implement this inventory control system, our stock levels will be reduced by 15 percent.” The trouble is that predictions are passive; if the fates are kind, good things will happen. There is little we can do to influence the outcome.

However, if benefits are regarded as goals, the attitude toward them is reversed. Most businesses set goals and understand the steps of working to achieve them. Hence, a goal statement for a project might be, “When we implement this inventory system, we intend to reduce our stock levels by 15 percent in the first year of operation.” The difference between this statement and the prediction in the preceding paragraph may seem semantic, but the attitudes behind them are poles apart. A goal is actionable, requiring an approach, a plan, checkpoints, and a commitment to execution.

IT project benefits that are expressed as goals are properly part of the project's implementation plan. That plan typically addresses such issues as training, pilot and parallel testing, rollout, and phasing out of existing systems. For projects that are properly justified, it should also list all the benefits identified at the start of the project and present a plan to realize them. In this way, the IT project manager is not simply a courier, handing over a new or enhanced system, he or she is providing a procedure to help the organization realize the benefits it expected when it started the project. The project manager is an active contributor of value to the company.

Benefits Are Not Effects. One of the most popular sources of apparent benefit is savings in employment costs through layoffs, enabled by the conversion to a new technology. For example, if this $500,000 system will reduce workloads by the equivalent of 10 clerical staff, each of whom costs us $50,000 per year in salary and benefits, we will save $500,000 in the first year alone. A payback period of just one year is compelling. But is it realistic?

In order to actually save $500,000, we will have to dismiss 10 people. This may not be possible for several reasons:

The appropriate people are protected by union contracts. Getting rid of them will be extremely expensive. If buyouts will cost an average of one year's salary per employee, the total costs increase to a million dollars and the payback period doubles.

Reader Service Number 5147

The company was founded on a policy of employment protection. If an employee's job is eliminated, the company has committed to find that person another job within the company. Hence the payroll cannot actually be reduced.

The employees in the affected department are specialists and, while the workload of each will be reduced, the company cannot afford to lose the skills of any of them.

The savings in workload does add up to a total of 10 people, but they are distributed over 100 people in such a way that no one person (or two or 10) among that 100 ends up with no work to perform.

In this example, the savings in workload are effects. Reducing someone's workload by an hour a day is an effect, but it has no financial impact on the organization. In order to be a benefit, there must be a real dollar savings. Too many project justifications are based on effects, not benefits.

The acid test that distinguishes an effect from a benefit is the question, “How will this result save (or earn) money?” This question makes it clear that reducing workloads, to continue with the illustration, does not in itself save money; some other actions need to be taken. For example, the reduced workload may mean more time for people to complete assignments, resulting in increased quality and ultimately in higher sales. Or the reduced workload may make it possible to free up resources to improve internal processes or assist sales or solve long-standing irritations, all of which may be quantifiable in dollar terms. And of course, it may be possible to reduce staff and realize cost reductions. (In over 30 years of IT experience, I have never seen a project actually result in layoffs. That's not to say it never happens, only that it's neither common nor easy.) The point is that an effect does not directly result in financial benefits, but it may enable them through other means.

Benefits Cannot Be Intangible. One common theme in IT project justification is an inevitable list of “intangible benefits,” replete with catch phrases such as “state-of-the-art,” “flexible,” and, of course, “user friendly.” The only problem is that there is no such thing as an intangible benefit. A benefit is real, tangible. Anything else is a collection of buzzwords designed to sell what is probably a marginally justified project. Projects that deliver real benefits do not need a list of intangibles.

One of the real ironies behind the focus on intangible benefits is that many of them do produce tangible results. For example, consider “user friendly.” I will define this as a system characteristic in which the correct response to a screen state is more intuitively obvious to an average, untrained user than any possible incorrect one.

Does user-friendliness, by my definition, lead to benefits? Of course. To identify just three, it reduces the need for users to consult documentation, thereby increasing productivity; it reduces training time and with it lost production while staff are in classes; and it reduces the rate of errors and the need for subsequent rework. But how much will productivity be increased? How much will rework diminish? These benefits are hard to quantify and, in some cases, even to measure, so writers of business cases take the easy way out and label them as “intangible” when what they really mean is, “We couldn't be bothered trying to quantify this.”

However, quantifying such benefits is not difficult if they are treated as goals and not as predictions. Now it becomes reasonable to say, “Because of the intuitive nature of the system, we intend to reduce the training budget by $500 per person per year and to increase transaction throughput by 10 percent. In addition, we intend to reduce rework costs by 20 percent.” Of course, the numbers in this example are for illustration only and presumably would be supported by some level of analysis in a real case, but the point is simply that it is easier to set targets than to predict results. Will you meet the targets? Of course not. You never do. Sometimes you fall short and sometimes you exceed them. But having a quantified target rather than a nebulous wish is the first step to providing real benefits to the organization.

WHY ARE JUSTIFICATION and benefits important to IT project managers? Why not simply focus on the already difficult job of delivering results and let line management worry about the business side? We'll address these questions in a companion article in next month's PM Network (December). ■

Jolyon Hallows is a Certified Management Consultant and project manager. He is the author of Information Systems Project Management (AMACOM, 1998) and teaches courses in project management. His company, Westwind Consulting Services, provides project management services including project reviews, establishing project management methodologies, and training project managers.

PM Network • November 1998



Related Content