CHAPTER 5 - Project Scope Management Flashcards
1
Q
? ? ? includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. Managing the project scope is primarily concerned with defining and controlling what is and is not included in the project.
A
Project Scope Management
2
Q
The ? ? ? processes are (6):
- Plan Scope Management
- Collect Requirements
- Define Scope
- Create WBS
- Validate Scope
- Control Scope
A
Project Scope Management
3
Q
One of the 6 processes in Project Scope Management is?
The process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled.
A
Plan Scope Management
4
Q
One of the 6 processes in Project Scope Management is?
The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
A
Collect Requirements [P]
Project Scope Management
5
Q
One of the 6 processes in Project Scope Management is?
The process of developing a detailed description of the project and product.
A
Define Scope [P]
One of the 6 processes in Project Scope Management
6
Q
The process of subdividing project deliverables and project work into smaller, more manageable components.
A
Create WBS [P]
One of the 6 processes in Project Scope Management
7
Q
One of the 6 processes in Project Scope Management is?
The process of formalizing acceptance of the completed project deliverables.
A
Validate Scope [M]
One of the 6 processes in Project Scope Management
8
Q
The process of monitoring the status of the project and product scope and managing changes to the scope baseline.
A
Control Scope [M]
One of the 6 processes in Project Scope Management
9
Q
In the project context, the term “scope” can refer to:
- ? scope. The features and functions that characterize a product, service, or result.
- ? scope. The work performed to deliver a product, service, or result with the specified features and functions.
A
Product
Project
The term “project scope” is sometimes viewed as including product scope.
10
Q
Project life cycles can range along a ? from predictive approaches at one end to adaptive or agile approaches at the other.
A
continuum
11
Q
In a ? (approach) life cycle, the project deliverables are defined at the beginning of the project and any changes to the scope are progressively managed and updated as necessary, using the integrated change control process.
A
predictive
12
Q
In an ? or ? (approach) life cycle , the deliverables are developed over multiple iterations where a detailed scope is defined and approved for each iteration when it begins. These projects are intended to respond to high levels of change and require ongoing stakeholder engagement.
A
adaptive or agile
13
Q
The overall scope of an adaptive project will be decomposed into a set of requirements and work to be performed, sometimes referred to as a product ?. At the beginning of an iteration, the team will work to determine how many of the highest-priority items on the (S) list can be delivered within the next iteration. Projects with adaptive life cycles use (S) (including product requirements and user stories) to reflect their current needs.
A
backlog
Three processes (Collect Requirements, Define Scope, and Create WBS) are repeated for each iteration.
14
Q
In Project Scope Management with an adaptive or agile life cycle, the sponsor and customer representatives should be continuously engaged with the project to provide ? on deliverables as they are created and to ensure that the product backlog reflects their current needs.
A
feedback
Two processes (Validate Scope and Control Scope) are repeated for each iteration.
15
Q
In Project Scope Management with a predictive project approach (life cycle), Validate Scope occurs with ? deliverable or phase review and Control Scope is an ongoing process
A
each
16
Q
In predictive projects, the scope ? for the project is the approved version of the project scope statement, work breakdown structure (WBS), and its associated WBS dictionary. A (S) can be changed only through formal change control procedures and is used as a basis for comparison while performing Validate Scope and Control Scope processes as well as other controlling processes
A
baseline
17
Q
Completion of the project scope is measured against the project management plan, while completion of the product scope is measured against the product ?. The term “(S)” is defined as a condition or capability that is required to be present in a product, service, or result to satisfy an agreement or other formally imposed specification
A
requirements
18
Q
? ? is the process of formalizing acceptance of the completed project deliverables. The verified deliverables obtained from the Control Quality process are an input to the (S) process. One of the outputs of (S) is Accepted Deliverables that are formally signed off and approved by the authorized stakeholder.
A
Validate Scope [M]
Project Scope Management
19
Q
Because the accepted deliverables are formally signed off and approved by the authorized stakeholder, the stakeholder needs to get involved early on during ? (sometimes initiating as well) and to provide inputs about quality of deliverables so that Control Quality can assess the performance and recommend necessary changes.
A
planning
20
Q
As the global environment becomes more complex, organizations are starting to recognize how to use business analysis to their competitive advantage by defining, managing, and controlling requirements activities. Activities of business analysis may start before a project is initiated and a project manager is assigned. According to “Requirements Management: A Practice Guide”, the requirements management process starts with a ? ?, which may begin in portfolio planning, in program planning, or within a discrete project.
A
needs assessment
21
Q
In Project Scope Management, Trends and emerging practices in ? ? includes:
- Determine problems and identify business needs;
- Identify and recommend viable solutions for meeting those needs;
- Elicit, document, and manage stakeholder requirements in order to meet business and project objectives; and
- Facilitate the successful implementation of the product, service, or end result of the program or project
A
business analysis
The process ends with the requirements closure, which transitions the product, service, or result to the recipient in order to measure, monitor, realize, and sustain benefits over time.
22
Q
The role with responsibility to conduct business analysis should be assigned to resources with sufficient business analysis ? and ?. If a business analyst is assigned to a project, requirement-related activities are the responsibility of that role.
The project manager is responsible for ensuring that requirements-related work is accounted for in the project management plan and that requirements-related activities are performed on time and within budget and deliver value.
A
skills and expertise
23
Q
The relationship between a project manager and a business analyst should be a collaborative partnership. A project will have a higher likelihood of being successful if project managers and business analysts fully understand each other’s ? and ? to successfully achieve project objectives.
A
roles and responsibilities
24
Q
Because each project is unique, the project manager will need to ? the way Project Scope Management processes (6) are applied by considering these:
- Knowledge and Requirements Management
- Validation and control
- Development approach
- Stability of requirements.
- Governance.
A
tailor
25
Considerations for tailoring Project Scope Management processes should include the PM asking:
Does the organization have formal or informal ? and ? Management systems? What guidelines should the project manager establish for requirements to be reused in the future?
Knowledge and Requirements
26
Considerations for tailoring Project Scope Management processes should include the PM asking:
Does the organization have existing formal or informal ? and ?-related policies, procedures, and guidelines?
Validation and control
27
Considerations for tailoring Project Scope Management processes should include the PM asking:
What ? ? does the organization use, is it agile, iterative or incremental; predictive or will a hybrid be more productive?
Development approach
28
Considerations for tailoring Project Scope Management processes should include the PM asking about the ? of requirements:
Are there areas of the project with unstable requirements? Do unstable requirements necessitate the use of lean, agile, or other adaptive techniques until they are stable and well defined?
Stability
| ...of requirements.
29
Considerations for tailoring Project Scope Management processes should include them PM asking:
Does the organization have formal or informal audit and ? policies, procedures, and guidelines?
Governance.
30
In projects with evolving requirements, high risk, or significant uncertainty, the ? is often not understood at the beginning of the project or it evolves during the project. Agile methods deliberately spend less time trying to define and agree on (S) in the early stage of the project and spend more time establishing the process for its ongoing discovery and refinement. Many environments with emerging requirements find that there is often a gap between the real business requirements and the business requirements that were originally stated. Therefore, agile methods purposefully build and review prototypes and release versions in order to refine the requirements. As a result, (S) is defined and redefined throughout the project.
scope
31
In agile approaches, the requirements constitute the ?.
backlog
32
? ? ? is the process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled. The key benefit of this process is that it provides guidance and direction on how scope will be managed throughout the project. This process is performed once or at predefined points in the project.
Plan Scope Management
33
```
1 Project charter
2 Project management plan
• Quality management plan
• Project life cycle description
• Development approach
3 Enterprise environmental factors
4 Organizational process assets
Process/flow?
```
Inputs - Plan Scope Management
34
```
1 Expert judgment
2 Data analysis
• Alternatives analysis
3 Meetings
Process/flow?
```
Tools & Techniques - Plan Scope Management
35
1 Scope management plan
2 Requirements management plan
Process/flow?
Outputs - Plan Scope Management
36
The scope management plan is a component of the ? or ? management plan/s that describes how the scope will be defined, developed, monitored, controlled, and validated.
project or program
37
The development of the scope management plan and the detailing of the project scope begin with the ? of information contained in;
- the project charter,
- the latest approved subsidiary plans of the project management plan,
- historical information contained in the organizational process assets, and
- any other relevant (EEF) enterprise environmental factors
analysis
38
The ? ? documents the project purpose, high-level project description, assumptions, constraints, and high-level requirements that the project is intended to satisfy.
Process/flow
Project charter
- Inputs - Plan Scope Management
+ others.....
39
- Quality management plan
- Project life cycle description
- Development approach
Are ? in what +Process/flow
components
Project Management Plan - Inputs - Plan Scope Management
40
The way the project and product scope will be managed can be influenced by how the organization’s quality policy, methodologies, and standards are implemented on the project.
+process/flow
Quality management plan
Project Management Plan - Inputs - Plan Scope Management
41
The ? ? ? ? identifies the series of phases that a project passes through from its inception to the end of the project.
+process/flow
Project life cycle description
Project Management Plan - Inputs - Plan Scope Management
42
The ? ? defines whether waterfall, iterative, adaptive, agile, or a hybrid development approach will be used.
+process/flow
Development approach
Project Management Plan - Inputs - Plan Scope Management
43
```
The ? ? ? that can influence the Plan Scope Management process include but are not limited to:
- Organization’s culture,
- Infrastructure,
- Personnel administration, and
- Marketplace conditions.
+process/flow
```
Enterprise Environmental Factors
| - Inputs - Plan Scope Management
44
The ? ? ? that can influence the Plan Scope Management process include but are not limited to:
- Policies and procedures, and
- Historical information and lessons learned repositories.
+process/flow
Organizational Process Assets
| - Inputs - Plan Scope Management
45
Specialized knowledge or training in the following topics should be considered here:
- Previous similar projects, and
- Information in the industry, discipline, and application area.
Process/flow?
Expert Judgement - Tools and Techniques - Plan Scope Management
46
A data analysis technique that can be used for this process includes but is not limited to ? analysis. Various ways of collecting requirements, elaborating the project and product scope, creating the product, validating the scope, and controlling the scope are evaluated.
+Process/flow?
alternatives
Data Analysis - Tools and Techniques - Plan Scope Management
47
Project teams may attend project ? to develop the scope management plan. Attendees may include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for any of the scope management processes, and others as needed.
Meetings
| - Tools and Techniques - Plan Scope Management
48
The scope management plan is a ? of the project management plan that describes how the scope will be defined, developed, monitored, controlled, and validated. The (S) of a scope management plan include:
- Process for preparing a project scope statement;
- Process that enables the creation of the WBS from the detailed project scope statement;
- Process that establishes how the scope baseline will be approved and maintained; and
- Process that specifies how formal acceptance of the completed project deliverables will be obtained.
+Process/flow
components
Scope Management Plan - Outputs - Plan Scope Management
The scope management plan can be formal or informal, broadly framed or highly detailed, based on the needs of the project.
49
The ? ? ? is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed.
Requirements Management Plan
Project Management Plan - Inputs - Plan Scope Management
50
Components of the ? ? ? (or Business Analysis Plan) can include but are not limited to:
- How requirements activities will be planned, tracked, and reported;
- Configuration management activities such as: how changes will be initiated; how impacts will be analyzed, how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes;
- Requirements prioritization process;
- Metrics that will be used and the rationale for using them; and
- Traceability structure that reflects the requirement attributes captured on the traceability matrix.
+Process/flow
Requirements Management Plan
| (Project Management Plan) - Outputs - Plan Scope Management
51
The Requirements Management Plan is also known as a ? ? ?.
| +Process/flow
Business Analysis Plan
Requirements Management Plan - Outputs - Plan Scope Management
52
? ? is the process of determining, documenting, and managing stakeholder needs and requirements to meet objectives. The key benefit of this process is that it provides the basis for defining the product scope and project scope. This process is performed once or at predefined points in the project.
Collect Requirements
Project Scope Management process
53
```
1 Project charter
2 Project management plan
• Scope management plan
• Requirements management plan
• Stakeholder engagement plan.
3 Project documents
• Assumption log
• Lessons learned register
• Stakeholder register.
4 Business documents
• Business case.
5 Agreements.
6 Enterprise environmental factors.
7 Organizational process assets.
Process/flow
```
Inputs - Collect Requirements.
Project Scope Management
54
```
1 Expert judgment.
2 Data gathering
• Brainstorming
• Interviews
• Focus groups
• Questionnaires and surveys
• Benchmarking.
3 Data analysis
• Document analysis.
4 Decision making
• Voting
• Autocratic decision making
• Multicriteria decision analysis.
5 Data representation
• Affinity diagrams
• Mind mapping.
6 Interpersonal and team skills
• Nominal group technique
• Observation/conversation
• Facilitation.
7 Context diagram.
8 Prototypes.
```
Tools and Techniques - Collect Requirements.
Project Scope Management
55
1 Requirements documentation.
| 2 Requirements traceability matrix
Outputs - Collect Requirements.
Project Scope Management
56
The 6 Processes of which ka?
- Plan Project Scope [P]
- Collect Requirements [P]
- Define Scope [P]
- Create WBS [P]
- Validate Scope [M]
- Control Scope [M]
Project Scope Management
57
```
The 6 process of Project Scope Management include:
?
- Collect Requirements [P]
- Define Scope [P]
- Create WBS [P]
- Validate Scope [M]
- Control Scope [M]
```
- Plan Project Scope [P]
58
```
The 6 process of Project Scope Management include:
- Plan Project Scope [P]
?
- Define Scope [P]
- Create WBS [P]
- Validate Scope [M]
- Control Scope [M]
```
- Collect Requirements [P]
59
```
The 6 process of Project Scope Management include:
- Plan Project Scope [P]
- Collect Requirements [P]
?
- Create WBS [P]
- Validate Scope [M]
- Control Scope [M]
```
- Define Scope [P]
60
```
The 6 process of Project Scope Management include:
- Plan Project Scope [P]
- Collect Requirements [P]
- Define Scope [P]
?
- Validate Scope [M]
- Control Scope [M]
```
- Create WBS [P]
61
```
The 6 process of Project Scope Management include:
- Plan Project Scope [P]
- Collect Requirements [P]
- Define Scope [P]
- Create WBS [P]
?
- Control Scope [M]
```
- Validate Scope [M]
62
```
The 6 process of Project Scope Management include:
- Plan Project Scope [P]
- Collect Requirements [P]
- Define Scope [P]
- Create WBS [P]
- Validate Scope [M]
?
```
- Control Scope [M]
63
The project’s success is directly influenced by active stakeholder involvement in the discovery and decomposition of needs into project and product ? and by the care taken in determining, documenting, and managing the (S) of the product, service, or result of the project. (S) include:
- conditions or capabilities that are required to be present in a product, service, or result to satisfy an agreement or other formally imposed specification.
- the quantified and documented needs and expectations of the sponsor, customer, and other stakeholders.
Requirements
64
? become the foundation of the WBS.
| Cost, schedule, quality planning, and procurement are all based on these (S).
Requirements
65
The ? ? documents the high-level project description and high-level requirements that will be used to develop detailed requirements
+Process/flow
Project Charter
| - Inputs - Collect Requirements
66
```
? ? ? components include but are not limited to:
- Scope management plan
- Requirements management plan
- Stakeholder engagement plan
Process/flow?
```
Project Management Plan - Inputs - Collect Requirements
67
The ? ? ? contains information on how the project scope will be defined and developed.
+Process/flow
Scope management plan
| - Inputs - Collect Requirements
68
The ? ? ? has information on how project requirements will be collected, analyzed, and documented.
+Process/flow
Requirements management plan
Project Management Plan - Inputs - Collect Requirements
69
The ? ? ? is used to understand stakeholder communication requirements and the level of stakeholder engagement in order to assess and adapt to the level of stakeholder participation in requirements activities.
+Process/flow
Stakeholder engagement plan
Project Management Plan - Inputs - Collect Requirements
70
Examples of ? ? that can be considered as inputs for this process include but are not limited to:
- Assumption Log
- Lessons learned register
- Stakeholder Register
Project Documents
| - Inputs - Collect Requirements
71
The ? ? identified assumptions about the product, project, environment, stakeholders, and other factors that can influence requirements.
+Process/flow
Assumption Log
Project Documents - Inputs - Collect Requirements
72
The ? ? ? is used to provide information on effective requirements collection techniques, especially for projects that are using an iterative or adaptive product development methodology.
+Process/flow
Lessons learned register
Project Documents - Inputs - Collect Requirements
73
The ? ? is used to identify stakeholders who can provide information on the requirements. It also captures requirements and expectations that stakeholders have for the project.
+Process/flow
Stakeholder Register
Project Documents - Inputs - Collect Requirements
74
A business document that can influence the Collect Requirements process is the ? ?, which can describe required, desired, and optional criteria for meeting the business needs.
+Process/flow
Business Case
Business Documents - Inputs - Collect Requirements
75
? can contain project and product requirements.
| +Process/flow
Agreements
| - Inputs - Collect Requirements
76
- Organization’s culture,
- Infrastructure,
- Personnel administration, and
- Marketplace conditions.
Process/flow?
EEF
| - Inputs - Collect Requirements
77
- Policies and procedures, and
| - Historical information and lessons learned repository with information from previous projects.
OPAs
| - Inputs - Collect Requirements
78
- Business analysis,
- Requirements elicitation,
- Requirements analysis,
- Requirements documentation,
- Project requirements in previous similar projects,
- Diagramming techniques,
- Facilitation, and
- Conflict management.
Process/flow?
Expert Judgement
| - Tools and Techniques - Collect Requirements
79
```
? ? techniques that can be used for this process include but are not limited to:
- Brainstorming
- Interview
- Focus groups.
- Benchmarking
- Questionnaires and surveys
+Process/flow
```
Data-gathering - Tools and Techniques - Collect Requirements
80
? is a technique used to generate and collect multiple
ideas related to project and product requirements.
+Process/flow
Brainstorming
Data-gathering - Tools and Techniques - Collect Requirements
81
An ? is to elicit information from stakeholders by talking to them directly.
Typically performed:
- using a formal or informal approach
- to elicit information from stakeholders by talking to them directly
- by asking prepared and spontaneous questions and
- recording the responses.
- on an individual basis or between multiple interviewers and/or multiple interviewees.
- with experienced project participants,
sponsors, other executives, and SME because they :
< can aid in identifying and defining the features and functions of the desired product deliverables.
> are useful for obtaining confidential information.
+Process/flow
Interview
Data-gathering - Tools and Techniques - Collect Requirements
82
? ? bring together prequalified stakeholders and subject matter experts to learn about their expectations and attitudes about a proposed product, service, or result. A trained moderator guides the group through an interactive discussion designed to be more conversational than a one-on-one interview
+Process/flow
Focus groups.
Data-gathering - Tools and Techniques - Collect Requirements
83
? and ? are written sets of questions designed to quickly accumulate information from a large number of respondents and are most appropriate with varied audiences, when a quick turnaround is needed, when respondents are geographically dispersed, and where statistical analysis could be appropriate.
Questionnaires and surveys
Data-gathering - Tools and Techniques - Collect Requirements
84
? involves comparing actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. The organizations compared during (S) can be internal or external.
Benchmarking
Data-gathering - Tools and Techniques - Collect Requirements
85
Data analysis techniques that can be used for this process include but are not limited to ? ?, which consists of reviewing and assessing any relevant documented information. In this process, (S) is used to elicit requirements by analyzing existing documentation and identifying information relevant to the requirements.
document analysis
Data analysis - Tools and Techniques - Collect Requirements [P]
Project Scope Management
86
```
There is a wide range of ? that may be analyzed to help elicit relevant requirements including:
- Agreements;
- Business plans;
- Business process or interface documentation;
- Business rules repositories;
- Current process flows;
- Marketing literature;
- Problem/issue logs;
- Policies and procedures;
- Regulatory documentation such as laws, codes, or ordinances;
- Requests for proposal; and
- Use cases.
+Process/flow
```
Documents
Data Analysis - Tools and Techniques - Collect Requirements
87
Requirements need to be elicited, analyzed, and recorded in enough detail to be included in the scope ? and to be measured once project execution begins.
baseline
88
? ? techniques that can be used in the Collect Requirements process include but are not limited to:
- Voting
- Autocratic decision making
- Multicriteria decision making
Decision-making
| - Tools and Techniques - Collect Requirements
89
? ? techniques that can be used for this process include but are not limited to:
- Affinity diagrams.
- Mind mapping.
Process/flow
Data representation
| - Tools and Techniques - Collect Requirements
90
? ? allow large numbers of ideas to be classified into groups for review and analysis.
+Process/flow
Affinity diagrams
Data representation - Tools and Techniques - Collect Requirements
91
? ? consolidates ideas created through individual brainstorming sessions into a single map to reflect commonality and differences in understanding and to generate new ideas.
+Process/flow
Mind mapping
Data representation - Tools and Techniques - Collect Requirements
92
- Nominal group technique.
- Observation/conversation.
- Facilitation.
> Joint application design/development (JAD).
> Quality function deployment (QFD).
> User stories.
Process/flow?
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
93
This technique enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization and is a structured form of brainstorming consisting of four steps:
1. A question or problem is posed to the group. Each person silently generates and writes down their ideas.
2. The moderator writes down the ideas on a flip chart until all ideas are recorded.
3. Each recorded idea is discussed until all group members have a clear understanding.
4. Individuals vote privately to prioritize the ideas, usually using a scale of 1 – 5. Voting may take place in many rounds to reduce and focus in on ideas. After each round, the votes are tallied and the highest scoring ideas are selected.
+Process/flow
Nominal group technique.
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
94
This provide a direct way of viewing individuals in their environment and how they perform their jobs or tasks and carry out processes. It is particularly helpful for detailed processes when the people who use the product have difficulty or are reluctant to articulate their requirements.
+Process/flow
Observation/conversation.
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
Observation aka “job shadowing.” - usually done externally by an observer viewing a business expert performing a job. It can also be done by a “participant observer” who actually performs a process or procedure to experience how it is done to uncover hidden requirements.
95
This is used with focused sessions that bring key stakeholders together to define product requirements. Workshops can be used to quickly define cross-functional requirements and reconcile stakeholder differences. Because of their interactive group nature, well-facilitated sessions can build trust, foster relationships, and improve communication among the participants, which can lead to increased stakeholder consensus. In addition, issues can be discovered earlier and resolved more quickly than in individual sessions.
? skills are used in the following situations, but are not limited to:
> Joint application design/development (JAD).
> Quality function deployment (QFD).
> User stories.
+Process/flow
Facilitation.
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
96
These sessions are used in the software development industry and focus on bringing business subject matter experts and the development team together to gather requirements and improve the software development process.
+Process/flow
Joint application design/development (JAD).
Is an example of Facilitation in
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
97
In the manufacturing industry, ? ? ? is another facilitation technique that helps determine critical characteristics for new product development. It starts by collecting customer needs, also known as voice of the customer (VOC). These needs are then objectively sorted and prioritized, and goals are set for achieving them.
+Process/flow
Quality function deployment (QFD).
Is an example of Facilitation in
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
98
? ? are short, textual descriptions of required functionality, and are often developed during a requirements workshop. They describe the stakeholder role, who benefits from the feature (role), what the stakeholder needs to accomplish (goal), and the benefit to the stakeholder (motivation).
+Process/flow
User stories.
Is an example of Facilitation in
Interpersonal and Team Skills - Tools and Techniques - Collect Requirements
99
The ? ? is an example of a scope model and visually depict the product scope by showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it. (S) show inputs to the business system, the actor(s) providing the input, the outputs from the business system, and the actor(s) receiving the output.
Context Diagram
| - Tools and Techniques - Collect Requirements
100
? is a method of obtaining early feedback on requirements by providing a model of the expected product before actually building it. Examples of (S) are small-scale products, computer generated 2D and 3D models, mock-ups, or simulations.
Prototyping
Prototypes - Tools and Techniques - Collect Requirements
Prototypes;
- allow stakeholders to experiment with a model of the final product rather than being limited to discussing abstract representations of their requirements.
- support the concept of progressive elaboration in iterative cycles of mock-up creation, user experimentation, feedback generation, and Prototype revision.
101
? is a prototyping technique showing sequence or navigation through a series of images or illustrations and are used on a variety of projects in a variety of industries, such as film, advertising, instructional design, and on agile and other software development projects. In software development, (S) use mock-ups to show navigation paths through web pages, screens, or other user interfaces.
Storyboarding
Prototypes - Tools and Techniques - Collect Requirements
102
? ? describes how individual requirements meet the business need for the project. Requirements may start out at a high level and become progressively more detailed as more information about the requirements is known. Before being baselined, requirements need to be unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. The format of the (S) may range from a simple document listing all the requirements categorized by stakeholder and priority, to more elaborate forms containing an executive summary, detailed descriptions, and attachments.
Requirements Documentation
| - Outputs - Collect Requirements
103
Many organizations categorize requirements into different types, such as business (stakeholder needs) and technical solutions (how those needs will be implemented).
These ? ? can be further elaborated into categories or classifications including:
- Business requirements.
- Stakeholder requirements.
- Solution requirements.
> Functional requirements
> Nonfunctional requirements.
- Transition and readiness requirements.
- Project requirements.
- Quality requirements
Process/flow
Requirements Documentation - Outputs - Collect Requirements
104
These describe the higher-level needs of the organization as a whole, such as the business issues or opportunities, and reasons why a project has been undertaken.
+Process/flow
Business requirements.
Requirements Documentation - Outputs - Collect Requirements
105
These describe needs of a stakeholder or stakeholder group.
| +Process/flow
Stakeholder requirements.
Requirements Documentation - Outputs - Collect Requirements
106
These describe features, functions, and characteristics of the product, service, or result that will meet the business and stakeholder requirements. This is further grouped into functional and nonfunctional requirements:
+Process/flow
Solution requirements.
Requirements Documentation (Project Document) - Outputs - Collect Requirements
107
? ? describe the behaviors of the product. Examples include actions, processes, data, and interactions that the product should execute.
+Process/flow
Functional requirements
is a subclassification of Solution requirements (Requirements Documentation) - Outputs - Collect Requirements
108
? ? supplement functional requirements and describe the environmental conditions or qualities required for the product to be effective. Examples include: reliability, security, performance, safety, level of service, supportability, retention/purge, etc.
+Process/flow
Nonfunctional requirements.
is a subclassification of Solution requirements in
Requirements Documentation - Outputs - Collect Requirements
109
These describe temporary capabilities, such as data conversion and training requirements, needed to transition from the current as-is state to the desired future state.
+Process/flow
Transition and readiness requirements.
Requirements Documentation - Outputs - Collect Requirements
110
These describe the actions, processes, or other conditions the project needs to meet. Examples include milestone dates, contractual obligations, constraints, etc.
+Process/flow
Project requirements.
Requirements Documentation - Outputs - Collect Requirements
111
These capture any condition or criteria needed to validate the successful completion of a project deliverable or fulfillment of other project requirements. Examples include tests, certifications,
validations, etc.
+Process/flow
Quality requirements
Requirements Documentation - Outputs - Collect Requirements
112
The ? ? ? is a grid that links product requirements from their origin to the deliverables that satisfy them. The implementation of a (S) helps ensure that each requirement adds business value by linking it to the business and project objectives. It provides a means to track requirements throughout the project life cycle, helping to ensure that requirements approved in the requirements documentation are delivered at the end of the project. Finally, it provides a structure for managing changes to the product scope.
Requirements Traceability Matrix
| - Outputs - Collect Requirements
113
- Business needs, opportunities, goals, and objectives;
- Project objectives;
- Project scope and WBS deliverables;
- Product design;
- Product development;
- Test strategy and test scenarios; and
- High-level requirements to more detailed requirements.
Are some examples of tracing in ? ? ?
+process/flow
Requirements Traceability Matrix
| (Project Documents) - Outputs - Collect Requirements
114
Each requirement that needs tracing has ? associated with it that can be recorded in the requirements traceability matrix. These (S) help to define key information about the requirement. Typical (S) used in the requirements traceability matrix may include: a unique identifier, a textual description of the requirement, the rationale for inclusion, owner, source, priority, version, current status (such as active, cancelled, deferred, added, approved, assigned, completed), and status date. Additional (S) to ensure that the requirement has met stakeholders’ satisfaction may include stability, complexity, and acceptance criteria.
+Process/flow
Attributes
Requirements Traceability Matrix - Outputs - Collect Requirements
115
This is the process of developing a detailed description of the project and product. The key benefit of this process is that it describes the product, service, or result boundaries and acceptance criteria
Define Scope
116
```
1 Project charter
2 Project management plan
• Scope management plan
3 Project documents
• Assumption log
• Requirements documentation
• Risk register
4 Enterprise environmental factors
5 Organizational process assets
```
Inputs - Define Scope
117
```
1 Expert judgment
2 Data analysis
• Alternatives analysis
3 Decision making
• Multicriteria decision
analysis
4 Interpersonal and team skills
• Facilitation
5 Product analysis
```
Tools and Techniques - Define Scope
118
```
1 Project scope statement
2 Project documents updates
• Assumption log
• Requirements documentation
• Requirements traceability matrix
• Stakeholder register
```
Outputs - Define Scope
119
Since all the requirements identified in Collect Requirements may NOT be included in the project, the ? ? process selects the final project requirements from the requirements documentation developed during the Collect Requirements process. It then develops a detailed description of the project and product, service, or result.
# Define Scope [P].
Project Scope Management.
120
The preparation of a detailed ? ? ? builds upon the high-level project description that is documented during project initiation. During project planning, the project scope is defined and described with greater specificity as more information about the project is known. Existing risks, assumptions, and constraints are analyzed for completeness and added or updated as necessary.
Project Scope Statement
- Outputs - Define Scope [P].
Project Scope Management.
121
The Define Scope process can be highly ?. In (S) life cycle projects, a high-level vision will be developed for the overall project, but the detailed scope is determined one iteration at a time, and the detailed planning for the next iteration is carried out as work progresses on the current project scope and deliverables.
iterative
Define Scope [P].
Project Scope Management.
122
This provides the high-level project description, product characteristics, and approval requirements.
+process/flow
Project Charter
| - Inputs - Define Scope
123
A ? ? ? component includes but is not limited to the scope management plan which documents how the project scope will be defined, validated, and controlled.
+Process/flow
Project Management Plan - Inputs - Define Scope
124
- Assumption log.
- Requirements documentation.
- Risk register.
Project Documents - Inputs - Define Scope
125
This identifies assumptions and constraints about the product, project, environment, stakeholders, and other factors that can influence the project and product scope.
+Process/flow
Assumption log.
Project Documents - Inputs - Define Scope
126
This identifies requirements that will be incorporated into the scope.
+Process/flow
Requirements documentation.
Project Documents - Inputs - Define Scope
127
This contains response strategies that may affect the project scope, such as reducing or changing project and product scope to avoid or mitigate a risk.
+Process/flow
Risk register.
Project Documents - Inputs - Define Scope
128
- Organization’s culture,
- Infrastructure,
- Personnel administration, and
- Marketplace conditions.
Process/flow?
EEF - Inputs - Define Scope
129
- Policies, procedures, and templates for a project scope statement;
- Project files from previous projects; and
- Lessons learned from previous phases or projects.
Process/flow?
OPAs - Inputs - Define Scope
130
This should be considered from individuals or groups with knowledge of or experience with similar projects.
+Process/flow?
Expert Judgement
| - Tools and Techniques - Define Scope
131
This analysis can be used to evaluate ways to meet the requirements and the objectives identified in the charter. (Other analyses can also be used)
+Process/flow?
Alternatives
Data Analysis- Tools and Techniques - Define Scope
132
This is a technique that uses a decision matrix to provide a systematic analytical approach for establishing criteria, such as requirements, schedule, budget, and resources, in order to refine the project and product scope for the project. (Other techniques can also be used)
+Process/flow?
Multicriteria Decision Analysis
Decision making - Tools and Techniques - Define Scope
133
This is used in workshops and working sessions with key stakeholders who have a variety of expectations or fields of expertise. The goal is to reach a cross-functional and common understanding of the project deliverables and project and product boundaries.
(Other techniques can also be used)
+Process/flow?
Facilitation
Interpersonal and Team Skills- Tools and Techniques - Define Scope
134
This can be used to define products and services. It includes asking questions about a product or service and forming answers to describe the use, characteristics, and other relevant aspects of what is going to be delivered.
+Process/flow?
Product analysis
| - Tools and Techniques - Define Scope
135
```
For Product analyses, each application area has one or more generally accepted methods for translating high-level product or service descriptions into meaningful deliverables. ? are captured at a high level and decomposed to the level of detail needed to design the final product. Examples of product analysis techniques include but are not limited to:
- Product breakdown,
- Requirements analysis,
- Systems analysis,
- Systems engineering,
- Value analysis, and
- Value engineering.
+Process/flow?
```
Requirements
Product analysis - Tools and Techniques - Define Scope
136
The ? ? ? is the description of the project scope, major deliverables, and exclusions. It documents the entire scope, including project and product scope. It describes the project’s deliverables in detail. It also provides a common understanding of the project scope among project stakeholders. It may contain explicit scope exclusions that can assist in managing stakeholder expectations. It enables the project team to perform more detailed planning, guides the project team’s work during execution, and provides the baseline for evaluating whether requests for changes or additional work are contained within or outside the project’s boundaries.
+Process/flow
Project Scope Statement
| (Project Document) - Outputs - Define Scope
137
The degree and level of detail to which the project scope statement defines the work that will be performed and the work that is excluded can help determine how well the project management team can ? the overall project scope.
control
Project Scope Statement (Project Document) - Outputs - Define Scope
138
The detailed ? ? ?, either directly or by reference to other documents, includes the following:
- Product scope description.
- Deliverables
- Acceptance criteria.
- Project exclusions.
Project Scope Statement (Project Document) - Outputs - Define Scope
139
Progressively elaborates the characteristics of the product, service, or result described in the project charter and requirements documentation.
+Process/flow
Product scope description.
Project Scope Statement (Project Document) - Outputs - Define Scope
140
Any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. These also include ancillary results, such as project management reports and documentation. They may also be described at a summary level or in great detail.
+Process/flow
Deliverables
Project Scope Statement (Project Document) - Outputs - Define Scope
141
A set of conditions that is required to be met before deliverables are accepted.
+Process/flow
Acceptance criteria.
Project Scope Statement (Project Document) - Outputs - Define Scope
142
Identifies what is excluded from the project. Explicitly stating what is out of scope for the project helps manage stakeholders’ expectations and can reduce scope creep.
+Process/flow
Project exclusions.
Project Scope Statement (Project Document) - Outputs - Define Scope
143
Although the project charter and the project scope statement are sometimes perceived as containing a certain degree of redundancy, they are different in the level of detail contained in each. The project charter contains ? information, while the project scope statement contains a ? description of the scope components. These components are progressively elaborated throughout the project.
high-level
detailed
Project Scope Statement (Project Document) - Outputs - Define Scope
components of the statement include; product scope description, deliverables, acceptance criteria and project exclusions
144
These are elements/componets of what?
- Project purpose
- Measurable project objectives and related success criteria
- High-level requirements
- High-level project description, boundaries, and key deliverables
- Overall project risk
- Summary milestone schedule
- Preapproved financial resources
- Key stakeholder list
- Project approval requirements (i.e., what constitutes success, who decides the project is successful, who signs off on the project)
- Project exit criteria (i.e., what are the conditions to be met in order to close or to cancel the project or phase
- Assigned project manager, responsibility, and authority level
- Name and authority of the sponsor or other person(s) authorizing the project charter
Project Charter
145
These are elements/componets of what?
- Project scope description (progressively elaborated)
- Project deliverables
- Acceptance criteria
- Project exclusions
Project Scope Statement
| (Project Document) - Outputs - Define Scope
146
- Assumption log.
- Requirements documentation.
- Requirements traceability matrix.
- Stakeholder register.
Process/flow
Project Documents Updates - Outputs - Define Scope
147
This is updated with additional assumptions or constraints that were identified during this process.
+Process/flow
Assumption log.
Project Documents Updates - Outputs - Define Scope
148
This may be updated with additional or changed requirements.
| +Process/flow
Requirements documentation.
Project Documents Updates - Outputs - Define Scope
149
This may be updated to reflect updates in requirement documentation.
+Process/flow
Requirements traceability matrix.
Project Documents Updates - Outputs - Define Scope
150
Where additional information on existing or new stakeholders is gathered as a result of this process, it is recorded in the ? ? .
+Process/flow
Stakeholder register.
Project Documents Updates - Outputs - Define Scope
151
This is the process of subdividing project deliverables and project work into smaller, more manageable components. The key benefit of this process is that it provides a framework of what has to be delivered. This process is performed once or at predefined points in the project.
Create WBS [P]
Project Scope Management
152
```
1 Project management plan
• Scope management plan
2 Project documents
• Project scope statement
• Requirements documentation
3 Enterprise environmental factors
4 Organizational process assets
```
Inputs - Create WBS [P]
153
1 Expert judgment
| 2 Decomposition
Tools and Techniques - Create WBS [P]
154
1 Scope baseline (Project Management Plan)
2 Project documents updates
• Assumption log
• Requirements documentation
Outputs - Create WBS [P]
155
The WBS is a hierarchical ? of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project and represents the work specified in the current approved project scope statement.
decomposition
Tools and Techniques - Create WBS [P]
Project Scope Management
156
The planned work is contained within the lowest level of WBS components, which are called ? ?. A (S) can be used to group the activities where work is scheduled and estimated, monitored, and controlled. In the context of the WBS, work refers to work products or deliverables that are the result of activity and NOT to the activity itself.
work packages
157
A ? ? ? component includes but is not limited to the scope management plan. It documents how the WBS will be created from the project scope statement
Project Management Plan
| - Inputs - Create WBS
158
This describes the work that will be performed and the work that is excluded.
Project scope statement.
Project Documents - Inputs - Create WBS
159
- Requirements documentation.
- Project scope statement.
Process/flow
Project Documents - Inputs - Create WBS
160
Detailed requirements describe how individual requirements meet the business need for the project.
+Process/flow
Requirements documentation.
Project Documents - Inputs - Create WBS
161
These can influence the Create WBS process and include but are not limited to industry-specific WBS standards that are relevant to the nature of the project. These industry-specific standards may serve as external reference sources for creating the WBS.
Process/flow
EEF
| - Inputs - Create WBS
162
- Policies, procedures, and templates for the WBS;
- Project files from previous projects; and
- Lessons learned from previous projects.
Are influences from what process/flow
OPAs
| - Inputs - Create WBS
163
Expertise should be considered from individuals or groups with knowledge of or experience with similar projects.
Process/flow
Expert Judgement
| - Tools and Techniques - Create WBS
164
This is a technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts. The work package is the work defined at the lowest level of the WBS for which cost and duration can be estimated and managed. The level of ? is often guided by the degree of control needed to effectively manage the project. The level of detail for work packages will vary with the size and complexity of the project.
+ Process/flow
Decomposition
| - Tools and Techniques - Create WBS
165
? of the total project work into work packages generally involves the following activities:
- Identifying and analyzing the deliverables and related work,
- Structuring and organizing the WBS,
- Decomposing the upper WBS levels into lower-level detailed components,
- Developing and assigning identification codes to the WBS components, and
- Verifying that the degree of decomposition of the deliverables is appropriate.
Decomposition
| - Tools and Techniques - Create WBS
166
A WBS structure may be created through various approaches. Some of the popular methods include the ? ? approach, the use of organization-specific guidelines, and the use of WBS templates. Otherwise a ? ? approach can be used to group subcomponents.
+process/flow
top-down
bottom-up
Decomposition - Tools and Techniques - Create WBS
The WBS structure can be represented in a number of forms/ways
167
Decomposition of the upper-level WBS components requires subdividing the work for each of the deliverables or subcomponents into its most ? components, where the WBS components represent verifiable products, services, or results. (If an agile approach is used, epics can be decomposed into user stories.) The WBS may be structured as an outline, an organizational chart, or other method that identifies a hierarchical breakdown. Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher-level deliverables.
fundamental
Decomposition - Tools and Techniques - Create WBS
168
Different deliverables can have different levels of decomposition. To arrive at a work package, the work for some deliverables needs to be decomposed only to the next level, while others need additional levels of decomposition. As the work is decomposed to greater levels of detail, the ability to plan, manage, and control the work is ?. However, excessive decomposition can lead to nonproductive management effort, inefficient use of resources, decreased efficiency in performing the work, and difficulty aggregating data over different levels of the WBS.
enhanced
Decomposition - Tools and Techniques - Create WBS
169
Decomposition may not be possible for a deliverable or subcomponent that will be accomplished far into the future. The project management team usually waits until the deliverable or subcomponent is agreed on, so the details of the WBS can be developed. This technique is sometimes referred to as ? ? ?.
rolling wave planning
Decomposition - Tools and Techniques - Create WBS
170
The WBS represents all product and project work, including the project management work. The total of the work at the lowest levels should roll up to the higher levels so that nothing is left out and no extra work is performed. This is sometimes called the ? ? ?.
100 percent rule
Decomposition - Tools and Techniques - Create WBS
171
This is the approved version of a scope statement, WBS, and its associated WBS dictionary, which can be changed only through formal change control procedures and is used as a basis for comparison. It is a component of the project management plan.
Scope Baseline
in Project Management Plan (Updates) - Outputs - Create WBS
172
The ? ? ? includes the description of the project scope, major deliverables, and exclusions.
Project scope statement.
?? p161 says Subcomponent of
Scope Baseline in Project Management Plan (Updates) - Outputs - Create WBS
?? p157 says Project Documents - Inputs - Create WBS
(is it a Scope Baseline/PMP or Project Doc?)
173
The ? is a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the required deliverables. Each descending level of the (S) represents an increasingly detailed definition of the project work.
WBS
Subcomponent of Scope Baseline
in Project Management Plan (Updates) - Outputs - Create WBS
174
The lowest level of the WBS is a work package with a unique ?. These (S) provide a structure for hierarchical summation of costs, schedule, and resource information and form a code of accounts. Each work package is part of a control account. A control account is a management control point where scope, budget, and schedule are integrated and compared to the earned value for performance measurement. A control account has two or more work packages, though each work package is associated with a single control account.
Is a subcomponent in what Process/flow?
identifier
A Work Package is a subcomponent of Scope Baseline
in Project Management Plan (Updates) - Outputs - Create WBS
175
A control account may include one or more ? ?. A (S) is a work breakdown structure component below the control account and above the work package with known work content but without detailed schedule activities.
Is a subcomponent in what Process/flow?
Planning package.
Subcomponent of Scope Baseline
in Project Management Plan (Updates) - Outputs - Create WBS
176
This is a document that provides detailed deliverable, activity, and scheduling information about each component in the WBS. The ? ? is a document that supports the WBS. Most of the information included in the ? ? is created by other processes and added to this document at a later stage.
Is a subcomponent in what Process/flow?
WBS dictionary
Subcomponent of Scope Baseline
in Project Management Plan (Updates) - Outputs - Create WBS
177
- Code of account identifier,
- Description of work,
- Assumptions and constraints,
- Responsible organization,
- Schedule milestones,
- Associated schedule activities,
- Resources required,
- Cost estimates,
- Quality requirements,
- Acceptance criteria,
- Technical references, and
- Agreement information.
Are some examples found in the ? ?
WBS dictionary
Subcomponent of Scope Baseline
in Project Management Plan (Updates) - Outputs - Create WBS
178
- Project scope statement.
- WBS
- Work package.
- Planning package.
- WBS dictionary.
Are subcomponents in what Process/flow?
Scope Baseline
in Project Management Plan (Updates ) - Outputs - Create WBS
179
- Assumption log.
| - Requirements documentation.
Project Documents Updates - Outputs - Create WBS
180
This is updated with additional assumptions or constraints that were identified during the Create WBS process.
+process/flow
Assumption log.
Project Documents Updates - Outputs - Create WBS
181
This is updated to include approved changes resulting from the Create WBS process.
+process/flow
Requirements documentation.
Project Documents Updates - Outputs - Create WBS
