CompTIA PK0-005 Cheat Sheet: Scope, Delivery, and Change Control
April 13, 2026
CompTIA PK0-005 cheat sheet for scope, delivery, change control, traps, and final review.
On this page
Use this cheat sheet for last-mile review. Project+ is usually testing whether you can protect delivery with the right phase logic, artifact choice, and approval path, not whether you can repeat generic PM slogans.
Charter: The artifact that authorizes the project and names its purpose and sponsor.
Change request: The formal request used to assess and approve scope, schedule, cost, or solution changes.
Float: The amount of time a task can slip before it affects a later milestone or the project finish.
PK0-005 answer sequence
Use this when the stem mixes project authority, planning, change control, communication, or methodology fit.
flowchart TD
S["Scenario"] --> A["Check authority and justification"]
A --> P["Check planning artifact or phase"]
P --> C["Check change, communication, or control path"]
C --> V["Verify approval, ownership, and closure"]
Fast lane picker
If the question is really about…
Focus first on…
Strongest first move
project authority or justification
discovery and initiation
confirm sponsor, business case, and charter
work definition or sequencing
planning
identify the baseline, WBS, schedule, or responsibility artifact
active delivery friction
execution and control
decide whether this is an issue, variance, or formal change
communication confusion
meetings and stakeholder control
choose the communication plan, cadence, or escalation path
technical guardrails
IT governance
protect change control, privacy, security, and environment separation
Phase and artifact map
Phase
What good control looks like
Typical outputs
discovery
strategic fit and expected value are clear
business case, vendor shortlist, funding assumptions
initiation
authority, goals, sponsor, and key stakeholders are named
charter, stakeholder list, kickoff expectations
planning
work is broken down, sequenced, costed, and governed
WBS, schedule, budget, RAM or RACI, risk register, communication plan
execution
work moves, status is visible, and blockers are owned
status reports, issue log, meeting actions, vendor follow-up
closing
acceptance, handoff, archive, and lessons learned are complete
sign-off, closure report, archived docs, release of resources
Artifact chooser
If the stem is asking…
Strongest first artifact
who authorized the work
project charter
what work is included or excluded
scope statement or approved backlog boundary
how the work is broken down
WBS
who is responsible
RAM or RACI
who needs what update and when
communication plan
what might go wrong later
risk register
what already went wrong
issue log
what needs formal approval
change request and change log
what closed the project cleanly
acceptance and closure documentation
Methodology fit
Situation
Strongest first fit
Why
scope is stable and governance is formal
predictive
planning and baseline control matter most
requirements are changing quickly
agile
short feedback loops reduce wasted work
one workstream is fixed while another is exploratory
hybrid
stable work stays controlled while uncertain work iterates
Risk, issue, and change contrasts
Pair
Keep this distinction clear
risk vs issue
uncertain future event vs current problem
issue log vs change log
active problem tracking vs requested or approved modification
charter vs project plan
project authority vs execution and control detail
preventive vs corrective action
reduce future likelihood vs fix a current problem
escalation vs routine communication
formal raise across authority boundary vs normal status update
Schedule logic
Concept
What it means
Exam hint
critical path
longest path through the schedule
determines finish date
float or slack
time a task may slip without changing a later date
a delay does not always force rebaseline
milestone
zero-duration marker
good for approvals, gates, and reporting
crashing
add resources to shorten duration
useful, but not always cheapest or safest
fast tracking
overlap tasks
shortens time but increases rework risk
Governance sequence
flowchart TD
A["Request, variance, or blocker appears"] --> B["Classify it: risk, issue, or change"]
B --> C["Assess impact on scope, schedule, cost, quality, and risk"]
C --> D{"Approval needed?"}
D -->|Yes| E["Route through the right governance path"]
D -->|No| F["Document owner and next action"]
E --> G["Update baseline, logs, and communications"]
F --> G
IT and governance cues
Scenario clue
Strongest first instinct
production change bypasses normal review
stop and use formal IT change control
privacy or compliance exposure appears
protect confidentiality, legal obligations, and data handling first
cloud or infrastructure terms show up
focus on fit, environments, and operational impact rather than vendor trivia
ESG is mentioned
connect project choices to environmental, regulatory, value, or brand impact
Common Project+ traps
implementing the change because the sponsor asked for it verbally
confusing a live outage or missed dependency with a future risk
escalating before documenting impact and owner
rebaselining too early instead of first trying corrective action
treating the tool brand as more important than the control it supports