Project Constraints

One more important consideration in identifying requirements is to realize that some requirements actually represent constraints. These constraints may take the form of constraints to the project process. Or, a constraint may be that the product is in and of itself a constraining device. Either way, this condition may generate other requirements. For instance, if the requirement is for a device to be delivered by a certain date, not unusual in federal sector contracts, then the schedule represents a constraint. This scheduling constraint may force the provider to hire additional personnel or consultants or even to team with another company to meet the deadline. If the product is something that is used in a dangerous environment, then the environment may impose additional requirements. An example might be a product used in a military vehicle, say, in a helicopter or tank. Although the product itself might be rather benign, the very nature of its operational environment will dictate its design parameters. For instance, a computer in a tank must be "ruggedized" to withstand the forces imposed on it by the tank's operational environment.

Remember, all requirements have to be fulfilled to the customer's satisfaction before the project can be considered a success, and some requirements are more important than others. In other words, not precisely meeting the requirement that a product be a certain color to match the company's logo will not affect the functionality of the product, and perhaps it results only in a less than totally satisfied customer. This result is not unimportant, but it is relatively harmless and easy to rectify. But not considering requirements that are also constraints usually results in significant cost and schedule overruns, complete failure of the project, total customer dissatisfaction, or all of these conclusions. Requirements are not only important—they are the very heart of the project's existence. How, then, can we eliminate or at least reduce this significant problem source?

The obvious answer to eliminating problems resulting from requirements interpretation is for the customer to establish clear and concise requirements and for the provider to ensure they are precisely interpreted. Yet how can these actions be brought together to yield the desired result? There are three key steps: a clearly written set of requirements, a medium for transmitting these requirements to the provider, and a process for ensuring that the provider and the customer are in complete agreement about the intent of the project and the results desired. Let's begin by looking at the first step—providing a clearly written set of requirements.