Chapter 5 - Scope Management Flashcards
Scope Management
Process of defining what work is required and then making sure that work, and only that work, is complete
Product scope
- Requirements that relate to the product, service, or result of the project
- Answers the question, “What end result is needed?”
Project scope
- The work the project team will do to deliver the product
- Encompasses the product scope
- Includes the planning, coordination, and management activities that ensure the product scope is achieved
Scope management process (6 steps)
- Develop a plan for how you will plan, validate, and control scope and requirements on the project
- Determine requirements, making sure all requirements support the project’s business case as described in the charter
- Sort and balance the needs of stakeholders to determine scope
- Create a WBS to break the scope down to smaller, more manageable pieces, and define each piece in the WBS dictionary
- Obtain validation that the completed scope of work is acceptable to the customer or sponsor
- Measure scope performance, and adjust as needed
Inputs to the Plan Scope Management process
- Project charter - high-level description of the product, service, or result
- Project life cycle description - breaks the project into the phases it will go through to produce the product, service, or result
- Development approach - influences how requirements will be elicited as well as how the scope statement and WBS will be developed
- OPAs - may be useful for planning
Outputs to the Plan Scope Management Process
- Scope Management Plan
- Requirements Management Plan
Scope Management Plan
Contains 3 parts which detail how scope will be planned, executed, and controlled. It defines the following:
- How to achieve scope
- What tools will help accomplish the scope
- How to create the WBS
- How scope will be managed and controlled to the PMP
- How to obtain acceptance of deliverables
Main idea behind scope management plan (and all other management plans)
If you can’t plan it, you can’t do it
Requirements Management Plan
- Describes the methods you intend to use to identify requirements
- Answers the questions of, “Once I have all the requirements, what will I do to analyze, prioritize, manage, and track changes to them? What should I include in the requirements traceability matrix?
Requirements
Requirements are what stakeholders need from a project or service
Should relate to solving problems or achieving objectives outlined in the charter
Components of requirements
- Quality
- Business processes
- Compliance
- Project management
Inputs to the Collect Requirements process
- Project charter
- Assumption log
- Stakeholder register
- Agreements
- OPAs
Tools and techniques for collecting requirements
- Brainstorming
- Interviews
- Focus groups
- Questionnaires and surveys
- Benchmarking
- Voting
- Mutlicriteria decision analysis
- Affinity diagrams
- Mind maps
- Nominal group technique
- Observation
- Facilitation
- Context diagrams
- Prototypes
- Balancing stakeholder requirements
Focus groups
- Members of a focus group are usually selected from a specific demographic group of customers
- Focus group is directed by a moderator
Types of voting conensus
- Unanimous - everyone agrees
- Autocratic - a single person is assgined to make the decision for the group
- Majority - group chooses the decision that more than half of its members support
- Plurality - group chooses decision that has the largest number of supporters
Multicriteria decision analysis
Stakeholders quantify requirements using a decision matrix based on factors such as expected risk levels, time estimates, and cost and benefits estimates
Affinity diagram`
Ideas generated from any other requirements gathering techniques are grouped by similaries, which are each given a title
Outside of similarities, what can affinity diagrams be organized by?
Requirements categories, which include:
- Business requirements - Why was the project undertaken? What business need is the project intended to address?
- Stakeholder requirements - What do stakeholders want to gain from the project?
- Solution requirements - What does the product need to look/function like? What will make the product effective?
- Transition requirements - What types of handoff procedures/training are needed to transfer the product to the customer or organization?
- Project requirements - How should the project be initiated, planned, executed, controlled, and closed?
- Quality requirements - What quality measures does the product need to meet? What constitutes a successfully completed deliverable?
- Technical requirements - How will the product be built? What are the product specifications?
Mind map
- Diagram of ideas or notes to help generate, classify, or record information
- Looks like tree branches branching out of a central core word/term
Nominal group technique
- Usually done during brainstorming
- Follows 4 steps:
- A question or issue is posed
- Meeting participants write down and share their ideas
- Group discusses what’s been shared
- Ideas are ranked based on which ideas are most useful
Facilitation
Facilitation brings stakehodlers together with different perspectives, such as product designers and end users, to talk about the product and ultimately define requirements
Uses a consensus approach, which achieves general agreement about a decision
User story
Describes functionality or features that stakeholders hope to see, and are often written in the following format:
As a <role>, I want <functionality/goal> so that <business benefit/motivation>
E.g., as a community organizer, I want the new library to offer public meeting spaces so that we have a central place to gather and share ideas
Examples of facilitiation sessions
- Joint Application Design (JAD) - used primarily in software development efforts
- Quality Functional Deployment (QFD) - also referred to as Voice of the Customer or VOC, is a technique generally used in the manufacturing industry
Context diagrams
- Shows the boundaries of the product scope by highlighting the product and its interfaces with people, processes, or systems
- Also known as a context level data flow diagram
Balancing stakeholder requirements
- Involves making sure the requirements can be met with the project objectives
- Also involves prioritizing requirements and resolving conflicts
- In order to balance stakeholder requirements, it’s vital to identify and prioritize the requirements!
When resolving competing requirements, which requirements should you accept?
Those that comply with the following:
- Business case, i.e., reason the project was initiated
- Project charter
- Project scope statement
- Project constraints
Outputs to the Collect Requirements process
- Requirements documentation
- Requirements traceability matrix
What one thing MUST be included in requirements documentation?
Acceptance criteria, i.e. “how will we know if the work we do will meet this requirement?”
Requirements traceability matrix
- Helps link requirements to the objectives and/or other requirements to ensure the strategic goals are accomplished
- Used throughout the project in analyzing proposed changes to project/product scope
What should be documented in a requirements traceability matrix?
- Requirement ID numbers
- Source of each requirements
- Resource management assignment
- Requirement status
Define Scope process
- Primarily concerned with what is and what is not included in the project and its deliverabled
- Uses info from the charter, scope management plan, requirements documentation, assumption log, and risk register to define the project and product scope
Project scope statement
The project scope statement effectively says, “here is what we will do on this project”
Includes the following:
- Product scope
- Project scope
- Project deliverables
- Acceptiance criteria
- What is not part of the project
- Assumptions and constraints
Work Breakdown Structure (WBS)
- Breaks down the project into pieces you can plan, organize, manage and control
- Shows all of the scope on a project broken down into managable deliverables, which can be further broken into into smaller component deliverables (work packages)
- ALL projects need a WBS
Work package
- The smaller component deliverables that make up a deliverable
- Work packages consist of nouns (deliverables) rather than actions (activities)
- Lowest level of the WBS
- Assigned to ONLY ONE control account
Activity
- A particular piece of work scheduled for a project
- NOT part of the WBS
Guidelines to follow when creating a WBS
- A WBS should be created by the PM with input from team and stakeholders
- Each level of a WBS is a breakdown of the previous level
- An entire project should be included in the highest levels of a WBS
- A WBS includes only project deliverables that are required
Control account
A tool that allows you to collect and analyze WPD regarding costs, schedule, and scope
Provides a way to manage and control costs, schedule, and scope at a higher level than the work package
What do you do when you complete the WBS?
Scope re-evaulation
Key points of a WBS
- Graphical representation of the hierarchy of a project
- Identifies all deliverables to be completed
- Is the foundation upon which a project is built
- Is very important and should exist for every project
- Can be reused for other projects
- Does NOT show dependencies
Difference between decomposition and WBS
- Decomposition refers to what you are doing
- WBS is the means to do it
- I.e., you decompose a project using a WBS
WBS dictionary
- Provides a description of the work to be done for each WBS, work package, and it lists the acceptance criteria for each deliverable, which ensures the resulting work matches what is needed
- Puts boundaries around what’s included in a work package, similar to how a project scope statement puts boundaries around what’s included in a project
What does a WBS dicitionary typically include?
- Descriptions of schedule milestones
- Acceptance criteria
- Durations
- Interdependencies
Validate Scope Process
- Involves frequent, planned meetings with the customer or sponsor to gain formal acceptance of deliverables during project monitoring and controlling
- It is NOT confirming the validity and appropriateness of the scope definition during project planning
Validate Scope Process inputs
- Work must be completed and checked before each meeting with the customer, i.e. need verified deliverables
- Scope baseline
- Need to share info about the requirements of the project and how those requirements have been met, i.e., requirements management plan and requirements traceability matrix
- Requirements documentation in order to compare the requirements to actual results
- Quality reports to include info about open or closed issues
- Lessons learned to improve the process of validating project deliverables
- Scope management plan to show previously agreed-upon deliverables and plans for gaining formal acceptance to them
- WPD to assess how well product deliverables are meeting requirements
Valide Scope Process ouputs
Validate scope is done to ensure the project is on track from the customer’s point of view, rather than just hoping to get final acceptance in project closure. Ouputs include:
- WPI (i.e., analyzed WPD)
- Accepted deliverables
- Change requests
- Updates to the lessons learned register, requirements traceability matrix, and requirements documentation
Control Scope Process
- Involves measuring WPD against the scope baseline and managing scope baseline changes
- Includs thinking about where changes to scope are coming from and what can be done to prevent/remove the need for any more changes from that source
