Most project managers understand the need to manage scope effectively to be successful. But in spite of this awareness, many project managers have trouble making scope change management work. One of the major problems is that the project manager did not do a good enough job defining the scope to begin with.
Defining scope is perhaps the most important part of the upfront definition and planning process. If you don't know what you are delivering and what the boundaries of the project are, you have no chance for success.
There are two major places where scope is defined. The high-level scope is established in the Project Definition (charter). The detailed scope is defined in the approved business requirements. Of the two, project managers most often have difficulty writing the high-level scope statements. If you struggle determining what your scope section should look like, the following categories will help. Note that in many cases the out-of-scope statements provide as much value to the reader as the in-scope statements.
If you do nothing else, the scope section should include the major deliverables that the project team is creating. Generally, you only include the final deliverables that your project delivers to the client and not the internal documents used by your project team. For instance, a Business Requirements Report and Current State Assessment could be listed as project deliverables since they are both client approved deliverables. You would not need to mention internal project documents such as the project workplan, Technical Design, or Test Cases. If you think that the reader might have any confusion about other potential deliverables that you won't create, these should be specifically listed as out-of-scope so that there is absolutely no ambiguity.
If your project is only going to execute a portion of the lifecycle, the scope statement should identify this as a lifecycle boundary. For instance, if you have a project that's only going to cover project analysis, you should specifically include the Analysis Phase as in scope, while identifying the Design, Construct, Test, and Implement Phases as being out of scope.
Data / data sources
It's possible that your project will work with some types of data and won't work with others. For example, you might state that financial data is in scope, while sales and manufacturing data is out of scope. "Data sources" are files, tables, or databases of aggregated data. So you might state, for instance, that the Customer Database and General Ledger are in-scope, while the Billing Tables are out of scope.
If your solution covers more than one organization, you can state which ones are in scope and which are out of scope. For instance, your project may focus on Human Resources and Accounting, but the Manufacturing Division might be out of scope.
If your project is delivering a solution with less than full functionality, you should describe the major features and functions that are in and out of scope. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope.
If you think hard enough, there are many categories of scope that you can use to describe the boundaries of the project – both in terms of inside the boundaries and outside the boundaries. The more aspects of scope you can identify, the better off your project will be.