Scope Management Plan Checklist
 |
||
 |
||
 |
||
This scope management plan checklist ensures that you create a well defined and presented scope plan following the four key processes that define scope management.
Any project you undertake must have a well defined and presented scope management plan as this provides the working framework to ensure its success. One of the key functions of this document is that of defining how your project scope will be managed and controlled as the project progresses.
1. Collect and document requirements
2. Definition of the scope
3. Produce a work breakdown structure (WBS)
4. Verify and control scope
First you must collect and define exactly what your customers' needs and expectations of the project are. You will also need to carefully read the project charter and stakeholder register to fully appreciate the project obligations and write your requirements management plan.
Once you have a complete understanding and appreciation of your project requirements, including the acceptance criteria, you will have the foundation to produce your work breakdown structure.
Before progressing to the work breakdown structure you need to define the scope of the project from the project requirements and charter. The scope document provides a detailed description of exactly what your project objective is, its deliverables, exclusions, and acceptance criteria.
 |
On completion of your project scope statement you can begin to focus on the detailed aspects of your planning and communications. A key part of any project is planning and anticipating request for changes, your scope must describe how you will handle such requests.
Your project scope statement also defines the project teams roles and responsibilities, allocating a specified individual per role, as well as the level, format and circulation of the project documentation and reports.
Now you are ready to produce your work breakdown structure. This breaks down the project deliverables into manageable portions of work packages that you allocate a unique id to. This is commonly shown in a graphical form, such as an organizational style chart or a fishbone diagram.
This process of breaking work down is referred to as 'decomposition' and enables you to estimate costs and activity with a greater degree of accuracy. These details are recorded in your WBS dictionary and form the basis of your scope baseline.
 |
This plan will show how you will plan, prioritize, track and report these requirements. It also documents the policies, procedures and processes that the project must adhere to. In addition it explains the interactions between functions, service level agreements and their compliance. Descriptions of any assumptions and constraints are included along with quality, performance, support and security needs of your project
Once you have your scope you need to gain formal acceptance of the project deliverables by the stakeholders and on their agreement your project scope is verified. Any changes or alterations that arise after this sign off of the scope must adhere to your project's integrated change control process.
The final aspect of verifying your project scope is the description of how the inevitable changes to the project scope will be controlled. It is essential that you have strict controls over the change request process, other wise you could suffer from 'scope creep'. This is where unacceptable or unqualified risks get introduced into your project often causing project failure in one form or anther. This can be missing key milestones or over spending against your budget.
Work performance data (as shown below) along with the project plan and the requirements documentation are the three things that you must have to control over your projects scope.
• Current status - future / current / WIP / completed.
• Timely nature - ahead / on-time/ behind.
• Cost component - over / balanced / under budget or forecast.
Once a project change request has been accepted and signed your scope baseline and any other appropriate project baselines must be update and a new version of the project plan issued.
