Part 45: Project Scope Management Processes

Project Scope Management includes

  • Plan Scope Management
    • KEY BENEFIT: Develop a plan for managing scope throughout the project
    • In this process, we create a Scope Management Plan
    • The Scope Management Plan is NOT the Scope
    • The Scope Management Plan tells us how the scope will be defined, validated, and controlled

  • Collect Requirements
    • KEY BENEFIT: Identifies requirements for product scope and project scope
    • In this process, we
      • Determine, document, and manage stakeholder needs and requirements
    • For a project to be successful, stakeholders must be actively involved
    • Requirements
      • Requirements are what the project or product will be capable of
      • Includes quantified and documented needs and expectations of the sponsor or customer
      • Requirements need to be analyzed and recorded with enough detail so that they can be part of the scope baseline and measured later.  We need to be able to make sure that our result meets the requirements.
      • Requirements are part of the WBS (Work breakdown Structure)
      • Cost, Schedule, Quality, and Procurement are based on requirements
    • Requirements can be classified as
      • Business requirements (higher-level needs of the organization such as a marketing plan or investment plan)
      • Stakeholder requirements
      • Solution requirements (features of the product or service), which include
        • Functional Requirements
          • How the product will behave (for example, the shelf must hold at least 300 pounds)
        • Non-functional Requirements
          • Supplement functional requirements (for example, the shelf will be produced from oak)
          • Describe environmental conditions or qualities
      • Transition requirements
        • Temporary capabilities
      • Project Requirements
        • Actions/processes of the project
      • Quality Requirements

  • Define Scope
    • KEY BENEFIT: Uses requirements from Collect Requirements to describe the product, service, or result.
    • Remember, we already collected a whole bunch of requirements from our stakeholders.  Our stakeholders have competing interests.  Thus, we won’t be able to incorporate every single requirement into our final product.  Even if we could, it may not be cost-effective, or we may not have enough time.
    • This process forces us to define the project boundaries (we identify the requirements that we will keep, and we identify the requirements that we will exclude)
    • In this process
      • We develop a detailed description of the project and product
      • Existing risks, assumptions, and constraints are analyzed and updated
      • Excluding work is just as important as including work.  It would be a waste of time to perform work that is not required.
    • This process can be highly iterative

  • Create Work Breakdown Structure (WBS)
    • KEY BENEFIT: Results in a structured outline of the work that the project must deliver
    • In this process, we
      • Subdivide the project work and deliverables into smaller, manageable components
    • The WBS
      • Is hierarchical; work is broken down into sub-components, and sub-sub-components, and even more layers if necessary
      • Each deliverables can have a distinct level of decomposition
      • Decomposition leads to a greater ability to manage/control work, but excessive decomposition can be inefficient
      • Sometimes, it is only possible to decompose work that is short term; work that is still far away cannot be decomposed because not enough details are known about it.  This is part of PROGRESSIVE ELABORATION.
      • The WBS details all the work that is required
      • The lowest level in the WBS contains the Work Packages
    • A Work Package is a group of activities where work can be scheduled, estimated, monitored, and controlled
    • WBS Structure contains
      • Bottom-Up Structure when integrating multiple subcomponents developed by outside vendors
      • Phases of the project life cycle
      • Major deliverables
    • WBS represents all the work, including project management work
    • 100% RULE = at the lowest levels of the WBS, no work is left out, and no extra work is performed

  • Validate Scope
    • KEY BENEFIT: Increases the chance of acceptance of the final product, service, or result.  That’s because we use this process to review each deliverable with the customer.
    • In this process, we
      • Formalize acceptance of the completed deliverables
      • We take the deliverables from the Control Quality process
      • Verified deliverables are reviewed with the customer or sponsor to ensure they are satisfactory
      • We compare the deliverables with the scope baseline and requirements documentation
      • Validate Scope is concerned with deliverable acceptance; Quality Control is concerned with deliverable correctness.  Just because a deliverable passes Quality Control does not mean that the customer will accept it.
      • On a side note, you can design a great product, but it’s “not what the customer had in mind”.  If you don’t communicate with the customer, and show them your progress, you may end up in a completely different direction than what they expect.  For a large project, you don’t want to wait until the end.

  • Control Scope
    • KEY BENEFIT: Ensures that the scope baseline is maintained throughout the project
    • In this process, we monitor the status of the project, and manage changes to the scope
    • SCOPE CREEP is when we expand the product scope or project scope from the original Scope Baseline, but we don’t adjust the time, cost, and/or resources
    • Remember that changes do happen, and are expected
      • When a change is required, we don’t just implement the change
      • We follow the proper change control process to approve the change
      • We adjust the budget and schedule
      • This avoids Scope Creep