Project Scope - Explained
What is Project Scope?
- Marketing, Advertising, Sales & PR
- Accounting, Taxation, and Reporting
- Professionalism & Career Development
-
Law, Transactions, & Risk Management
Government, Legal System, Administrative Law, & Constitutional Law Legal Disputes - Civil & Criminal Law Agency Law HR, Employment, Labor, & Discrimination Business Entities, Corporate Governance & Ownership Business Transactions, Antitrust, & Securities Law Real Estate, Personal, & Intellectual Property Commercial Law: Contract, Payments, Security Interests, & Bankruptcy Consumer Protection Insurance & Risk Management Immigration Law Environmental Protection Law Inheritance, Estates, and Trusts
- Business Management & Operations
- Economics, Finance, & Analytics
What is Project Scope
The project scope identifies the total work (activities), processes, and decision making of the project and their relationship to stakeholders. It generally sets the boundaries for the project.
What is Project Scope Management?
Per the PMBOK, “Managing project scope is primarily concerned with defining and controlling what is and is not included in the project.”
The PMBOK recognizes 6 major scope management processes involved in managing and defining a project’s parameters. These are:
- Planning Scope Management: A scope management plan
- Collecting Requirements: A requirements management plan
- Defining Scope: (A project scope statement)
- Validating Scope: (Deliverables are inspected and reviewed).
- Controlling Scope: (Comparing scope plans against implemented).
What is a Scope Document
A project scope statement, also known as a “Statement of Work” or “Scope Document”, provides the project team with information the team needs to design and implement the project .
According to the Project Management Institute, the scope statement should include the following:
- Description of the scope
- Product acceptance criteria
- Project deliverables
- Project exclusions
- Project constraints
- Project assumptions
Other (or a more detailed breakdown) of the elements of the statement might include:
- The project name
- The project charter
- The project owner, sponsors, and stakeholders
- The problem statement
- The project goals and objectives
- The project requirements
- The project deliverables
- The project non-goals (what is out of scope)
- Milestones
- Cost estimates
It should break down all of the requirements into:
- Functional Requirements - Characteristics of the deliverables and what they do).
-
Non-Functional Requirements- The standards or quality guidelines for the deliverable that serve as constraints
- Performance Constraints: (Ex. Equipment standards)
- Development Constraints: Time, Resources, Quality
- Technical Requirements - They specify how the system needs to be designed and implemented to provide required functionality and fulfill required operational characteristics.
- Business Requirements - These are specific requirements placed by the sponsoring organization.
- User Requirements - This has to do with the User Experience of the finished product.
- Regulatory Requirements - This are generally the legal or industry requirements imposed on the project.
- Software Requirements - The programs that must be in place
- Measuring Requirements - How information is recorded on the project.
This document should be developed with the input of as many stakeholders as possible. It is particularly important to have the buy-in and approval of the project sponsor. The document must sufficiently describe deliverables to create common expectations among all stakeholders.
Gather Information to Determine Project Scope?
To identify the elements that go into the scope document, the Project Manager may undertake any of the following:
- Interviews
- Focus groups
- Facilitated groups such as JAD (joint application development)
- Group creativity techniques: brainstorming, nominal groups, delphi, mind map, affinity diagnostics
- Prototyping
- Observation
- Questions and surveys
- Group decision-making techniques: unanimity, majority, plurality, dictatorship
The scope document is generally not static. It changes as the project develops. The team will not deviate from the project scope; rather, it will react to the environment and necessary changes to carry out the project.
Documenting the changes within the scope document serve to inform all stakeholders of changes and allows the project manager to effectively manage expectations.
Requirements Traceability Matrix
The requirements traceability matrix is a tool used to link the requirements of a project to their objectives. It also allows the project manager to take the requirement through the project life cycle, and thus a structure for managing the project scope. .
Attributes associated with each requirement are recorded in the traceability matrix. The matrix will contain key information about the requirement.
Typical attributes used in the requirements traceability matrix include:
- a unique identifier,
- a textual description of the requirement,
- the rationale for inclusion,
- owner,
- source,
- priority,
- version,
- current status (active/cancelled/deferred/added/approved),
- date completed
- stability,
- complexity, and
- acceptance criteria.
What is the Work Breakdown Structure?
After identifying the requirements and deliverables, the project work should be laid out in the work breakdown structure (WBS).
WBS is a hierarchical decomposition of the project into phases, deliverables, and work packages.
More specifically, the WBS subdivides the work down into components that can be scheduled, estimated, monitored, and controlled. Complicated task are broken down as far as possible into smaller tasks. When broken down to the lowest level, each component is known as a “child”.
This attempts to estimate the duration and resources required for each activity. The WBS is organized around the phases of the project to demonstrate the work required in each phase.
At the same time, the WBS decides the work based upon the project units or functions of the project. This facilitates an understanding of the amount of work required for each function.
As such, the WBS is broken down into successive levels. The lowest level contains the most detailed description of each task. Moving up the structure, the activities are grouped based upon time and resources, project unit, or function. Each level has a progressively broader description. The highest level is the most broad description that indicate the objectives to be achieved by the tasks.
This document incorporates the project scope and deliverables. Collectively, this document will incorporate the entire scope of the project.
To create the WBS, do the following:
- List the project outputs (deliverables)
- Identify the activities required for each output
- Subdivide the activities into sub-activities and tasks
- Identify the deliverables and milestones for each task
- Identify the necessary resources for each task.
The WBS allows project managers and teams to:
- Manage the individual components of the project,
- Estimate time, cost, and resources,
- Assign Human Resources,
- Assign responsibility for activities.
The “100 Percent Rule” requires that all work be broken down into its simplest components (a child) of the next state of component (the “parent”).