Project Scope Management - PMBOK® Guide Study Ch5 Notes

Project Scope Management Fundamentals

  • Definition: 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.

  • Primary Concern: It focuses on defining and controlling what is and is not included in the project.

  • The Six Processes of Project Scope Management:

    • 5.1 Plan Scope Management: Creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled.

    • 5.2 Collect Requirements: Determining, documenting, and managing stakeholder needs and requirements to meet project objectives.

    • 5.3 Define Scope: Developing a detailed description of the project and product.

    • 5.4 Create WBS: Subdividing project deliverables and project work into smaller, more manageable components.

    • 5.5 Validate Scope: Formalizing acceptance of the completed project deliverables.

    • 5.6 Control Scope: Monitoring the status of the project and product scope and managing changes to the scope baseline.

  • Process Interaction: While presented as discrete processes with defined interfaces, in practice, they overlap and interact in ways that cannot be completely detailed in the PMBOK® Guide.

Key Concepts for Project Scope Management

  • Definition of Scope:

    • Product Scope: The features and functions that characterize a product, service, or result.

    • Project Scope: The work performed to deliver a product, service, or result with the specified features and functions. Sometimes, "project scope" is viewed as including product scope.

  • Project Life Cycles:

    • Predictive Life Cycle: Deliverables are defined at the beginning and changes are managed progressively. Processes (Collect Requirements, Define Scope, Create WBS) are performed early and updated via integrated change control.

    • Adaptive or Agile Life Cycle: Deliverables are developed over multiple iterations. Detailed scope is defined and approved for each iteration as it begins. The scope is decomposed into a set of requirements called a "product backlog."

  • Process Repetition in Agile:

    • Collect Requirements, Define Scope, and Create WBS: Repeated for each iteration.

    • Validate Scope and Control Scope: Repeated for each iteration to get sponsor/customer feedback and ensure the backlog reflects current needs.

  • Baselines and Change Control:

    • Predictive Baseline: The approved version of the project scope statement, WBS, and WBS dictionary. It can only be changed through formal change control procedures.

    • Adaptive Documentation: Uses backlogs (including product requirements and user stories) to reflect current needs.

  • Measurement of Completion:

    • Completion of project scope is measured against the project management plan.

    • Completion of product scope is measured against the product requirements.

  • Definitions and Success Factors:

    • Requirement: A condition or capability required to be present in a product, service, or result to satisfy an agreement or specification.

    • Validate Scope Activity: Involves formalizing acceptance. Verified deliverables from the Control Quality process are inputs. Stakeholder involvement is critical early during planning to provide inputs on quality.

Trends and Emerging Practices in Scope Management

  • Professional Evolution: Organizations are increasingly using business analysis to gain competitive advantage by better defining and managing requirements.

  • Business Analysis (BA):

    • Activities may start before project initiation or PM assignment.

    • The process often starts with a needs assessment in portfolio or program planning.

    • The BA process ends with requirements closure and transition to the recipient.

  • Collaboration between PM and BA:

    • The Project Manager (PM) and Business Analyst (BA) should have a collaborative partnership.

    • BA Responsibilities: Conducting requirement-related activities if assigned.

    • PM Responsibilities: Ensuring requirements work is in the PM plan, performed on time, within budget, and delivers value.

  • Focus Areas for Collaboration:

    • Determining problems and identifies business needs.

    • Identifying/recommending viable solutions.

    • Eliciting and managing stakeholder requirements.

    • Facilitating successful implementation.

Tailoring and Agile Environment Considerations

  • Tailoring Considerations:

    • Knowledge and requirements management: Organization systems and guidelines for requirement reuse.

    • Validation and control: Existing formal or informal policies.

    • Development approach: Agile, iterative, incremental, predictive, or hybrid.

    • Stability of requirements: Instability might necessitate lean or agile techniques.

    • Governance: Formal/informal audit and governance policies.

  • Agile/Adaptive Environment Details:

    • Used when scope is not understood at the beginning or is highly evolutionary.

    • Agile methods spend less time defining scope early and more time on discovery and refinement processes.

    • A gap often exists between real business requirements and originally stated requirements; prototypes and release versions are used to bridge this gap.

5.1 Plan Scope Management

  • Definition: The process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled.

  • Key Benefit: Provides guidance and direction on scope management throughout the project.

  • 5.1.1 Inputs:

    • Project Charter: Documents project purpose, high-level description, assumptions, constraints, and high-level requirements.

    • Project Management Plan: Includes the Quality management plan, Project life cycle description, and Development approach.

    • Enterprise Environmental Factors (EEFs): Culture, infrastructure, personnel administration, and marketplace conditions.

    • Organizational Process Assets (OPAs): Policies, procedures, historical information, and lessons learned repositories.

  • 5.1.2 Tools & Techniques:

    • Expert Judgment: From those with experience in similar projects or specific industries.

    • Data Analysis: Alternatives analysis to evaluate ways to collect requirements and elaborate scope.

    • Meetings: Attended by PM, sponsor, team members, and stakeholders.

  • 5.1.3 Outputs:

    • Scope Management Plan: Describes how scope will be defined, developed, monitored, controlled, and validated. Includes processes for scope statement preparation, WBS creation, baseline approval, and formal acceptance of deliverables.

    • Requirements Management Plan: Also called a "business analysis plan." Describes how requirements will be analyzed, documented, and managed. Includes configuration management, prioritization, metrics, and traceability structure.

5.2 Collect Requirements

  • Definition: Determining, documenting, and managing stakeholder needs to meet objectives.

  • Importance: Success is influenced by active stakeholder involvement in the discovery and decomposition of needs.

  • 5.2.1 Inputs: Project Charter, PM Plan (Scope, Requirements, and Stakeholder Engagement plans), Project Documents (Assumption log, Lessons learned register, Stakeholder register), Business documents (Business case), Agreements, EEFs, and OPAs.

  • 5.2.2 Tools & Techniques:

    • Data Gathering:

      • Brainstorming: Generating multiple ideas.

      • Interviews: Formal or informal direct communication. Useful for confidential info.

      • Focus Groups: Prequalified stakeholders and SMEs led by a moderator.

      • Questionnaires/Surveys: Quick turnaround from a large, dispersed audience.

      • Benchmarking: Comparing internal/external products or processes to identify best practices.

    • Data Analysis: Document analysis (reviewing agreements, business plans, regulatory docs, etc.).

    • Decision Making:

      • Voting: Unanimity, Majority (more than 50\%$% approval), Plurality (largest block decides).\n * **Autocratic**: One individual decides.\n * **Multicriteria Decision Analysis**: Using a decision matrix to rank ideas based on risk, value, etc.\n * **Data Representation**: Affinity diagrams (grouping ideas) and Mind mapping.\n * **Interpersonal and Team Skills**:\n * **Nominal Group Technique**: Structured brainstorming involving a question, silent generation of ideas, recording, discussion, and private voting (usually on a scale of 1 - 5$$).

      • Observation/Conversation: "Job shadowing," useful when users can't articulate requirements. Includes "participant observer" who performs the task.

      • Facilitation: Workshops like Joint Application Design/Development (JAD) for software, Quality Function Deployment (QFD) for manufacturing (using Voice of the Customer - VOC), and User Stories (Role-Goal-Motivation).

    • Context Diagram: A visual scope model showing a business system and its interactions with actors (people or other systems).

    • Prototypes: Models, mock-ups, or simulations for progressive elaboration through feedback cycles. Storyboarding is a technique showing image sequences.

  • 5.2.3 Outputs:

    • Requirements Documentation: Must be unambiguous (measurable and testable), traceable, complete, and consistent. Classifications include: Business, Stakeholder, Solution (Functional and Nonfunctional), Transition/Readiness, Project, and Quality requirements.

    • Requirements Traceability Matrix (RTM): A grid linking requirements to their origin and the deliverables that satisfy them. Tracks status (active, cancelled, deferred, etc.) and attributes like rationale, owner, and priority.

5.3 Define Scope

  • Definition: Developing a detailed description of the project and product; selects final requirements from documentation.

  • 5.3.1 Inputs: Project Charter, Scope Management Plan, Project Documents (Assumption log, Requirements documentation, Risk register), EEFs, and OPAs.

  • 5.3.2 Tools & Techniques: Expert Judgment, Data Analysis (Alternatives Analysis), Multicriteria Decision Analysis, Facilitation, and Product Analysis (translating high-level descriptions into deliverables via systems engineering, value analysis, etc.).

  • 5.3.3 Outputs:

    • Project Scope Statement: Includes Product scope description, Deliverables, Acceptance criteria, and Project exclusions.

    • Charter vs. Scope Statement: The charter contains high-level info (purpose, summary milestones); the scope statement is detailed and progressively elaborated.

5.4 Create WBS (Work Breakdown Structure)

  • Definition: Subdividing project deliverables and work into smaller, more manageable components. The WBS is a hierarchical decomposition of the total scope.

  • Work Package: The lowest level of the WBS where cost and duration can be estimated and managed.

  • 5.4.2 Tools & Techniques:

    • Decomposition: Dividing deliverables. Activities include: analyzing work, structuring the WBS, decomposing levels, assigning ID codes, and verifying decomposition.

    • Methods: Top-down approach, WBS templates, or bottom-up grouping.

    • Structure options: By project life cycle phases or by major deliverables.

  • Rules and Concepts:

    • 100 Percent Rule: The WBS includes all product and project work; the total work at the lowest levels must roll up to the higher levels exactly.

    • Rolling Wave Planning: Waiting until future deliverables are agreed upon to develop WBS details.

    • Excessive Decomposition: Can lead to inefficient resource use and difficulty aggregating data.

  • 5.4.3 Outputs - Scope Baseline:

    • Project Scope Statement.

    • WBS: Hierarchical decomposition.

    • Work Package: Unique identifier/code of accounts.

    • Control Account: Management control point integrating scope, budget, and schedule for performance measurement. Contains one or more work/planning packages.

    • Planning Package: Below control account, above work package; known content but no detailed schedule activities.

    • WBS Dictionary: Detailed info for each WBS component (description, owner, milestones, cost estimates, quality requirements, etc.).

5.5 Validate Scope

  • Definition: Formalizing acceptance of completed deliverables. Focuses on acceptance, whereas Control Quality focuses on correctness and quality requirements.

  • 5.5.1 Inputs: PM Plan (Scope baseline, etc.), Project Documents (Lessons learned, Quality reports), Verified deliverables (from Control Quality), and Work performance data.

  • 5.5.2 Tools & Techniques: Inspection (measuring, examining, validating; also called reviews or walkthroughs) and Voting.

  • 5.5.3 Outputs: Accepted Deliverables (formally signed off by customer/sponsor), Work performance information, Change requests (for non-accepted items requiring repair), and Document updates.

5.6 Control Scope

  • Definition: Monitoring scope status and managing changes to the scope baseline. Ensures changes go through Perform Integrated Change Control.

  • Scope Creep: Uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.

  • 5.6.1 Inputs: PM Plan (Scope, Requirements, Change, and Configuration management plans; Scope and Performance measurement baselines), Project Documents, Work performance data, and OPAs.

  • 5.6.2 Tools & Techniques: Variance Analysis (comparing baseline to actual) and Trend Analysis (performance over time).

  • 5.6.3 Outputs:

    • Work Performance Information: Correlated info on performance vs. baseline, identifying causes of variance.

    • Change Requests: May result in updates to scope, schedule, or cost baselines.

    • Project Management Plan Updates: Specifically to the Scope Management Plan, Scope Baseline, Schedule Baseline, Cost Baseline, and Performance Measurement Baseline.

    • Project Documents Updates: Lessons learned register, Requirements documentation, and Requirements traceability matrix.