CAPM — PMI Certified Associate in Project Management Cheat Sheet

Last revised: September 28, 2026

Cheat sheet: CAPM reference for PMI project management concepts, predictive and agile methods, business analysis, formulas, roles, artifacts, and exam decision cues.

Use the tables for a quick pre-exam check. Expand a topic’s notes for explanations, examples, and additional distinctions.

Scope and study context

What artifact, role, or process fits a scenario.
Whether a situation is predictive, agile, hybrid, or business-analysis focused.
Which formula applies and how to interpret the result.
What a project manager, team member, product owner, sponsor, or business analyst should do next.

The CAPM rewards candidates who can do more than recognize terms. You need to connect project management vocabulary to realistic scenarios: which artifact is used, what the project manager should do next, which lifecycle fits the situation, and how to avoid common “sounds right but not best” answers.

This page is PM Mastery review support and companion practice guidance. It is not affiliated with PMI.

Item	Details
Provider	PMI
Official exam title	PMI Certified Associate in Project Management (CAPM)
Exam code	CAPM
Best use of this page	Final concept refresh before original practice questions, topic drills, and mock exam review

CAPM Mental Model

Exam cue	Think first	Then decide
“New project,” “authorization,” “funding”	Initiating	Project charter, sponsor approval, high-level risks/stakeholders
“How will we do the work?”	Planning	Management plans, baselines, requirements, estimates
“Work is being performed”	Executing	Team, communications, quality assurance, stakeholder engagement
“Compare actual to plan”	Monitoring and controlling	Variance, forecasts, change requests, corrective action
“Customer accepts deliverable”	Closing	Formal acceptance, lessons learned, final reports, archive
“Unclear requirements, frequent feedback”	Agile/adaptive	Iteration, backlog, product owner, inspect and adapt
“Stable requirements, regulated sequence”	Predictive	Up-front planning, baselines, change control
“Need business value clarity”	Business analysis	Needs assessment, requirements, traceability, acceptance criteria
“Someone asks for extra work”	Scope/change control	Do not just do it; evaluate and process the change
“Risk event happens”	Issue response	Use response plan, update issue log, assess changes

Core PMI Project Terms

Term	Practical meaning	Common exam trap
Project	Temporary effort to create a unique product, service, or result	Temporary does not mean short; operations are ongoing
Program	Related projects managed together for benefits	Program focuses on coordinated benefits, not just a big project
Portfolio	Projects/programs grouped to meet strategic objectives	Portfolio selection is strategy and investment focused
Product	Output or service delivered to users/customers	Product lifecycle can continue after the project ends
Project lifecycle	Phases from start to close	Can be predictive, iterative, incremental, agile, or hybrid
Development approach	How the product/service is created	Separate from the management lifecycle, though related
Deliverable	Verifiable product, result, or capability	Must be accepted against criteria
Milestone	Significant point or event	Usually zero duration
Constraint	Limitation such as time, cost, scope, quality, resources, risk	Not all constraints are equal in every scenario
Assumption	Believed true for planning	Must be validated; uncertainty can become risk
Baseline	Approved version of scope, schedule, or cost	Changes require formal control in predictive environments
Tailoring	Adapting methods to context	Not skipping discipline; choosing appropriate rigor
Value	Benefit, usefulness, or outcome delivered	PMI questions often favor value over mere activity completion

Notes and examples

Project, program, portfolio, and operations

Concept	Meaning	Exam trap
Project	Temporary effort that creates a unique product, service, or result	“Temporary” means the project ends, not necessarily that the result is short-lived
Operations	Ongoing, repetitive work that sustains the business	Operations can use project outputs, but they are not projects
Program	Related projects managed together for benefits not available separately	Do not treat a program as merely a large project
Portfolio	Projects, programs, and operations grouped to meet strategic objectives	Portfolio decisions are about strategic alignment and investment choices

Core project constraints

CAPM questions often hide the real issue inside one constraint while distracting you with another.

Constraint	Typical question signal	Review point
Scope	New features, unclear deliverables, acceptance disputes	Use requirements, scope statement, WBS, acceptance criteria, and change control
Schedule	Missed dates, dependencies, critical path, compression	Review sequencing, duration estimates, float, crashing, and fast tracking
Cost	Budget variance, reserves, cost estimates	Know cost baseline, contingency reserve, management reserve, and earned value basics
Quality	Defects, rework, inspection, prevention	Quality is meeting requirements, not automatically “premium grade”
Risk	Uncertain future event, probability, impact	Risk is proactive; issues are already happening
Resources	Skills, availability, conflict, team performance	Match staffing, development, conflict resolution, and recognition
Stakeholders	Resistance, expectations, communication needs	Analyze interest, influence, engagement, and communication preferences

Organizational structures

Structure	Project manager authority	Resource control	Typical clue
Functional	Low	Functional manager	Team members report mainly to department managers
Weak matrix	Low to moderate	Functional manager	Project coordinator or expediter language may appear
Balanced matrix	Shared	Shared	PM and functional manager both influence decisions
Strong matrix	Moderate to high	Project manager	PM has meaningful authority over work and priorities
Projectized	High	Project manager	Team is organized around projects

Project manager behavior that is usually favored

In scenario questions, the best project manager usually:

Uses documented processes before acting informally.
Communicates early and appropriately.
Engages stakeholders instead of avoiding conflict.
Uses data, baselines, and agreed criteria.
Facilitates team problem solving.
Protects value and quality.
Tailors the approach to the project context.
Escalates only after reasonable project-level action is insufficient.

Project, Program, Portfolio, and Operations

Situation	Best classification	Why
Implement a new payroll system	Project	Temporary and unique deliverable
Maintain payroll every two weeks	Operations	Repetitive ongoing work
Modernize HR systems through multiple related projects	Program	Coordinated related projects for benefits
Select which internal transformation initiatives receive funding	Portfolio	Strategic prioritization across investments
Improve support desk response time continuously	Operations / continuous improvement	Ongoing process improvement unless a temporary initiative is defined
Build app v1, then transition support to IT operations	Project then operations	Project creates capability; operations sustain it

PMI Principles and Performance Domains

PMBOK-Style Principles

Principle	Exam-ready meaning
Stewardship	Act responsibly, ethically, and with care for resources and impact
Team	Build a collaborative, respectful project team environment
Stakeholders	Engage stakeholders proactively and continuously
Value	Focus decisions on expected benefit and outcomes
Systems thinking	Understand interdependencies and broader organizational context
Leadership	Influence, guide, motivate, and remove barriers
Tailoring	Fit approach, governance, and artifacts to the context
Quality	Build quality into processes and deliverables
Complexity	Recognize uncertainty, ambiguity, interfaces, and human factors
Risk	Address threats and opportunities proactively
Adaptability and resilience	Respond effectively to change and disruption
Change	Enable beneficial change and transition to new outcomes

Notes and examples

Performance Domains

Domain	What to watch for in questions
Stakeholders	Identification, analysis, engagement, communication, expectations
Team	Culture, leadership, roles, conflict, performance
Development approach and lifecycle	Predictive vs agile vs hybrid selection
Planning	Progressive elaboration, baselines, plans, estimates
Project work	Execution, procurement, resources, issues, knowledge
Delivery	Scope completion, quality, acceptance, value delivery
Measurement	Metrics, variance, forecasts, performance reporting
Uncertainty	Risks, ambiguity, complexity, resilience

Lifecycle and Approach Selection

Approach	Choose when	Planning style	Delivery style	Change handling
Predictive / waterfall	Requirements are stable; sequence is known; high need for control	Up-front detailed planning	Deliver near the end or at major phase gates	Formal change control
Iterative	Need feedback to refine solution	Plan enough to repeat cycles	Rework/refine through iterations	Expected learning and refinement
Incremental	Need usable pieces delivered over time	Plan by increments	Deliver completed subsets	New increments can adjust scope
Agile / adaptive	Requirements uncertain; frequent feedback needed	Rolling wave, backlog-driven	Frequent value delivery	Change expected and prioritized
Hybrid	Some parts stable, others uncertain	Mix of predictive and adaptive planning	Predictive components plus agile increments	Formal control for baselined parts; backlog control for agile parts

Notes and examples

High-Yield Distinctions

Pair	Distinction
Iterative vs incremental	Iterative improves the same solution through feedback; incremental delivers usable pieces
Predictive vs agile	Predictive protects baselines; agile optimizes learning and value delivery
Tailoring vs shortcutting	Tailoring is deliberate fit-for-purpose governance; shortcutting ignores needed controls
Product scope vs project scope	Product scope = features/functions; project scope = work to deliver them
Verification vs validation	Verification checks correctness against requirements; validation checks fitness for intended use
Risk vs issue	Risk may happen; issue has happened
Corrective action vs preventive action	Corrective realigns performance; preventive reduces chance of future variance
Quality assurance vs quality control	Assurance improves process; control inspects deliverables/results
Manage stakeholders vs manage communications	Stakeholders focuses engagement and relationships; communications focuses information flow

Predictive Process Reference

Process Groups

Process group	Purpose	Typical outputs
Initiating	Authorize project or phase	Project charter, stakeholder register
Planning	Define objectives, scope, approach, baselines	Project management plan, subsidiary plans, baselines
Executing	Complete work and coordinate people/resources	Deliverables, work performance data, issue log updates
Monitoring and controlling	Track, compare, control, and recommend changes	Work performance information, change requests, forecasts
Closing	Formally complete project/phase/contract	Accepted deliverables, final report, lessons learned archive

Notes and examples

Knowledge Area Quick Map

Knowledge area	Main concern	Key artifacts / outputs	Exam cue
Integration	Coordinate all parts	Charter, project management plan, change log, lessons learned	“Coordinate,” “overall plan,” “change request”
Scope	Define and control what is included	Scope statement, WBS, scope baseline, requirements traceability matrix	“Extra feature,” “what work is included”
Schedule	Sequence and time work	Activity list, network diagram, schedule baseline	“Delay,” “critical path,” “float”
Cost	Estimate, budget, control costs	Cost estimates, cost baseline, forecasts	“Over budget,” “CPI,” “EAC”
Quality	Meet requirements and fitness for use	Quality management plan, metrics, quality reports	“Defects,” “inspection,” “process improvement”
Resource	Acquire, develop, manage team/resources	Resource management plan, team charter, assignments	“Team performance,” “resource conflict”
Communications	Ensure right information reaches right people	Communications management plan, reports	“Who needs what information when”
Risk	Manage uncertainty	Risk register, risk report, response plans	“Threat,” “opportunity,” “probability/impact”
Procurement	Buy products/services externally	Procurement strategy, bid documents, contracts	“Vendor,” “seller,” “contract”
Stakeholder	Identify and engage impacted parties	Stakeholder register, engagement plan	“Resistance,” “expectations,” “influence”

Key Predictive Artifacts

Artifact	Purpose	Created/used when	Do not confuse with
Business case	Justifies investment and expected benefits	Before or during initiation	Project charter
Benefits management plan	Describes how benefits will be measured and sustained	Initiation/planning	Scope baseline
Project charter	Formally authorizes project and PM authority	Initiating	Project management plan
Stakeholder register	Lists stakeholders and key attributes	Initiating, updated throughout	Communications plan
Project management plan	Integrated plan for executing, monitoring, controlling, closing	Planning, updated by change control	Schedule alone
Scope statement	Detailed product/project scope and exclusions	Planning	WBS
WBS	Hierarchical decomposition of total scope	Planning	Schedule or org chart
WBS dictionary	Detail for WBS components	Planning	Requirements document
Scope baseline	Approved scope statement + WBS + WBS dictionary	Planning/control	Product roadmap
Schedule baseline	Approved schedule model	Planning/control	Activity list
Cost baseline	Approved time-phased budget	Planning/control	Funding limit
Issue log	Tracks current problems needing action	Throughout	Risk register
Risk register	Records risks, analysis, owners, responses	Throughout	Issue log
Change log	Tracks change requests and status	Control changes	Backlog
Lessons learned register	Captures learning during the project	Throughout	Final archive only
Final report	Summarizes performance and closure	Closing	Status report

Project Charter vs Project Management Plan

Attribute	Project charter	Project management plan
Main purpose	Authorize the project	Direct how the project will be executed and controlled
Level of detail	High level	Detailed and integrated
Approved by	Sponsor or authorized initiator	Appropriate governance/change authority
Contains	Purpose, objectives, high-level requirements, high-level risks, milestones, budget, PM authority	Subsidiary plans, baselines, governance, methods
Timing	Initiating	Planning and updated through control
Exam cue	“Project does not yet exist formally”	“How should the work be managed?”

Scope and Requirements

Concept	Meaning	Exam cue
Requirement	Condition or capability needed by stakeholder/product	“The system must…”
Acceptance criteria	Conditions that must be met for acceptance	“Done means…”
Product scope	Features/functions of the deliverable	User-facing capability
Project scope	Work required to deliver product scope	Activities and deliverables
WBS	Decomposes total project scope	Work packages
Work package	Lowest WBS level typically used for estimating/managing	Assignable work
Scope baseline	Approved scope definition	Used to detect scope variance
Scope creep	Uncontrolled expansion of scope	Extra work without approval
Gold plating	Adding unrequested features	Team adds value not requested; still bad practice
Requirements traceability matrix	Links requirements to business need, deliverables, tests, acceptance	Impact analysis and coverage

Notes and examples

Product scope vs project scope

Concept	Meaning	Example
Product scope	Features and functions of the product, service, or result	What the software does
Project scope	Work required to deliver the product, service, or result	The project activities needed to build and release the software

WBS essentials

The work breakdown structure is a hierarchical decomposition of the total project scope.

Remember:

The WBS organizes deliverables and work packages.
The WBS dictionary gives detail about WBS components.
The scope baseline includes the approved scope statement, WBS, and WBS dictionary.
The WBS is not the same as the schedule; activities are developed from work packages.

Integrated change control

When a requested change could affect scope, schedule, cost, quality, risk, or baselines, do not simply “do the work.”

Typical sequence:

Document the change request.
Assess impact on scope, schedule, cost, quality, resources, risk, and stakeholders.
Submit to the appropriate change control authority.
Communicate the decision.
Update plans, baselines, and documents if approved.
Implement and verify the approved change.

Common trap: “The customer is important, so implement immediately” is usually wrong if the change affects approved baselines.

Schedule Reference

Term	Meaning	Decision cue
Activity	Work needed to produce deliverable	Decompose work packages into activities
Dependency	Logical relationship between activities	Sequence work
Mandatory dependency	Required by nature/contract	Cannot easily change
Discretionary dependency	Preferred/best practice	Can be revised for compression
External dependency	Outside project control	Monitor and manage
Lead	Successor can start before predecessor fully finishes	Overlap work
Lag	Waiting time between activities	Delay successor
Critical path	Longest path through network; determines shortest project duration	Activities with zero/lowest float
Total float	How long activity can slip without delaying project finish	Schedule flexibility
Free float	How long activity can slip without delaying successor	Local flexibility
Fast tracking	Do activities in parallel that were sequential	Adds risk/rework
Crashing	Add resources to shorten duration	Adds cost

Notes and examples

Schedule Compression Decision

Situation	Better technique	Why
Need shorten schedule and budget is available	Crashing	Adds resources to critical-path work
Need shorten schedule with limited budget but risk acceptable	Fast tracking	Overlaps work; increases rework risk
Non-critical activity is late but has float	Use float, monitor	May not affect project finish
Critical-path activity is late	Compress, re-sequence, or change scope	Directly affects finish date
Customer requests earlier date without changing scope/cost	Analyze impact first	Do not commit without evaluating constraints

Dependencies

Dependency type	Meaning	Example clue
Mandatory	Inherent or legally/contractually required	Foundation before walls
Discretionary	Preferred or best-practice sequence	Team chooses one design review before another
External	Dependency outside project control	Vendor or regulator action
Internal	Dependency within project control	Team A must finish before Team B starts

Leads and lags

Term	Meaning	Trap
Lead	Successor can start before predecessor fully finishes	Lead accelerates overlap
Lag	Waiting time between activities	Lag adds delay

Critical path and float

The critical path is the longest path through the network and usually determines the shortest project duration. Activities on the critical path generally have zero total float, but always rely on the data in the question.

Metric	Plain-language formula
Total float	LS - ES, or LF - EF
Free float	Time an activity can slip without delaying the early start of its successor
Critical path	Longest path through the project network

Schedule compression

Technique	Meaning	Main risk
Crashing	Add resources to shorten duration	Higher cost; may not work for all activities
Fast tracking	Perform activities in parallel that were planned sequentially	Increased rework and risk

Cost and Earned Value Formula Sheet

Core Earned Value Terms

Term	Plain formula / meaning	Interpretation
PV	Planned Value	Budgeted value of work planned by a date
EV	Earned Value	Budgeted value of work actually completed
AC	Actual Cost	Actual cost incurred
BAC	Budget at Completion	Total approved budget
CV	EV - AC	Positive = under budget; negative = over budget
SV	EV - PV	Positive = ahead of schedule; negative = behind schedule
CPI	EV / AC	Greater than 1 = cost efficient
SPI	EV / PV	Greater than 1 = schedule efficient
EAC	Estimate at Completion	Forecast total cost
ETC	EAC - AC	Expected cost to finish remaining work
VAC	BAC - EAC	Positive = expected under budget; negative = over budget
TCPI	(BAC - EV) / (BAC - AC) or (BAC - EV) / (EAC - AC)	Required future cost performance

Notes and examples

Display Formula Reference

\[ \text{CV} = \text{EV} - \text{AC} \]\[ \text{SV} = \text{EV} - \text{PV} \]\[ \text{CPI} = \frac{\text{EV}}{\text{AC}} \]\[ \text{SPI} = \frac{\text{EV}}{\text{PV}} \]\[ \text{EAC} = \frac{\text{BAC}}{\text{CPI}} \]\[ \text{ETC} = \text{EAC} - \text{AC} \]\[ \text{VAC} = \text{BAC} - \text{EAC} \]

EAC Selection

Situation	Use	Plain formula
Current cost performance expected to continue	Cost efficiency drives forecast	EAC = BAC / CPI
Original estimate no longer valid	Re-estimate remaining work	EAC = AC + bottom-up ETC
Future work expected at original budgeted rate	Past variance is atypical	EAC = AC + (BAC - EV)
Both cost and schedule performance affect remaining work	Cost and schedule issues continue	EAC = AC + ((BAC - EV) / (CPI x SPI))

Earned Value Interpretation

Result	Meaning	Likely management response
CV < 0	Over budget	Analyze causes; consider corrective action
CV > 0	Under budget	Verify work is complete and quality is acceptable
SV < 0	Behind schedule	Check critical path and schedule forecast
SV > 0	Ahead of schedule	Confirm sequencing and value actually earned
CPI < 1	Cost inefficient	Investigate spending, productivity, estimates
CPI > 1	Cost efficient	Validate no quality/scope tradeoff hidden
SPI < 1	Schedule inefficient	Consider compression or re-planning
SPI > 1	Schedule efficient	Confirm completed work aligns with plan

Key cost terms

Term	Meaning
Rough order estimate	Early estimate with limited detail
Definitive estimate	More detailed estimate when information is better known
Contingency reserve	Budget for identified risks, often controlled within the project
Management reserve	Budget for unknown unknowns, usually outside the cost baseline
Cost baseline	Approved budget used to measure cost performance

Earned value basics

Know the meaning before memorizing formulas.

Metric	Meaning	Interpretation
PV	Planned Value: budgeted value of work planned	What should have been earned by now
EV	Earned Value: budgeted value of work actually completed	Value of completed work
AC	Actual Cost: actual cost incurred	What has been spent
CV	Cost Variance = EV - AC	Positive is under budget; negative is over budget
SV	Schedule Variance = EV - PV	Positive is ahead of schedule; negative is behind schedule
CPI	Cost Performance Index = EV / AC	Greater than 1 is favorable
SPI	Schedule Performance Index = EV / PV	Greater than 1 is favorable
EAC	Estimate at Completion	Forecasted total cost
VAC	Variance at Completion = BAC - EAC	Positive is favorable

High-yield formulas:

Fast interpretation rule:

Variance: positive is generally good.
Index: greater than 1 is generally good.
If EV is lower than PV, the project has earned less value than planned.
If AC is higher than EV, the project spent more than the value earned.

Estimating and Planning Formulas

Concept	Plain formula	Use
Communication channels	n(n - 1) / 2	Number of potential communication paths
Triangular estimate	(O + M + P) / 3	Simple three-point average
PERT / beta expected estimate	(O + 4M + P) / 6	Weighted estimate favoring most likely
Beta standard deviation	(P - O) / 6	Uncertainty spread
Range estimate	Expected estimate ± standard deviation	Quick estimate range
Expected monetary value	Probability x impact	Quantitative risk analysis
Net present value	Present value of benefits - present value of costs	Investment comparison
ROI	(Benefit - Cost) / Cost	Return relative to cost
Velocity	Completed story points per iteration	Agile planning trend
Cycle time	Time from work start to completion	Flow efficiency
Lead time	Time from request to delivery	Customer wait time

Notes and examples

\[ \text{Communication Channels} = \frac{n(n-1)}{2} \]\[ \text{PERT Expected Duration} = \frac{O + 4M + P}{6} \]\[ \text{Expected Monetary Value} = \text{Probability} \times \text{Impact} \]

Quality Reference

Concept	Meaning	Exam cue
Quality	Degree to which requirements are met	“Conformance to requirements”
Grade	Category or rank of functionality	Low grade may be acceptable; low quality is not
Prevention	Avoid defects	Preferred over inspection
Inspection	Find defects after work	More costly than prevention
Cost of quality	Cost of conformance + cost of nonconformance	Invest in prevention/appraisal
Cost of conformance	Prevention + appraisal costs	Training, testing, reviews
Cost of nonconformance	Internal + external failure costs	Rework, warranty, complaints
Quality assurance	Process-focused; ensure correct processes	Audits, process analysis
Quality control	Product/result-focused; verify deliverables	Inspection, testing, measurements
Continuous improvement	Ongoing process improvement	Retrospectives, lessons learned, Kaizen-style thinking

Notes and examples

Quality Tools

Tool	Use
Check sheet	Collect defect/frequency data
Pareto chart	Identify most significant causes
Cause-and-effect diagram	Explore root causes
Control chart	Determine process stability
Histogram	Show distribution/frequency
Scatter diagram	Show relationship between variables
Flowchart	Visualize process steps
Checklist	Verify required steps/items
Audit	Check compliance with process
Design of experiments	Analyze variable effects on outcomes

Quality vs grade

Concept	Meaning	Example
Quality	Degree to which requirements are met	A basic product that meets all requirements can be high quality
Grade	Category or rank of features	A luxury version may be higher grade

Do not assume higher grade means higher quality.

Prevention, inspection, and cost of quality

Concept	Meaning	Exam point
Prevention	Avoid defects before they happen	Usually preferred over inspection
Inspection	Find defects after work is done	Necessary but not as efficient as building quality in
Cost of conformance	Money spent to prevent defects	Training, process improvement, testing
Cost of nonconformance	Money lost due to defects	Rework, warranty, reputation damage

Quality assurance vs quality control

Term	Focus
Manage quality / quality assurance	Process effectiveness and quality practices
Control quality	Inspecting and verifying deliverables meet requirements

Risk Reference

Term	Meaning	Exam action
Risk	Uncertain event/condition affecting objectives	Record in risk register
Threat	Negative risk	Avoid, mitigate, transfer, accept, escalate
Opportunity	Positive risk	Exploit, enhance, share, accept, escalate
Trigger	Warning sign that risk may occur	Monitor
Risk owner	Person responsible for risk response	Assign clearly
Residual risk	Risk remaining after response	Monitor/accept/respond
Secondary risk	New risk created by response	Analyze and manage
Risk appetite	General willingness to take risk	Align response
Risk threshold	Specific measurable limit	Escalate if exceeded
Contingency reserve	For identified risks	Part of cost/schedule baseline when approved
Management reserve	For unknown-unknowns	Outside baseline; controlled by management

Notes and examples

Risk Response Selection

Scenario	Threat response	Opportunity response
Remove uncertainty entirely	Avoid	Exploit
Reduce probability or impact	Mitigate	Enhance
Shift ownership to third party	Transfer	Share
Take no proactive action beyond monitoring	Accept	Accept
Outside project manager authority	Escalate	Escalate

Risk vs issue

Concept	Meaning	Response
Risk	Uncertain future event	Analyze and plan response
Issue	Current problem or event that has occurred	Manage and resolve now

Threat responses

Response	Meaning
Avoid	Change plan to eliminate the threat
Mitigate	Reduce probability or impact
Transfer	Shift impact to a third party, often through contract or insurance
Accept	Take no proactive action beyond monitoring or reserve
Escalate	Move outside project authority when appropriate

Opportunity responses

Response	Meaning
Exploit	Ensure the opportunity happens
Enhance	Increase probability or positive impact
Share	Allocate ownership to a party best able to capture it
Accept	Take advantage if it occurs
Escalate	Move outside project authority when appropriate

Expected monetary value:

\[ \text{EMV} = \text{Probability} \times \text{Impact} \]

For decision trees, multiply each outcome by its probability and sum the results for each option.

Communications and Stakeholder Management

Need	Best artifact/action
Identify who is affected by the project	Stakeholder register
Analyze power, interest, influence, impact	Stakeholder analysis
Decide how to engage resistant stakeholders	Stakeholder engagement plan
Decide what information goes to whom and when	Communications management plan
Track stakeholder concerns and actions	Issue log
Report actual project performance	Performance report
Communicate urgent blocker	Direct communication/escalation per plan
Handle misunderstanding	Use active listening, confirm message, adjust communication method

Notes and examples

Stakeholder Engagement Levels

Level	Meaning
Unaware	Does not know about project/impact
Resistant	Aware but opposed
Neutral	Aware but neither supportive nor resistant
Supportive	Aware and supportive
Leading	Actively engaged in project success

Communication Method Selection

Method	Best for	Weakness
Interactive	Meetings, calls, workshops, conflict resolution	Requires availability
Push	Email, memo, report sent to recipients	Does not ensure understanding
Pull	Portal, repository, dashboard	Requires stakeholder to retrieve information
Formal written	Contracts, approvals, baselines	Slower but authoritative
Informal verbal	Quick alignment	Poor audit trail

Communications review

Communication questions often test the method, not just the message.

Method	Best use	Example
Interactive	Real-time multidirectional communication	Meeting, call, workshop
Push	Sent to recipients	Email, memo, report
Pull	Recipients access when needed	Portal, knowledge base, dashboard

Communication channel formula:

\[ \text{Number of communication channels} = \frac{n(n-1)}{2} \]

Where \(n\) is the number of people.

Common trap: adding one stakeholder increases channels by more than one because that person can communicate with every existing person.

Identify, analyze, engage

Activity	Purpose
Identify stakeholders	Determine who can affect or be affected by the project
Analyze stakeholders	Understand interest, influence, power, expectations, and impact
Plan engagement	Decide how to move stakeholders toward desired engagement
Manage engagement	Communicate, address concerns, and involve stakeholders
Monitor engagement	Compare actual engagement to desired engagement

Stakeholder engagement levels

Level	Meaning
Unaware	Does not know about the project or impact
Resistant	Aware but opposed
Neutral	Aware but neither supportive nor resistant
Supportive	Aware and supportive
Leading	Actively helps the project succeed

Exam trap: the best answer is often to engage, understand concerns, and communicate value—not ignore resistance or escalate immediately.

Resources, Team, and Leadership

Concept	Meaning	Exam cue
Functional organization	Functional manager has high authority	PM coordinates with departments
Projectized organization	PM has high authority	Dedicated project team
Matrix organization	Authority shared	Resource negotiation is common
RACI	Responsible, Accountable, Consulted, Informed	Clarifies role ambiguity
Team charter	Team values, ground rules, working agreements	Conflict prevention
Servant leadership	Remove impediments, support team autonomy	Agile and collaborative scenarios
Emotional intelligence	Understand/manage self and relationships	Conflict, negotiation, stakeholder trust
Conflict management	Address disagreement constructively	Collaborate/problem solve often preferred
Virtual team	Team members geographically dispersed	Communication planning is critical

Notes and examples

Conflict Techniques

Technique	Meaning	When appropriate
Collaborate / problem solve	Seek win-win and root cause resolution	Important issues, time available
Compromise / reconcile	Each side gives up something	Moderate urgency
Smooth / accommodate	Emphasize agreement	Low-stakes or relationship priority
Force / direct	One viewpoint imposed	Emergency or safety issue
Withdraw / avoid	Delay or retreat	Cooling-off or low-priority issue

Team development

A common model describes team progression as forming, storming, norming, performing, and adjourning.

Stage	Clue	Project manager focus
Forming	Team is polite, uncertain, looking for direction	Clarify goals, roles, working agreements
Storming	Conflict, disagreement, competition	Facilitate conflict resolution
Norming	Team establishes norms and trust	Reinforce collaboration
Performing	Team works effectively and independently	Remove impediments, support performance
Adjourning	Work ends, team disbands	Recognition, lessons learned, transition

Conflict resolution

Technique	Meaning	When it is attractive
Collaborate / problem solve	Work together for a win-win solution	Usually best for important issues
Compromise	Each side gives something up	Useful when time is limited and both can accept tradeoff
Smooth / accommodate	Emphasize agreement, downplay disagreement	Temporary or low-priority issues
Force / direct	One side wins	Emergency or when authority must decide
Withdraw / avoid	Postpone or retreat	Rarely best for important unresolved issues

Exam trap: “Avoid the conflict” is seldom best when the conflict affects project objectives or team performance.

Responsibility assignment

A RACI chart clarifies roles:

Letter	Meaning
R	Responsible: does the work
A	Accountable: owns the outcome or decision
C	Consulted: provides input
I	Informed: kept updated

Procurement Reference

Contract type	Buyer risk	Seller risk	Best when
Firm fixed price	Lower	Higher	Scope is well defined
Fixed price incentive fee	Medium	Medium	Need cost/schedule/performance incentives
Fixed price with economic price adjustment	Lower/medium	Medium	Long duration with market uncertainty
Cost plus fixed fee	Higher	Lower	Scope uncertain; fixed seller fee
Cost plus incentive fee	Higher	Medium	Need seller cost-performance incentive
Cost plus award fee	Higher	Medium	Subjective performance award criteria
Time and materials	Medium/high	Medium/low	Staff augmentation or undefined quantity; needs oversight

Notes and examples

Procurement Decision Cues

Scenario	Likely action
Need external goods/services	Plan procurement
Need bids/proposals	Conduct procurement
Seller performance issue	Control procurement
Contract complete	Close procurement
Ambiguous contract term	Follow contract and procurement procedures; involve authorized roles
Seller requests change	Process through contract/change control
Buyer wants lowest risk with clear scope	Fixed price
Scope unclear and buyer can manage oversight	Cost-reimbursable or T&M may appear

Contract types

Contract type	Buyer risk	Seller risk	Best fit
Fixed price	Lower if scope is clear	Higher if seller underestimates	Well-defined scope
Cost reimbursable	Higher	Lower	Uncertain or evolving work
Time and materials	Moderate; can grow without control	Moderate	Staff augmentation or unclear duration

Common traps:

Fixed price is not automatically best; unclear scope can cause disputes and change requests.
Cost reimbursable does not mean uncontrolled spending; it still needs oversight.
Procurement documents should match the type of work and the desired risk allocation.

Agile and Adaptive Reference

Agile Values in Exam Language

Agile value	Practical interpretation
Individuals and interactions over processes and tools	Collaboration matters more than rigid procedure
Working product over comprehensive documentation	Useful increments demonstrate progress
Customer collaboration over contract negotiation	Frequent feedback reduces misunderstanding
Responding to change over following a plan	Change can improve value when managed through backlog

Notes and examples

Scrum Reference

Element	Purpose	Exam cue
Product owner	Maximizes product value; orders product backlog	Owns priorities, acceptance, value
Scrum master	Servant leader; removes impediments; supports Scrum	Facilitates, coaches, protects process
Developers / team	Create the increment	Self-managing, cross-functional
Product backlog	Ordered list of product work	Changes as learning occurs
Sprint backlog	Work selected for sprint plus plan	Team-owned during sprint
Increment	Usable completed product slice	Meets definition of done
Sprint planning	Select sprint goal and backlog items	Start of sprint
Daily scrum	Inspect progress toward sprint goal	Short team coordination
Sprint review	Inspect product increment with stakeholders	Feedback on product
Sprint retrospective	Improve team/process	After sprint review, before next sprint
Definition of done	Shared quality/completion standard	Prevents incomplete work from being counted

Agile Planning Levels

Level	Focus
Vision	Product purpose and desired outcome
Roadmap	Major releases/features over time
Release plan	Target capabilities for release
Iteration/sprint plan	Near-term work for iteration
Daily plan	Immediate coordination and impediments

Agile Metrics

Metric	Meaning	Trap
Velocity	Amount of work completed per iteration	Use for planning, not comparing teams
Burndown chart	Work remaining over time	Flat line may show blockers or overcommitment
Burnup chart	Work completed and total scope	Shows scope growth clearly
Cumulative flow diagram	Work across states over time	Widening band may indicate bottleneck
Cycle time	Start-to-finish work time	Helps improve flow
Lead time	Request-to-delivery time	Customer-focused waiting time
WIP limit	Maximum work in progress	Improves focus and flow

Agile Change Handling

Situation	Preferred response
Stakeholder requests new feature	Product owner evaluates and orders backlog
Team discovers better technical approach	Discuss with team/product owner; adapt if valuable
Work does not meet definition of done	Do not count as complete
Sprint goal at risk	Team raises impediment; scrum master helps remove
Stakeholder wants to change current sprint work	Protect sprint goal; product owner considers tradeoffs
Product backlog has too much uncertainty	Refine backlog, split stories, clarify acceptance criteria
Velocity drops	Inspect causes; do not punish the team
Frequent defects	Strengthen definition of done, testing, engineering practices

Agile mindset

Agile questions usually favor:

Frequent delivery of usable value.
Close customer or stakeholder collaboration.
Welcoming change when it improves value.
Self-organizing, empowered teams.
Transparency through visual work and regular feedback.
Continuous improvement through retrospectives.

Agile does not mean no planning. It means planning is continuous and adaptive.

Scrum review

Element	Purpose
Product owner	Maximizes product value and orders the product backlog
Scrum master	Facilitates Scrum, removes impediments, supports the team
Developers / team	Build the increment
Product backlog	Ordered list of product work
Sprint backlog	Work selected for the sprint plus delivery plan
Increment	Usable completed work that meets the Definition of Done
Sprint planning	Decide what can be delivered and how
Daily Scrum	Short daily inspection and adaptation by the team
Sprint review	Inspect increment and adapt backlog with stakeholders
Sprint retrospective	Improve process and teamwork

Common trap: the daily Scrum is not a status meeting for the project manager. It is for the team to coordinate.

Kanban review

Concept	Meaning
Visual board	Makes work visible
WIP limit	Limits work in progress to improve flow
Pull system	Work is pulled when capacity exists
Cycle time	Time from starting work to finishing it
Lead time	Time from request to delivery
Bottleneck	Constraint slowing flow

Common trap: adding more work to a clogged system usually worsens flow. Reduce WIP and address bottlenecks.

Agile estimation and tracking

Metric or practice	Meaning	Trap
Story points	Relative estimate of effort, complexity, and uncertainty	Do not compare points directly across unrelated teams
Velocity	Amount of work completed in an iteration	Useful for forecasting, not as a performance weapon
Burndown chart	Shows work remaining over time	A flat line signals little completed work
Burnup chart	Shows work completed and may show scope changes	Helps reveal expanding scope
Definition of Done	Shared quality/completion standard	“Almost done” is not done
Acceptance criteria	Conditions a story or requirement must meet	Used to confirm the right outcome

User stories

A common user story pattern is:

“As a [user], I want [capability], so that [benefit].”

Good user stories are small enough to complete, testable, valuable, and understood by the team. Acceptance criteria clarify when the story satisfies the need.

Predictive vs Agile Decision Table

Question stem says…	Best mindset
Detailed requirements approved and baselined	Predictive control
Regulatory phase gate or contractual milestone	Predictive or hybrid governance
Customer wants frequent demos and evolving scope	Agile/adaptive
Team is delivering usable pieces every few weeks	Agile/incremental
Sponsor asks for impact of scope change on cost/schedule	Predictive change analysis
Product owner reorders work based on value	Agile backlog management
Project has hardware build plus software iteration	Hybrid
Requirements cannot be fully known at start	Agile/iterative discovery
Late change to signed baseline	Formal change request
New feature request in backlog	Product owner prioritization

Business Analysis Reference for CAPM

BA concept	Meaning	Exam cue
Needs assessment	Understand problem/opportunity and business need	“Why is this project needed?”
Business requirements	High-level organizational needs	Strategic outcomes
Stakeholder requirements	Needs of stakeholders/user groups	Expectations and constraints
Solution requirements	Product capabilities and qualities	Functional/nonfunctional requirements
Functional requirement	What the solution does	Behavior/capability
Nonfunctional requirement	How well the solution performs	Security, performance, usability
Transition requirement	Temporary capability needed to move to future state	Data migration, training
Elicitation	Draw out information from stakeholders	Interviews, workshops, observation
Requirements analysis	Organize, model, prioritize, validate requirements	Resolve conflicts and gaps
Requirements traceability	Link requirement to source, design, test, deliverable	Impact analysis
Acceptance criteria	Conditions for accepting work	Testable completion
Product roadmap	High-level product direction	Releases/features over time
Backlog refinement	Clarify and split upcoming backlog items	Agile BA work

Notes and examples

Elicitation Technique Selection

Technique	Best for	Watch out
Interview	Deep individual insight	May be biased or incomplete
Workshop	Shared understanding and fast alignment	Needs facilitation
Survey/questionnaire	Many stakeholders	Limited depth
Observation/job shadowing	Understand actual work process	People may behave differently when observed
Document analysis	Existing rules/processes	Documents may be outdated
Prototype	Clarify uncertain requirements	Stakeholders may think prototype is finished product
Brainstorming	Generate options quickly	Needs later filtering
Focus group	Gather reactions from selected users	Not statistically broad

Requirement Prioritization

Method	Meaning
MoSCoW	Must, Should, Could, Won’t for now
Ranking	Order from highest to lowest priority
Weighted scoring	Score options against weighted criteria
Kano-style thinking	Basic needs, performance needs, delighters
Value vs effort	Prioritize high-value, feasible items
Risk-based prioritization	Do risky/uncertain work earlier

Need, requirement, and solution

Term	Meaning
Business need	Problem or opportunity that justifies action
Requirement	Condition or capability needed by a stakeholder or solution
Solution	Product, service, or result that satisfies the need
Acceptance criteria	Conditions used to determine whether a requirement is satisfied

Requirement types

Requirement type	Focus
Business requirements	High-level organizational needs
Stakeholder requirements	Needs of a stakeholder group
Solution requirements	Functional and nonfunctional capabilities
Functional requirements	What the solution must do
Nonfunctional requirements	Quality attributes such as performance, security, usability
Transition requirements	Temporary capabilities needed to move from current to future state

Elicitation techniques

Technique	Best use
Interviews	Deep individual insight
Workshops	Shared understanding and alignment
Observation	Discover actual work practices
Surveys	Broad input from many people
Document analysis	Understand existing rules, processes, and systems
Prototypes	Clarify uncertain or visual requirements

Verification vs validation

Concept	Question to ask
Verification	Is the requirement or deliverable built correctly according to specification?
Validation	Does it meet the business need and stakeholder expectations?

Common trap: a requirement can be documented clearly and still fail to solve the real business problem.

Change Control Decision Reference

Scenario	What should happen next?	Why
Stakeholder requests scope addition in predictive project	Document change request and analyze impact	Baselines require control
Team member starts extra unapproved feature	Stop gold plating; evaluate through change control/backlog	Prevent uncontrolled scope
Defect found in deliverable	Log, analyze, correct according to quality/change process	Defect repair may need approval
Approved change affects schedule baseline	Update impacted baselines and plans	Keep plans integrated
Emergency change needed	Follow approved emergency change procedure if defined	Control still applies
Change request rejected	Communicate decision and update change log	Maintain transparency
Agile stakeholder requests new feature	Product owner evaluates and orders backlog	Backlog is the change mechanism
Change exceeds PM authority	Escalate to change control board/sponsor as appropriate	Authority matters

Notes and examples

Integrated Change Control Flow

    flowchart TD
	    A[Change idea or variance] --> B[Document change request]
	    B --> C[Analyze impact on scope, schedule, cost, quality, risk, resources, stakeholders]
	    C --> D{Within PM authority?}
	    D -- Yes --> E[Approve, defer, or reject per governance]
	    D -- No --> F[Submit to CCB/sponsor/authorized body]
	    E --> G[Update change log]
	    F --> G
	    G --> H{Approved?}
	    H -- Yes --> I[Update plans, baselines, documents, communicate]
	    H -- No --> J[Communicate decision, keep current baseline]

“What Should the Project Manager Do Next?”

Exam situation	Usually do next	Avoid
Project lacks formal approval	Obtain/confirm charter authorization	Begin full execution
Stakeholder is newly identified	Add to stakeholder register and analyze	Ignore until next phase
Team reports a risk may occur	Record/analyze in risk register	Treat as issue before it happens
Risk event occurs	Implement response; update issue log/risk documents	Re-plan everything immediately
Customer requests scope change	Submit/evaluate change request	Add work informally
Work performance differs from baseline	Analyze variance and forecast	Jump straight to corrective action
Corrective action affects baseline	Process change request	Update baseline without approval
Team conflict emerges	Address collaboratively and early	Escalate first unless severe
Stakeholder is resistant	Analyze concerns and adjust engagement	Remove stakeholder from communication
Vendor misses deliverable	Review contract and manage procurement	Personally redo seller work without process
Agile team has impediment	Scrum master/team removes or escalates impediment	Blame individual team members
Agile product priorities change	Product owner reorders backlog	PM unilaterally changes sprint scope
Deliverable completed	Verify/control quality, then seek acceptance as applicable	Close project immediately
Project is ending	Confirm acceptance, close procurements, archive, lessons learned	Skip final administrative closure

Ethics and Professional Conduct Cues

Theme	Exam behavior
Responsibility	Own decisions, follow policies, report truthfully
Respect	Treat stakeholders fairly and professionally
Fairness	Avoid favoritism, discrimination, and improper advantage
Honesty	Provide accurate information; do not misrepresent status
Conflict of interest	Disclose and follow appropriate guidance
Confidentiality	Protect sensitive information
Gifts or favors	Avoid anything that could impair objectivity or appear improper
Bad news	Report accurately and promptly; do not hide problems
Pressure to falsify	Refuse and escalate through proper channels

Common CAPM Traps

Trap	Correct exam thinking
“The PM should just approve it”	Check authority, governance, and change process
“Agile means no documentation”	Agile uses right-sized documentation
“Customer asked, so team should do it”	Customer input still needs prioritization/control
“Under budget always good”	Could indicate incomplete scope or quality issues
“Fast tracking is free”	It increases risk and potential rework
“Crashing always works”	Only useful where added resources shorten critical-path work
“Risk response after event is risk management”	Once it occurs, it is issue management using planned responses
“High power stakeholder can be ignored if uninterested”	Manage closely or keep satisfied depending analysis
“Velocity is a productivity ranking”	It is for team planning, not cross-team comparison
“Lessons learned happen only at the end”	Capture throughout and archive at closure
“Quality is inspected in at the end”	Quality should be planned and built in
“Scope baseline equals requirements list”	Scope baseline includes scope statement, WBS, WBS dictionary

Notes and examples

Trap 1: Memorizing terms without context

Many wrong answers use correct vocabulary in the wrong situation. Practice identifying the project phase, lifecycle, artifact, and decision point before choosing.

Trap 2: Skipping change control

If an approved baseline may change, use formal change control. Do not implement just because the sponsor, customer, or senior stakeholder requested it.

Trap 3: Confusing risks and issues

A risk may happen. An issue has happened. Risk responses are planned proactively; issue management is immediate and corrective.

Trap 4: Treating agile as unplanned work

Agile uses planning, prioritization, quality standards, reviews, and retrospectives. It is adaptive, not chaotic.

Trap 5: Choosing escalation too quickly

Escalation can be correct, but only when the matter exceeds the project manager’s authority or reasonable project-level action has failed.

Trap 6: Ignoring stakeholders

Stakeholder resistance usually calls for analysis, engagement, communication, and understanding—not avoidance.

Trap 7: Misreading “best,” “first,” and “next”

First often means identify, document, assess, or understand before acting.
Next means the immediate logical step in the process.
Best means the most professional, proactive, and process-aligned answer.
Most likely asks for diagnosis, not necessarily the ideal action.

Last-Minute Review Checklist

Know the difference between project charter, project management plan, and baselines.
Practice earned value interpretation: CV/SV/CPI/SPI and common EAC variants.
Be able to choose predictive, agile, iterative, incremental, or hybrid from scenario clues.
Memorize risk responses for threats and opportunities.
Know Scrum roles, events, artifacts, and who owns prioritization.
Understand business analysis flow: need, stakeholders, elicitation, requirements, traceability, acceptance.
For “what next” questions, first identify whether the situation is a risk, issue, change, defect, conflict, or stakeholder engagement problem.
Favor ethical, transparent, documented, and value-focused actions.
Do not skip analysis before escalation unless there is an immediate safety, legal, or authority issue.

High-yield review map

Area	Know cold	Common exam angle
Project fundamentals	Project vs operations, programs, portfolios, constraints, stakeholders, value	Identify what type of work is being described and who should act
Predictive project management	Charter, plan, baselines, WBS, schedule, budget, quality, risks, change control	Choose the next process, artifact, or control action
Agile and adaptive approaches	Scrum, Kanban, servant leadership, backlog, increments, velocity, WIP	Match adaptive practices to uncertain or changing work
Hybrid delivery	Combining predictive governance with adaptive execution	Decide which parts should be planned up front and which should evolve
Business analysis	Needs, requirements, elicitation, traceability, acceptance criteria	Separate business need, solution requirement, and acceptance validation
Formulas and metrics	EVM, PERT, communication channels, EMV, float	Interpret whether the project is ahead/behind or over/under budget
Scenario judgment	“First,” “best,” “next,” “most likely”	Avoid jumping to escalation, blame, or undocumented action

Delivery approach decision rules

Choosing the lifecycle is a frequent decision point. Focus on uncertainty, change frequency, stakeholder involvement, and ability to define requirements early.

    flowchart TD
	    A[Start with product and project uncertainty] --> B{Requirements stable and well understood?}
	    B -- Yes --> C{Technology and work approach familiar?}
	    C -- Yes --> D[Predictive approach likely fits]
	    C -- No --> E[Hybrid may fit: plan governance, adapt technical work]
	    B -- No --> F{Frequent stakeholder feedback possible?}
	    F -- Yes --> G[Adaptive or agile approach likely fits]
	    F -- No --> H[Hybrid with discovery, prototypes, and staged decisions]

Notes and examples

Approach	Best fit	Weak fit	Key artifacts or practices
Predictive	Stable requirements, regulated sequence, clear scope	High uncertainty and frequent change	Charter, baselines, WBS, detailed plan, formal change control
Iterative	Need repeated refinement of solution	Work that must be fully defined once and delivered once	Prototypes, feedback cycles, evolving solution
Incremental	Need usable pieces delivered over time	Product cannot provide value until everything is complete	Increments, release planning, staged delivery
Adaptive/agile	Requirements change, discovery needed, high stakeholder involvement	Low collaboration or fixed detailed scope with no flexibility	Backlog, sprint/iteration, daily coordination, review, retrospective
Hybrid	Some elements stable, others uncertain	Organization cannot support mixed governance	Predictive milestones plus adaptive delivery cycles

Predictive project management essentials

Initiating

High-yield idea: initiating authorizes the project and identifies key stakeholders. It does not create every detailed plan.

Artifact	Purpose	Trap
Business case	Explains business need and justification	Usually created before or around project selection, not as a substitute for the project plan
Benefits management information	Describes expected benefits and how they may be measured	Benefits may continue after project closure
Project charter	Formally authorizes the project and names the project manager	A project manager should not spend heavily or direct major work before authorization
Stakeholder register	Identifies stakeholders and relevant information	It is updated as new stakeholders are discovered

Notes and examples

Planning

Planning defines how the project will be executed, monitored, controlled, and closed.

Planning item	What to remember
Project management plan	Integrated plan made of subsidiary plans and baselines
Scope baseline	Approved scope statement, WBS, and WBS dictionary
Schedule baseline	Approved schedule used to measure schedule performance
Cost baseline	Approved time-phased budget, excluding certain management-level reserves
Requirements documentation	Captures stakeholder and solution requirements
Requirements traceability matrix	Links requirements to business needs, deliverables, tests, and acceptance
Risk register	Contains identified risks, analysis, owners, and responses
Communications plan	Defines who needs what information, when, how, and from whom
Stakeholder engagement plan	Plans how to move stakeholders toward desired engagement

Executing

Executing is where the team performs the work and the project manager facilitates delivery.

Common executing activities:

Direct and manage project work.
Manage quality.
Acquire, develop, and manage the team.
Manage communications.
Implement risk responses.
Conduct procurements.
Manage stakeholder engagement.

Exam trap: executing is not uncontrolled doing. Work should follow the approved plan, and problems should feed monitoring, controlling, or change control when needed.

Monitoring and controlling

Monitoring and controlling compares actual performance against the plan and recommends corrective action.

If the question says…	Think…
Performance differs from baseline	Analyze variance and determine corrective or preventive action
Deliverable needs formal acceptance	Validate scope
Work results need inspection	Control quality
A requested change affects baseline	Submit and evaluate through change control
Risk trigger occurs	Implement risk response or handle as issue
Stakeholder engagement differs from plan	Adjust engagement and communication actions

Closing

Closing confirms completion, acceptance, transition, records, lessons learned, and release of resources.

Common trap: closing is not only administrative. It includes formal acceptance, final reporting, procurement closure where applicable, archiving records, and capturing lessons learned.

Hybrid project management

Hybrid questions test tailoring. A project can use predictive planning for governance, funding, compliance, or major milestones while using agile delivery for uncertain product features.

Situation	Likely approach
Fixed regulatory deadline, uncertain product design	Hybrid
Stable construction sequence with defined plans	Predictive
New digital product with evolving customer feedback	Adaptive
Hardware component fixed, software features evolving	Hybrid
Research or discovery work with unknown solution	Iterative or adaptive

Common trap: do not force every project into agile. The best approach depends on uncertainty, risk, stakeholder availability, and organizational needs.

Formula quick sheet

PERT expected duration

\[ \text{Expected duration} = \frac{O + 4M + P}{6} \]

Where:

\(O\) = optimistic estimate
\(M\) = most likely estimate
\(P\) = pessimistic estimate

Communication channels

\[ \text{Channels} = \frac{n(n-1)}{2} \]

Earned value interpretation

If…	Meaning
CV is positive	Under budget
CV is negative	Over budget
SV is positive	Ahead of schedule
SV is negative	Behind schedule
CPI greater than 1	Cost efficiency is favorable
CPI less than 1	Cost efficiency is unfavorable
SPI greater than 1	Schedule efficiency is favorable
SPI less than 1	Schedule efficiency is unfavorable

Scenario-answering checklist

Use this quick mental sequence on practice questions:

Identify the lifecycle. Predictive, agile, or hybrid?
Find the moment. Initiating, planning, executing, monitoring/controlling, or closing?
Name the issue. Scope, schedule, cost, quality, risk, resources, communications, procurement, stakeholder, or business analysis?
Look for the artifact. Charter, plan, baseline, backlog, risk register, stakeholder register, requirements traceability matrix, etc.
Apply the rule. Change control, stakeholder engagement, risk response, team facilitation, or value delivery?
Eliminate weak answers. Ignore, blame, act without approval, gold-plate, over-escalate, or skip analysis.
Choose the most professional next step.

Practice focus before exam day

Use this Cheat Sheet as a checklist, then move into PM Mastery practice:

Practice activity	Goal
Topic drills	Isolate weak areas such as EVM, agile roles, risk responses, or requirements
Original practice questions	Build recognition of realistic scenario patterns
Mock exams	Practice timing, stamina, and mixed-topic decision-making
Detailed explanations	Learn why the best answer is best and why distractors are wrong
Error log	Track repeated mistakes by concept and question wording

A strong final review cycle is: read this Cheat Sheet, complete focused topic drills, review detailed explanations, then sit for a mixed mock exam and update your error log.

Put the review into practice

PM Mastery

Start Cheat Sheet practice on Web

Tip: Use the web app to preview question style, then practise the topics you need to revisit.

Use the web app for Cheat Sheet scenario practice, topic drills, timed mock exams, detailed explanations, and saved progress. Original PM Mastery practice only; not official questions, copied live-exam content, or exam dumps.

Current alignment Mapped to the current exam content outline, domains, tasks, learning outcomes, or syllabus areas for this exam.

Practice modes Use topic drills, timed mocks, scenario practice, and focused pages before deeper mixed practice.

Teaching explanations Explanations teach the project, agile, governance, or delivery rule that makes the best option stronger.

Stable bank Questions are prebuilt and reviewed before publication, so practice is stable and inspectable, not improvised during a quiz.

Study Plan