When managing a project or developing a product, you need to have a scope. That scope will tell you what you have to do to create value with the project for the attainment of organizational goals.
Project scope management is the process of defining the work required for the project and making sure all of the work defined is done and nothing more than that.
Based on the Project Management Book of Knowledge (PMBOK) 6th edition, scope management is one of the 10 project management knowledge areas.
If you are a project manager or you are aspiring to be a certified project manager by getting certifications like the Project Professional Professional (PMP) certification, Certificate Scrum Master (CSM), Prince 2 Practitioner, and others, you need a firm grasp on the concept of the project scope and how to manage it.
From a broad point of view, the core of project scope management is outlined below.
- The project scope must be defined clearly and formally approved.
- The project must plan how to manage and control the project scope.
- The project requirements are to be acquired from the project stakeholders.
- After acquiring the requirements, they are to be evaluated with the business case of the project to see if they are within the project scope. The requirements are then prioritized.
- A Work Breakdown Structure is integral to managing scope. It goes beyond a list and is a source of clarity for the project manager and team.
What is Scope in Project Management?
The scope in project management refers to the project and product scope. Both the product scope and project scope are geared towards creating the business value detailed in the project business case.
Read Also: Project Management Initiating Process Group
Project Scope Definition
The project scope is the work required to deliver the product or service that represents value to the organization. It is a detailed outline of the project.
The project scope outlines the deliverables, timelines, activities, key stakeholders, processes, assumptions, and constraints of the project.
It details what is included in the project, and what is not included, as well as a general idea of what the project is about.
Product Scope
Product scope is applicable to product development. The product scope is the details of the product. These include how it looks, its functionality, features, and others.
It is concerned with the characteristics of the product, service, or result.
Product Scope vs Project Scope
The product scope and project scope are all about the result. However, while the product scope is concerned with the features of the result, the project scope is the work that delivers the product with these desired features.
Project Scope Management
Project scope management as a knowledge area is a set of processes that ensures the scope of the project is well-defined and accurately mapped.
These processes are to give you as the project manager and your team the roadmap to define the project scope and product scope that will create value for the stakeholders, and how to ensure the product or service is in tandem with this scope.
Project Scope Management Processes
Project scope management entails 6 processes. These are:
- Plan Scope Management
- Collect requirements
- Define scope
- Create a Work Breakdown Structure (WBS)
- Validate scope
- Control scope
A brief outlay of these processes can be summarized below.
- Determine how to plan, validate, and control the scope of the project and the requirement.
- Collect requirements from stakeholders, then analyze and evaluate them to see those that support the business case.
- Prioritize the requirements that support the business case.
- Determine the scope of the project.
- Decompose the scope into smaller pieces to form the WBS structure. Define each piece or work package in the WBS dictionary.
- Gain acceptance of the scope from the sponsor or customer.
- Measure the scope performance and adjust.
It is important to note that in some organizations, requirements gathering and evaluation are established as separate projects.
Also, every requirement should support the business case or be a separate project.
Read Also: Ways to Avoid Gold Plating in Project Management
Plan Scope Management Process
The outputs of this process provide directions on how the project and product scope will be defined, managed, and controlled.
The inputs to the process are the project charter, project life cycle, and Organizational Process Assets (OPAs).
This process has 2 outputs. These are the scope management plan and the requirements management plan.
Scope Management Plan
The scope management plan is a documented plan that defines how to define and achieve the scope, the tools to use, and how to create the Work Breakdown Structure (WBS) and the WBS dictionary.
It details how to manage and control the scope of the project to resonate with the project management plan, and how to gain acceptance of deliverables.
The scope management plan may be developed in stages. It can be started at a high level and iterated with progressive elaboration during planning.
During the later parts of planning when planning risk responses, an additional scope can be added thus changing the scope management plan, project scope statement, and WBS.
Requirements Management Plan
This is referred to as the Business analyst’s plan. It plans how to identify the requirements, then analyze, prioritize, manage, and monitor them.
Business analysis is about gathering business requirements, defining, analyzing, and ensuring they satisfy the business need.
Business analysts help to identify problems, define business needs, recommend solutions, elicit requirements from stakeholders, and document them in order to meet business and project objectives.
The project manager is focused on project delivery, while the business analyst has requirements responsibilities.
Collect Requirements Process
Requirements are what stakeholders need or expect from a project. They make up the scope of the project and product.
The requirements could include specifications of a process, product, or the overall project. However, the requirements have to support the business case.
Requirements can relate to business processes, solutions, transition, quality, compliance, and project management processes.
Collecting requirements involves looking for all requirements and not only those related to the project. A missed requirement could down the line lead to conflict and changes.
Read Also: Kill Point in Project Management
Inputs to Collect Requirements Process
The inputs to this process are the project charter, project management plan (scope management plan, stakeholder engagement plan, and requirements management plan), assumption log, stakeholder register, agreements, business documents, and Organizational Process Assets (OPAs).
Techniques for The Collect Requirements Process
When collecting project requirements, there are lots of techniques you can employ. These are some useful techniques.
Brainstorming
Brainstorming goes beyond a normal meeting. It is a gathering of experts with diverse perspectives to build on each other’s ideas.
Focus Group
This is a gathering of a selection from the demography of subject experts.
Benchmarking
This is a technique of collecting requirements by looking at what the competition is doing and measuring performance against that.
Voting
This is using a voting system for requirements. You can use the unanimous approach, majority, or plurality.
Multicriteria Decision Analysis
This involves ranking ideas with a decision matrix based on factors like the expected risk levels, time estimates, cost, and benefits analysis.
Affinity Diagram
This involves ranking requirements based on similarities.
Mind Maps
This is a tree of ideas branching out from a central core.
Nominal Group Technique
This is usually used during brainstorming. A question is asked, and participants are asked to write ideas. The ideas are then discussed by the group and ranked.
Facilitation
This brings stakeholders with different perspectives to talk about the project or product using a consensus approach.
Examples of facilitation sessions include Joint Application Design (JAD) which is used in software development projects and Quality Functional Deployment (QFD) which is used in manufacturing projects.
Context Diagram
This is also called Context Level Data Flow. It is used to define and model the scope of the project. It shows the boundaries of the product scope and interferences with people, processes, and systems.
Prototype
This is a model of the proposed product presented to stakeholders to elicit their ideas and views.
Other techniques include interviews, surveys, and questionnaires.
Balancing Stakeholder Requirements
After collecting the project requirements from the stakeholders, it is very important to balance them.
This involves analyzing requirements to check feasibility within constraints and options, and prioritizing and resolving conflicts.
It involves the following processes.
- Identify all stakeholders and their needs.
- Look for conflicting interests while planning.
- Look for resolution means for conflicting interests from techniques like schedule compression, brainstorming, reestimating, and fast-tracking.
- Resolving conflicting requirements based on how it affects the project.
- Give priority to the customer’s needs.
- Say no to conflicting interests.
- Fix the project when project metrics deviate from the requirements, rather than changing requirements.
- Call on management for resolution when you and the project team are unable to.
Resolving Conflicting Project Requirements
When collecting requirements, conflicts are bound to arise. Some of these conflicts end up having to be escalated to management. Resolution should be based on accepting those that comply best with:
- Business case
- Project charter
- Project scope statement if it is already available
- Project constraints
Outputs to Collect Requirements Process
The process of collecting requirements has the following outputs.
Requirements Documentation
After the project requirements have been collected, analyzed, and prioritized, they are documented. This documentation is the output of the collect requirements process.
There are various documentations and the acceptance criteria are key. The documented requirements can then be measured against deliverables when executing the project.
Requirements Traceability Matrix
This is another output of the collect requirements process. It is a matrix that visually links the project requirements to other requirements and/or the project objectives or goals.
It is used throughout the project for analyzing proposed changes to the project or product scope.
It contains details like requirement identification number, source of requirement, and who is assigned to manage the requirement. Assigning responsibility to each requirement is similar to the concept of risk owners.
Define Scope Process
This process is concerned with the project deliverables, what is in the project, and what is not included.
The inputs to this process are the project charter, scope management plan, requirements documentation, assumption log, and risk register to define the scope of the project.
It is important to note in this process that planning is key. After defining the scope, the other processes defined in the project charter follow.
The scope has to be balanced with the other triple constraints which are schedule and cost in order to be realistic. Also, the process of defining the scope of the project is an ongoing process throughout the project.
Product Analysis
Product analysis is a technique done to analyze the requirements and define the tangible deliverables using techniques like systems engineering, value analysis, systems analysis, requirements analysis, product breakdown, and value engineering.
Product Scope Statement
This is an output of the define scope process. The scope statement combined with the WBS and WBS dictionary form the scope measurement baseline.
It includes the following:
- Product scope
- Project scope
- Deliverables
- Acceptance criteria
- What is not in the project
- Constraints and assumptions
Create a Work Breakdown Structure (WBS)
The WBS is a hierarchical breakdown of the project deliverables into work packages. It gives a breakdown and flow of the deliverables.
Using the WBS helps the team to walk the entirety of the project within their minds and see how one deliverable relates to another and the overall project or product goal.
A WBS breaks the project into phases, then breaks the phases into deliverables, and then work packages. It is a deliverable-oriented visual representation.
During project planning, the scope of the project is broken down until the work package level is reached. At the work package level,
- Deliverables are confidently estimated.
- Deliverables can be outsourced.
- They can be completed quickly.
- They can be completed without interruption and need for more information.
When the WBS is complete, identification numbers are assigned to each work package. At this point, you can enter the work packages into project scheduling software.
Each work package has a control account. A control account is a tool used to analyze work performance data regarding the project scope, schedule, and cost.
As planning continues, the work packages are broken down into scheduled activities or tasks.
Benefits of Work Breakdown Structure (WBS)
The WBS is beneficial to the project in lots of ways.
- It provides clarity on the project.
- It helps to identify risks to the project.
- It helps in the estimation of project schedule and cost.
- It helps in preventing project work from slipping through the cracks.
- It helps the project team have a mental image of the project and its goal.
Scope Creep
Scope creep is something you definitely do not want on your project. This is where the scope of the project is deviating from the plan. It is often a result of changes to the scope bypassing integrated change control.
Work Breakdown Structure Dictionary
The WBS dictionary is an output of the Create WBS process.
It defines each work package including the descriptions, control account identification, work involved in producing the deliverable, acceptance criteria, constraints and assumptions, quality metrics, risks, resources assigned, duration, cost, milestones, due date, and interdependencies.
Scope Baseline
The scope baseline is made up of the project scope statement, WBS, and BS dictionary. It is the standard by which the scope of the project actually done is measured against.
Validate Scope Process
This process involves getting the project sponsor or customer to accept interim project deliverables.
The inputs to the process are:
- Verified deliverables from the control quality process.
- Scope baseline
- Requirements management plan and requirements traceability matrix
- Requirements documentation
- Scope amanegement plan
- Work performance data
- Lessons learned and quality reports.
The techniques used for this process are inspection, measuring, testing, examining, validating, reviews, audits, walk-throughs, and decision-making.
The outputs of the process are:
- Accepted deliverables
- Change requests
- Work performance information
- Updates to project requirements documentation, requirements traceability matrix, and the lessons learned register.
Control Scope Process
To control the scope of the project, you must have a clear description of the scope baseline, and be aware of the requirements documentation and requirements traceability matrix.
Then you need to consistently measure completed project work against the scope baseline. The control scope process is focused on being proactive rather than reactive.
It aims to prevent unnecessary changes, check where changes are coming from, and address the root causes.
Conclusion
The key to managing your project successfully and having happy stakeholders and customers starts with proper project scope management.
Project scope management enables you to have a scope that is aligned with the project and organizational goal, and work towards meeting it.
