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

Managing for Benefits in Information Technology Projects

In a previous article [the one that precedes this one], I stated that information technology (IT) projects need to focus on the delivery of benefits in addition to the traditional triad of budget, schedule, and scope. I also discussed the characteristics of a proper benefits statement. In this article, I will discuss why understanding benefits is important for IT project managers and how they can focus on delivering benefits in managing their projects.

It is 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 requests and 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.

There is a subtle difference here between realizing benefits and providing the means by which benefits can be realized. It is not the project manager’s job to deliver benefits. Unless the organization is willing to make him or her the sales director or inventory manager or human resources manager or whatever functional role is needed to implement a new system, that implementation is the sole responsibility of the line manager in whose department the system falls. 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. (It should be noted that 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.

It is also necessary, during the execution of a project, to 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 it 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 “non-justification” 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 three 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 on-line. With the second, they would download a subset of the data into their computers and review it afterwards. 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. (This does not have to be the most senior technical person. Leadership usually devolves to 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 number two. 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 manger 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 sub-section for each benefit and a plan for achieving that benefit.

The main sub-section 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. One of the emerging themes in IT is a critical, sometimes jaundiced view of the value that IT brings to an organization. It is common to hear management question the benefits they are getting for the millions of dollars they are investing 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. For example, 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.

Too many IT projects are executed without proper benefits and too many of those that are justified lack a means to measure whether or not they actually produced results. 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.

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