Read and Delete This Page Before Use
Permissions
You are free to use this template for your professional activity in your organization and with your team.
You are not allowed to distribute this template. If someone wants to use this template, they should get
their copy from my site. Please send them to https://pmbasics101.com/project-scope/.
I strongly recommend that you get my Scope Management Resource Guide. It will help you learn
project scope management. You will adapt this template with fewer mistakes and inefficiencies.
1.
2.
3.
4.
One-page Cheat Sheet on Project Scope Management Processes.
Quick access to articles and videos that explain Scope Management processes.
Access to other templates (Project Scope Statement, Requirements Traceability Matrix)
Special Video: How to Adapt PMBOK Guide Processes to the Real-World Projects.
Click here to get access to the resource guide.
Why do you need a Scope Management Plan?
In most organizations, you don't need to have a Project Management Plan as a formal document.
However, it's still beneficial to have the main processes described. After you adapt the Scope
Management Plan to your project needs, I recommend putting it on your project's Wiki page.
1.
2.
3.
4.
Present it to the whole team.
Refer to it when you need to manage scope.
Update it together with the team as needed. It's not set in stone.
Use it as a guiding principles for scope management.
Also, save it for future needs. You never know whether your next project will require a formal Scope
Management Plan.
It's a template. It’s a starting point. Here's what you need to do:
1. Read through the sections.
2. Adapt to the processes that you have using the same explanatory language.
3. Add links to the tools you use.
4. Please don't get too specific; it's not an in-depth document.
5. Adjust format and styles to your company.
6. Add a branded title page with the following information:
1. Project Scope Management Plan
2. Project Name
3. Created by: <Your Name>
4. Date
7. Review and delete all places marked with yellow.
Introduction
This document describes how the project team will manage the project scope, roles and
responsibilities, and tools they use.
For the purpose of this document, term "Project" means one Release cycle from initiation to
the deployment to the market in the overall Product Life Cycle.
Project Scope includes all the work that a project team needs to perform to reach project
objectives. The Project Manager is responsible for controlling project scope.
The main flow of Project Scope Management includes the following processes:
1. Requirements Identification
2. Creating of Project Scope Statement
3. Creating of Work Breakdown Structure and WBS Dictionary
4. Approving Scope Baseline
5. Continuous Scope Validation
6. Continuous Scope Control and Change Management
This project team follows the principle of one tool. As much as practical, we will keep all project
documentation in JIRA + Confluence {Google Docs, MS Office 365, Asana, ClickUp, etc.}. All
team members and authorized stakeholders should have access to documentation and the
ability to collaborate on it.
The main access point is here: {URL to Scope Documentation}
Work With Third Parties
This project requires collaboration with other teams and third parties. Their work is in the scope
of this project. It includes but not limited to:
1. UI/UX designs
2. Performance Testing
3. Security and Cyber Assessment
4. UAT/BVT Testing
This work and required communication should be transparently included in the Scope
Management and Communication Management plans.
Requirements Identification
All collected requirements should help achieve one of the project's objectives stated in the
Project Charter.
Business System Analyst (BSA) is the owner of the Requirements Identification process. The
Project Manager is responsible for controlling the execution of the required activities according
to the project timeline.
Following the best practices of agile software development and Scrum Framework, the main
documentation type for requirements is a User Story (Product Backlog Item or PBI).
For additional transparency and organization, all User Stories should have a parent Epic. All
entities should contain sufficient information for long-term scope management. Team will
follow the best practices for creating User Stories provided by agile community.
All project Deliverables for the current release cycle should be connected to the corresponding
User Stories.
The Project Team and BSA may decide to use any additional forms of requirements
documentation like diagrams, specifications, use cases, etc.
BSA is responsible for collecting requirements from Product Owner, Subject Matter Experts
(SME), and other stakeholders. BSA will use the following techniques:
1. Interviews
2. Meetings
3. Alternative Generation
4. Group Decision Making
5. Sprint Planning and Backlog Refinement Meetings
Project Team is the leading SME for technical and non-functional requirements. Non-functional
requirements, technical debt, ongoing refactoring, Quality Assurance, and testing are parts of
the project scope. All these parts should be transparently included in the backlog for the
current release as Enabler User Stories (Enablers).
Life Cycle of a User Story
{Arguably it's the most critical part of the Scope Management Plan. You need to describe how
to use the project management tool you have and integrate it with the scope management
approach you describe here. The best way is to tie all to the workflow of the software that you
use. For JIRA, we tie everything to the state of a User Story.}
{Important: Don't use this diagram as is and don't try to customize your tool to this workflow.
You need to use what you currently have. Therefore, you need to create your own workflow
based on how your tools are set up.}
Requirements Traceability Matrix (Optional. Recommended
on early stages of Product development)
Requirements Traceability Matrix is a tool that allows connecting requirements to the project
objectives, deliverables, stakeholders, testing coverage, and sign-offs.
BSA is the owner of the Requirements Traceability Matrix.
Requirements Traceability Matrix is located here: {Link to RTM. Get my RTM Template in my
Resource Guide}
Project Scope Statement (Optional.
Recommended on early stages of product
development)
{I recommend that you create a template Project Scope Statement on your own. It will include a
description of the typical deliverables for your type of project. You'll then include a list of
Epics/User Stories that are part of the current release cycle. Refer to the Resource Guide for
best practices for Project Scope Statement}
Project Scope Statement is a document that clearly communicates the project scope. It should
be written in simple and non-technical language as much as possible. The main goal of the
Project Scope Statement is to allow clients and other stakeholders to comprehend and assess
the amount of work required for the given project.
Project Scope Statement should provide a deeper level of details compared to Project Charter
or any prior agreements.
The Project Manager is responsible for drafting out the Project Scope Statement. Clients and
sponsors will need to review and approve the statement.
The Project Manager will create a detailed Project Management Plan based on the approved
Project Scope Statement.
Any deliverables that were not included in the Scope Statement can be added only via a Change
Request.
Work Breakdown Structure (optional for
software development projects)
{Create a WBS only if it adds transparency to the project scope. I recommend creating a WBS in
the IT project only when you have lots of deliverables different in nature. Also, ensure that you
have a tool that allows creation and maintenance of a WBS without extra efforts}
The main deliverable of the project is a stable and potentially shippable product. Work
Breakdown Structure describes other product development deliverables (designs, approvals,
sign-offs), project management deliverables (Release Plan, Risk Register, Project Management
Plan, etc.), and stable builds of the product required for certain events and milestones.
Further decomposition of work should happen in JIRA as Epics and User Stories.
The latest version of the WBS is located here: {Link to WBS}
Project Scope Baseline
Project Scope Baseline includes approved Project Scope Statement, WBS, and WBS Dictionary.
Project Scope Statement should contain User Stories grouped by the Sprints for the current
release cycle.
Scope Baseline should contain a portion of the User Stories that are negotiable for de-scoping
from the current release cycle to allow agility and adaptivity.
Project Scope Validation
Project Scope Validation includes a demonstration of the product increment after each sprint
and formal acceptance of User Stories.
The Product Owner should explicitly notify the project team about accepting a User Story via
Email or by setting an appropriate state for selected PBIs.
Each PBI and Product, in general, should comply with the Quality Management Plan all the
time.
At the end of the release cycle, the project team needs to provide a Release Candidate for
verification and User Acceptance Testing. The project team needs to facilitate all required prerelease activities and collect sign-offs before the Go Live date.
Scope Control and Change Management
The whole project team controls Project Scope on a User Story level following two main
principles:
1. Any change to the project scope should be fully aligned with the business need and
objectives of a project stated in the Project Charter.
2. If a change to the project scope is required to meet an objective, it should be presented
as a new Epic or User Story. A change to the existing functionality should be marked as a
Change Request (CR).
3. A User Story in the "Approved" state can be changed only with impact analysis and the
project team's approval.
Any member of the team or project stakeholder can suggest a change or addition to the
project. All changes should be logged into backlog as Epics and User Stories. Clients and sponsor
may add User Stories to the backlog directly. Others should provide suggestions to the Business
System Analyst. BSA will create User Stories appropriately.
Changes to the scope of the current release cycle should be communicated via Email. Changes
to the scope of the current iteration are allowed only with agreement from the project team.
Changes to the next and future iterations are welcomed.