Project Lifecycle Acquisition Support
While the baseline project scope and price are defined upon contract award, it is not unusual for there to be dozens or hundreds of legitimate scope changes during the course of the contract, each with an impact on cost and schedule that must be analyzed. We’ll discuss this process here. There are two primary sources of scope change: scope ambiguity and requirements changes. We’ll start by discussing what is often the larger of these, scope ambiguity.
Scope Ambiguity
Low ambiguity projects are those for which a comparable product exists and to which this product may be compared. A good example is a tract house. If you want to know what your house will look like, go look at the model house. It will look just like that. Other examples of low ambiguity projects are shrink-wrap software installations and hardware installations. Many projects fit into the low ambiguity category, and scope can and should be tightly managed on these projects.
Moderate ambiguity projects are those where the components of the final product all have comparable products elsewhere for comparison, but the combination of those components in this product is unique. Consider a custom built home using standard construction techniques. The cabinets, flooring, windows, etc. are all components that are well defined but uniquely assembled. Even things like flooring can be unambiguously described, as in “100 square yards of carpet with padding.” Some Commercial Off-The-Shelf (COTS) software installations are another example of moderate ambiguity projects. One characteristic of these projects is that professionals in that domain tend to see these as low ambiguity, while customers for which this is their first exposure to this domain will often see them as high ambiguity. For example, a builder might be able to look at a well drawn set of blueprints and understand the scope exactly, but a homeowner might not understand what is being built until they can actually see it. This disconnect in perception can result in friction. Here, effective scope management centers on early education of the customer about exactly what the product will be when delivered, or reducing the customer’s scope ambiguity in other words.
A high ambiguity project is one in which there are no comparable products for direct comparison. An example might be a mission to Mars. A more common example would be virtually every custom software project. Because there are no comparable products for direct comparison, we will have scope ambiguity.
Figure 2: Dealing with Scope Ambiguity
Dealing with Ambiguity
For high ambiguity projects, a significant portion of the project effort is spent reducing that ambiguity. Looking at Figure 2, we see that in reality the project doesn’t have a single baseline, but rather it has an evolving baseline that is progressively elaborated. For example, on a software project we start with business need, then define the requirements, then turn those into high level design, turn that into detail design, possibly do a prototype, turn that into physical code, and turn that into delivered functionality (the actual product). At each step in the process we are elaborating on the work of the previous stage, refining, clarifying, correcting, and changing as we go.