Managing for benefits in information technology projects

by Jolyon E. Hallows

LAST MONTH IN “The Fourth Dimension: Justifying Information Technology Projects,” I made the case that information technology projects need to focus on the delivery of benefits in addition to the traditional triad of budget, schedule, and scope. This month, I'll discuss why understanding benefits is important for IT project managers and how they can focus on delivering benefits in managing their projects.

It's tempting to say that benefits are a business decision, best left to the corporate line managers who sponsor projects. If, for example, a sales director funds the development of a sales information system, it is surely up to that executive to ensure that the sales people use it and that it provides the benefits that prompted the company to spend money on it. The project manager's job is to plan and execute the project so that it finishes on time, on budget, and in scope. Whether or not the sales director actually uses it is beyond the project manager's purview—isn't it?


There's a subtle difference here between realizing benefits and providing the means by which benefits can be realized. The project manager cannot be faulted if the sales director, for unfathomable reasons, consigns the project efforts to a dusty shelf. However, it is unquestionably the project manager's job to provide a product that is capable of producing benefits. For that, the project manager must understand what those benefits are and must be satisfied that they are achievable.

There are two primary reasons that project managers should insist on a clear benefits statement: to advise management on the disposition of the project, and to manage the project for benefits.

Advising Management. In the ideal world, a project is approved, a team is appointed, and the project happily proceeds to its conclusion. Unfortunately, in the real world, the rationale for a project is continually under attack. Opponents of the project find common cause with supporters of alternative projects, budgets are reviewed and cut, and project enthusiasts are transferred, promoted, or fired out of the positions from which they could defend the project. A project is rarely killed outright. It dies a slow death from resource starvation when its opponents succeed in relegating it to the lowest priority in the organization. The best defense against an attack on a project is its justification. It is hard for the most virulent opponent to muster support to kill a project that will return its costs in a brief period of time. A project manager who understands the justification of a project is far better positioned to defend it against cuts or outright cancellation than one who regards benefits as a business matter that is of no concern.

During the execution of a project, a project manager should assess whether or not the justification still exists. During most projects, the costs usually increase and the benefits usually decline. There may come a point at which the project is no longer justified. When this happens, the project manager needs to report to management that the costs of continuing with the project now outweigh the benefits, and recommend that the project be cancelled. It is not in the company's best interests to continue spending money when the benefits no longer exceed the costs.

However, for psychological as well as professional reasons, this is a difficult recommendation to make. Killing a project never looks good, even if doing so is for the good of the organization—which is one of the reasons that so many IT projects stumble along, consuming resources and careers, long after they should have been terminated. Those project managers who have not bothered to fully understand the justification and all of the benefits that the client expects will not even be aware when the point of “nonjustification” has been reached and will certainly not be able to alert management that the justification for the project has evaporated.

Managing for Benefits. Managing a project for benefits means that, in the execution of the project, the project manager will take specific actions to improve the probability that the benefits will be realized. There are three such types of action: technical decisions, scope changes, and implementation planning.

Technical Decisions. ABC Company started a project to support its outside sales people by providing them with notebook computers and Internet access to corporate databases. The project was justified by a targeted 3 percent increase in sales to new customers. During the project, the technical team identified two competing technical approaches. With the first, the sales representatives would log onto the corporate system and interrogate the databases online. With the second, they would download a subset of the data into their computers and review it afterward. Both approaches were valid. Both were of about the same technical complexity. There were arguments for either alternative. Which approach should the designers take?

In most projects, technical decisions tend to be the alternatives preferred by the de facto technical leader of the team—usually the person with the loudest voice or most uncompromising attitude. However, when a project is managed for benefits, all technical decisions are based on their ability to contribute to the realization of benefits. That is, each technical alternative is assessed according to the extent to which it will enhance the probability that the benefits will be realized.

ABC's project manager, who was managing for benefits and was therefore not prepared to leave the decision to the team, presented the alternatives to some sales people and solicited their opinions. Typical of the comments was that of the East Coast sales supervisor who said, “I want No. 2. I'd far rather let the machine do the downloading while I'm off schmoozing with my clients and then let me look up whatever information I need when I need it.” The feedback from the sales people was that the second alternative, downloading data, would provide a higher probability that the benefit of increased sales would be realized. The decision was made. Irrespective of the technical merits of either alternative, data would be downloaded.

Of course, not all technical decisions are equally clear. There will be occasions when the users cannot agree and secondary factors will have to influence the decision. But the point is that technical decisions must be reviewed for their impact on benefits. Otherwise, there is a risk that the project will produce a product that has severe impediments to realizing benefits.

Scope Changes. Three months into the ABC Company's project, the customer service manager responsible for inside sales approached the project manager to request that the system be designed for use by the inside sales force. The argument was simple: The inside sales people needed the same information as the outside sales people, the new system provided that information, the modifications to the system to provide access would be minimal, therefore it “made good sense” to modify the system to include the inside sales staff.

This kind of request is common in IT projects. Because there is considerable overlap in business functionality and operational responsibilities, it is sometimes hard to draw a precise line that limits a system. Yet the line must be drawn or the system will never be finished. One of the most powerful approaches for evaluating requests to expand the scope is to appeal to the original project justification.

The project manager consulted the Project Charter, in which the justification was clearly stated. The principal benefit from this project was to be an increase in sales to new customers. With some questioning, the project manager determined that the inside sales force did not develop new customers. On the rare occasions that one of them received a call from a potential customer, the call was referred to an outside sales rep. It was clear that expanding the project to include the inside sales force would not contribute in any way to the stated benefits of the project. The project manager therefore recommended against the scope change. If the customer service manager could prepare a cost/benefit analysis showing that modifying the system for the inside sales force was justified, the ABC Company would consider starting a new project, but the existing project would not be modified.

This example illustrates a common misconception about scope changes. Some people feel that if a scope change is justified, it can be accepted. However, almost all scope changes are justified; very few project managers or steering committees will accept scope changes that have no benefits. Hence, justification is not an adequate reason to accept a scope change. The real evaluation of a scope change request is whether or not it contributes to the original benefits of the project. That is, does it increase those benefits or increase the probability that they will be realized. If not, it must be rejected, no matter how beneficial it may be. If it has its own valid benefits, it can become a separate project, but it cannot serve as a scope change.

Implementation Planning. Systems development projects include (or should include) an implementation plan. This is a document that describes how the system will be released within the company. It deals with issues such as parallel testing, pilot testing, user training, handoffs to the support groups, and phasing out of systems that are to be replaced. The plan normally includes a schedule and a list of people and equipment needed.

The implementation plan for the ABC Company project was a standard type of plan. It dealt with all of these topics, as well as the acquisition of notebook computers and establishing Internet access for the sales staff. However, because the project manager was managing for benefits, the plan also, atypically, included a section on benefit realization. This section consisted of a subsection for each benefit and a plan for achieving that benefit.

The main subsection dealt with the plan to increase the number of customers. It was written by the sales director who, for this activity, was part of the project team, with responsibility to the project manager for delivering the plan. The plan described in detail how the sales staff would use various components of the system to identify prospective customers, to qualify them, to present to them, and to close. Most important, the plan identified specific actions and assigned people and dates to each one. The sales director accepted personal responsibility to ensure that the plan was executed.

Each of the other benefits was similarly planned by one of ABC's line managers, each of whom committed to execute his or her plan. The project manager reviewed all plans before they were added to the implementation plan, ensuring that the plans were capable of being executed and that they all had one vital activity in common: After each plan was executed, the respective managers would report the results to the sales director. The sales director would compile the results, determine the overall benefit to ABC, and present the final numbers to the Executive Committee. This final step ensured that the project benefits would now be disclosed to the company, enabling its management to judge the effectiveness of the project and the performance of its staff in using the new system.

Reader Service Number 5029

ONE OF THE EMERGING THEMES in IT is a critical—sometimes jaundiced—view of the value that IT brings to an organization. Management commonly questions the benefits they are getting for the millions of dollars they invest in IT. One of the reasons that managers are not clear on the benefits is that nobody is clear. Where projects are not properly justified or are not managed for benefits, any improvements that result from a project are lost. Suppose that the ABC project manager had simply released the system to the sales director and not provided for a post-implementation benefits review. If the sales had actually increased, all the credit would have gone to the Sales Department. Then, once the members of the Executive Committee had finished handing out praise to the sales director, they would have turned to the CIO and asked, “What have you done for us lately?” By insisting on a proper benefits statement and by managing for benefits, the IT Department ensured not only that the benefits would be realized but also that its contribution to the health of the company would be visible.

By insisting on a proper benefits statement and by managing for benefits, IT departments and project managers can ensure that their efforts bring real value to their organizations. ■

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 consulting company, Westwind Consulting Services, provides project management services including project reviews, establishing project management methodologies, and training project managers.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI.

PM Network • December 1998



Related Content