Why are We Doing This?

Why are We Doing This?

There is only one valid reason to spend money on a project: It will generate or save more money than it costs. Unfortunately, there is confusion between a project's purpose and its justification. The purpose of a project is a general statement about why the project is being carried out. A purpose statement may be:

The purpose of this project is to create a state-of-the-art, on-line, real-time inventory system that will allow us to manage our inventory more closely while continuing to meet the demands of our customers.

This purpose statement, despite the high-tech buzzwords, is clear: We are going to build a system that will manage inventory. What it does not tell us is whether the project is justified that is, whether it will save or earn more than it will cost.

A justification is an analysis of the costs versus the benefits showing that the benefits are greater. (If the analysis shows that the costs are greater, then it is a justification for scrapping the project, not for proceeding.) A justification describes exactly where the improved savings or revenues will arise.

Many justifications are filled with such vague notions as flexibility, customer service, integration, state-of-the-art, and other motherhood values that remain both unchallenged and undefined. But a true justification has two necessary characteristics: It is dollar quantified, and it is treated as a target or goal.

Justifications Are Dollar Quantified

A justification describes the returns that will accrue from doing a project: the benefit side of a cost-benefit analysis. It must be quantified;

if it is not, nobody will know in the beginning if the project is worthwhile or in the end if it was successful.

Consider the justification, "to increase customer service." This could mean reducing response time to customer inquiries, improving the accuracy or quantity of information available, adding to the services that are offered, or simply smiling at customers. Without more detail, nobody will understand what is expected.

Furthermore, if the justification is not quantified, then any improvement, however slight, in any area affecting customers will allow the company to claim that service has been increased. For example, if the system reduces an average two-minute customer waiting time by five seconds, service has been improved, but few companies would expend effort to achieve such a trivial result, and, more important, no customers will notice.

Justifications are quantified only when they are expressed in terms of dollars (or some other currency). They might involve payroll savings, increased sales, or reduced costs in areas such as inventory or finance charges. However they are expressed, justifications must be quantified so that they can be assessed and projects can be approved based on real financial benefits.

Justifications Are Goals, Not Predictions

Assume that a project is justified by an expected sales increase of 15 percent. When the project is being evaluated, nobody can state with certainty what the increase will be; it can simply be said that one is expected. A 15 percent increase is an estimate, subject to the vagaries of all estimates. Whether or not this figure is realized depends on whether it is treated as a goal or as a prediction.

A prediction is a guess about what will happen; a goal is a target to be achieved. The difference is startling. With a prediction, the outcome of the project is left to the fates, who, the client hopes, will be kind. With a goal, the justification becomes a matter of policy, planned within the overall project. It becomes part of the system implementation plan, enters your purview, and becomes a discrete set of activities rather than an idle hope.

Your job is to ensure that justifications become goals that management accepts the responsibility for achieving.

Intangible Benefits

Justifications for projects usually include a long, predictable list of "intangible benefits." The problem is that there is no such thing; all benefits are realized in terms of costs or revenue. To call a benefit "intangible" simply means that nobody has been ableor has botheredto attach hard numbers to it. For example, consider flexibility. (This word, like most words used to label intangible benefits, lacks a consistent definition. Here, I use it to describe a system that can be easily modified.) With a flexible system, enhancements will take less effort, producing the tangible benefits that maintenance costs will be lower and enhancement requests will be delivered faster. Furthermore, client departments will realize the tangible benefits arising from enhancements sooner. Flexibility is a benefit because it leads to real results. The problem is how to measure what those results will be.

Some will argue that even though certain benefits cannot be quantified, they should still be identified. Indeed they should, but only if they are used to set targets. For example:

The system will be flexible. "We intend to reduce maintenance costs by 15 percent, which will save us $24,000 per year."

The system will be developed with state-of-the-art tools. "We plan to increase development productivity by two function points per work-month, which will save us an average of $100,000 per year in development costs at current levels."

The system will be integrated. "We plan to lever the greater access to customer information into a 5 percent increase in sales, which will boost our revenues by $200,000 per year."

The point of setting targets is to ensure that a real that is, tangible dollar benefit emerges from the flexible, state-of-the-art, or integrated nature of the system.

The best way to quantify an intangible benefit is to ask three questions: "So what?"; "How much?"; and "What does that work out to in dollars?" (Your actual phraseology may not be as blunt, but the intent is the same.) Keep asking these questions until you get an answer with a dollar value in it. Ultimately, the slipperiest  project advocate will be forced into giving numbers, however imprecise, or admitting that none can be stated, in which case the "benefit" has evaporated.

Here's a brief example:

Client:The system will be flexible.

Project Manager:So what?

Client: So we'll be able to modify it more easily.

PM: So what?

Client:Well, that means that our maintenance time will be cut.

PM:How much?

Client: That's hard to quantify.

PM: Make a guess. (How much?)

Client:Well, perhaps by 15 percent.

PM: And what does that work out to in dollars?

Client:Well, we have three maintenance programmers at $60,000 per year. That's $180,000 per year total, so we could probably save about $24,000 each year.

You have just shifted the benefit from an intangible wish to a real target.

If a benefit is incapable of being quantifiedas opposed to having highly uncertain resultsthen it is not a benefit, it carries no implicit target, and it does not belong in any list of justifications.

Beware the Phantom Justification

Consider a project that is justified by a reduced time to process business transactions. The numbers indicate that each of five people will have his or her workloads reduced by an average of an hour a day, which, at a salary (plus benefits) rate of $30 an hour, will save the company $150 per day, or $37,500 per year. Here are just three things that could go wrong with this justification:

1. A reduction of five hours a day is less than one full-time person, which makes it difficult to reduce staff. It is true that because  of the resulting slack time, extra work can be assigned to the people. But the benefit comes from a redistribution of work, not from staff cuts.

2. The people are currently overloaded and have to cut corers. The reduced workload means that they can do a more thorough job, which may lead to improved quality, but not staff cost savings.

3. The people may have specialized skills, which means that they are not interchangeable. Nobody can be cut, and there is no real benefit.

The problem with the apparent cost saving is that it is an effect, not a benefit. Certainly, the five people will each have an extra hour, but that hour does not automatically translate into returns for the company.

An effect differs from a benefit in that it does not directly lead to reduced costs or increased revenue. Reducing the staff time required to perform some task saves nothing unless the payroll is actually reduced. Making customer information more accessible to the sales staff achieves nothing unless the information leads to increased sales. Improving quality is pointless unless sales are increased or service costs are reduced. Effects may lead to benefits, but only benefits constitute justification for the costs of a project.

The best way to smoke out effects is to ask questions until you are satisfied that the "benefit" is real. Here's a simple example:

Client:The staff workload will be cut by five hours per day.

Project Manager:How does that help?

Client:We'll be able to cut our costs.

PM:How?

Client: Uh, good question. We don't have enough of a savings to cut staff.

PM:What else could these people do with their extra time?

Client:Well, right now they complain of being rushed. More time would enable them to do a better job, which could cut rework. If we could reduce that by just 10 percent, it would save us, let's see, over $200,000 per year.

PM:Would the improved quality get you more customers?

Client:Perhaps, but I know that it would improve goodwill among existing customers. There's an intangible benefit!

PM: So what?

By the time this dialogue is over, not only will you have helped the client identify where the real benefits of the system are to be sought, you will have increased the benefits far beyond what could be realized from simply laying off staff.

In reviewing project justifications, ensure that the effects of the system lead to real benefits that are capable of being realized.

Payback Period

Some companies insist on a payback period before they will approve an expenditure. This is the period in which the benefits will fully recover the project costs. Payback periods are easy to compute: divide the project costs, including operations costs, by the annual benefits. Adjust for months, and you will have the number of months required to recover the project costs.

The payback period is a powerful indicator of how desirable a project is. If the costs can be recovered in under a year, few companies will decline to proceed. If it will take four or five years, few will approve the project. Most companies that ask for a payback period in a project proposal have guidelines indicating what periods are acceptable and what are not.

When you are computing a payback period, do not concern yourself with calculating future costs of money unless your company requires it. For most projects, the payback period is short enough that inflation is not a significant factor.

Cost Components

When you review your project's cost-benefit analysis, examine the costs to ensure that they are complete. Many projects have run into trouble because a major item, such as software licenses or consulting fees, was not included in the costs. The costs should also identify operating expenses during the payback period.

PM:Would the improved quality get you more customers?

Client:Perhaps, but I know that it would improve goodwill among existing customers. There's an intangible benefit!

PM: So what?

By the time this dialogue is over, not only will you have helped the client identify where the real benefits of the system are to be sought, you will have increased the benefits far beyond what could be realized from simply laying off staff.

In reviewing project justifications, ensure that the effects of the system lead to real benefits that are capable of being realized.

Payback Period

Some companies insist on a payback period before they will approve an expenditure. This is the period in which the benefits will fully recover the project costs. Payback periods are easy to compute: divide the project costs, including operations costs, by the annual benefits. Adjust for months, and you will have the number of months required to recover the project costs.

The payback period is a powerful indicator of how desirable a project is. If the costs can be recovered in under a year, few companies will decline to proceed. If it will take four or five years, few will approve the project. Most companies that ask for a payback period in a project proposal have guidelines indicating what periods are acceptable and what are not.

When you are computing a payback period, do not concern yourself with calculating future costs of money unless your company requires it. For most projects, the payback period is short enough that inflation is not a significant factor.

Cost Components

When you review your project's cost-benefit analysis, examine the costs to ensure that they are complete. Many projects have run into trouble because a major item, such as software licenses or consulting fees, was not included in the costs. The costs should also identify operating expenses during the payback period.

Exhibit 2.1 is a checklist that identifies costs that your project may include and that should be part of the cost-benefit analysis.

Exhibit 2.1 Potential Cost Components

Systems Development Labor Costs

Labor costs to define system requirements

____

Labor costs to design the system

____

Labor costs to design the system infrastructure, such as network costs

____

Labor costs to code, unit test, integrate, and systems test the system

____

Labor costs for documentation, including training materials

____

Labor costs for project management, including such functions as configuration management, quality control, and support

____

Hardware Costs

Labor costs to scope, configure, and order hardware

____

Capital costs to purchase hardware

____

Labor costs to install hardware

____

Labor costs to maintain hardware

____

Software Costs

Labor costs to scope, configure, and order software

____

Purchase costs for operating systems software

____

Purchase costs for infrastructure software, such as communications, performance enhancement, or performance statistics

____

Purchase costs for applications support software, such as database management, graphical user interface, or ad hoc inquiry and reporting

____

Labor costs to install and configure software

____

Project Execution Costs

Project costs for travel and living

____

Project costs for external consulting

____

(continues)

Exhibit 2.1 (continued)

Project costs for training

____

Project costs for supplies and materials

____

Project Client Costs

Operating costs for staff attendance at training programs

____

Operating costs for user participation on the client project team

____

Operating costs for client involvement in the project

____

Implementation Costs

Operating costs for additional staff effort during implementation

____

Operating costs for travel and living during implementation

____

System Operations Costs

Operating costs for staff labor during the payback period

____

Materials and supplies costs during the payback period

____

Hardware and software maintenance contracts during the payback period

____

Hardware leasing costs during the payback period

____

Projected costs for hardware and software upgrades during the payback period.

____

What If?

The Client Will Not Identify Benefits.

If the client will not identify benefits, you will find it difficult to make project decisions that enhance the project justification and you will find it harder to keep the project in scope.

Actions

Create a "working benefits statement," a set of benefits that arise from your understanding of the project and that seem reasonable to you. This will be your private benefits statement; it will not have the force of a real statement, but it will allow you to act day to day as if benefits were clearly defined.

Define the scope of the project at a much greater level of detail than normal and ensure that a solid scope change mechanism is in place. This should help overcome the difficulty of managing project scope without a clear statement of benefits.

The Client Refuses To Set Benefit Goals or Targets.

If the client defines benefits but will not set targets, you will find it hard to implement the project in such a way that benefits can be realized.

Actions

Calculate the level of benefits that would be needed to justify the project. For example, if the client wants to reduce inventory levels, determine the level of reductions needed to recover the cost of the project.

If the level of benefits is reasonable, propose it to the client as a working set of benefits, to be reviewed and revised when the project is implemented. If it is not reasonablefor example, if the client will need to cut inventory levels by 85 percent-point this out. If the client still wants to proceed, recognize that you will be managing an unjustified project.

If your calculation of benefits levels is reasonable, consider deferring setting the goals until you are planning for implementation on the expectation that as the client becomes more familiar with the project, goal setting will become easier.

The Project is Being Done To Use Up Available Budget or To Make Work.

In this case, the project is justified solely by its ability to spend somebody's budget; it has no inherent justification. However, this does not mean that it cannot deliver value to the organization.

Action

In such projects, there is always an apparent justification. Few companies overtly execute projects without some excuse. Act as described above for the situation in which the purpose of the project is real, but the client will not identify the benefits.

Define the scope of the project at a much greater level of detail than normal and ensure that a solid scope change mechanism is in place. This should help overcome the difficulty of managing project scope without a clear statement of benefits.

The Client Refuses To Set Benefit Goals or Targets.

If the client defines benefits but will not set targets, you will find it hard to implement the project in such a way that benefits can be realized.

Actions

Calculate the level of benefits that would be needed to justify the project. For example, if the client wants to reduce inventory levels, determine the level of reductions needed to recover the cost of the project.

If the level of benefits is reasonable, propose it to the client as a working set of benefits, to be reviewed and revised when the project is implemented. If it is not reasonablefor example, if the client will need to cut inventory levels by 85 percent-point this out. If the client still wants to proceed, recognize that you will be managing an unjustified project.

If your calculation of benefits levels is reasonable, consider deferring setting the goals until you are planning for implementation on the expectation that as the client becomes more familiar with the project, goal setting will become easier.

The Project is Being Done To Use Up Available Budget or To Make Work.

In this case, the project is justified solely by its ability to spend somebody's budget; it has no inherent justification. However, this does not mean that it cannot deliver value to the organization.

Action

In such projects, there is always an apparent justification. Few companies overtly execute projects without some excuse. Act as described above for the situation in which the purpose of the project is real, but the client will not identify the benefits.

The Client Takes The Position That Justification is a Business Issue Outside Your Mandate.

The most obvious consequence is that you will not have a justification to work with on the project. However, there is a more serious issue: your role. In order to manage the project, you will need to be actively concerned with its business aspects, not just from the point of view of functionality but in terms of its context within the client organization. If you are to be blocked from anything beyond the narrow scope of the project, your ability to deliver real value will be seriously compromised.

Actions

Attempt to educate the client on your role. In particular, point out that your job is to deliver value to the organization and that that job is more than meeting a schedule. If possible, think of examples, such as the project in which you recommended a major shift in direction because of your understanding of the project context and created a more valuable product as a result.

Inform your client why you need to understand the justification. Describe its role in managing scope and in helping to reach day-to-day decisions.

If these attempts fail, escalate this as an issue to your management (see ''Notification and Escalation" in Chapter 3). Make it clear that this client's attitudes are hindering your ability to succeed.