A lire sur: Method123
Defining scope is perhaps the most important part of the initial 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. If you have not done a good job of defining scope, managing scope will be almost impossible.
Most people understand what scope means, but many struggle trying to actually define the scope of a project. It is easiest if you remember there are two major aspects of defining scope on your project – deliverables and boundaries.
- The deliverables. All projects produce deliverables. (These are sometimes called the "products" produced by the project.) Even if you are not sure what else to include in your scope definition, you should always include your deliverables. Understanding the deliverables you are building goes a long way to understanding the scope of the project. There are many deliverables that could be listed, but you should focus on the final deliverables of the project - not necessarily the internal deliverables produced as a part of delivering the final solution.
- Project boundaries. The scope boundary statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more boundaries you can identify, the better off your project will be. You would not need to state that some aspect of the project was in-scope unless you could also contrast that with some aspect that is out of scope. The nature of a true boundary statement is that there is both an in-scope and a relevant out-of-scope counterpart. For example.
- The major life-cycle processes that are in scope and out of scope.For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases. Or perhaps your project is performing research, but you are not going to develop the results. These would be examples of using boundary statements to clearly state what your project is responsible for, and what is out of scope.
- The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may be applicable to the Human Resources and Accounting Departments, but the Manufacturing Division might be out of scope. Or perhaps your project is only impacting the corporate office while the field offices are out of scope.
- The major functionality that is in scope and out of scope. This might be a good boundary if you were delivering less than full functionality. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope. Or perhaps financial reporting is in-scope for your project, but Human Resources reporting is out of scope.
What do you need to remember? First - scope is defined as deliverables and boundaries. Deliverables are the things you build during the project. Boundaries are statements that describe the project in terms of in-scope and out-of-scope.