Plan and manage scope

Enablers

• Determine and prioritize requirements. (ECO 2.8.1)
• Break down scope and define acceptance criteria (definition of done). (ECO 2.8.2)
• Build work packages/do some work.
• Monitor, reprioritize and validate scope. (ECO 2.8.3)

Deliverables, and Tools

Scope Management Plan

A scope management plan * is a component of the project management plan or program management plan that describes how the project scope will be defined, developed, monitored, controlled, and validated.

Scope Management Tools and Techniques

Project Requirements

Project requirements are the agreed-upon conditions or capabilities of a product, service, or outcome that the project is designed to satisfy.

• High-level requirements may already be documented and in the project charter.
• The project manager must verify that all requirements are determined and documented.
• Requirements create the foundation for building the WBS, and are verified regularly during the project execution process.

Elicitation Techniques

• Document analysis is a technique used to gain project requirements from current documentation evaluation.
• Focus groups * are an elicitation technique that brings together pre-qualified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result.
• Questionnaires * are written sets of questions designed to quickly accumulate information from a large number of respondents.
• Benchmarking * is the comparison of actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance.
• An interview * is a formal or informal approach to elicit information from stakeholders by talking with them directly.

Elicitation Techniques

Decision-making techniques are used by a group to reach a decision.

Voting method:

• Unanimity * • Plurality *
• Majority • Autocratic

Mind mapping *

Affinity diagram *

Observations , also referred to as job shadowing

Facilitated workshops . There are different types of workshops used depending on the industry you are working in:

• Joint application design/development (JAD)
• Quality function deployment (QFD)

A context diagram * is a visual depiction of the product scope showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it.

Prototype and Storyboarding

Requirements Documentation

• Business requirements: High-level needs of an organization.
• Stakeholder requirements.
• Solution requirements.
• Transition and readiness requirements.
• Project requirements.
• Quality requirements.

Requirements Management Plan

The requirements management plan * is a component of the project or program management plan that describes how requirements will be analyzed, documented, and managed.

Components of a Project Requirements Management Plan:

• How requirements activities will be planned, tracked, and reported.
• Configuration management activities such as how changes to the requirements will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; and what authorization level is required to approve these changes.
• Requirements prioritization process, which defines how project requirements will be analyzed and prioritized.
• Metrics that will be used and the rationale for using them.
• Traceability structure stating which requirement attributes will be captured on the traceability matrix, the forward and backward chain of traceability, and the categorization of requirements.

Requirements Traceability Matrix

The requirements traceability matrix * is a grid that links product requirements from their origin to the deliverables that satisfy them. The purpose of this matrix is to justify each requirement determined and to link it directly to the business and project objectives.

There are a number of tracing requirements used when creating the traceability matrix:

• Business needs, opportunities, goals, and objectives.
• Project objectives.
• Project scope and WBS deliverables.
• Product design.
• Product development.
• Test strategy and test scenarios.
• High-level requirements to more detailed requirements.
• Work package mapping.
• Stakeholder reference, so you can track each individual requirement to a stakeholder.

Guidelines for Collecting Project Requirements

Guidelines for collecting project requirements are as follows:

• Review the scope management plan.
• Review the requirements management plan.
• Review the stakeholder engagement plan.
• Review the project charter.
• Review the stakeholder register.
• Use tools and techniques such as interviews, focus groups, facilitated workshops, interpersonal and team skills, decision-making techniques, questionnaires and surveys, observations, prototypes, benchmarking, context diagrams, and document analysis to collect requirements for the project.
• Document the requirements and create a requirements traceability matrix.

Project Scope Statement

The project scope statement * is the description of the project scope, major deliverables, assumptions, and constraints.

A project scope statement include:

• Project scope description
• Acceptance criteria
• Deliverable
• Project exclusion
• Constraints
• Assumptions

Product Analysis

Product analysis * is a tool to define scope that generally means asking questions about a product and forming answers to describe the use, characteristics, and other relevant aspects of what is going to be manufactured

• Product breakdown
• Systems analysis
• Requirements analysis
• Systems engineering
• Value engineering
• Value analysis

Guidelines to Develop a Project Scope Statement

• Review the scope management plan for the activities for developing, monitoring, and controlling the project scope.
• Review the project charter for the high-level project description, product characteristic, and project approval requirements.
• Review the requirements documentation to select the requirements that will be included in the project.
• Review the OPAs
• Use tools and techniques such as expert judgment, product analysis, alternatives analysis, and facilitated workshops to define the project scope.
• Document the project scope statement and update any project documents, as needed.

WBS

The work breakdown structure (WBS) * is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables.

Work Packages

The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed is called a work package *. A work package must describe a deliverable that can be adequately scheduled, budgeted, and assigned to an individual person or group.

WBS Dictionary

The WBS dictionary * is a document that provides detailed deliverable, activity, and scheduling information about each component in the work breakdown structure.

The WBS dictionary can include any of the following:

• Code of account identifier
• Description of work
• Assumptions and constraints
• Responsible organization
• Schedule milestones
• Associated schedule activities
• Resources required to complete the work
• Cost estimations
• Quality requirements
• Acceptance criteria
• Technical references
• Agreement information

Decomposition

Decomposition * is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.

Control Accounts

A control account * is a management control point where scope, budget, actual cost, and schedule are integrated and compared to earned value for performance measurement.

• Control accounts are associated with different work packages and verified against the earned value to check performance.
• Work packages are assigned a control account and work will be managed within that account throughout the project.
• Control accounts can contain more than one work package, but each work package is assigned to only one control account.

Planning Packages

A planning package * is a WBS component below the control account with known work content but without detailed schedule activities.

Code of Accounts

A code of accounts * is a numbering system used to uniquely identify each component of the WBS.

Scope Baseline

The scope baseline * is the approved version of a scope statement, WBS, and its associated WBS dictionary, that can be changed using formal change control procedures and is used as a basis for comparison to actual results.

A scope baseline may include any of the following components:

• Project scope statement
• WBS
• Work package
• Planning package
• WBS dictionary

Guidelines to Create a WBS

• Review the scope management plan
• Review the project scope statement
• Review the requirements documentation
• Review the Enterprise Environmental Factors (EEFs)
• Review Organizational Process Assets (OPAs)
• Use tools and techniques such as decomposition
• Use expert judgment
• Include notes on work products that may be delivered incrementally.
• Document the scope baseline and update any project documents, as needed.

Product and Iteration Backlogs

A product backlog is essentially a list of the expected work to deliver the product.

A project’s product backlog changes throughout the project.

Grooming and refining the product backlog is an ongoing exercise, typically scheduled in weekly or monthly intervals.

Product backlog items (PBI) drop off when work is completed.

• PBIs are edited and clarified as more is known or as product requirements may change.
• PBIs are continually added as necessary when more work must be done.

The iteration backlog includes items from the product backlog that can conceivably be completed within the time period based on the team’s capacity.

Teams must estimate the effort size of the work and understand the priorities of the business.

User Stories

• Project deliver value.
• User stories help teams focus on that value provided to the user.
• User stories frame who is to benefit from the work of the team.
• Framing the user’s desire as a story instead of a detailed requirement or specification enables the team to focus on the user and what they value.

Tools and Techniques for Verifying the Scope