Scope Management Plan: Example, Guidelines (+template)

I created a Scope Management Plan once and improved it bit by bit during all 11+ years of my career in the IT industry. The plan helped many times to organize the work of a new team. So, it’s a worthwhile investment of your efforts.

A scope management plan is a document that describes processes and tools a project manager will use to collect requirements, identify, control, and verify project scope. A project manager should tailor a scope management plan to the needs of a specific project.

Unfortunately, project owners in the software development industry don’t see the value of a scope management plan. However, I believe it’s critical. That’s why you’ll find:

• Scope management plan example
• Guidelines on how to write the plan

Scope Management Plan Example

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, the 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 in 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

Highly recommended in case you need to produce not only the application but also some other deliverables. 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 the creation and maintenance of a WBS without extra effort}

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 pre-release 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 needs 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. 

Scope Management Plan Template

Unfortunately, this article was just one piece of a complex project scope management framework: Many other processes happen before and after this one.

If one part doesn’t work, the whole system breaks.

My Scope Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on scope management. 

Don’t put your projects and reputation at risk. Ensure you know how scope management works in the real world.

All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Scope Management Plan Template.