WCS logo

Your Source for Project Management Training

Home Page | Course Overview | Partnering with Westwind | FAQ | Testimonials | Free Project Process Charts
Some Articles we have Written | The Project Management Guide | Our Books | How to Contact Us | Our Corporate Profile


Project Management Articles

The Fourth Dimension: Justifying Information Technology Projects

If you ask a room full of project managers what constitutes a successful project, the overwhelming answer will 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 (IT) 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 in most of the rest, are painfully aware 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 fourteen IT project management books, thirteen had no index entries for “benefit,” “cost benefit analysis,” or “justification.” The reference in the fourteenth 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.

In this article, I will define the characteristics of a usable statement of benefits. In a subsequent article, I will describe the process of managing an IT project to ensure that benefits are met.

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

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 non-financial “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 non-financial 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 that is 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 non-financial “benefit” is improved customer service. But why would any organization want go to the expense and effort of improving customer service? The obvious answer is to increase (or at worst, to protect) sales revenues. But where a benefit is identified by such an obtuse 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 five percent and sales to new customers will increase by two percent.” Given the current annual sales, the benefit from the project is easily calculated.

However, this type of justification only applies 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 non-financial 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 company-wide groupware system. Such projects are usually “justified” by arguing that the company needs to “enter the twenty-first 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%.” 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% 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 ten 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 ten people. There are several reasons that this may not be possible:

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, saving. 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 longstanding 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 thirty 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 is not common and certainly not 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. (Contrary to some opinions, user-friendliness is not simply a matter of wrapping a windows-like interface around a poorly constructed design.)

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 re-work. But how much will productivity be increased? How much will re-work 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, as recommended above, 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 five hundred dollars per person per year and to increase transaction throughput by ten percent. In addition, we intend to reduce re-work costs by twenty 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.

But 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? That is the topic for the next article.

Project Management Institute, PM Network® Magazine, Project Management Institute Inc., (1998). Copyright and all rights reserved. Material from this publication has been reproduced with the permission of PMI.

 

Back to Articles | Return to top | Return to Home Page