CAPM Terms 2 Flashcards
(204 cards)
1
Q
RACI chart
A
• A RACI chart is a matrix chart that only uses the activities of responsible, accountable, consult, and inform.
2
Q
RAG rating
A
• An ordinal scale that uses red, amber, and green (RAG) to capture the probability, impact, and risk score.
3
Q
Receiver
A
• The person who receives the message.
4
Q
Refactoring
A
• To adjust working code to improve functionality and conservation.
5
Q
Referent power
A
- The project team personally knows the project manager. Referent can also mean that the project manager refers to the person who assigned him the position.
- The project manager is respected or admired because of the team’s past experiences with the project manager. This is about the project manager’s credibility in the organization.
6
Q
Refinement
A
• An update to the work breakdown structure.
7
Q
Regression analysis
A
- This is a statistical approach to predicting what future values may be, based on historical values. Regression analysis creates quantitative predictions based on variables within one value to predict variables in another. This form of estimating relies solely on pure statistical math to reveal relationships between variables and to predict future values.
- A mathematical model to examine the relationship among project variables, like cost, time, labor, and other project metrics.
8
Q
Relative prioritization
A
• A list of all user stories and features ordered by highest priority to the lowest priority.
9
Q
Relative sizing
A
• To estimate the size of a story in comparison with another story.
10
Q
Release
A
• Iteration outcomes delivered to customers (end-users).
11
Q
Release plan
A
• A document that describes the timeline of a product release.
12
Q
Reporting system
A
• A reporting system is a software program to store and analyze project data for reporting. A common reporting system will take project data, allow the project manager to pass the data through earned value management, for example, and then create forecasting reports about the project costs and schedule.
13
Q
Request for Proposal (RFP)
A
• From buyer to seller. Requests the seller to provide a proposal to complete the procured work or to provide the procured product.
14
Q
Request for Quote (RFQ)
A
• From buyer to seller. Requests the seller to provide a price for the procured product or service.
15
Q
Requirements at a high level
A
• Requirements are in the form of user stories, and collected at a high level to estimate a budget.
16
Q
Requirements documentation
A
• This documentation of what the stakeholders expected in the project defines all of the requirements that must be present for the work to be accepted by the stakeholders.
17
Q
Requirements management plan
A
• This subsidiary plan defines how changes to the project requirements will be permitted, how requirements will be tracked, and how changes to the requirements will be approved.
18
Q
Requirements prioritization model
A
• A model to rate each feature with the calculation of weighted formula defined by the team.
19
Q
Requirements review
A
• To review the requirements so they fulfill the needs and priorities of stakeholders.
20
Q
Requirements Traceability Matrix (RTM)
A
• This is a table that maps the requirements throughout the project all the way to their completion.
21
Q
Reserve analysis
A
• Cost reserves are for unknown unknowns within a project. The management reserve is not part of the project cost baseline, but is included as part of the project budget.
22
Q
Residual risks
A
• Risks that are expected to remain after a risk response.
23
Q
Resistant stakeholder status
A
• Part of stakeholder analysis classification. A resistant stakeholder is aware of your project, but they do not support the changes your project will create.
24
Q
Resource Breakdown Structure (RBS)
A
- This hierarchical chart can decompose the project by the type of resources used throughout it.
- This is a hierarchical breakdown of the project resources by category and resource type. For example, you could have a category of equipment, a category of human resources, and a category of materials. Within each category, you could identify the types of equipment your project will use, the types of human resources, and the types of materials.
25
Resource calendars
• Calendars that identify when project resources are available for the project work.
26
Resource management plan
• This plan defines staff acquisition, the timetable for staff acquisition, the staff release plan, training needs for the project team, any organizational compliance issues, rewards and recognitions, and safety concerns for the project team doing the project work.
27
Resource-leveling heuristic
• A method to flatten the schedule when resources are overallocated. Resource leveling can be applied using different methods to accomplish different goals. One of the most common methods is to ensure that workers are not overextended on activities.
28
Responsibility
• A responsibility is the work that a role performs.
29
Responsibility Assignment Matrix (RAM)
• A RAM chart shows the correlation between project team members and the work they’ve been assigned to complete.
30
Reward
• The project manager has the authority to reward the project team.
31
Risk
• A project risk is an uncertain event or condition that can have a positive or negative impact on the project.
32
Risk burn down
• A chart that displays risk and success with feature vs. time.
33
Risk identification
• The systematic process of combing through the project, the project plan, the work breakdown structure, and all supporting documentation to identify as many risks that may affect the project as possible.
34
Risk impact
• To analyze the consequences of the risk if they occur based on their probability.
35
Risk management plan
• A project management subsidiary plan that defines how risks will be identified, analyzed, responded to, and monitored within the project. The plan also defines the iterative risk management process that the project is expected to adhere to.
36
Risk owners
• The individuals or entities that are responsible for monitoring and responding to an identified risk within the project.
37
Risk probability
• The likelihood that the risk will occur.
38
Risk register
• The risk register is a project plan component that contains all of the information related to the risk management activities. It’s updated as risk management activities are conducted to reflect the status, progress, and nature of the project risks. • The risk register is a centralized database consisting of the outcome of all the other risk management processes, such as the outcome of risk identification, qualitative analysis, and quantitative analysis.
39
Risk report
• The risk report explains the overall project risks and provides summaries about the individual project risks.
40
Risk response audit
• An audit to test the validity of the established risk responses.
41
Risk response plan
• This subsidiary plan defines the risk responses that are to be used in the project for both positive and negative risks.
42
Risk responsibilities
• The level of ownership an individual or entity has over a project risk.
43
Risk score
• The calculated score based on each risk’s probability and impact. The approach can be used in both qualitative and quantitative risk analysis.
44
Risk severity
• How much the risk’s consequences will influence the success or failure of a project. Risk Probability (%) x Risk Impact ($) = Risk Severity
45
Risk-adjusted backlog
• A product backlog adjusted to help balance the risk and value factors of product.
46
Risk-based spike
• This spike helps the team remove major risks, and if the spike fails every approach possible, the project is defined as “fast failure”.
47
Risk-related contractual agreements
• When the project management team decides to use transference to respond to a risk, a risk- related contractual agreement is created between the buyer and the seller.
48
ROI
• Return on Investment-The return an organization makes on an investment expressed by a percentage.
49
Role
• This denotes what a person is specifically responsible for in a project. Roles are usually tied to job titles, such as network engineer, mechanical engineer, and electrician.
50
Rolling wave planning
• The imminent work is planned in detail, while the work in the future is planned at a high level. This is a form of progressive elaboration.
51
Root cause analysis
• To investigate beyond the symptoms of the problem and to understand the root cause of the problem.
52
Root cause diagram
• A diagram that correlates different factors and the symptom.
53
Root cause identification
• Root cause identification aims to find out why a risk event may be occurring, the causal factors for the risk events, and then, eventually, how the events can be mitigated or eliminated.
54
Rough order of magnitude
• This rough estimate is used during the initiating processes and in top-down estimates. The range of variance for the estimate can be from –25 percent to +75 percent.
55
Rule of seven
• A component of a control chart that illustrates the results of seven measurements on one side of the mean, which is considered “out of control” in the project.
56
Run chart
• A quality control tool that shows the results of inspection in the order in which they’ve occurred. The goal of a run chart is first to demonstrate the results of a process over time and then to use trend analysis to predict when certain trends may reemerge.
57
Satisfaction
• The feeling of workers when their needs are fulfilled. Known as motivators.
58
Scatter diagram
• A quality control tool that tracks the relationship between two variables over time. The two variables are considered related the closer they track against a diagonal line.
59
Schedule baseline
• This is the planned start and finish of the project. The comparison of what was planned and what was experienced is the schedule variance.
60
Schedule management plan
• Defines how the project schedule will be created and managed. • A subsidiary plan in the project management plan. It defines how the project schedule will be created, estimated, controlled, and managed.
61
Schedule milestones
• The project customer may have specific dates when phases of the project should be completed. These milestones are often treated as project constraints.
62
Schedule Performance Index (SPI)
• Measures the project based on its schedule performance. The formula is SPI = EV/PV.
63
Schedule Variance (SV)
• The difference between the earned value and the planned value. • The formula is SV = EV –PV.
64
Scope baseline
• The scope baseline is a combination of three project documents: the project scope statement, the work breakdown structure, and the WBS dictionary. The creation of the project deliverable will be measured against the scope baseline to show any variances from what was expected and what the project team has created.
65
Scope creep
• The uncontrolled changes or growth in a project’s scope which goes beyond the initial agreement. • Undocumented, unapproved changes to the project scope.
66
Scope validation
• The formal inspection of the project deliverables, which leads to project acceptance.
67
Scoring models
• These models use a common set of values for all of the projects up for selection. For example, values can be profitability, complexity, customer demand, and so on.
68
Screening system
• A tool that filters or screens out vendors that don’t qualify for the contract.
69
Scrum
• A popular agile methodology.
70
Scrum of scrums
• Meetings used to organize large projects with scrum masters from different teams.
71
Scum master
• The leader that helps the team to follow Scrum methodology.
72
Secondary risks
• New risks that are created as a result of a risk response.
73
Self-directing team
• This team has the capability to make their own decisions, empowerment, mutual accountability, and collective ownership of a project, which leads them to be more productive and efficient.
74
Self-organizing team
• Naturally formed teams that interact with minimal management supervision.
75
Seller rating systems
• These are used by organizations to rate prior experience with each vendor that they have worked with in the past. The seller rating system can track performance, quality ratings, delivery, and even contract compliance.
76
Sender
• The person who is sending the message.
77
Sender-receiver models
• Communication requires a sender and a receiver. Within this model may be multiple avenues to complete the flow of communication, but barriers to effective communication may be present as well. • Feedback loops and barriers to communications.
78
Sensitivity analysis
• A quantitative risk analysis tool that examines each risk to determine which one has the largest impact on the project’s success.
79
Servant leadership
• The leader puts others first and focuses on the needs of the people he serves. Servant leaders provide opportunity for growth, education, autonomy within the project, and the well-being of others. The primary focus of servant leadership is service to others.
80
Seven basic quality tools
• These seven tools are used in quality planning and in quality control: cause-and-effect diagrams, flowcharts, check sheets, Pareto diagrams, histograms, control charts, and scatter diagrams.
81
Sharing
• A risk response that shares the advantages of a positive risk within a project.
82
Shu-Ha-Ri Model
• Originated in Japan as a way to understand learning and mastery, Shu –obeying the rules, Ha - consciously moving away from the rules, and Ri –consciously finding an individual path.
83
Silo
• Work that is isolated.
84
Single source
• Many vendors can provide what your project needs to purchase, but you prefer to work with a specific vendor.
85
Situational power
• The project manager has power because of certain situations in the organization.
86
Smoothing
• This approach smooths out the conflict by minimizing the perceived size of the problem. It is a temporary solution, but can calm team relations and boisterous discussions.
87
Social media-based communication
• Communication used conveniently to receive instant feedback, ideas, and requirements from a particular community.
88
Soft logic
• The activities don’t necessarily have to happen in a specific order. For example, you could install the light fixtures first, then the carpet, and then paint the room. The project manager could use soft logic to change the order of the activities if so desired.
89
Software Development Life Cycle (SDLC)
• This cycle tends to be long and requires a lot of advanced planning.
90
Sole source
• Only one vendor can provide what your project needs to purchase. Examples include a specific consultant, specialized service, or unique type of material.
91
Special Cause
• A cause that occurs once because of special reasons.
92
Specification breakdown
• This occurs when requirements for the specification are incomplete or conflicting.
93
Spike
• An experiment that helps a team answer a particular question and determine future actions.
94
Sprint
• A consistent iteration that lasts from one week to one month in order to measure velocity in Scrum.
95
Sprint plan
• A document that explains sprint goals, tasks, and requirements and how the tasks will reach completion.
96
Sprint retrospective
• A team-member meeting that occurs after each sprint to evaluate the product and process to improve efficiency and effectiveness.
97
Sprint review
• A meeting that occurs after each sprint to show the product or process to stakeholders for approval and to receive feedback.
98
Stakeholder
• Anyone who is affected by the existence of the project or who can affect the project’s existence. Stakeholders can enter and exit the project as conditions change within the project.
99
Stakeholder analysis
• A scope definition process where the project management team interviews the stakeholders and categorizes, prioritizes, and documents what the project customer wants and needs. The analysis is to determine, quantify, and prioritize the interests of the stakeholders. Stakeholder analysis demands quantification of stakeholder objectives; goals such as “good,” “satisfaction,” and “speedy” aren’t quantifiable. • An activity that ranks stakeholders based on their influence, interests, and expectations of the project. Stakeholders are identified and ranked, and then their needs and expectations are documented and addressed.
100
Stakeholder classification models
• These are charts and diagrams that help the project manager determine the influence of stakeholders in relation to their interest in the project. Common classification models include the power/interest grid, the power/influence grid, the influence/impact grid, and the salience model.
101
Stakeholder engagement
• The project manager works to keep the project stakeholders interested, involved, and supportive of the project. Through communication, management skills, and interpersonal skills, the project manager can work to keep the project stakeholders engaged and interested in the project.
102
Stakeholder engagement plan
• The stakeholder engagement plan documents a strategy for managing the engagement of project stakeholders. The stakeholder engagement plan establishes stakeholder engagement and defines how the project manager can increase and improve stakeholder engagement.
103
Stakeholder engagement planning
• The project manager works with the project team and subject matter experts to create a strategy to manage the project stakeholders.
104
Stakeholder identification
• A project initiation activity to identify, document, and classify the project stakeholders as early as possible in the project.
105
Stakeholder management
• The project management knowledge area that focuses on the management and engagement of the project stakeholders. There are four processes in this knowledge area: identify stakeholders, plan stakeholder management, manage stakeholder engagement, and monitor stakeholder engagement.
106
Stakeholder notifications
• Notices to the stakeholders about resolved issues, approved changes, and the overall health of the project.
107
Stakeholder register
• A documentation of each stakeholder’s contact information, position, concerns, interests, and attitude toward the project. The project manager updates the register as new stakeholders are identified and when stakeholders leave the project.
108
Start-to-finish
• An activity relationship that requires an activity to start so that its successor can finish. This is the most unusual of all the activity relationship types.
109
Start-to-start
• An activity relationship type that requires the current activity to start before its successor can start.
110
Statistical sampling
• A process of choosing a percentage of results at random. For example, a project creating a medical device may have 20 percent of all units randomly selected to check for quality.
111
Status review meeting
• A regularly scheduled meeting to discuss the status of the project and its progress toward completing the project scope statement.
112
Storming
• The project team struggles for project positions, leadership, and project direction. The project team can become hostile toward the project leader, challenge ideas, and try to establish and claim positions about the project work. The amount of debate and fury can vary depending on if the project team is willing to work together, the nature of the project, and the control of the project manager.
113
Story card
• An index card that displays the user story.
114
Story map
• A prioritization tool that backlogged stories made smaller and organized by user functionality.
115
Story point
• A unit of measurement to estimate the difficulty of a user story.
116
Strong matrix structure
• An organization where organizational resources are pooled into one project team, but the functional managers have less project power than the project manager.
117
Style
• The tone, structure, and formality of the message being sent should be in alignment with the audience and the content of the message.
118
Subnet
• A representation of a project network diagram that is often used for outsourced portions of projects, repetitive work within a project, or a subproject. Also called a fragnet.
119
Subprojects
• A smaller project managed within a larger, parent project. Subprojects are often contracted work whose deliverable allows the larger project to progress.
120
Sunk costs
• Monies that have already been invested in a project.
121
Supportive stakeholder status
• This is part of stakeholder analysis classification. A supportive stakeholder is aware of your project and is supportive and hopeful that the project will be successful.
122
Sustainability
• A maintainable pace of work that is intense yet steady.
123
Swarming
• When the team collaborates to focus on a single user story.
124
SWOT analysis
• SWOT analysis is the process of examining the project from the perspective of each characteristic: strengths, weaknesses, opportunities, and threats.
125
System or process flowcharts
• Flowcharts that illustrate the flow of a process through a system, such as a project change request through the change control system, or work authorization through a quality control process.
126
Systems analysis
• A scope definition approach that studies and analyzes a system, its components, and the relationship of the components within the system.
127
Systems engineering
• This project scope statement creation process studies how a system should work, designs and creates a system model, and then enacts the working system based on the project’s goals and the customer’s expectations. Systems engineering aims to balance the time and cost of the project in relation to the scope of the project.
128
Tabaka’s Model
• A model originated in Japan to describe a team with values that include self-organization, empowered to make decisions, belief in vision and success, a committed team, trust, participatory decision making, consensus-driven, and constructive disagreement.
129
Tacit knowledge
• Knowledge that’s more difficult to express because it’s personal beliefs, values, knowledge gain from experience, and “know-how” when doing a task.
130
Tasks
• The smaller jobs to fulfill a user story, usually divided among team members.
131
Team
• A group of individuals charged with the responsibility of delivery and value of a project.
132
Team empowerment
• A team that is empowered has collaboration, responsibility, and self-sufficiency.
133
Team formation
• Formation happens when a team creates ground rules and processes to build bonds and shared goals.
134
Team participation
• When the team discusses the requirements that will fulfill the customer’s needs.
135
Team space
• An area for team members to collocate, usually a physical location, in some cases a virtual location is created.
136
Team velocity
• The number of story points completed during iteration, and used to determine the planned capacity.
137
Teamwork
• Team members function in a way that is collaborative to complete tasks and reach a common goal, mostly achieved with strong communication.
138
Technical debt
• Technical decisions a team chooses to not implement currently, but must do so or face difficulty in the future.
139
Technical interfaces
• The project team identifies the disciplines and specialties that the project will require to complete the project scope statement. The technical interfaces are the resources that will be doing the project work.
140
Technical, quality, or performance risks
• Technical risks are associated with new, unproven, or complex technologies being used on the project. Changes to the technology during the project implementation can also be a risk. Quality risks are the levels set for expectations of impractical quality and performance.
141
TECOP
• A prompt list used in risk identification to examine the Technical, Environmental, Commercial, Operational, and Political factors of the project.
142
Template
• A previous project that can be adapted for the current project and forms that are pre-populated with organizational-specific information.
143
Terms of reference
• Defines the obligations for the seller, what the seller will provide, and all of the particulars of the contracted work. Terms of reference is similar to the statement of work.
144
Test-Driven Development (TDD)
• A written acceptance test for a module with the code built to pass the tests in order to ensure correct performance.
145
Tester
• Explains acceptance test to the customers then consistently measures the product against the test and records results for the team. (XP Role)
146
Theme
• A group of stories, iteration, or release’s idea determined by the customer and the team agrees with the idea.
147
Three-point estimate
• A technique for each activity that requires optimistic, most likely, and pessimistic estimates to be created. Based on these three estimates, an average can be created to predict how long the activity should take.
148
Time and materials contract
• A contract type in which the buyer pays for the time and materials for the procured work. This is a simple contract, usually for smaller procurement conditions. These contract types require a not- to-exceed clause, or the buyer assumes the risk for cost overruns.
149
Time reporting system
• A system to record the actual time to complete project activities.
150
Time-boxing
• To set a fixed delivery date for a project or release.
151
To-complete performance index
• A formula to forecast the likelihood of a project to achieve its goals based on what’s happening in the project right now. There are two different flavors for the TCPI, depending on what you want to accomplish. If you want to see if your project can meet the budget at completion, you’ll use this formula: TCPI = (BAC –EV)/(BAC –AC). If you want to see if your project can meet the newly created estimate at completion, you’ll use this version of the formula: TCPI = (BAC – EV)/(EAC –AC).
152
Total float
• This is the total time an activity can be delayed without delaying project completion.
153
Tracker
• A role in XP that measures the team’s progress, and communicates the measurements to the team.
154
Traditional management
• A top-down approach that consists of long cycles, heavy planning, and minimal customer involvement.
155
Transactional leadership
• The leader emphasizes the goals of the project and rewards and disincentives for the project team. This is sometimes called management by exception as it’s the exception that is reward or punished.
156
Transference
• A risk response that transfers the ownership of the risk to another party. Insurance, licensed contractors, or other project teams are good examples of transference. A fee and contractual relationships are typically involved with the transference of a risk.
157
Transformational leadership
• The leader inspires and motivates the project team to achieve the project goals. Transformational leaders aim to empower the project team to act, be innovative in the project work, and accomplish through ambition.
158
Transparency
• To show everyone’s involvement and progress to the entire team.
159
Tree diagram
• Tree diagrams show the hierarchies and decomposition of a solution, an organization, or a project team. The WBS and an org chart are examples of tree diagrams.
160
Trend analysis
• The science of using past results to predict future performance.
161
Triple constraints of project management
• Also known as the Iron Triangle. This theory posits that time, cost, and scope are three constraints that every project has.
162
Two-way communication
• To allow communication between parties so their concerns and perspectives are given for effective feedback.
163
Unanimity
• A group decision method where everyone must be in agreement.
164
Unaware stakeholder status
• Part of stakeholder analysis classification. An unaware status means the stakeholder doesn’t know about the project and the effect the project may create on the stakeholder.
165
Unit testing
• These tests are used for continuous feedback to achieve quality improvement and assurance.
166
Usability testing
• An exploratory test which uses a test subject to understand the usability of software.
167
User story
• At least one business requirement that increases the value for the user.
168
Users involvement
• The active involvement of users in the development cycle of a project so team members can receive feedback about the user’s requirements.
169
Validation
• The way to make sure that the product is acceptable to the customer.
170
Value
• The worth of a product, project, or service.
171
Value analysis
• As with value engineering, this approach examines the functions of the project’s product in relation to the cost of the features and functions. This is where, to some extent, the grade of the product is in relationship to the cost of the product.
172
Value engineering
• This approach to project scope statement creation attempts to find the correct level of quality in relation to a reasonable budget for the project deliverable while still achieving an acceptable level of performance of the product.
173
Value stream mapping
• A tool used to analyze a chain of processes with the desired outcome of eliminating waste.
174
Value-based prioritization
• To allow the PO or customer determine which function to implement first based on the value it delivers.
175
Value-driven delivery
• To realize the values needed to deliver a project.
176
Variability risks
• A type of risk based on the variations that may occur in the project, such as production, number of quality errors, or even the weather.
177
Variable costs
• Costs that change based on the conditions applied in the project (the number of meeting participants, the supply of and demand for materials, and so on).
178
Variance
• The difference between what was expected and what was experienced.
179
Variance
• The measurement of how far apart data is from each other.
180
Variance At Completion (VAC)
• A forecasting formula that predicts how much of a variance the project will likely have based on current conditions within the project. The formula is VAC = BAC –EAC.
181
Velocity
• The total number of features that a team delivers in iteration.
182
Verification
• To ensure the product meets requirements and specifications.
183
Virtual organization
• Uses a network structure to communicate and interact with other groups and departments. A point of contact exists for each department and these department point of contact receive and send all messages for the department.
184
Virtual team
• A geographically distributed group that does not meet physically.
185
Visibility
• The team’s work and progress must be transparent to all stakeholders.
186
Vroom’s Expectancy Theory
• This theory states that people will behave based on what they expect as a result of their behavior. In other words, people will work in relation to the expected reward.
187
VUCA
• A prompt list used in risk identification that examines the Volatility, Uncertainty, Complexity, and Ambiguity of risk factors within the project.
188
War room
• A space where the team can work and collaborate effectively.
189
Waterfall
• Resistant to change that requires heavy planning and sequential, traditional approach.
190
WBS dictionary
• A WBS companion document that defines all of the characteristics of each element within the WBS.
191
WBS template
• A prepopulated WBS for repetitive projects. Previous projects’ WBSs are often used as templates for current similar projects.
192
Weak matrix structure
• An organization where organizational resources are pooled into one project team, but the functional managers have more project power than the project manager.
193
Weighting system
• This takes out the personal preferences of the decision maker in the organization to ensure that the best seller is awarded the contract. Weights are assigned to the values of the proposals, and each proposal is scored.
194
Wide-Band Delphi Estimating
• An estimation technique for user stories. The PO presents user stories & discusses challenges. Each story’s estimates plotted, and then the team comes to an agreement on the range of points.
195
WIP
• Work-In-Progress-Stories that have started, which are displayed in workflows to show progress and what still needs to be completed.
196
WIP Limits
• To limit work-in-progress so a team can do the following: maintain focus on completing work, maintaining quality, and delivering value.
197
Wireframe
• A lightweight non-functional UI design that shows the customer the vital elements and how they will interact before coding.
198
Withdrawal
• This conflict resolution method sees one side of the argument walking away from the problem, usually in disgust.
199
Work Breakdown Structure (WBS)
• A deliverables-oriented breakdown of the project scope.
200
Work package
• The smallest item in the work breakdown structure.
201
Work performance data
• Raw data, observations, and measurements about project components. Work performance data is gathered and stored in the project management information system.
202
Work performance information
• Work performance information is the processed and analyzed data that will help the project manager make project decisions.
203
Work performance reports
• Work performance reports is the formatted communication of work performance information. Work performance reports communicate what is happening in the project through status reports, memos, dashboards, or other modalities.
204
Workflow
• A series of phases or stages the team has agreed to execute for a project.
