Section 1. The Purpose of the Project

1. The Purpose of the Project

The first section of the template deals with the fundamental reason your client asked you to build a new product. That is, it describes the business problem the client faces and explains how the product is intended solve the problem.

1a. The User Business or Background of the Project Effort

This description focuses on the work the user does, examining why it is not currently functioning as well as desired. There must be some problem or some significant opportunity to improve; otherwise, you would not be asked to develop a new product. The description may be quite brief:

The road authority is unhappy with the number of road accidents caused by ice.

Alternatively, it may more fully describe the operational problem, usually giving the most weight to the most serious problems and the problems that your intended product best addresses.

Roads freeze in winter, and icy conditions cause road accidents that kill people. We need to be able to predict when a road is likely to freeze so our depot can schedule a de-icing truck in time to prevent the road from freezing. We expect a new product will provide more accurate predictions of icy conditions by using thermal maps of the district, road temperatures from weather stations installed in the roads, and the weather forecasts. This will lead to more timely de-icing treatment than at present, which will reduce road accidents. We also want to eliminate indiscriminate treatment of roads, which wastes de-icing compounds and causes environmental damage.

Give references to any material that supports your statement. Any problem that is serious enough to warrant new product development is serious enough to be well documented.

Thornes, J. E. Cost-Effective Snow and Ice Control for the Nineties. Third International Symposium on Snow and Ice Control Technology, Minneapolis, Minnesota, Vol. 1, Paper 24, 1992.

Perhaps there are no serious problems, just a significant business opportunity your client wishes to exploit. In this case, describe the opportunity.

Ice formation on roads is a serious problem in many countries, particularly in the northern hemisphere. There is currently no accurate way of predicting ice formation, and road treatment is unscientific at best and haphazard at worst. There is a significant market available if we produce an accurate ice forecasting and treatment-scheduling product. Our marketing department has identified 25 countries that would immediately buy such a product.

Alternatively, the project may seek to explore or investigate possibilities. In this case the project deliverable, instead of a new product, would be a document proving that the requirements for a product can (or cannot) be satisfied.

Ice forecasting and truck scheduling have traditionally been done by separate entities. We suspect that treatment scheduling can be done far more effectively if it is combined with forecasting. Both activities would likely benefit by sharing data and optimization strategies. We wish to investigate whether there is a product development opportunity for our organization.

1b. Goals of the Project

This part of the specification describes what we want the product to do and what advantage it will bring to the overall goals of the work. Do not be too wordy in this sectiona brief explanation of the product's goals is usually more valuable than a long, rambling treatise. A short, sharp goal will be clearer to the stakeholders and improve the chances of reaching a consensus for the goal.

To reduce road accidents by accurately forecasting and scheduling the de-icing of roads.

If a goal is worth while, then it must provide some advantage or benefit. You can also think of it as adding value to the work. Rob Thomsett, a prominent management consultant, says that there are three categories of benefit:

• Value in the marketplace

• Reduced cost of operations

• Increased value or service to customers

Reducing road accidents can be counted as increasing a service to customers.

The advantage must be measurable. If you cannot measure it, it is not a worth while goal. How could you ever tell if your product has achieved the advantage it was intended to produce?

For example, suppose you have the following goal:

To produce a distributed quality-focused devolved groupware coordination and phased dynamic alliance monitoring solution.

No possible advantage is stated here, and certainly nothing that can be measured. Instead of having a goal such as the above gibberish, we suggest that you look for a quantifiable benefit.

Chapter 9 explains fit criteria in detail.

In Chapter 9, we referred to the measurement attached to a requirement as a fit criterion. The measurement of the goal is, in essence, the same thing. In Chapter 3, Project Blastoff , you saw how to arrive at a clear goal by using the PAM (Purpose, Advantage, Measurement) technique.

We came up with the following goals for the Icebreaker project:

For more on how to write goals, refer to Chapter 3, Project Blastoff.

Purpose: To accurately forecast road freezing times and dispatch de-icing trucks.

Advantage: To reduce road accidents by forecasting icy road conditions.

Measurement: Accidents attributed to ice shall be no more than 15 percent of the total number of accidents during winter.

Purpose: To save money on winter road maintenance costs.

Advantage: Reduced de-icing and road maintenance costs.

Measurement: The cost of de-icing shall be reduced by 25 percent of the current cost of road treatment, and damage to roads from ice shall be reduced by 50 percent.

Supporting Materials: Thornes, J. E. Cost-Effective Snow and Ice Control for the Nineties. Third International Symposium on Snow and Ice Control Technology, Minneapolis, Minnesota, Vol. 1, Paper 24, 1992.

These measurements are testable and provide guidance to help the project team focus their attention on those requirements that make the greatest contributions to meeting the goals. Although other goals may exist for this product, be careful not to include every individual requirement as a goal. A goal is an overriding requirement: It applies to the product as a whole. Thus

To save money on winter road maintenance costs.

is a goal, whereas

The product shall record air-temperature readings, humidity readings, precipitation readings, and road-temperature readings received from weather stations.

is a functional requirement that contributes to the goal.

You determine the goals at blastoff time. You must ensure that these goals are reasonable, attainable, simply stated, and worthwhile, and that they carry a measurement so you can test the delivered product to ensure that it satisfies the goal. If the goal does not have these properties, then history suggests the project is unlikely to deliver anything useful.

The goal is used throughout the requirements-gathering activity. Each requirement you gather must contribute, even if indirectly, to that goal. Requirements that do not contribute are not relevant and should be discarded.