pmbok - cap 10 scope management

8/12/2019 PMBOK - CAP 10 Scope Management

1/42

Presentation Compiled by: Shaymaa Kadry, PMPE-mail: [email protected]: Shaymaa_kadry

Chapter Ten - PMBOK- 4 th Edition


2/42

Project Scope Management includes the processes required to ensure that the

project includes all the work required, and only the work required, to complete

the project successfully. Project scope management is primarily concerned with

defining and controlling what is and is not included in the project.

The processes used to manage project scope, as well as the supporting tools and

techniques, vary by application area and are usually defined as part of the project

life cycle. The approved detailed project scope statement and its associated WBSand WBS dictionary are the scope baseline for the project. This baselined scope is

then monitored, verified, and controlled throughout the lifecycle of the project.


3/42

Product scope: The features and functions that characterize a product,service, or result. Completion of the product scope is measured againstthe product requirements.

Project scope: The work that needs to be accomplished to deliver aproduct, service, or result with the specified features and functions.Completion of the project scope is measured against the projectmanagement plan


4/42


5/42

It is the process of defining and documenting stakeholders needs to meet the project

objectives. Requirements include the quantified and documented needs and expectations

of the sponsor, customer, and other stakeholders. These requirements need to be elicited,

analyzed, and recorded in enough detail to be measured once project execution begins.

Collecting requirements is defining and managing customer expectations. Requirements

become the foundation of the WBS. Cost, schedule, and quality planning are all built upon

these requirements. The development of requirements begins with an analysis of the

information contained in the project charter and the stakeholder register.

Many organizations categorize requirements into project requirements and product

requirements. Project requirements can include business requirements, project

management requirements, delivery requirements, etc. Product requirements can include

information on technical requirements, security requirements, performance requirements

etc.


6/42

InputsInputs

Tools andTechniquesTools and

Techniques

OutputsOutputs

Project CharterStakeholder Register

InterviewsFocus GroupsFacilitated WorkshopsGroup Creativity techniquesGroup decision making techniquesQuestionnaires and surveysObservations

Prototypes

Requirements documentationRequirements management plan

Requirements traceability matrix


7/42

InputsInputs

Project Charter: used to provide the high-level project requirements and high-levelproduct description of the project so that detailed product requirements can bedeveloped.

Stakeholder Register: used to identify stakeholders that can provide information ondetailed project and product requirements .


8/42

Tools and TechniquesTools and Techniques

Focus groups: bring together prequalified stakeholders and subject matter experts tolearn about their expectations and attitudes about a proposed product, service, orresult. A trained moderator guides the group through an interactive discussion,designed to be more conversational than a one-on-one interview.

Interviews: a formal or informal approach to discover information from stakeholdersby talking to them directly. It is typically performed by asking prepared andspontaneous questions and recording the responses. Interviews are often conductedone-on-one, but may involve multiple interviewers and/or multiple interviewees.Interviewing experienced project participants, stakeholders, and subject matter expertscan aid in identifying and defining the features and functions of the desired projectdeliverables


9/42


Facilitated Workshops: focused sessions that bring key cross-functional stakeholderstogether to define product requirements. Workshops are considered a primarytechnique for quickly defining cross-functional requirements and reconcilingstakeholder differences.Its benefits: can build trust, foster relationships, and improve communication amongthe participants which can lead to increased stakeholder consensus. Another benefit ofthis technique is that issues can be discovered and resolved more quickly than inindividual sessions.


10/42


Group Creativity Techniques: Several group activities can be organized to identifyproject and product requirements. E.g.,:

Brainstorming: I ts used to generate and collect multiple ideas related to project andproduct requirements.Nominal group technique: It enhances brainstorming with a voting process used torank the most useful ideas for further brainstorming or for prioritization.The Delphi Technique: A selected group of experts answers questionnaires &provides feedback regarding responses from each round of requirements gathering.Idea/mind mapping: Ideas created through individual brainstorming are combined

into a single map to reflect commonality & differences in understanding, & generatenew ideas.Affinity diagram.: It allows large numbers of ideas to be sorted into groups forreview and analysis.


11/42


Group Decision Making Techniques: i s an assessment process of multiple alternativeswith an expected outcome in the form of future actions resolution. These techniquescan be used to generate, classify, and prioritize product requirements. E.g.,:

Questionnaires and Surveys: Questionnaires and surveys are written sets of questionsdesigned to quickly accumulate information from a wide number of respondents.Questionnaires and/or surveys are most appropriate with broad audiences, whenquick turnaround is needed, and where statistical analysis is appropriate.

Unanimity: Everyone agrees on a single course of action.

Majority: Support from more than 50% of the members of the group.Plurality: The largest block in a group decides even if a majority is not achieved.Dictatorship: One individual makes the decision for the group.


12/42


Observations: provide a direct way of viewing individuals in their environment andhow they perform their jobs or tasks and carry out processes. It is particularly helpfulfor detailed processes when the people that use the product have difficulty or arereluctant to articulate their requirements. Its also called job shadowing, and usuallydone externally by the observer viewing the user performing his or her job. It can alsobe done by a participant observer who actually performs a process or procedure toexperience how it is done to uncover hidden requirements.

Prototypes: a method of obtaining early feedback on requirements by providing aworking model of the expected product before actually building it. Since prototypesare tangible, it allows stakeholders to experiment with a model of their final productrather than only discussing abstract representations of their requirements. Prototypessupport the concept of progressive elaboration because they are used in iterative cyclesof mock-up creation, user experimentation, feedback generation, and prototyperevision. When enough feedback cycles have been performed, the requirements

obtained from the prototype are sufficiently complete to move to a design or buildphase.


13/42

OutputsOutputs

Requirements Documentation: describes how individual requirements meet the businessneed for the project. Before being baselined, requirements must be unambiguous(measurable and testable), traceable, complete, consistent, and acceptable to keystakeholders. Components of requirements documentation can include, but, are notlimited to:

Business need or opportunity to be seized, describing the limitations of the current situation andwhy the project has been undertaken;Business and project objectives for traceability;Functional requirements, describing business processes, information, and interaction with theproduct, as appropriate which can be documented textually in a requirements list, in models, orboth;Non-functional requirements, such as level of service, performance, safety, security, compliance,supportability, retention/purge, etc.;Quality requirements;Acceptance criteria;Business rules stating the guiding principles of the organization;Impacts to other organizational areas, such as the call center, sales force, technology groups;Impacts to other entities inside or outside the performing organization;

Support and training requirements; andRequirements assumptions and constraints.


14/42

OutputsOutputs

Requirements Management Plan : It documents how requirements will be analyzed,documented, and managed throughout the project. Components of the requirementsmanagement plan can include, but are not limited to:

How requirements activities will be planned, tracked, and reported;Configuration management activities such as how changes to the product, service, or resultrequirements will be initiated, how impacts will be analyzed, how they will be traced, tracked, rand reported, as well as the authorization levels required to approve these changes;Requirements prioritization process;Product metrics that will be used and the rationale for using them; andTraceability structure, that is, which requirements attributes will be captured on the traceabilitymatrix and to which other project documents requirements will be traced.


15/42

OutputsOutputs

Requirements Traceability Matrix: It is a table that links requirements to their origin andtraces them throughout the project life cycle. The implementation of a requirementstraceability matrix helps ensure that each requirement adds business value by linking it tothe business and project objectives. It provides a structure for managing changes to theproduct scope. It includes, but is not limited to tracing:

Attributes associated with each requirement can be recorded in the requirementstraceability matrix. These attributes help to define key information about the requirement.Example for attributes: a unique identifier, a textual description of the requirement, therationale for inclusion, owner, source, priority, version, current status (such as active,

cancelled, deferred, added, approved) and date completed., stability, complexity, andacceptance criteria.

Requirements to business needs, opportunities, goals, and objectives;Requirements to project objectives;Requirements to project scope/WBS deliverables;Requirements to product design;Requirements to product development;Requirements to test strategy and test scenarios; and

High-level requirements to more detailed requirements.


16/42

The process of developing a detailed description of the project and product. The

preparation of a detailed project scope statement is critical to project success and buildsupon the major deliverables, assumptions, and constraints that are documented during

project initiation. During planning, the project scope is defined and described with greater

specificity as more information about the project is known. Existing risks, assumptions,

and constraints are analyzed for completeness; additional risks, assumptions, andconstraints are added as necessary.


17/42

InputsInputs


Techniques

OutputsOutputs

Project CharterRequirements documentationOrganizational Process Assets

Expert JudgmentProduct analysisAlternatives definitionFacilitated workshops

Project Scope StatementProject documents updates


18/42

InputsInputs

Organizational Process Assets: Examples of organizational process assets that caninfluence the Define Scope process include, but are not limited to: Policies, procedures,and templates for a project scope statement - Project files from previous projects -Lessons learned from previous phases or projects.

Project Charter: provides the high-level project description and product characteristics.It also contains project approval requirements.

Requirements documentations


19/42


Product Analysis: Each application area has one or more generally accepted methodsfor translating project objectives into tangible deliverables and requirements. Productanalysis includes techniques such as product breakdown, systems analysis, systemsengineering, value engineering, value analysis, and functional analysis.

Alternatives Identification: Identifying alternatives is a technique used to generatedifferent approaches to execute and perform the work of the project. A variety ofgeneral management techniques is often used here, the most common of which arebrainstorming and lateral thinking.

Expert Judgment

Facilitated Workshops


20/42

OutputsOutputs

Project Scope Statement : It includes: Product scope description: Progressively elaborates the characteristics of the product,

service, or result described in the project charter and requirements documentation. Product acceptance criteria: Defines the process and criteria for accepting completed

products, services, or results. Project deliverables: include both the outputs that comprise the product or service of

the project, as well as ancillary results, such as project management reports anddocumentation.

Project exclusions: identifies what is excluded as from the project. Explicitly statingwhat is out of scope for the project helps to manage stakeholders expectations.

Project constraints: Lists and describes the specific project constraints associated with

the project scope that limits the teams options, for example, a predefined budget orany imposed dates or schedule milestones that are issued by the customer orperforming organization.

Project assumptions: Lists and describes the specific project assumptions associatedwith the project scope and the potential impact of those assumptions if they prove tobe false. Project teams frequently identify, document, and validate assumptions as partof their planning process.


21/42

OutputsOutputs

Project Documents updates: It may be updated include, but are not limited to:

Stakeholder register,Requirements documentation, andRequirements traceability matrix.


22/42

Create WBS is the process of subdividing project deliverables and project work into

smaller, more manageable components. The work breakdown structure (WBS) is a

deliverable-oriented hierarchical decomposition of the work to be executed by the project

team to accomplish the project objectives and create the required deliverables, with each

descending level of the WBS representing an increasingly detailed definition of the project

work. The WBS organizes and defines the total scope of the project, and represents thework specified in the current approved project scope statement

The planned work is contained within the lowest level WBS components, which are

called work packages. A work package can be scheduled, cost estimated, monitored, andcontrolled. In the context of the WBS, work refers to work products or deliverables that are

the result of effort and not to the effort itself.


23/42

InputsInputs


Techniques

OutputsOutputs

Project Scope StatementRequirements documentationsOrganizational Process Assets

Decomposition

Work Breakdown StructureWBS DictionaryScope BaselineProject documents updates


24/42

InputsInputs

Organizational Process Assets: include, but are not limited to: Policies, procedures,and templates for the WBS - Project files from previous projects - Lessons learned fromprevious projects.

Project Scope Statement

Requirements Documentations


25/42


Decomposition: is the subdivision of project deliverables into smaller, moremanageable components until the work and deliverables are defined to the workpackage level. The work package level is the lowest level in the WBS, and is the point atwhich the cost and schedule for the work can be reliably estimated.

Decomposition of the total project work into work packages generally involves the

following activities: Identifying and analyzing the deliverables and related work, Structuring and organizing the WBS, Decomposing the upper WBS levels into lower level detailed components, Developing and assigning identification codes to the WBS components, and Verifying that the degree of decomposition of the work is necessary and sufficient.

The WBS structure can be created in a number of forms, such as: Using phases of the project life cycle as the first level of decomposition, with the product

and project deliverables inserted at the second level, Using major deliverables as the first level of decomposition, Using subprojects which may be developed by organizations outside the project team,

such as contracted work. The seller then develops the supporting contract workbreakdown structure as part of the contracted work.


26/42

OutputsOutputs

Work Breakdown Structure: a deliverable-oriented hierarchical decomposition of thework to be executed by the project team, to accomplish the project objectives and createthe required deliverables, with each descending level of the WBS representing anincreasingly detailed definition of the project work. The WBS is finalized by establishingcontrol accounts for the work packages and a unique identifier from a code of accounts.These identifiers provide a structure for hierarchical summation of costs, schedule, andresource information. A control account is a management control point where scope, cost,and schedule are integrated and compared to the earned value for performancemeasurement. Control accounts are placed at selected management points in the WBS.Each control account may include one or more work packages, but each of the workpackages must be associated with only one control account.

WBS Dictionary: It is a companion document to the WBS. The detailed content of thecomponents contained in a WBS, including work packages and control accounts, can bedescribed in the WBS dictionary. For each WBS component, the WBS dictionary includesa code of account identifier, description of work, responsible organization, list of schedulemilestones, associated schedule activities, resources required, cost estimates, Qualityrequirements, acceptance criteria, technical references, and contract information.


27/42


28/42

Sample Work Breakdown Structure Organized by Phase


29/42

Sample Work Breakdown with Major Deliverables


30/42


31/42

Verify Scope is the process of formalizing acceptance of the completed project

deliverables. Verifying scope includes reviewing deliverables with the customer or

sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance

of deliverables by the customer or sponsor. Scope verification differs from quality control

in that scope verification is primarily concerned with acceptance of the deliverables, while

quality control is primarily concerned with correctness of the deliverables and meeting thequality requirements specified for the deliverables. Quality control is generally performed

before scope verification, but these two processes can be performed in parallel.


32/42

InputsInputs


Techniques

OutputsOutputs

Project Management PlanRequirements DocumentationsRequirements tractability MatrixValidated deliverables

Inspection

Accepted DeliverablesChange requestsProject Documents updates


33/42

InputsInputs

Project Management Plan: The project management plan contains the scope baseline.Components of the scope baseline include: Project scope statement - WBS. - WBSdictionary.

Requirements Documentation

Requirements Traceability Matrix

Validated Deliverables


34/42


Inspection: includes activities such as measuring, examining, and verifying todetermine whether work and deliverables meet requirements and product acceptancecriteria. Inspections are variously called reviews, product reviews, audits, andwalkthroughs. In some application areas, these different terms have narrow andspecific meanings


35/42

OutputsOutputs

Accepted Deliverables: Deliverables that meet the acceptance criteria are formally signedoff and approved by the customer or sponsor. Formal documentation received from thecustomer or sponsor acknowledging formal stakeholder acceptance of the projectsdeliverables is forwarded to the Close Project or Phase process

Change Requests: Those completed deliverables that have not been formally accepted aredocumented, along with the reasons for non-acceptance. Those deliverables may require achange request for defect repair. The change requests are processed for review anddisposition through the Perform Integrated Change Control process

Project Document Updates: Project documents that may be updated as a result of theVerify Scope process include any documents that define the product or report status onproduct completion.


36/42

Control Scope is the process of monitoring the status of the project and product scopeand managing changes to the scope baseline. Controlling the project scope ensures allrequested changes and recommended corrective or preventive actions are processedthrough the Perform Integrated Change Control process. Project scope control is also usedto manage the actual changes when they occur and is integrated with the other controlprocesses. Uncontrolled changes are often referred to as project scope creep. Change isinevitable, thereby mandating some type of change control process.


37/42

InputsInputs

Tools and

Techniques

Tools and

Techniques

OutputsOutputs

Project Management PlanWork Performance InformationRequirements Documentation

Requirements Traceability MatrixOrganizational Process Assets

Variance Analysis

Work performance Measurements

Organizational Process Assets (Updates)Change RequestsProject Management Plan updatesProject document updates


38/42

InputsInputs

Project Management Plan: it contains the following information that is used tocontrol scope:

Scope baseline: The scope baseline is compared to actual results to determineif a change , corrective action, or preventive action is necessary.

Scope management plan: The scope management plan describes how the

project scope will be managed and controlled. Change management plan: The change management plan defines the processfor managing change on the project.

Configuration management plan: The configuration management plandefines those items that are configurable, those items that require formalchange control, and the process for controlling changes to such items.

Requirements management plan: The requirements management plan canincludes how requirements activities will be planned, tracked, and reportedand how changes to the product, service, or result requirements will beinitiated. It also describes how impacts will be analyzed and the authorizationlevels required to approve these changes;


39/42

InputsInputs

Requirements Documentation

Requirements Traceability Matrix

Organizational Process Assets: The organizational process assets that can influencethe Control Scope process include but are not limited to:

Existing formal and informal scope control-related policies, procedures, andguidelines,

Monitoring and reporting methods to be used.

Work Performance Information


40/42


Variance Analysis: Project performance measurements are used to assess themagnitude of variation. Important aspects of project scope control include determiningthe cause of variance relative to the scope baseline and deciding whether corrective orpreventive action is required.


41/42

OutputsOutputs

Work Performance Measurements: Measurements can include planned vs. actualtechnical performance or other scope performance measurements. This information isdocumented and communicated to stakeholders.

Organizational Process Assets Updates: Organizational process assets that may beupdated include, but are not limited to:

Causes of variances, Corrective action chosen and the reasons, and Other types of lessons learned from project scope control.

Change Requests: Analysis of scope performance can result in a change request to thescope baseline or other components of the project management plan. Change requests caninclude preventive or corrective actions or defect repairs. Change requests are processedfor review and disposition according to the Perform Integrated Change Control process.


42/42