There are two places that scope is defined on your project. High-level scope is defined in your project charter. Low-level scope is defined in your business requirements document.
High-level scope consists of two main components.
- Deliverables. If you can’t remember anything else about scope, list your deliverables. Defining your deliverables goes a long way toward defining the overall scope of the project.
- Boundaries. You should also try to define the boundaries of your project. Boundary statements help to separate the things that are applicable to your project from those areas that are out of scope. Examples of boundary statements include:
- This project will affect USA operations only. All other locations are out of scope.
- We will deliver our solution to the Finance and Legal departments. All other departments are out of scope.
Think of project scope as a box. High-level scope defines the sides of the box and separates what is relevant to your project from that which is irrelevant.
Once the project starts, however, you generally do not have a lot of requests to change boundaries and deliverables. Most of the scope change requests you receive are changes to the business requirements.
Business requirements help define the detailed scope. The project deliverables are used to define high-level scope. Business requirements describe the details of the deliverables. If scope is a box, then your requirements are what fill in the inside of the box.
There are two types of requirements. They are:
- Product requirements (features). Product requirements describe the characteristics of the deliverables. If you were building a bridge, for instance, most of the requirements would be product based. These might include the number of cars the bridge would hold, the strength of the steel, the water level it needs to span, the color of the bridge, etc.
- Process requirements (functions). Process requirements describe how people interact with a product and how a product interacts with other products. For example, when you discuss how data gets moved and how business transactions flow from one point to another, you are describing process requirements. If you need to describe the requirements for billing transactions, most of the requirements could end up being process oriented. This would include how billing transactions move from orders to invoicing to accounts receivable. They can describe at what points people look up a status, how people manually update an invoice and what people should do if accounts are out of balance.
If you remember how these pieces fit together, you’ll have an easier time defining scope for your project in the future. High-level scope is defined in your charter and consists of boundary statements and deliverables. Low-level scope is defined by your business requirements. These two components together make up the entire scope definition for your project.