Concepts

• Product Scope is everything that must be completed in order to meet product requirements, while the project scope includes everything in the entire project plan.

• The Project Manager should always be in control of the scope by thoroughly defining it and carefully managing the processes.

• Changes to the scope should be handled in a structured and controlled way.

• It is important to begin with the end in mind when it comes to scope management so that each requirement and its acceptance criteria is documented.

• Project Manager should work pro-actively to identify and influence the factors that cause change.

• The overall goals of scope management are to define the need, to set stakeholder expectations, to deliver to the expectations, to manage changes, and to minimize surprises so that the product will ultimately gain approval.

• Gold Plating: Try to exceed customer expectactions by delivering more than was agreed upon. Increases risk and uncertainty and may add potential problems to the project.

• Scope Management Knowledge Area consists of the following elements:

  • Planning the overall scope-related efforts

  • Gathering the requirements for the product and the project

  • Defining and documenting the deliverables that are a part of the product and the project (scope)

  • Checking the work being done against the scope to ensure that it is complete

  • Ensuring that all of what is "in scope" and only what is "in scope" is completed and that changes are properly managed.

• [Planning] Plan Scope Management

  • Plan Scope Management is a process that looks at the other (subsequent) five scope processes and plans the overall approach as to how they will be carried out.

  • Very significant impact on the success of the project

  • The requirements are the main means of understanding and managing stakeholder expectations.

  • The unfinished Project Management Plan is brought in, and the Scope Management Plan is produced.

  • Inputs:

    • Project Charter

    • Project Management Plan
      • Unfinished at this point, and is brought to help determine how the scope will be gathered, defined, broken down, validated, and managed.

    • Enterprise Environmental Factors

    • Organizational Process Assets

  • Tools:

    • Expert Judgement

    • Data Analysis

    • Meetings

  • Outputs:

    • Scope Management Plan
      • It describes how the scope documents will be prepared and how the remaining five scope process will be carried out.

    • Requirement Management Plan
      • It defines what activities the team will perform in order to gather and manage the project requirements.
      • This document is only the plan for how the requirements will be managed and does not contain the requirements themselves.
      • It shows how requirements will be gathered, how decisions will be made ,how changes to the requirements will be handled, and how the requireents will be documented.

• [Planning] Collect Requirements

  • Collect Requirements is about understanding what is needed to satisfy the stakeholders and then documenting that understanding.

  • The requirements will factor heavily into the project plan and should certainly be gathered and accurately documented before any execution take place.

  • Develop Project Charter and Identify Stakeholders must be performed before it is possible to complete the Collect Requirements process since the charter gives the project manager authority to work on the project and the stakeholder register identifies the right people to involve in this process.

  • Inputs:
    • Project Charter
      • Used as guidance to help define the requirements.
      • Also gives the project manager formal organizational authority to carry out this work.
    • Project Management Plan
      • Scope Management Plan
        • Brings clarity to the types of requirements that the team will gather.
      • Requirements Management Plan
        • Describes how the requirements will be collected and documentated.
      • Stakeholder Engagement Plan
        • Informs how deeply the stakeholders should be involved in the requirements process and how this should be carried out.
    • Project Documents
      • Assumption Log
        • Lists the things you are treating as true for purposes of planning.
        • This documents the assumption and lets you proceed even though the prototype has not yet passed the trials.
      • Lessions Learned Register
        • Gives you the information on best practices in your organization for gathering requirements.
        • Takes on greater importance with agile projects.
      • Stakeholder Register
        • Contains a list of all the project stakeholders, and it is these stakesholders who can explain the requirements and the underlying needs.
        • Important to involve the right people early in the project and to ensure that they have the appropriate voice from the start.
      • Business Documents
        • Explains the particular reasons this project is being undertaken.
      • Agreements
      • Enterprise Environmental Factors
      • Organizational Process Assets

  • Tools:

    • Expert Judgement

    • Data-Gathering

      • Brainstorming
        • Ideas are shared in a rapid-fire setting and are not discussed or ranked until everyone is out of ideas
        • Goal is to gather numerous, creative responses.

      • Interviews
        • Conducted by the project manager or business analyst with a subject matter expert.
        • The subject matter expert can help explain what features or attributes the product should contain and why they matter.

      • Focus Group
        • Focus Groups are conducted by someone on the project team who meets with a group of stakeholders to discuss their needs and requirements.
        • Intended to create a safe environment for stakeholders to dicuss their expectations of the project.

      • Questionnaires and Surverys
        • Works well with large groups of people, allowing the team to gather opinions and requirements rapidly.
        • Generally in a standard format, aggregation and analysis is easier than with some other forms.

      • Benchmarking
        • Understand best practices and gain inspiration
        • Best to look at organizations or project that have something in common with this project.

    • Data Analysis
      • Data analysis includes anything that might help you understand the requirement.

    • Decision Making
      • Voting

        • Unanimity

        • Majority

        • Consensus

        • Plurality

        • Autocratic Decision Making
      • Multicriteria Decision Analysis
        • Uses a weighted matrix to assign values to each criterion and then rate them accordingly.
        • The Multicriteria Decision Analysis yields a score that may be compared against other scores.

    • Data Representation
      • Affinity Diagrams
        • An affinity diagram takes the ideas that came from brainstorming and organizes them into logical groups or categories.
      • Mind Mapping
        • A technique of diagramming ideas and creating meaningful associations in a graphical format.
        • Helps the team to see relationships among ideas.

    • Interpersonal and Team Skills
      • Norminal Group Techniques
        • Ideas are brainstormed and are voted on and sorted by priority.
      • Obeservation and Conversation
        • AKA "Job Shadowing", where a worker is studied as he performs his jobs.
        • The goal is to understand how the worker performs and to capture any requirements that may not be evident through interviews or other methods.
        • Conversation is important components here.
      • Facilitation
        • The goal behind facilitated workshops is to colocate all of the key stakeholders together and to elaborate the requirements.
        • Essential to have a skilled facilitator.
      • Context Diagram
        • A context diagram is the generic term for a use case diagram that shows systems and the "actors" that interact with each system.
        • Each actor may be a user or another system
      • Prototypes
        • Interactive model of the product
        • Advantage: the idea becomes tangible and can be used by people, allowing the project team to understand what works and does not work.
        • Prototypes receive varying degrees of emphasis, depending on the end product and on the project methodologies.
        • Friendly to the project management idea of progressive elaboration, which stresses that a deliverable can be revisited repeatedly before it is finalized.
        • Another way of prototyping is to storyboard the flow of the product.
          • Wireframe screen mockups for a software application to the stages in a new robotic assembly line.

  • Outputs:

    • Requirements Documentation

      • Describes what needs to be performed and why each requirement is important on the project.

      • The Requirement Documentation should include a description of:

        • The root business problem being solved

        • The source of the requirement

        • The way each requirement addresses the problem

        • How the business processes interact with the requirements

        • Associated measurements for each requirement

        • Business, Legal, and Ethical compliance

        • Constraints and Assumptions

        • Anticipated impart of the requirement on others

      • Requirements Traceability Matrix
        • Be able to identify the source
        • The source could originate from a stakeholder or departmental request, a legal, contractual, or ethical need, an underlying requirement, or any number of other sources.
        • If a requirement is important enough to be documented, it is important to list the source here.
        • Also include information about who owns the requirement, the status of the requirement, etc.

• [Planning] Define Scope

  • Define Scope is the process where the project's requirements are more thoroughly understood and documented.

  • The more time & effort spend on Define Scope, the less risk the project will have.

  • Begin very early in the project lifecycle, may be revisited many times throughout the project lifecycle.

  

  • Inputs:

    • Project Charter
      • If the project charter does not exist, then the project manager should still capture the project's overall goals, a brief description of the scope ,and the known contrainsts and assumotions before performing Define Scope.

    • Project Management Plan
      • Describes how all of the scope activities will be managed, including define scope.

    • Project Documents

      • Assumption Log
        • A list of everything that the team is treating as true even though it is uncertain at this point in the project.

      • Requirements Documentation
        • The stakeholder requirements provide the primary fuel for this process.
        • Requirements define what the project has to do and the degree to which it must perform.

      • Risk Register
        • A list of all identified risks and planned responses that may influence the scope.

    • Enterprise Environmental Factors

    • Organizational PRocess Assets

  • Tools

    • Expert Judgement
      • Having experts work with the project team to develop portions of the project scope management.

    • Data Analysis
      • The requirements are reviewed to look at different ways of achieving the goals.

    • Decision Making

    • Interpersonal and Team Skills

    • Product Analysis
      • A detailed analysis of the project's product, service, or result, with the intent of improving the project team's understanding of the product and helping to capture that understanding in the form of requirements.
      • Product Analysis Tools may be used:

        • Product Breakdown

        • Requirements Analysis

        • System Analysis

        • System Engineering

        • Value Analysis

        • Value Engineering

  • Outputs

    • Project Scope Statement
      • Used to level-set among the project's stakeholders
      • Details including:

        • Goal of the project

        • Product Scope Description

        • Requirements for the project

        • Constraints and assumptions

        • Identified risks related to the scope
      • Product Scope Description
        • A narrative description of the scope that is kept up to date throughout the project.
      • Deliverables
        • Clear and measurable description of what the product is going to look and feel like.
        • Every characterisitc or attribute should be documented here.
      • Acceptance Criteria
        • A checklist of the tests and measurements that will be performed before the product is accepted.
      • Project Exclusions
        • Documents what is out of scope with the project.

    • Project Documents Updates

• [Planning] Create WBS

  • This process does create the WBS(but not output), but at the same time WBS combines it with two other documnents to create the Scope Baseline.

  • WBS becomes a hub of information for the project, and arguably becomes the most import component of the project plan.

  • Risks, activitiesm costsm quality attributes, and procuemtn decisions all link back to the WBS.

  • WBS is a primary tool for verifying and controlling the project scope.

  • Performed early in the project, after the requirements have been collected, and the scope has been defined, but before the bulk of the work is executed.

  

  • Inputs

    • Project Management Plan
      • The important component of the project management plan is the Scope Management Plan.

    • Product Documents
      • Project Scope Statement
        • It will be used in this process as a primary stating point from which to create the WBS.
      • Requirements Documentation
        • Requirements Documentation ties each requirment back to a specific business nedd or benfit, and often progressively elabborated.

    • Enterprise Environmental Factors

    • Organizational Process Assets
      • Most Common Assets:
        • Methodologies that spell out how to create the work breakdown structure
        • Software tools to create the graphical chart
        • WBS templates
        • Completed WBS examples from previously performed projects.

  • Tools

    • Expert Judgement

    • Decomposition
      • Main tool used in creating the WBS
      • Breaking down the project deliverables into progressively smaller components.
      • Every level is detailed explanation of the level above it.
      • Many projects, including almost all agile projects, use a Rolling Wave Technique to decomposite the requirements.
        • Advantage of Rolling Wave Technique: It does not try to look far into the future. Instead, it deals with things in the relatively short term and gets product into the hands of the users to make the creation of the WBS easier and more accurate.

  • Outputs

    • Scope Baseline

      • Original plan plus all approved changes.

      • Combination of the project scope statement, the WBS, the WBS dictionary, work package, and planning package.

      • When the scope baseline is created, it is placed under control, meaning that changes to the scope are made according to the scope management plan.

      • WBS

        • The WBS is primarily constructed through decomposition, the practice of breaking down deliverables (product features, characteristics, or attributes) into progressively smaller pieces.

        • This process continues until the deliverables are small enough to be considered work packages.

        • A node may be considered a work package when it meets the following criteria:

          The work package

          • cannot be easily decomposied any further

          • is small enough to be estimated for time (effort)

          • is small enough to be estimated for cost

          • may ba assigned to a single person

        • If the node is being subcontracted outside of the performing organization, that node, regardless of size, may be considered a work package, and the subcontracting organization builds a "sub-WBS" from that node.

        • Each node on the WBS has a unique number used to locate and identify it.

        • Each level of the WBS is mutually exclusive and cumulatively exhaustive. This means that there are no gaps and no overlap in the work package.

        • Elements of a Good WBS:

          • Must be detailed down to a low level. Lowest level consists of work packages that define every deliverable on the project.

          • It is graphical, arranged like a pyramid, where each sub-level rolls up to the level above it.

          • It number each element, and the numbering system should allow anyone who reads the WBS to find individual elements quickly and easily.

          • It should provide sufficient detail to drive the subsequent phases of planning.

          • It may often be borrowed from other projects in the organization as a starting point. Thses starting points are know as templates.

          • It is thorough and complete. If an item is not in the WBS, it does not get delivered with the project.

          • It is central to the project

          • The project team, and not just the project manager, creates the WBS. Developing the WBS can also be a means of team-building.

          • It is an integration tool, allowing you to see where the individual pieces of work fit into the project as whole.

          • It helps define responsibilities for the team.

          • It is a communication tool.

      • Work Package

        • The lowest level of work breakdown structure.

      • Planning Package

        • Nodes on the WBS that are larger than work packages but that cannot be broken down into work packages at this time. Typically this would be true because not enough information is known at this time.

      • Control Account

        • AKA " Cost Account", is a node on the WBS where the scope, time ,and cost are measured.

        • Usually contain several work packages and are used to measure earned value.

      • WBS Dictionary

        • The WBS Dictionary is a document that details the contents of the WBS.

        • Provides detailed information about the nodes on a WBS.

    • Project Documents Updates

      • Through the process of creating the scope basline and WBS, the understanding of the project often changes and improves. This change in understanding should be documented back in the appropriate place.

• [Monitoring & Controlling] Validate Scope

  • Validate Scope is the process of ensuring that the product, service, or result of the project matches the documented scope.

  • Validate Scope vs Control Quality:

    • Simiarity: Both inspect the product against the scope.

    • Differences:

      • Control Quality is performed before Validate Scope

      • Validate Scope is primarily concerned with completeness, while Control Quality is primarily concerned with correctness.

      • Validate Scope is concerned with the acceptance of the product by the product manager, the sponsor, the sponsor, the customer, and others, while Control Quality is concerned with adherence to the quality specification.

  • Validate Scope would be performed after at least some of the product componenets have been delivered, although it may be performed several times throughout the life of the project.

  • It would at least be performed once late in the project life cycle as the product is ready to be delivered.

  • Inputs:

    • Project Management Plan

    • Project Documents

    • Verified Deliverables
      • Verified Deliverables flow out of the Control Quality process and into this one.
      • Validate Scope is all about comparing the deliverables with the documented scope to ensure that everything was completed.

    • Work Performance Data
      • Sometimes a team can achieve the right outcome but the path to get there was unacceptable. (i.e., taking too long to finish)
      • Work Performance Data tells more about "how" the deliverables were created, which needs to be considered along with the product itself.

  • Tools:

    • Inspection
      • Inspection involves a point-by-point review of the scope and associated deliverable.

    • Decision Making

  • Outputs:

    • Accepted Deliverables
      • Acceptance of the deliverables is the primary output of the process of Validate Scope and one the most important in the project.
      • This process is typically perfromed by the project manager, the sponsor, the customer, and the functional managers, and the result is a formal, written acceptance by the appropriate stakeholders.

    • Work Performance Information

    • Change Requests

    • Project Documents Updates

• [Monitoring & Controlling] Control Scope

  • Control Scope is about maintaining control of the project by preventing scope change requests from overwhelming the project, and alos about making certain that scope change requests are properly handled.

  • This ensures that the scope baseline is always kept current.

  • One of the more challenging concepts behind Control Scope can be resolving disputes.

  • The customer is one of the most important stakeholders. All other things being equal, diputes should be resolved in favor of the customer.

  • Control Scope makes certain all change requests are processed, and also that any of the underlying causes of scope change requests are understood and managed.

  • Control Scope is an ongoing process that begins as soon as the scope baseline is created.

  • Control Scope process should be performed any time the work results are known to differ from the documented scope, whether or not the scope change was requested in advance.

  • Inputs:

    • Project Management Plan
      • Scope Baseline consists of the WBS, the WBS dictionary and the proejct scope Statement, and it is the documented source for what the project team is supposed to create.
      • The Scope Baseline provides the baseline that the project manager will control.

    • Project Documents

    • Work Performance Data
      • It provides information on all aspects of the work completed as it relates to the project plan.

    • Organizational Process Assets

  • Tools:

    • Data Analysis
      • Variance Analysis
        • Measures differences between what was defined in the scope baseline and what aws created and to investigate the root cause behind any differences.
      • Trend Analysis
        • Help identify areas that are about to become problems.

  • Outputs:

    • Work Performance Information
      • Work Performance Information (WPI) is Work Performance Data that has been processed and put into an actionable format.
      • Change Requests
        • As changes are made to the scope baseline, these must be factored into updates to the WBS,
      • Project Management Plan Updates
      • Project Documents Updates