1
Q
Scope Management
A
Process of defining what work is required and then making sure that work, and only that work, is complete
2
Q
Product scope
A
- Requirements that relate to the product, service, or result of the project
- Answers the question, “What end result is needed?”
3
Q
Project scope
A
- 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
4
Q
Scope management process (6 steps)
A
- 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
5
Q
Inputs to the Plan Scope Management process
A
- 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
6
Q
Outputs to the Plan Scope Management Process
A
- Scope Management Plan
- Requirements Management Plan
7
Q
Scope Management Plan
A
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
8
Q
Main idea behind scope management plan (and all other management plans)
A
If you can’t plan it, you can’t do it
9
Q
Requirements Management Plan
A
- 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?
10
Q
Requirements
A
Requirements are what stakeholders need from a project or service
Should relate to solving problems or achieving objectives outlined in the charter
11
Q
Components of requirements
A
- Quality
- Business processes
- Compliance
- Project management
12
Q
Inputs to the Collect Requirements process
A
- Project charter
- Assumption log
- Stakeholder register
- Agreements
- OPAs
13
Q
Tools and techniques for collecting requirements
A
- 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
14
Q
Focus groups
A
- Members of a focus group are usually selected from a specific demographic group of customers
- Focus group is directed by a moderator
15
Q
Types of voting conensus
A
- 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
16
Q
Multicriteria decision analysis
A
Stakeholders quantify requirements using a decision matrix based on factors such as expected risk levels, time estimates, and cost and benefits estimates
17
Q
Affinity diagram`
A
Ideas generated from any other requirements gathering techniques are grouped by similaries, which are each given a title
18
Q
Outside of similarities, what can affinity diagrams be organized by?
A
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?
19
Q
Mind map
A
- Diagram of ideas or notes to help generate, classify, or record information
- Looks like tree branches branching out of a central core word/term
20
Q
Nominal group technique
A
- 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
21
Q
Facilitation
A
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
22
Q
User story
A
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
23
Q
Examples of facilitiation sessions
A
- 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
24
Q
Context diagrams
A
- 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
25
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!**
26
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**
27
Outputs to the Collect Requirements process
* **Requirements documentation**
* **Requirements traceability matrix**
28
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?"
29
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**
30
What should be documented in a requirements traceability matrix?
* **Requirement ID numbers**
* **Source of each requirements**
* **Resource management assignment**
* **Requirement status**
31
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**
32
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**
33
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**
34
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**
35
Activity
* **A particular piece of work scheduled for a project**
* **NOT part of the WBS**
36
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**
37
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**
38
What do you do when you complete the WBS?
**Scope re-evaulation**
39
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**
40
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**
41
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**
42
What does a WBS dicitionary typically include?
* **Descriptions of schedule milestones**
* **Acceptance criteria**
* **Durations**
* **Interdependencies**
43
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**
44
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**
45
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**
46
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**
2 - RMC PMP Exam Prep
flashcards
Decks in class (14)
# Cards
-
Chapter 2 - Project Management Framework52
-
Chapter 3 - Project Management Processes39
-
Chapter 4 - Integration Management72
-
Chapter 5 - Scope Management46
-
Chapter 6 - Schedule Management79
-
Chapter 7 - Cost Management41
-
Chapter 8 - Quality Management57
-
Chapter 9 - Resource Management75
-
Chapter 10 - Communications Management13
-
Chapter 11 - Risk Management0
-
Chapter 12 - Procurement Management0
-
Chapter 13 - Stakeholder Management0
-
Chapter 14 - Professional and Social Responsibility0
-
Chapter 15 - The PMP Exam: Tips for Passing the Exam the First Time0
