Scope Management is the collection of processes which ensure that the project includes all the work required to complete it while excluding all work which is not necessary to complete it. The Scope Management Plan details how the project scope will be defined, developed, and verified. It clearly defines who is responsible for managing the projects’ scope and acts as a guide for managing and controlling the scope. Download this free project Scope Management Plan template by clicking on the link above.
Project Scope Management follows a five step process; Collect Requirements, Define Scope, Create WBS, Verify Scope, and Control Scope.
- Collect Requirements – this first step is the process by which we define and document the requirements needed to meet all project objectives. The foundation of this process is the project charter and stakeholder register. From these, the team can identify requirements, collectively discuss details associated with meeting each requirement, conduct interviews and follow-on discussion to clarify the requirements, and document the requirements in sufficient detail to measure them once the project begins the execution phase. This documentation also serves as an input to the next step in the process which is to define scope.
- Define Scope – this step is critical to project success as it requires the development of a detailed project/product description to include deliverables, assumptions, and constraints and establishes the framework within which project work must be performed.
- Create WBS – this process breaks project deliverables down into progressively smaller and more manageable components which, at the lowest level, are called work packages. This hierarchical structure allows for more simplicity in scheduling, costing, monitoring, and controlling the project.
- Verify Scope – this is the process by which the project team receives a formalized acceptance of all deliverables with the sponsor and/or customer.
- Control Scope – this is the process of monitoring/controlling the project/product scope as well as managing any changes in the scope baseline. Changes may be necessary to the project scope but it is imperative they are controlled and integrated in order to prevent scope creep.
The Scope Management Plan provides the scope framework for this project. This plan documents the scope management approach; roles and responsibilities as they pertain to project scope; scope definition; verification and control measures; scope change control; and the project’s work breakdown structure. Any project communication which pertains to the project’s scope should adhere to the Scope Management Plan.
This project is for designing, programming, and testing a new software product which will be used to track the company’s finances and improve various financial processes. This includes design of the software, all programming and coding, and testing/validation of the software. No external resources or outsourcing are anticipated for this project.
Scope Management Approach
It is important that the approach to managing the projects’ scope be clearly defined and documented in detail. This section of the Scope Management Plan provides a summary of the Scope Management Plan in which it addresses the following:
- Who has authority and responsibility for scope management
- How the scope is defined (i.e. Scope Statement, WBS, WBS Dictionary, Statement of Work, etc.)
- How the scope is measured and verified (i.e. Quality Checklists, Scope Baseline, Work Performance Measurements, etc.)
- The scope change process (who initiates, who authorizes, etc.)
- Who is responsible for accepting the final project deliverable and approves acceptance of project scope
For this project, scope management will be the sole responsibility of the Project Manager. The scope for this project is defined by the Scope Statement, Work Breakdown Structure (WBS) and WBS Dictionary. The Project Manager, Sponsor and Stakeholders will establish and approve documentation for measuring project scope which includes deliverable quality checklists and work performance measurements. Proposed scope changes may be initiated by the Project Manager, Stakeholders or any member of the project team. All change requests will be submitted to the Project Manager who will then evaluate the requested scope change. Upon acceptance of the scope change request the Project Manager will submit the scope change request to the Change Control Board and Project Sponsor for acceptance. Upon approval of scope changes by the Change Control Board and Project Sponsor the Project Manager will update all project documents and communicate the scope change to all stakeholders. Based on feedback and input from the Project Manager and Stakeholders, the Project Sponsor is responsible for the acceptance of the final project deliverables and project scope.
Roles and Responsibilities
In order to successfully manage a projects’ scope it’s important that all roles and responsibilities for scope management are clearly defined in the Scope Management Plan. This section of the template defines the role of the Project Manager, Project Team, Stakeholders and other key persons who are involved in managing the scope of the project. It should state who is responsible for scope management and who is responsible for accepting the deliverables of the project as defined by the projects’ scope. Any other roles in scope management should also be stated in this section of the Scope Management Plan template.
The Project Manager, Sponsor and team will all play key roles in managing the scope of this project. As such, the project sponsor, manager, and team members must be aware of their responsibilities in order to ensure that work performed on the project is within the established scope throughout the entire duration of the project. The table below defines the roles and responsibilities for the scope management of this project.
|John Doe||Sponsor||Approve or deny scope change requests as appropriate|
Evaluate need for scope change requests
Accept project deliverables
|Jane Doe||Project Manager||– Measure and verify project scope|
– Facilitate scope change requests
– Facilitate impact assessments of scope change requests
– Organize and facilitate scheduled change control meetings
– Communicate outcomes of scope change requests
– Update project documents upon approval of all scope changes
|Bob Jones||Team Lead||– Measure and verify project scope|
– Validate scope change requests
– Participate in impact assessments of scope change requests
– Communicate outcomes of scope change requests to team
– Facilitate team level change review process
|John Smith||Team Member||– Participate in defining change resolutions|
– Evaluate the need for scope changes and communicate them to the project manager as necessary
|Tom Brown||Team Member||– Participate in defining change resolutions|
– Evaluate the need for scope changes and communicate them to the project manager as necessary
Table 1.1, Scope Management Roles and Responsibilities
The scope definition section of this Scope Management Plan template details the process of developing a detailed description of the project and its deliverables. This can only be completed after the requirements have been identified and defined during the requirements definition process. During the requirements definition process three documents were created; Requirements Documentation, Requirements Management Plan and a Requirements Traceability Matrix. You can refer to these documents when defining the projects’ scope.
This section of the Scope Management Plan should explain the process you followed to develop the detailed description of the project and its deliverables. If you used other documents such as the Project Charter, Preliminary Project Scope Statement or Requirements Documentation you should identify them and all other documents used. You should tie the scope definition process back to the requirements definition as the projects’ scope answers the requirements for the project as shown in this template below.
You should also document the tools and techniques used to define the project scope such as expert judgment, product analysis, alternatives identification or facilitated workshops.
The scope for this project was defined through a comprehensive requirements collection process. First, a thorough analysis was performed on the company’s current software applications based on employee and user feedback. From this information, the project team developed the project requirements documentation, the requirements management plan, and the requirements traceability matrix for what the new software application must accomplish.
The project description and deliverables were developed based on the requirements collection process and input from subject matter experts in software design, technical support, programming and business applications. This process of expert judgment provided feedback on the most effective ways to meet the original requirements of providing a new software platform from which the company can improve its financial tracking and internal financial processes.
Project Scope Statement
The project scope statement details the project’s deliverables and the work necessary to create these deliverables. The Project Scope Statement should contain the following components:
- Product Scope Description – describes what the project will accomplish
- Product Acceptance Criteria – describes what requirements must be met in order for the project to be accepted as complete
- Project Deliverables – detailed list of deliverables the project will result in
- Project Exclusions – description of work that is not included in the project and outside of the scope
- Project Constraints – lists limits on resources for time, money, manpower, or equipment (capital)
- Project Assumptions – describes the list of assumptions the project team and stakeholders are working under to complete the project
The project scope statement provides a detailed description of the project, deliverables, constraints, exclusions, assumptions, and acceptance criteria. Additionally, the scope statement includes what work should not be performed in order to eliminate any implied but unnecessary work which falls outside the of the project’s scope.
This project includes the design, programming, and testing of a new software application for tracking the company’s finances. The deliverables for this project are a completed software application for finance tracking with the flexibility to modify and expand the application as necessary in the future. This project will be accepted once the new software has been successfully tested in each department and has been shown to be compatible with the company’s current information technology (IT) infrastructure. This project does not include ongoing operations and maintenance of the software. Only internal personnel and resources may be used for this project. Additionally, the project is not to exceed 180 days in duration or $450,000 in spending. Assumptions for this project are that support will be provided by the project sponsor and all department managers and that adequate internal resources are available for the successful completion of this project.
Work Breakdown Structure
The Work Breakdown Structure (WBS) and Work Breakdown Structure Dictionary are key elements to effective scope management and should be included in the Scope Management Plan. This section of the Scope Management Plan template discusses how the project scope is to be subdivided into smaller deliverables in the WBS and WBS Dictionary and how these smaller components are managed during the life of the project.
In order to effectively manage the work required to complete this project, it will be subdivided into individual work packages which will not exceed 40 hours of work. This will allow the Project Manager to more effectively manage the project’s scope as the project team works on the tasks necessary for project completion. The project is broken down into three phases: the design phase; the programming phase; and the testing phase. Each of these phases is then subdivided further down to work packages which will require no more than 40 hours of work and no less than 4 hours of work (see WBS structure below).
Figure 1.1, Work Breakdown Structure (WBS)
In order to more clearly define the work necessary for project completion the WBS Dictionary is used. The WBS Dictionary includes an entry for each WBS element. The WBS Dictionary includes a detailed description of work for each element and the deliverables, budget and resource needs for that element. The project team will use the WBS Dictionary as a statement of work for each WBS element.
|Level||WBS Code||Element Name||Description of Work||Deliverables||Budget||Resources|
Table 1.2, WBS Dictionary
Scope verification discusses how the deliverables will be verified against the original scope and how the deliverables from the project will be formally accepted. The deliverables for the project should be formally accepted and signed off on by the customer throughout the lifecycle of the project and not held back as a single deliverable at the end of the project.
As this project progresses the Project Manager will verify interim project deliverables against the original scope as defined in the scope statement, WBS and WBS Dictionary. Once the Project Manager verifies that the scope meets the requirements defined in the project plan, the Project Manager and Sponsor will meet for formal acceptance of the deliverable. During this meeting the Project Manager will present the deliverable to the Project Sponsor for formal acceptance. The Project Sponsor will accept the deliverable by signing a project deliverable acceptance document. This will ensure that project work remains within the scope of the project on a consistent basis throughout the life of the project.
Scope control is the process of monitoring the status of the scope of the project. This section of the Scope Management Plan template also details the change process for making changes to the scope baseline. Be sure to download this free Scope Management Plan template by clicking on the link at the top of this page.
The Project Manager and the project team will work together to control of the scope of the project. The project team will leverage the WBS Dictionary by using it as a statement of work for each WBS element. The project team will ensure that they perform only the work described in the WBS dictionary and generate the defined deliverables for each WBS element. The Project Manager will oversee the project team and the progression of the project to ensure that this scope control process if followed.
If a change to the project scope is needed the process for recommending changes to the scope of the project must be carried out. Any project team member or sponsor can request changes to the project scope. All change requests must be submitted to the Project Manager in the form of a project change request document. The Project Manager will then review the suggested change to the scope of the project. The Project Manager will then either deny the change request if it does not apply to the intent of the project or convene a change control meeting between the project team and Sponsor to review the change request further and perform an impact assessment of the change. If the change request receives initial approval by the Project Manager and Sponsor, the Project Manager will then formally submit the change request to the Change Control Board. If the Change Control Board approves the scope change the Project Sponsor will then formally accept the change by signing the project change control document. Upon acceptance of the scope change by the Change Control Board and Project Sponsor the Project Manager will update all project documents and communicate the scope change to all project team members stakeholders.