Tổng hợp các khái niệm cần nắm về lĩnh vực Project Scope Management (Chapter 05) trong kỳ thi PMP

Chapter 05: Project Scope Management

Có 6 Quy trình trong Project scope management:

  1. Plan scope management (Output: Scope management plan + Requirements management plan)
  2. Collect requirements (Output: Requirements doc + Requirements traceability matrix)
  3. Define scope (Output: Project scope statement)
  4. Create WBS (Output: Scope baseline)
  5. Validate scope (Output: Accepted deliverables + Change requests + WPI)
  6. Control scope (Output: WPI + Change requests)

>> Thi thử PMP chuyên đề Project Scope Management


  1. Product Scope: any requirements that relate to the product of the project, such as the features, functions that characterize a product/service. the work needs to be accomplished to deliver product/service with the specified features and functions.
  2. Plan Scope Management 5.1 (P): Creating a scope mgmt plan that documents how the project scope will be defined, validated and controlled. Provide guidance and direction on how scope will be managed throughout the project. The output: Scope Management Plan + Requirements management plan. Output: Scope management plan + Requirements management plan.
  3. Scope Management Plan (O): is a component of the project management plan, describes how the scope will be defined, developed, monitored, controlled and verified.
    • Process for preparing a detailed project scope statement.
    • Process that enable the creation of the WBS from the detailed project scope statement.
    • Process that establishes how the WBS will be maintained and approved.
    • Process that specifies  how formal acceptance of the completed project deliverables will be obtained.
    • Process to control how requests for changes to detailed project scope statement will be processed, and this is directly linked to the Perform Integrated Change Control.
  4. Requirements Management Plan (O):
    1. How requirements activities will be planned, tracked, and reported.
    2. How changes to product will be initiated, how impact will be analyzed, tracked, and approved…
    3. Requirements prioritization process.
  5. Condition to make CR in M/C:
    1. Status of project
    2. Solution
    3. Forecast
  6. Collect Requirement 5.2 (P): Determining, Documenting and Managing Stakeholder’s needs and requirements to meet the project objectives. Provide the basic for defining and managing the project scope including project scope. Output: Requirements doc + Requirements Traceability matrix
  7. Interview (TT): is a formal or informal approach to elicit information from stakeholders who will explain exactly what they need so that you can be sure your project can meet its goals – by taking to them directly, or may involve multiple interviewers and/or interviewees
  8. Focus Group (TT): Bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitude about a proposed product, service. A trained moderator guides the group through an interactive discussion, designed to be more conversational than a one-on-one interview.
  9. Facilitated Workshops (TT): Bring key stakeholders together to define product requirements. Be considered as a primary technique for quickly defining cross-functional requirements and reconciling stakeholders differences. Lead to build trust, foster relationships, improve communication, increase stakeholder consensus.
  10. Group Creativity Techniques (TT):
    1. Brainstorming: a technique used to generate and collect multiple ideas related to project and product requirements
    2. Nominal Group Technique: A technique that enhances brainstorming with a voting process used to rank the most useful & potential ideas for further brainstorming or for prioritization.
    3. Mind Mapping: A technique in which ideas created through individual brainstorming sessions are consolidated into a single map to reflect commonality  and differences in understanding, and generate new ideas.
    4. Delphi Technique: A way of letting everyone in the group give their thoughts about what should be in the product while keeping them anonymous.
    5. Affinity Diagram: Allow classify large numbers of ideas into groups for review and analysis.
  11. Group Decision Making Technique (TT):
    • Unanimity: A decision that is reached whereby everyone agrees.
    • Majority: A decision that is reached with support obtained from more than 50% of the members of the group agrees.
    • Plurality: A decision is reached whereby the largest block in a group decision, even if a Majority is not achieved.
    • Dictatorship: One individual makes the decision for the group.
  12. Questionnaires and Surveys (TT): Use a questionnaire and/or survey to get requirements from a bigger group of users, customers, or stakeholders => Statistical analysis.
  13. Observations(TT): Observers an end user performing the tasks to be analyzed in the end user’s own environment => Useful, when stakeholders have difficulties or reluctant to tell their requirements.
  14. Prototypes (TT): Are models of the product that you’re going to build that let your stakeholders get a better idea to elicit requirements more effectively.
  15. Benchmarking (TT): the comparable organizations to identify best practices, generate ideas for improvement, and provide a basic for measuring performance.
  16. Context Diagrams (TT): An example of a scope model.. Context Diagram visually depict the product scope by showing a business system (process, equipment, computer system…)
  17. Document Analysis (TT): Be used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements. Includes business plan, marketing literature, RFP, other requirement doc… regulatory document such as laws..
  18. Requirement Documentation: “How the work we do will acceptably meet requirements?” It contains various type of information, help make sure the requirements are clear and unambiguous (measurable and testable), traceable, meet the business need for the project, and acceptable to key stakeholders. Components can includes:
    1. Business requirements: business and project objectives.
    2. Stakeholder requirements: organizational impacts, communication and reporting…
    3. Project requirements: level of service, performance, safety, compliance
    4. Transition requirements
    5. Assumptions/ dependencies / constrains requirements/
  19. Requirement Traceability Matrix: is a grid link product requirements from their origin to the deliverables that satisfy them. Ensure that each requirement adds business value by linking it to the business and project objectives. Provides a means to track requirements throughout the project life cycle, help to make sure that requirement approved in the requirements documentation are delivered at the end of the project. Provide a structure for managing changes to the project scope.
  20. Define Scope 5.3 (P): Developing a detailed description of the project and product. The preparation of a detailed project scope statement is critical to project success and build upon the major deliverables, assumptions, and constraints that are documented during project initiation. Output: Project scope statement
  21. Product Analysis (TT): Traslate high level product description into tangible deliverables. Includes: Product breakdown, system analysis, system engineering, value engineering, functional analysis…
  22. Alternatives Identification (TT)Exploring different product concepts, design options, and project approach can help to find the combination that delivers the maximum fulfillment of project requirements.
  23. Facilitated workshops:
    1. JAD (Joint Application Design/Development): workshops are used in the software development industry… improve the software dev process.
    2. QFD (Quality Function Dev) workshops are used in manufacturing industry… determine critical characteristics for new product development.
  24. Project Scope Statement: describes the project’s deliverables and the work needed to create those deliverables. Components include:
    1. Product scope description (porgressively elaborated)
    2. Product acceptance criteria
    3. Project deliverables
    4. Project exclusion.. what are out of scope
    5. Project constrains (Available skilled resources, contract terms, requirements such as pre-defined budget, any imposed dates)
    6. Project Assumptions
  25. Create WBS 5.4 (P): Subdividing project deliverables and project work into smaller, more manageable components. The planned work is contained within the lowest level WBS components, which are called Work Packages. A WP can be used to group the activites where work is scheduled, cost estimated, monitored and controlled. Output: Scope baseline
  26. Decomposition (TT): Is subdivision of project deliverables into smaller, more manageable components util the work and deliverables are defined to the work package level. The WP is lowest level in the WBS and is the point at which the cost and activity durations for the work can be reliable estimated and managed. The level of detail for work packages will vary with the size and complexity of the project.
    1. Rolling Wave Planning: Decomposition of some deliverables can be waited util uncertainly is clarified.
    2. Team Buy-in (make team speaking the same language): is the most valuable result of creating a WBS.
  27. Scope Baseline = Project Scope Statement + WBS + WBS Dictionary.
  28. WBS: “Specifies What will be done. not How or When
    • WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by Project Team, to accomplish the project objectives and create the required deliverables.
    • WBS is finalized by establishing control accounts for the WPs. A control account is management control point where scope, cost & schedule are integrated and compared to the earned value for performance measurement.
    • Each control account may include one or more WPs, but more than one the WPs must be associated with only one control account.
  29. WBS Dictionary: provides a description of the work to be done for each WBS Wp and contains: A number identifier, Related control account (for cost), A statement of the work to be done, Who is responsible for doing the work, Any schedule milestones.
  30. Validate Scope 5.5 (P): Formalizing acceptance of the completed project deliverables. Scope Validation includes reviewing deliverables with the customer or sponsor to ensure that they are completed satisfactorily and obtaining formal acceptance of deliverable by the customer or sponsor => Check for Acceptance. Output: Accepted deliverables + change requests + WPI (Work Performance Information)
  31. Control Quality vs Validate Scope:
    • Quality Control is primary concerned with correctness of the deliverables/work results and meeting the quality requirements specified for the deliverables => Verified deliverables.
    • Scope Validation is primary concerned with acceptance of the deliverables/work results => Accepted deliverables.
    • => In generally, Control Quality will be performed before Validate Scope, or may be performed in parallel.
  32. Inspection (TT): is a technique, includes activities such as measuring, examining, and verifying to determine whether work and deliverables meet requirements and product acceptance criteria.
    • Inspection sometimes called review, product review, testing, measurement, desk-check, audit, and walkthrough
      • Walkthrough: The producer describes product and asks for comments from the participants.
      • Desk-check:
        • Carefully examine the product
        • Participants use a checklist to review the product one portion at a time
        • Issues and defects are recorded, and a product disposition is determined.
  33. Accepted Deliverables (O): (input to Close Project):
    • Deliverables that meet the acceptance criteria are formally signed off and approved by the customer
    • Formal documentation received from the customer acknowledging formal stakeholder acceptance of the project’s deliverables is forwarded to the close project phase process.
    • Deliverables that are not accepted must documented with the reasons. It is useful component of the lesson learned and audit trail of the project.
  34. Control Scope 5.6 (P): Monitoring the status of the project and product scope and managing changes to the scope baseline. Output: WPI (Work Performance Information) + change requests 
  35. Scope Creep: refers to the uncontrolled change expansion to product or project scope without adjustments to time, cost, and resource. This change in scope often comes from small, seemingly insignificant change requests that the project team accepts to keep the project sponsor happy. Causes of Scope Screep:
    1. Poorly detailed Project Scope Statement in the Project Initiation Doc.
    2. Poor Project Management Requirements have been delivered.
    3. Poor control of the project by PM
    4. Indecisive Project Stakeholders
    5. Too many project stakeholders who have differing priorities and objectives.
  36. Work Performance Information (O): Include:
    1. The correlated and contextualized information on how the project scope is performing compared to scope baseline.
    2. The categories of changes received, the identified scope variances and their causes, and how they impact schedule, cost, and forecast of the future scope performance.


>> Thi thử PMP chuyên đề Project Scope Management

Tổng hợp PMP Concepts: https://hocpmp.com/pmp-concepts




Leave a Reply

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

3 × two =

This site uses Akismet to reduce spam. Learn how your comment data is processed.