Project+ — CompTIA Project+ (PK0-005) Exam Quick Reference

Last revised: June 18, 2026

Compact CompTIA Project+ (PK0-005) quick reference covering lifecycle, artifacts, roles, formulas, change control, risk, communications, and exam decision points.

Exam Identity and How to Use This Page

Item	Reference
Provider	CompTIA
Official exam title	CompTIA Project+ (PK0-005)
Official exam code	Project+
Page purpose	Independent quick-reference support for real-exam preparation

Use this page to review high-yield project management distinctions quickly: lifecycle flow, artifacts, roles, governance, change control, risk, stakeholder communication, schedule/cost basics, and scenario decision logic.

Project Lifecycle Quick Map

    flowchart TD
	    A[Need, opportunity, problem, or mandate] --> B[Business case / charter]
	    B --> C{Authorized?}
	    C -- No --> X[Do not execute project work]
	    C -- Yes --> D[Plan scope, schedule, cost, quality, resources, communications, risks, procurement]
	    D --> E[Execute work and manage team, vendors, and stakeholders]
	    E --> F[Monitor performance, risks, issues, changes, quality]
	    F --> G{Change requested?}
	    G -- Yes --> H[Analyze impact and submit through change control]
	    H --> I{Approved?}
	    I -- Yes --> J[Update baselines, plans, logs, and communicate]
	    I -- No --> K[Communicate decision and prevent scope creep]
	    J --> E
	    K --> E
	    G -- No --> L{Deliverables accepted?}
	    L -- No --> E
	    L -- Yes --> M[Close procurements, transition, archive, lessons learned]

Phase / Process Area	Main purpose	High-yield outputs	Exam traps
Initiation	Decide whether the project should exist and authorize it	Business case, project charter, high-level scope, sponsor approval, initial stakeholders	Starting execution before authorization; confusing business case with charter
Planning	Define how the project will be executed, monitored, and controlled	Scope baseline, WBS, schedule, budget, risk register, communication plan, procurement plan, quality plan	Treating plans as static; ignoring stakeholder and risk planning
Execution	Produce deliverables and coordinate people/resources	Work results, team assignments, vendor work, status updates, quality activities	Doing unapproved work; bypassing change control
Monitoring and controlling	Compare actual performance against plan and manage variance	Status reports, change log, issue log, updated risks, forecasts, corrective actions	Reporting variance without action; approving changes informally
Closing	Formalize acceptance and preserve knowledge	Accepted deliverables, closure report, lessons learned, archived records, transitioned product/service	Closing before acceptance; skipping contract closure or handoff

Predictive, Adaptive, and Hybrid Selection

Situation	Best-fit approach	Why
Requirements are stable, scope is well understood, approvals are formal	Predictive / waterfall	Plan-driven baselines and formal change control fit stable work
Requirements are uncertain or expected to evolve	Adaptive / agile	Iterative delivery allows feedback-driven refinement
Regulated milestones exist, but parts of the product need iteration	Hybrid	Combines formal governance with adaptive delivery
Customer wants early usable increments	Agile or hybrid	Prioritizes incremental value
Vendor contract requires fixed deliverables and acceptance criteria	Predictive or hybrid	Contract control and baseline management matter
Infrastructure migration with defined sequence and dependencies	Predictive	Schedule, cutover, risk, and dependency planning dominate
New digital product with evolving user feedback	Adaptive	Backlog, demos, and reprioritization reduce waste

Agile vs Predictive Exam Distinctions

Concept	Predictive	Agile / adaptive
Scope	Defined early; controlled through baseline	Evolved through prioritized backlog
Change	Formal change request and approval	Reprioritized by product owner/backlog governance
Planning	Up-front detailed plan, then rolling updates	Rolling-wave planning each iteration
Delivery	Usually larger release near the end or at milestones	Frequent increments
Progress measure	Schedule/cost variance, milestones, deliverable completion	Working increments, velocity, burndown/burnup
Customer involvement	Key reviews and approvals	Continuous feedback
Best exam clue	“Approved baseline,” “change control board,” “phase gate”	“Sprint,” “backlog,” “iteration,” “daily stand-up,” “retrospective”

Core Roles and Responsibilities

Role	Primary responsibility	Does / owns	Does not usually do
Sponsor	Provides authority, funding, and executive support	Charter approval, major decisions, escalation resolution, business alignment	Manage daily tasks
Project manager	Integrates work across scope, schedule, cost, quality, risk, resources, and stakeholders	Plans, status, issue/risk management, change process, communications	Unilaterally approve major baseline changes
Project team	Performs project work	Estimates, task execution, technical input, quality checks	Own business case approval
Customer / end user	Receives or uses deliverables	Requirements input, acceptance feedback, validation	Manage project governance unless assigned
Product owner	Maximizes product value in agile contexts	Backlog prioritization, acceptance of backlog items	Serve as team manager in the traditional sense
Scrum master / agile facilitator	Supports agile process and removes impediments	Facilitation, coaching, impediment removal	Prioritize product scope
Functional manager	Manages department resources	Staff assignment, skill development, resource approval	Own integrated project delivery
PMO	Standards, governance, support, reporting	Templates, methodology, portfolio reporting, audits	Always control every project decision
Change control board	Reviews significant changes	Approve/reject/defer change requests based on impact	Receive informal hallway requests as approval
Vendor / supplier	Provides contracted goods or services	Contracted deliverables, service performance	Change contract scope without authorization
Stakeholder	Person/group affected by or influencing project	Requirements, constraints, feedback, support/resistance	Always have decision authority

Artifact Selection Reference

Artifact	Use it to answer questions about	Created / refined when	Key distinction
Business case	Why the project is worth doing	Initiation	Justifies investment; not the detailed execution plan
Project charter	Formal project authorization	Initiation	Gives PM authority; high-level scope/objectives
Stakeholder register	Who matters and how they are affected	Initiation and updated throughout	Identification and analysis source
Stakeholder engagement plan	How to manage stakeholder involvement	Planning	Strategy for support, resistance, and communication
Requirements documentation	What stakeholders need	Planning, refined as needed	Basis for scope and acceptance
Requirements traceability matrix	Link requirements to deliverables, tests, and acceptance	Planning through validation	Prevents missed or orphan requirements
Scope statement	What is included/excluded	Planning	More detailed than charter scope
WBS	Decomposes deliverables into manageable work	Planning	Deliverable-oriented; not a schedule by itself
WBS dictionary	Details about WBS components	Planning	Adds descriptions, assumptions, owners, acceptance info
Schedule	When work happens	Planning and controlling	Includes activities, sequencing, duration, dependencies
Budget / cost baseline	Approved cost plan	Planning and controlling	Used to compare actual cost performance
Risk register	Uncertain events that may affect objectives	Planning and continuously updated	Risks may or may not happen
Issue log	Current problems needing action	Execution/control	Issues are happening now
Change log	Tracks requested, approved, rejected, deferred changes	Control	Records decisions and status
Communication plan	Who receives what, when, how, and from whom	Planning	Prevents under/over-communication
Resource plan	People, equipment, materials, and availability	Planning	Addresses capacity and skill needs
RACI matrix	Responsibility clarity	Planning	Maps roles to work; prevents ownership gaps
Quality management plan	Quality standards and methods	Planning	Defines how quality will be planned, assured, controlled
Procurement plan	External purchasing strategy	Planning	Covers make/buy, vendor approach, contract type
Status report	Communicates project health	Execution/control	Summarizes progress, variance, risks, issues
Lessons learned register	Captures knowledge during project	Throughout, finalized at close	Not just a closing activity
Closure report	Confirms completion and outcomes	Closing	Documents acceptance, performance, open items, handoff

Document Type Distinctions

If the scenario asks for…	Choose…	Because…
Formal authorization to begin	Project charter	Authorizes project and PM authority
Justification for investment	Business case	Explains expected value, need, or benefit
Detailed deliverable decomposition	WBS	Breaks scope into work packages
Link from requirement to test or deliverable	Traceability matrix	Tracks each requirement through validation
Who is accountable or consulted	RACI matrix	Clarifies participation by work item
How to inform stakeholders	Communication plan	Defines audience, content, channel, cadence
Current unresolved problem	Issue log	Issues are active problems
Potential future problem/opportunity	Risk register	Risks are uncertain
Formal modification to approved baseline	Change request	Initiates change control
Record of change decisions	Change log	Tracks submitted and decided changes
Acceptance of completed work	Sign-off / acceptance documentation	Confirms deliverables meet criteria
Transition to operations	Handoff plan / transition plan	Moves product/service into support

“What Should the Project Manager Do Next?” Decision Table

Scenario clue	Best next action	Avoid
Stakeholder requests new scope after baseline approval	Document a change request and perform impact analysis	Telling team to start immediately
Team member discovers a possible future problem	Add/update risk register and analyze probability/impact	Logging as an issue unless it is already occurring
Risk event has happened	Move/manage as an issue; execute response or workaround	Leaving it only in the risk register
Deliverable fails inspection	Record defect, perform root cause/corrective action, rework if needed	Accepting deliverable to protect schedule
Sponsor asks for status	Provide concise report using agreed metrics and current data	Hiding bad news or giving informal guesses
Stakeholder is resistant	Analyze interests and engagement needs; update engagement/communication approach	Ignoring resistance until approval fails
Schedule variance exceeds tolerance	Analyze cause, consider corrective action, communicate/escalate per plan	Changing baseline without approval
Team conflict affects work	Facilitate collaboration/problem solving first when practical	Immediately escalating minor interpersonal conflict
Vendor misses a deliverable	Review contract/SOW, document issue, communicate with vendor, escalate if needed	Informally accepting late work without assessing impact
Requirement is unclear	Clarify with customer/product owner and update documentation	Letting team assume intent
Project objective no longer supports business need	Escalate to sponsor/governance for decision	Continuing because work already started
Sensitive data appears in project documents	Follow security/privacy handling procedures and restrict access	Sharing broadly for convenience
Final deliverable completed	Obtain formal acceptance, close procurements, transition, archive, lessons learned	Disbanding team before closure work
An urgent production-impacting defect occurs	Follow escalation/incident path and communicate impact	Waiting for the next routine meeting

Change Control Quick Reference

Step	Purpose	Key exam point
Identify change	Capture request clearly	All changes should be documented
Log request	Track ownership and status	Use a change log, not memory
Analyze impact	Assess scope, schedule, cost, quality, risk, resources, procurement, stakeholders	Impact analysis comes before approval
Review	Sponsor/CCB/product owner/governance evaluates	Authority depends on methodology and thresholds
Decide	Approve, reject, defer, or request more info	PM usually facilitates; does not always approve
Update	Revise baselines, plans, contracts, backlog, and documents if approved	Approved changes must be integrated
Communicate	Notify affected stakeholders	Communication prevents surprise and rework
Implement and verify	Execute authorized change and validate results	Unauthorized work is scope creep

Baseline Change vs Routine Update

Work item	Formal change control usually needed?	Reason
Correcting a typo in meeting notes	No	Administrative update
Updating actual task completion percentage	No	Performance reporting
Adding a new deliverable	Yes	Scope baseline impact
Extending approved milestone date	Yes	Schedule baseline impact
Increasing approved budget	Yes	Cost baseline impact
Changing acceptance criteria	Yes	Scope/quality impact
Reprioritizing agile backlog before sprint planning	Usually handled through backlog governance	Not the same as uncontrolled scope creep
Changing sprint work mid-iteration	Depends on agile rules and severity	Product owner/team agreement is key

Scope, Schedule, Cost, and Quality

Constraint	Main question	Common control tools	Exam warning
Scope	What work and deliverables are included?	Scope statement, WBS, requirements traceability, acceptance criteria	Gold plating and scope creep are not acceptable
Schedule	When will work finish?	Network diagram, Gantt chart, critical path, milestones, burndown	Adding people late can increase coordination overhead
Cost	What will it cost and how is spending controlled?	Budget, cost baseline, EVM, forecasts	Actual cost alone does not show value earned
Quality	Does output meet requirements and fitness for use?	Quality plan, inspections, tests, control charts, audits	Quality is planned in, not inspected in only
Resources	Who/what is available?	Resource calendar, responsibility matrix, capacity planning	Overallocation creates schedule and quality risk
Risk	What uncertainty could affect objectives?	Risk register, risk responses, reserves	Risk is not automatically negative; opportunities exist
Stakeholders	Who can affect or be affected?	Register, engagement plan, communication matrix	Missing stakeholders cause late requirements and resistance

Schedule and Estimating Reference

Concept	Meaning	High-yield point
Activity	Work unit needed to produce deliverables	Derived from WBS work packages
Milestone	Significant point or event	Zero duration
Dependency	Relationship between activities	Drives sequencing
Finish-to-start	Successor starts after predecessor finishes	Most common dependency type
Start-to-start	Successor starts after predecessor starts	Allows parallel starts
Finish-to-finish	Successor finishes after predecessor finishes	Finish alignment
Start-to-finish	Successor finishes after predecessor starts	Least common
Lead	Accelerates successor	Example: start testing before all development is complete
Lag	Waiting time inserted	Example: wait for curing/approval period
Critical path	Longest path through network	Determines shortest project duration
Float / slack	Time an activity can slip without delaying target	Critical path typically has zero float
Crashing	Add resources to shorten schedule	Usually increases cost
Fast tracking	Do sequential work in parallel	Usually increases risk/rework
Rolling-wave planning	Plan near-term work in detail, future work at higher level	Useful when details emerge over time

Estimating Formulas

Three-point beta / PERT-style expected estimate:

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

Triangular estimate:

\[ \text{Triangular estimate} = \frac{O + M + P}{3} \]

Where \(O\) = optimistic, \(M\) = most likely, and \(P\) = pessimistic.

Estimating method	Use when	Notes
Analogous	Similar past project exists	Fast, less precise
Parametric	Reliable unit rate exists	Example: cost per server, hours per unit
Bottom-up	Work packages are defined	More detailed; time-consuming
Three-point	Uncertainty exists	Uses optimistic, most likely, pessimistic values
Expert judgment	Skilled SMEs are available	Useful but should be documented
Vendor bid analysis	External supplier pricing is needed	Compare assumptions, scope, and exclusions

Earned Value and Performance Formulas

Core terms:

Term	Meaning
PV	Planned value: budgeted value of scheduled work
EV	Earned value: budgeted value of completed work
AC	Actual cost: actual cost incurred
BAC	Budget at completion: total approved budget

Formula	Plain-text formula	Interpretation
Cost variance	CV = EV - AC	Positive is under budget; negative is over budget
Schedule variance	SV = EV - PV	Positive is ahead of schedule; negative is behind
Cost performance index	CPI = EV / AC	Greater than 1 is favorable; less than 1 is unfavorable
Schedule performance index	SPI = EV / PV	Greater than 1 is favorable; less than 1 is unfavorable
Estimate at completion, simple	EAC = BAC / CPI	Use when current cost performance is expected to continue
Estimate to complete	ETC = EAC - AC	Expected remaining cost
Variance at completion	VAC = BAC - EAC	Positive is favorable; negative is unfavorable

High-yield interpretation:

If…	It means…
EV is less than PV	Less work completed than planned
EV is less than AC	Work completed costs more than its planned value
CPI = 0.80	Getting 0.80 of planned value for each 1.00 spent
SPI = 1.10	Progressing faster than planned by earned-value measure
CV negative and SV negative	Over budget and behind schedule
CPI favorable but SPI unfavorable	Spending efficiently but progressing too slowly

Communication Formulas and Methods

Number of communication channels with \(n\) participants:

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

Method	Best use	Weakness / trap
Interactive communication	Complex, urgent, or ambiguous topics	Meetings can be inefficient if poorly controlled
Push communication	Send information to specific recipients	Does not guarantee understanding
Pull communication	Large audience accesses information when needed	Requires stakeholders to retrieve it
Formal written	Contracts, approvals, status reports, decisions	Slower but auditable
Informal verbal	Quick clarification, relationship building	Poor for official decisions unless documented
Synchronous	Real-time discussion	Scheduling/time-zone challenges
Asynchronous	Email, dashboards, recorded updates	Slower feedback loop

Communication need	Better choice
Resolve complex conflict	Interactive meeting / facilitated discussion
Announce approved change	Formal written notice plus stakeholder briefing if needed
Share routine metrics	Dashboard or status report
Confirm acceptance	Formal sign-off
Communicate bad news	Timely, factual, with impact and options
Reach distributed stakeholders	Mix of asynchronous updates and scheduled interactive sessions

Stakeholder Management

Activity	Purpose	Exam focus
Identify stakeholders	Find affected/influential people and groups	Do this early and revisit
Analyze stakeholders	Understand power, interest, influence, expectations	Tailor engagement
Plan engagement	Define strategies to gain support and reduce resistance	Not all stakeholders need same communication
Manage engagement	Communicate, involve, negotiate, resolve concerns	Active management, not passive reporting
Monitor engagement	Check whether strategy works	Update plan as attitudes change

Stakeholder state	Meaning	Possible PM action
Unaware	Does not know project/impact	Inform and educate
Resistant	Opposes project or change	Understand concerns, address impact, involve appropriately
Neutral	Neither supports nor opposes	Provide relevant information
Supportive	Wants project success	Maintain engagement
Leading	Actively advocates	Use as champion where appropriate

Risk, Issue, Action, and Decision Logs

Item	Definition	Example	Correct record
Risk	Uncertain future event/condition	“Key engineer may become unavailable”	Risk register
Issue	Current problem	“Key engineer resigned”	Issue log
Action item	Assigned task to resolve/follow up	“PM to identify replacement by Friday”	Action item log
Decision	Choice made by authority	“Sponsor approved two-week extension”	Decision log / meeting minutes
Assumption	Something treated as true for planning	“Vendor API will be available by July”	Assumption log
Constraint	Limitation on options	“Must complete before data center shutdown”	Constraint list / charter / plan
Dependency	Relationship that affects sequencing	“Testing depends on environment readiness”	Schedule / dependency log

Risk Response Strategies

Risk type	Strategy	Meaning
Threat	Avoid	Change plan to eliminate threat
Threat	Mitigate	Reduce probability or impact
Threat	Transfer	Shift impact ownership, often by contract/insurance/vendor
Threat	Accept	Take no proactive action beyond monitoring/reserve
Opportunity	Exploit	Ensure opportunity occurs
Opportunity	Enhance	Increase probability or impact
Opportunity	Share	Partner to capture benefit
Opportunity	Accept	Take advantage if it occurs

Risk score is commonly expressed as probability times impact:

\[ \text{Risk score} = \text{Probability} \times \text{Impact} \]

Scenario clue	Best response
High probability and high impact threat	Plan active response; escalate if outside tolerance
Low impact risk	Monitor or accept if appropriate
Risk trigger occurs	Execute planned response
No response exists and issue occurs	Develop workaround; update issue/risk records
Risk response changes scope/schedule/cost baseline	Submit change request

Quality Management Quick Reference

Concept	Meaning	Exam clue
Quality planning	Define standards and how quality will be achieved	“What quality criteria apply?”
Quality assurance	Evaluate process effectiveness	“Are we following the right process?”
Quality control	Inspect/test deliverables	“Does this deliverable meet requirements?”
Acceptance criteria	Conditions deliverable must satisfy	Used for customer validation
Definition of done	Agile team’s completion criteria	Applies consistently to backlog items
Cost of quality	Cost to prevent, detect, and fix defects	Prevention is generally better than rework
Prevention cost	Training, standards, process improvement	Avoid defects
Appraisal cost	Inspection, testing, audits	Detect defects
Internal failure cost	Rework before customer delivery	Defect found internally
External failure cost	Warranty, returns, reputation damage	Defect found by customer

Tool	Use
Cause-and-effect / fishbone diagram	Identify possible root causes
Pareto chart	Focus on vital few causes
Control chart	Determine process stability over time
Run chart	Show trends over time
Histogram	Show frequency distribution
Scatter diagram	Show relationship between variables
Check sheet	Collect defect/event counts
Flowchart	Map process steps and handoffs
Audit	Check process compliance
Inspection	Examine deliverable for defects

Procurement and Vendor Reference

Document / term	Use	Exam distinction
Make-or-buy analysis	Decide internal vs external sourcing	Considers cost, capability, risk, schedule
RFI	Request information	Learn vendor capabilities; not usually final pricing
RFQ	Request quote	Price for well-defined goods/services
RFP	Request proposal	Vendor proposes solution/approach
SOW	Statement of work	Defines work, deliverables, acceptance criteria
SLA	Service-level agreement	Defines service performance targets
MSA	Master service agreement	General contractual terms across work
NDA	Nondisclosure agreement	Protects confidential information
PO	Purchase order	Authorizes purchase under defined terms
Contract	Binding agreement	Changes require formal control
Vendor scorecard	Performance tracking	Compares delivery, quality, cost, responsiveness

Contract type	Buyer risk	Seller risk	Best for
Fixed price	Lower if scope is clear	Higher if estimates are wrong	Well-defined deliverables
Time and materials	Medium to higher without controls	Lower	Uncertain duration or flexible scope
Cost-reimbursable	Higher	Lower to medium	Uncertain work where buyer accepts cost risk
Incentive-based	Shared	Shared	Aligning vendor behavior to targets

Vendor scenario pattern:

Check the contract/SOW/SLA.
Document performance issue.
Communicate with vendor through agreed channel.
Assess project impact.
Escalate or initiate change/claim process if needed.
Update project records and stakeholders.

Resource and Team Management

Topic	Reference point
Resource calendar	Shows availability, holidays, assignments, constraints
Responsibility assignment matrix	Maps work to roles/people
RACI	Responsible, Accountable, Consulted, Informed
Training need	Address skill gaps before they affect quality/schedule
Team charter	Defines team norms, decision rules, and working agreements
Virtual team	Requires explicit communication norms and tool discipline
Matrix environment	PM may share authority with functional managers
Resource leveling	Adjust schedule to address resource constraints; may change critical path
Resource smoothing	Adjust within available float; does not usually change end date

RACI Meanings

Letter	Meaning	Rule of thumb
R	Responsible	Does the work
A	Accountable	Owns final answer/approval; ideally one per activity
C	Consulted	Two-way input before decision/action
I	Informed	One-way update after decision/action

Conflict and Leadership Responses

Conflict method	Use when	Risk
Collaborate / problem solve	Important issue, time allows, win-win desired	Takes time
Compromise	Need acceptable middle ground quickly	Everyone gives up something
Smooth / accommodate	Preserve relationship, issue is minor	Root cause may remain
Force / direct	Emergency, safety, compliance, or authority-based decision	Can damage morale
Withdraw / avoid	Cooling-off period or issue is trivial	Delays resolution

Exam pattern: choose collaboration/problem solving for important project conflicts unless the scenario clearly requires urgent direction, escalation, or compliance action.

Meetings and Status Controls

Meeting / event	Purpose	Good output
Kickoff meeting	Align team and stakeholders before execution	Shared understanding of objectives, roles, plan
Status meeting	Review progress, blockers, risks, decisions	Updated actions, issues, risks
Change control meeting	Review change requests and impacts	Approved/rejected/deferred decisions
Risk review	Reassess risks, triggers, responses	Updated risk register
Sprint planning	Select and plan iteration work	Sprint goal/backlog
Daily stand-up	Synchronize agile team	Blockers identified
Sprint review	Demonstrate increment to stakeholders	Feedback and accepted/rejected items
Retrospective	Improve team process	Improvement actions
Lessons learned session	Capture reusable knowledge	Lessons learned register update
Closure meeting	Confirm completion and transition	Acceptance, handoff, archived records

Governance and Escalation

Escalate when…	Escalate to…	Why
Decision exceeds PM authority	Sponsor/governance body	Authority and accountability
Baseline impact exceeds tolerance	CCB/sponsor	Formal change approval needed
Funding or strategic alignment is questioned	Sponsor	Business decision
Functional resource conflict cannot be resolved	Functional manager/sponsor	Shared authority issue
Vendor breach or major nonperformance occurs	Procurement/vendor manager/sponsor	Contractual handling
Compliance/security concern arises	Appropriate governance/security/compliance contact	Specialized authority
Stakeholder conflict blocks acceptance	Sponsor or steering group	Business-level resolution
Project should be paused or terminated	Sponsor/governance body	PM should not make unilateral strategic termination decision

Do first	Before escalating
Verify facts	Avoid escalating rumors
Document impact	Scope, schedule, cost, risk, quality, stakeholders
Identify options	Give decision-makers choices
Follow communication plan	Use agreed path unless emergency requires faster action
Keep records	Decisions should be auditable

IT and Operational Transition Focus

CompTIA Project+ candidates often see project scenarios tied to technology delivery, service transition, implementation, or vendor-supported work.

Transition item	Purpose
Cutover plan	Defines move from old to new system/process
Rollback plan	Defines how to return to prior state if implementation fails
Runbook	Operational procedures for support teams
Support handoff	Transfers ownership to operations/service desk
Training plan	Prepares users/admins/support staff
Release notes	Communicate changes, fixes, known issues
Maintenance window	Planned time for implementation with reduced impact
Backout criteria	Conditions that trigger rollback
Post-implementation review	Confirms outcomes and captures lessons

Scenario clue	Better response
Deployment affects users	Communicate schedule, impact, support path
High-risk implementation	Confirm rollback/backout plan
Support team not ready	Delay handoff or complete training/runbook
Stakeholders dispute readiness	Review acceptance criteria and go/no-go checklist
Incident after deployment	Follow incident/escalation process and communicate

Common Exam Traps

Trap	Correct thinking
“The customer asked, so the team should do it”	Customer requests still need prioritization or change control
“A risk happened, so update only the risk register”	Once it happens, manage it as an issue
“The PM should approve all changes”	Approval authority depends on governance and thresholds
“Status reporting solves variance”	Reporting informs; corrective action controls
“Quality control and quality assurance are the same”	QC checks deliverables; QA checks processes
“A milestone is a task with duration”	Milestone has zero duration
“WBS is a task schedule”	WBS decomposes deliverables; schedule sequences activities
“More communication is always better”	Right information, right stakeholder, right timing, right channel
“Agile means no planning”	Agile uses continuous planning and disciplined feedback loops
“Closing is just celebration”	Closing includes acceptance, handoff, records, lessons learned, procurement closure
“Negative risk is the only risk”	Risks can be threats or opportunities
“Actual cost tells whether the project is healthy”	Compare actual cost with earned value and plan

Last-Minute Review Checklist

Area	Confirm you can answer…
Lifecycle	What artifact or action belongs in initiation, planning, execution, control, or closing?
Change	What happens before approval? Who decides? What gets updated after approval?
Risk vs issue	Is the event uncertain or already happening?
Artifacts	Which document fits the scenario clue?
Roles	Sponsor vs PM vs team vs product owner vs PMO vs CCB
Schedule	Critical path, float, dependencies, lead/lag, crashing vs fast tracking
Cost	EV, PV, AC, CV, SV, CPI, SPI interpretation
Communication	Push vs pull vs interactive; formal vs informal
Stakeholders	Identify, analyze, plan, manage, monitor engagement
Quality	QA vs QC; acceptance criteria; root cause tools
Procurement	RFI/RFQ/RFP/SOW/SLA; contract type risk
Agile	Backlog, sprint, increment, review, retrospective, velocity/burndown
Closing	Acceptance, transition, procurement closure, archive, lessons learned

Practical Next Step

Use this Quick Reference as a checklist, then work through scenario-based CompTIA Project+ (PK0-005) practice questions. For every missed question, identify whether the miss was caused by artifact selection, lifecycle timing, role authority, formula interpretation, or change/risk decision logic.

Scenario Guide

Project Management Concepts