PMP Certification Study Notes 5 – Project Scope Management


PMP Scope Management

Note to Aspirants taking the exam from 26 March 2018 onwards: please click here to read the updated PMP® Study Notes based on PMBOK® Guide 6th Edition. Happy learning!

Introduction: This part of the PMP® exam study notes is based on chapter 5 of PMBOK® Guide 5th Edition. More information on my PMP® certification exam preparation can be found at my PMP® exam and certification journey (with free PMP® study resources and tips) here.

  • ensure the inclusion of all and only the work required to complete the project successfully
  • Product Scope – requirements needed to be fulfilled to create the product, assessed against the product requirements and WBS
  • Project Scope – activities and processes needed to be performed to deliver the product scope, assessed against the scope baseline (scope statement, WBS and WBS dictionary), e.g. including testing & quality assurance, assessed against the PM plan
  • scope management to prevent scope creep (additional requirements added without any proper control)
  • The completion of project scope is measured against the project management plan whereas the completion of product scope is measured against the product requirements/WBS
  • gold plating – additional requirements initiated by the team members to exceed expectation, considered a subset of scope creep
  • Scope Baseline: scope statement + WBS + WBS dictionary
  • WBS includes only the deliverables/outcomes/results (not actions)

Plan Scope Management

  • Scope Management Plan: how the scope will be defined, validated and controlled
  • including how to prevent scope creep, how to handle change requests, escalation path for disagreement on scope elements between stakeholders, process for creating scope statement, WBS, processing CR, how the deliverables will be accepted
  • Requirements Management Plan: how the requirements will be managed, documented and analyzed,
  • including how to process requirements, address missed requirements, configuration management, prioritize requirements, metrics (and rationale) for defining the product, define the traceability structure (in RTM), authorization level for approving new requirements
  • important: primary means to understand and manage stakeholder expectations

Collect Requirements

  • Requirement: a condition/capability that must be met /possessed by a deliverable to satisfy a contract/standard/etc., including quantified/documented needs, wants, expectation of the sponsor/stakeholder/customer
    • Business requirements – support business objectives of the company
    • Stakeholder requirements
    • Solution requirements – functional (product behavior) and nonfunctional requirements (reliability, security, performance, safety, etc.)
    • Transitional requirements : temporary capability including data conversion/tracking/training
    • Project requirements : actions/processes/conditions the project needs to met
    • Quality requirements : quality criteria defined by stakeholders
  • Requirements Collection Tools
    • interviewing (expert interviewing)
    • focus groups (with SME and pre-qualified stakeholders)
    • facilitated workshops (QFD (Quality Function Deployment) – capture VOC voice of customer, translate customer needs into requirements; JAD (Joint Application Design) – facilitated workshop for IT and knowledge workers)
    • questionnaires and surveys
    • observation (shadowing or Gemba)
    • prototypes
    • context diagrams (diagrams showing input/source and output, to show how people interact with the system)
    • document analysis
  • Group Creativity Techniques: brainstorming, nominal group technique (to rank brainstormed ideas by voting anonymously), mind-mapping, affinity diagram (KJ method – group ideas into larger categories based on their similarity and give titles to each group), Delphi technique (for experts with widely varying opinions, all participants are anonymous, evaluation of ideas funneled by a facilitator), Multi-criteria Decision Analysis (with a decision matrix)
  • Group Decisions-making Techniques: Analytic Hierarchy Process (AHP, for complex decisions, give different weighs to factors to build an hierarchy), Voting (unanimous, majority >50%, plurality, dictatorship)
  • Requirements Traceability Matrix tracks requirements from origins to deliverables, including source of requirements and completion status, effective to prevent gold plating (also work with work authorization system)
  • requirement documentation needs to be unambiguous, traceable, compete, consistent and acceptable to key stakeholders and is approved by the customer and other stakeholders

Define Scope

  • project & product scope, outlines what will be and what will NOT be included in the deliverables, including details of risks, constraints and assumptions
  • vs project charter which includes high-level descriptions
  • provides alternatives if the budget and schedule could not meet management’s expectations
  • Product analysis includes techniques such as product breakdown, systems analysis, requirements analysis, systems engineering, value engineering, and value analysis
  • value engineering is a part of the product analysis technique (Value Engineering (value analysis, value management, value methodology) – finding alternatives to constraints to improve product/reduce cost without sacrificing the scope)
  • project scope statement includes objectives, (project and product) scope, requirements, boundaries, deliverables, acceptance criteria, constraints, assumptions, milestones, cost estimation, specifications, configuration management requirements, approval requirements, etc.
  • The scope statement is progressively elaborated

Create WBS

  • the WBS must be created (if take on a running project without WBS, stop the project and prepare the WBS first)
  • WBS is a structured hierarchy created by the organization/stakeholders, can be in an organization chart or table form, based on the project deliverables (not tasks needed)
  • can be a template in OPA
  • a higher level above a work package is ‘control account‘ (control point where scope, cost and schedule are compared to earn value for performance measurement), a work package can have only ONE control account
  • WBS includes 100% of scope (100% rule)
  • code of accounts: a numbering system to identify WBS components
  • chart of accounts: a list of all account names and numbers
  • 1.1 for the 2nd level, 1.1.1 for the 3rd level
  • WBS is a decomposition tool to break down work into lowest level manageable (time and cost can be estimated, work package can be assigned to a team member) work packages, e.g. by phase or major deliverables
  • different work packages can be at different levels of decompositions
  • WBS does not show dependencies between work packages, but a WBS dictionary does (WBS dictionary clarifies WBS by adding additional information)
  • the major deliverables should always be defined in terms of how the project will actually be organized, for a project with phases, the decomposition should begin with the phase first
  • scope baseline, an output from Create WBS, is created by the project team
  • the work packages are broken down enough to delegate to a staff, usu. 8 – 80 hours work

Validate Scope

  • gain formal acceptance of deliverables from customer/stakeholders (e.g. obtain customer sign off, requirements validations, etc.) near the end of project/phase/each deliverable, e.g. user acceptance test
  • work performance data tells how the deliverables were created, work performance data includes non-conformance and compliance data
  • change requests may be an output
  • if no formal sign off is received as stipulated, follow the pre-defined process in PM plan, e.g. escalation to management
  • often preceded by Control Quality Process to give the verified deliverable as input to this process, verified deliverables is fed from the control quality process
  • vs Control Quality: the process of monitoring/recording results of executing quality activities to assess performance and recommend necessary changes, e.g. unit testing -> high quality vs low quality
  • need to perform even in case of early termination/cancellation of the project to save any usable deliverables for other projects

Control Scope

  • assessing additional requirements by the customer or proactively overlooking the project scope
  • measure the work product against the scope baseline to ensure the project stays on track proactively, may need preventive, corrective actions or defect repair
  • to prevent unnecessary changes (either internally or externally requested) to the project
  • a documented and enforced change control process
  • the customer has the ultimate authority to change scope while the senior management can make use of management reserves
  • variance analysis – method to compare planned (baseline) and actual work and determine the causes/actions e.g. update baseline (keep the variance) or preventive/corrective actions, both need CR
  • work performance info – scope variance, causes, recommended action
  • may update the inputs – requirements documentation & requirement traceability matrix & lessons learnt in OPA
  • in general, disagreement should be resolved in favor of the customer

 


Additional PMP® Study Resources

If you find the above PMP® study notes useful, you may want to check out the recommended PMP® Exam study resources on my website (all are free):

 


PMP® Study Notes for PMP® Exam from 26 March 2018 onwards

 

 

 

Introduction: This part of the PMP® exam study notes (updated for PMP® Exam 2018) is based on Section 5 of new PMBOK® Guide 6th Edition. The study notes have been rewritten to reflect the latest changes in the PMBOK® Guide for the new PMP® Exam. More information on my PMP® certification exam preparation can be found at my PMP® exam and certification journey (with free PMP® study resources and tips) here.

Please note that the study notes below is intended to include only the most important or esaily confused PMP® concepts. It is by no means complete in the sense that one can rely on it to be fully prepared for the PMP® Exam. Aspirants are advised to make use of this piece of study notes for revision purposes. Wish you PMP® success!

Project Scope Management

  • The project manager would need to ensure the inclusion of all and only the work required to complete the project successfully (to achieve project objectives to deliver business values).
  • The primary aim of scope management to define the exact scope of work and to prevent scope creep (additional requirements added without any proper control) or gold-plating (added by the project team with a view to impressing stakeholders).
  • Product Scope – requirements needed to be fulfilled to create the product, assessed against the product requirements and WBS
  • Scope Baseline: scope statement + WBS + WBS dictionary
    • WBS includes only the deliverables/outcomes/results (not actions)
  • Project Scope – activities and processes needed to be performed to deliver the product scope, assessed against the scope baseline (scope statement, WBS and WBS dictionary), e.g. including testing & quality assurance, assessed against the Project Management Plan
    • The completion of project scope is measured against the project management plan whereas the completion of product scope is measured against the product requirements/WBS

Plan Scope Management


  • Inputs: Project Charter, Project Management Plan, EEF, OPA
  • Tools & Techniques: Expert Judgement, Data Analysis, Meetings
  • Outputs: Scope Management Plan, Requirements Management Plan

  • Scope Management Plan (will form part of the Project Management Plan): how the scope will be defined, validated and controlled
    • includes how to prevent scope creep, how to handle change requests, escalation path for disagreement on scope elements between stakeholders, processes for creating scope statement, WBS, processing CR, how the deliverables will be accepted
  • Requirements Management Plan: how the requirements will be managed, documented and analyzed
    • includes how to process requirements, address missed requirements, configuration management, prioritize requirements, metrics (and rationale) for defining the product, define the traceability structure (in RTM), authorization level for approving new requirements
    • [important] the requirement management plan is the primary means to understand and manage stakeholder expectations

Collect Requirements


  • Inputs: Project Charter, Project Management Plan, Project Documents, Business Documents, Agreements, EEF, OPA
  • Tools & Techniques: Expert Judgement, Data Gathering, Data Analysis, Decision Making, Data Representation, Interpersonal and Team Skills, Content Diagram, Prototypes
  • Outputs: Requirements Documentation, Requirements Traceability Matrix

  • Requirement: a condition/capability that must be met /possessed by a deliverable to satisfy a contract/standard/etc., including quantified/documented needs, wants, expectation of the sponsor/stakeholder/customer
    • Business requirements – support business objectives of the company
    • Stakeholder requirements
    • Solution requirements – functional (product behavior) and nonfunctional requirements (reliability, security, performance, safety, etc.)
    • Transitional requirements : temporary capability including data conversion/tracking/training
    • Project requirements : actions/processes/conditions the project needs to met
    • Quality requirements : quality criteria defined by stakeholders
  • Requirements Collection Tools
    • Data Gathering
      • Brainstorming
      • Interviews
      • Focus groups
      • Questionnaires and surveys
      • Benchmarking
    • Data Analysis
      • Document analysis
    • Data Representation
      • Affinity Diagram: for identifying a large number of ideas by grouping similar ideas together
      • Mind Mapping: to generate ideas with the process of backtracking
  • Requirements Traceability Matrix tracks requirements from origins to deliverables, including source of requirements and completion status, effective to prevent gold plating (also work with work authorization system)
  • Requirement documentation needs to be unambiguous, traceable, compete, consistent and acceptable to key stakeholders and is approved by the customer and other stakeholders

Define Scope


  • Inputs: Project Charter, Project Management Plan, Project Documents, EEF, OPA
  • Tools & Techniques: Expert Judgement, Data Analysis, Decision Making, Interpersonal and Team Skills, Product Analysis
  • Outputs: Project Scope Statement, Project Documents Updates

  • to define both the project & product scope in details, outlines what WILL and what WILL NOT be included in the deliverables, including details of constraints and assumptions
    • vs project charter which includes only high-level descriptions
  • may provide alternatives if the budget and schedule could not meet management’s expectations
  • Product analysis includes techniques such as:
    • product breakdown
    • systems analysis
    • requirements analysis
    • systems engineering
    • value engineering – a part of product analysis technique (Value Engineering (value analysis, value management, value methodology) with a view to finding alternatives to constraints to improve product/reduce cost without sacrificing the scope)
    • value analysis
  • Project Scope Statement includes objectives, (project and product) scope, requirements, boundaries, deliverables, acceptance criteria, constraints, assumptions, milestones, cost estimation, specifications, configuration management requirements, approval requirements, etc.
    • the scope statement is usually progressively elaborated throughout the project

Create WBS


  • Inputs: Project Management Plan, Project Documents, EEF, OPA
  • Tools & Techniques: Expert Judgement, Decomposition
  • Outputs: Scope Baseline, Project Documents Updates

  • the WBS must be created for every project (if you take on a running project without WBS, you must stop the project immediately and prepare the WBS first)
    • WBS is a structured hierarchy created by the organization/stakeholders, can be in an organization chart or table form, based on the project deliverables (not tasks needed)
    • WBS is a decomposition tool to break down work into lowest level manageable (time and cost can be estimated, work package can be assigned to a team member) work packages, e.g. by phase or major deliverables
    • the work packages are broken down enough to delegate to a staff, usu. 8 – 80 hours work and different work packages can be at different levels of decompositions
    • WBS does not show dependencies between work packages, but a WBS dictionary does (WBS dictionary clarifies WBS by adding additional information)
    • WBS includes 100% of scope (100% rule)
    • can be a template in OPA
  • a higher level above a work package is ‘control account‘ (control point where scope, cost and schedule are compared to earn value for performance measurement)
    • a work package can have only ONE control account
  • code of accounts: a numbering system to identify WBS components
  • chart of accounts: a list of all account names and numbers
    • 1.1 for the 2nd level, 1.1.1 for the 3rd level
  • the major deliverables should always be defined in terms of how the project will actually be organized, for a project with phases, the decomposition should begin with the phase first
  • Scope Baseline, an output from Create WBS, includes:
    • WBS (Work Breakdown Structure)
    • WBS Dictionary
    • Scope Statement
    • Scope Management Plan
  • Scope Baseline is to be created by the project team

Validate Scope


  • Inputs: Project Management Plan, Project Documents, Verified Deliverables, Work Performance Data
  • Tools & Techniques: Inspection, Decision Making
  • Outputs: Accepted Deliverables, Work Performance Information, Change Requests, Project Documents Updates

  • the purpose of this process is to gain formal acceptance of deliverables from customer/stakeholders (e.g. obtain customer sign off, requirements validations, etc.) near the end of project/phase/each deliverable, e.g. user acceptance test
    • change requests may be an output as stakeholders may request changes to the deliverables
    • if no formal sign off is received as stipulated, the Project Manager needs to follow the pre-defined process in PM plan, e.g. escalation to management
  • work performance data tells how the deliverables were created, work performance data includes non-conformance and compliance data
  • Validate Scope is often preceded by Control Quality Process to give the verified deliverable as input to this process, verified deliverables is fed from the control quality process
    • vs Control Quality: the process of monitoring/recording results of executing quality activities to assess performance and recommend necessary changes, e.g. unit testing -> high quality vs low quality
  • need to perform even in case of early termination/cancellation of the project to save any usable deliverables for other projects

Control Scope


  • Inputs: Project Management Plan, Project Documents, Work Performance Data, OPA
  • Tools & Techniques: Data Analysis
  • Outputs: Work Performance Information, Change Requests, Project Management Plan Updates, Project Documents Updates

  • Control Scope is performed when assessing additional requirements by the customer or the project manager proactively overlooking the project scope
    • to prevent unnecessary changes (either internally or externally requested) to the project
  • measure the work product against the scope baseline to ensure the project stays on track proactively, may need preventive, corrective actions or defect repair
  • a well documented and enforced change control process is required
  • the customer has the ultimate authority to change scope while the senior management can make use of management reserves
    • i.e. in general, disagreement should be resolved in favour of the customer
  • Data Analysis includes:
    • variance analysis – method to compare planned (baseline) and actual work and determine the causes/actions e.g. update baseline (keep the variance) or preventive/corrective actions, both need CR
    • trend analysis
  • work performance info – scope variance, causes, recommended action
  • may end up updating some of the inputs – requirements documentation & requirement traceability matrix & lessons learnt in OPA

 


Additional PMP® Study Resources (updated for PMP® Exam 2018)

If you find the above PMP® study notes useful, you may want to check out the free PMP® Exam study resources on my website (updated for PMP® Exam 2018):

Wish you PMP® success!

 

Most Popular PMP Certification Exam Articles

GreyCampus PMP online training course bundle for US$149 only

Support website running for FREE, thanks!

If you find this post helpful and if you are thinking of buying from Amazon, please support the running cost of this website at no extra cost to you by searching and buying through the search box below. Thank you very much for your help!

Edward Chung

Edward Chung aspires to become a full-stack web developer and project manager. In the quest to become a more competent professional, Edward studied for and passed the PMP Certification, ITIL v3 Foundation Certification, PMI-ACP Certification and Zend PHP Certification. Edward shares his certification experience and resources here in the hope of helping others who are pursuing these certification exams to achieve exam success.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *

5 Responses

  1. ziphozonke gasa says:

    thank you for the your information it was helpful on my assignment.

  2. Con says:

    Thank you very very much for these concise notes

  3. Princess Santos says:

    Hello Edward,
    I am goign to take the CAPM exam first week of september. I would appreciate if you can send me copy oy you ITTO Mind Map. Thank you!

  4. Rudy F says:

    Outstanding! Well-written and accurate.

  5. Ken Ashe says:

    You do a great job of summarizing this knowledge area. I came here for a refresher on “Plan Scope Management”, and I’m going to bookmark your site and come back here as I study for the PMP exam. I’m glad I found this. Thanks

April 9, 2014