Project Management

Define project scope to include deliverables, boundaries, and requirements


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.

  1. 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.
  2. 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.

11 comments
jleonti
jleonti

Good article for all having to write Scope documents.

fabishi
fabishi

would be great to have an example of a software development project thank you all

dreux.grever
dreux.grever

"Once the project starts, however, you generally do not have a lot of requests to change boundaries and deliverables" I'd take issue with this comment, I find users frequently try to add to the deliverables list after the project starts. Maybe its just the nature of creating software products, but they think nothing of requesting just "one" more piece of functionality. Heck, sometimes they ask for entire new departments to be included in the project scope.

ortreg
ortreg

Clearification is direct and well directed. I think the examples are fantastic.

altaee
altaee

Dear, Just want to say may be we can't discuss some articles because of time limit but most of articles whatever its simple, its good to read and review. Thanks!

Tony Hopkinson
Tony Hopkinson

Don't believe I've ever worked on a project where there weren't requests to increase scope.

aachour
aachour

I have never came across a software project where requirements didn't change or new ones were not added once customer requirements have been agreed and signed off. Despite the fact that new added requirements are mostly the cause for project scope changes but very often we see the same requirements being modified few times before they get finaly implemented.

clyde.sepulvado
clyde.sepulvado

People always want to add "just one more item/feature" to the project. One of the project manager's tasks is to make sure the project stays within the scope and does not suffer from scope creep. This is not to say that the folks wanting the new feature do not have a great idea--it is just not great for the present project--however it could make for another project down the road.

geoff.schmidt
geoff.schmidt

Although it's implicitly mentioned in the article, I'd reiterate and reinforce the need to define explicitly what is OUT of scope as well as what is in scope. Asking the question as to what the project is not covering makes scope more definitive, and also helps to correctly set boundaries by asking questions such as: "If not for non-USA locations, what are they doing to do for x process?" Out of scope definitions will often save your bacon further into the project. Further into a project, in-scope only definitions can be ambiguous when more about the project is defined and known. For example, US territories may not be explicitly in or out. The project has assumed out, the customer has assumed in.

Tony Hopkinson
Tony Hopkinson

Not in scope is usually a simple therefore clear definition. Where as in scope is generally a lot more detailed. I'd also add not in scope now. Link to another system for instance, a bit of groundwork in version one can make version two much easier.