Project+ — CompTIA Project+ (PK0-005) Exam Blueprint
Practical exam blueprint for CompTIA Project+ (PK0-005) candidates reviewing project management concepts, artifacts, scenarios, and final readiness.
How to Use This Exam Blueprint
Use this page as an independent readiness checklist for the CompTIA Project+ (PK0-005) exam, official exam code Project+. It is organized as a practical study map: what to review, what you should be able to do, and where candidates often lose points.
Do not use this as a substitute for the current CompTIA exam objectives. Use it to turn those objectives into actions:
- Mark each area Ready, Needs practice, or Unclear.
- For every weak area, write one example scenario and the correct next action.
- Practice choosing the best first step, the right artifact to update, and the right stakeholder to involve.
- Review calculations only until you can interpret the result, not just compute it.
| Readiness level | What it means | What to do next |
|---|---|---|
| Ready | You can explain the concept, apply it in a scenario, and choose the correct artifact or action. | Maintain with mixed practice. |
| Needs practice | You recognize the term but hesitate in scenario questions. | Drill scenario prompts and compare similar concepts. |
| Unclear | You cannot define it or do not know when to use it. | Relearn from source material, then practice immediately. |
Topic-Area Readiness Map
This checklist uses practical readiness areas, not official weighting claims.
| Readiness area | What to review | What “ready” looks like | Quick self-check |
|---|---|---|---|
| Project fundamentals | Project vs operations, programs, portfolios, constraints, objectives, deliverables | You can identify what makes work a project and what success criteria apply. | Can you explain why a temporary initiative with a defined outcome is a project? |
| Roles and governance | Sponsor, project manager, team, stakeholders, product owner, steering group, functional manager, vendors | You know who approves, who performs, who is consulted, and who escalates. | Can you decide whether to go to the sponsor, team lead, vendor, or change board? |
| Delivery approaches | Predictive, agile, hybrid, iterative, incremental | You can match approach to uncertainty, change rate, compliance, and delivery needs. | Can you explain why a stable-scope infrastructure rollout may differ from a changing software product? |
| Initiating work | Business need, project selection, charter, high-level scope, assumptions, constraints | You know what should be clarified before detailed planning begins. | Can you tell when a charter or sponsor approval is missing? |
| Planning | Scope, schedule, budget, resources, risk, quality, procurement, communications | You can identify the plan or baseline affected by a scenario. | Can you name the artifact to update after a scope, schedule, or risk change? |
| Scope management | Requirements, acceptance criteria, WBS, deliverables, scope baseline, scope creep | You distinguish product scope, project scope, and uncontrolled changes. | Can you respond correctly to “just add this small feature”? |
| Schedule management | Activities, dependencies, milestones, critical path, float, schedule compression | You can read basic schedule data and identify schedule risk. | Can you identify which delayed task affects the finish date? |
| Cost and budget | Estimates, budget baseline, actual cost, variance, reserves, procurement costs | You can interpret overrun, underrun, and forecast concerns. | Can you explain whether a project is over budget from EV data? |
| Risk and issues | Risk identification, probability, impact, response, owner, issue escalation | You know the difference between a possible future event and a current problem. | Can you decide when a risk becomes an issue? |
| Change control | Change request, impact analysis, approval, baselines, configuration control | You can prevent unauthorized scope, schedule, or cost changes. | Can you describe what happens before a baseline is changed? |
| Quality | Quality planning, assurance, control, testing, acceptance, defects | You can connect quality activities to requirements and acceptance criteria. | Can you distinguish preventing defects from finding defects? |
| Stakeholders and communication | Stakeholder analysis, communication methods, frequency, escalation, conflict | You can select the right message, channel, and audience. | Can you choose interactive, push, or pull communication for a scenario? |
| Team and resources | Resource allocation, responsibility matrix, team dynamics, conflict resolution | You can resolve common team problems professionally. | Can you identify when to coach, negotiate, or escalate? |
| Tools and documentation | Status reports, dashboards, risk register, issue log, RAID log, Gantt, Kanban, backlog | You know which tool supports which decision. | Can you choose between a risk register, issue log, change log, and status report? |
| Execution and monitoring | Work performance, variance, corrective action, reporting, stakeholder engagement | You can determine whether to act, escalate, replan, or document. | Can you answer “what should the project manager do next?” |
| Closing and transition | Acceptance, handoff, lessons learned, archive, release resources, close procurements | You know what must be completed before the project is closed. | Can you distinguish administrative closure from product acceptance? |
Project Foundations and Governance
Core concepts to know
- Explain the difference between a project, operation, program, and portfolio.
- Identify project characteristics: temporary work, defined objective, planned deliverables, constraints, stakeholders.
- Distinguish business need, project objective, deliverable, requirement, and acceptance criterion.
- Recognize common constraints: scope, schedule, cost, quality, resources, risk, compliance.
- Identify assumptions, dependencies, exclusions, constraints, and success criteria.
- Understand why governance matters: approvals, escalation paths, decision rights, reporting, and control.
Role readiness
| Role or group | Typical responsibility | Scenario clue |
|---|---|---|
| Sponsor | Authorizes the project, provides funding or authority, resolves major escalations | “Funding approval,” “strategic priority,” “cannot resolve at team level” |
| Project manager | Coordinates planning, execution, communication, risk, change, and delivery | “What should the PM do next?” |
| Project team | Performs the work and provides estimates, status, and technical input | “Task owner,” “developer,” “engineer,” “analyst” |
| Functional manager | Provides people or departmental resources | “Shared resource,” “resource conflict,” “department priority” |
| Stakeholder | Affected by or able to affect the project | “User group,” “customer,” “operations,” “legal,” “security” |
| Product owner or product representative | Prioritizes product value and backlog in agile-style work | “Feature priority,” “backlog,” “user value” |
| Vendor or supplier | Provides external goods or services | “Contract,” “SOW,” “late shipment,” “third party” |
| Steering committee or governance body | Provides oversight and major decisions | “Executive review,” “go/no-go,” “approval gate” |
Can you do this?
- Given a scenario, identify who owns the decision.
- Decide when the project manager can act directly and when approval is needed.
- Recognize when a problem is a governance issue, not just a task issue.
- Identify what should be documented before work begins.
- Explain why undocumented assumptions create risk.
Delivery Approach and Lifecycle Readiness
Predictive, agile, and hybrid comparison
| Approach | Best-fit cues | Common artifacts or practices | Exam-style decision point |
|---|---|---|---|
| Predictive | Stable requirements, defined scope, formal approvals, sequential phases | Charter, WBS, baselines, Gantt chart, formal change control | If scope is baselined, changes should go through impact analysis and approval. |
| Agile | Evolving requirements, frequent feedback, incremental value delivery | Backlog, iterations, demos, retrospectives, velocity or burndown-style tracking | If a stakeholder wants a new feature, prioritize it in the backlog rather than bypassing the process. |
| Hybrid | Formal governance with iterative delivery inside phases | Phase gates plus backlog or incremental delivery | Use formal controls where needed and adaptive planning where uncertainty is high. |
Lifecycle checkpoints
| Phase or stage | Readiness focus | Can you answer this? |
|---|---|---|
| Initiation | Business need, sponsor, charter, high-level feasibility, stakeholders | Is the project authorized and worth planning? |
| Planning | Scope, schedule, budget, quality, communication, risk, procurement | What is the baseline and how will work be controlled? |
| Execution | Directing work, acquiring resources, stakeholder engagement, deliverables | Is the team producing approved deliverables? |
| Monitoring and controlling | Compare actuals to plan, manage change, risks, issues, and quality | What variance exists and what action is appropriate? |
| Closing | Acceptance, transition, documentation, lessons learned, release resources | Has the project been formally completed and handed off? |
Delivery approach traps
- Do not treat agile as “no planning.” Agile still requires prioritization, visibility, and stakeholder alignment.
- Do not treat predictive as “never changes.” It changes through controlled approval.
- Do not bypass governance because a request is small.
- Do not choose an approach based only on personal preference; match it to risk, uncertainty, regulation, and stakeholder needs.
Initiation and Planning Artifact Checklist
| Artifact | Purpose | Scenario clue | Ready if you can… |
|---|---|---|---|
| Business case | Explains why the project is justified | “Return,” “benefit,” “strategic need,” “problem to solve” | Identify whether the project has a valid reason to exist. |
| Project charter | Authorizes the project and project manager | “Formal start,” “approval to begin,” “authority” | Recognize when work should not proceed without authorization. |
| Stakeholder register | Lists stakeholders and relevant attributes | “New affected group,” “influence,” “interest” | Update it when stakeholders are discovered or change. |
| Requirements documentation | Captures what the solution must do | “User needs,” “functional requirement,” “constraint” | Separate requirement from design preference. |
| Scope statement | Defines included and excluded work | “In scope,” “out of scope,” “deliverables” | Identify scope creep and exclusions. |
| WBS | Breaks deliverables into manageable work | “Decomposition,” “work packages” | Use it to organize scope, not to sequence activities. |
| Schedule | Shows timing, dependencies, milestones | “Start date,” “finish date,” “dependency” | Identify the impact of a delay. |
| Budget | Approved cost baseline or spending plan | “Cost overrun,” “funding limit” | Compare planned and actual cost. |
| Risk register | Tracks uncertain events, impacts, responses, owners | “May happen,” “probability,” “mitigation” | Add new risks and update response status. |
| Issue log | Tracks current problems requiring action | “Has happened,” “blocking,” “defect found” | Convert realized risks into issues when appropriate. |
| Change log | Tracks requested, approved, rejected, or deferred changes | “New request,” “baseline impact” | Follow change control instead of making undocumented changes. |
| Communication plan | Defines audience, method, frequency, message type | “Who needs to know?” “How often?” | Choose the correct communication channel. |
| RACI or responsibility matrix | Clarifies who is responsible, accountable, consulted, informed | “Confusion over ownership” | Assign clear responsibility and avoid duplicate accountability. |
| Quality plan | Defines standards, metrics, reviews, testing, acceptance | “Defect,” “inspection,” “acceptance criteria” | Connect quality work to requirements. |
| Procurement documents | Define vendor work, terms, selection, and performance | “Supplier,” “contract,” “SOW” | Know when vendor performance is a procurement issue. |
| Lessons learned register | Captures useful knowledge during or after the project | “What can future projects learn?” | Update throughout, not only at the end. |
Scope, Schedule, and Cost Readiness
Scope checklist
- Distinguish product scope from project scope.
- Define deliverables in measurable terms.
- Identify acceptance criteria for each major deliverable.
- Recognize scope creep when work is added without approval.
- Use the WBS to decompose deliverables, not to replace the schedule.
- Trace requirements to deliverables and tests where appropriate.
- Know when a change request is required.
Schedule checklist
- Identify activities, milestones, dependencies, leads, lags, and constraints.
- Interpret basic dependency types such as finish-to-start and start-to-start.
- Determine the critical path from a simple network.
- Understand that a delay on the critical path can delay the project finish.
- Calculate or interpret float when schedule data is provided.
- Recognize schedule compression options and their tradeoffs.
| Schedule concept | What it means | Common trap |
|---|---|---|
| Milestone | Significant point or event with no duration | Treating it like a work package |
| Critical path | Longest path through the schedule network | Assuming it is always the path with the most tasks |
| Float/slack | Time an activity can slip without affecting a defined date | Thinking all non-critical tasks have unlimited flexibility |
| Fast tracking | Performing work in parallel that was planned sequentially | Increases rework and coordination risk |
| Crashing | Adding resources to shorten duration | Usually increases cost and may not help every task |
Cost and earned-value readiness
You do not need to turn every project question into a calculation. But when numbers are supplied, be ready to compute and interpret basic performance indicators.
\[ \begin{aligned} CV &= EV - AC \\ SV &= EV - PV \\ CPI &= EV / AC \\ SPI &= EV / PV \end{aligned} \]| Measure | Plain meaning | If result is unfavorable |
|---|---|---|
| Cost variance, CV | Whether earned value is above or below actual cost | Investigate cost overrun and corrective action. |
| Schedule variance, SV | Whether earned value is ahead of or behind planned value | Investigate delayed or underperformed work. |
| Cost performance index, CPI | Cost efficiency ratio | Less than 1 usually signals cost inefficiency. |
| Schedule performance index, SPI | Schedule efficiency ratio | Less than 1 usually signals schedule inefficiency. |
Cost checklist
- Distinguish estimate, budget, baseline, actual cost, and forecast.
- Identify whether a variance is cost-related, schedule-related, or both.
- Understand reserves at a high level: known risks versus unknowns.
- Recognize procurement cost implications, including vendor delays and contract changes.
- Choose corrective action before escalating, unless authority or risk requires escalation.
- Explain why adding people late may increase cost and coordination overhead.
Risk, Issue, Change, and Quality Readiness
Risk versus issue decision checks
| Situation | Treat it as | First action | Artifact to update |
|---|---|---|---|
| A supplier may miss a future delivery date | Risk | Assess probability, impact, response, owner | Risk register |
| The supplier has missed the delivery date | Issue | Assign action, assess impact, communicate | Issue log |
| A stakeholder requests additional scope | Change request | Analyze impact on scope, schedule, cost, risk, quality | Change log and affected plans |
| A defect is found during testing | Quality issue or defect | Triage against acceptance criteria and severity | Issue log or defect tracker |
| A known risk occurs | Issue | Execute response or contingency, update status | Issue log and risk register |
| A new regulation affects deliverables | Risk, issue, or change depending on timing | Assess impact and authority required | Risk register, issue log, change log |
Risk response readiness
| Response type | Use when | Example cue |
|---|---|---|
| Avoid | Change the plan to eliminate the threat | Remove a risky feature or approach. |
| Mitigate | Reduce probability or impact | Add review, prototype, training, or redundancy. |
| Transfer | Shift ownership or financial impact | Insurance, warranty, outsourced specialist. |
| Accept | Take no immediate preventive action beyond monitoring | Low-impact risk or cost of response is too high. |
| Escalate | Risk is outside the project manager’s authority | Strategic, legal, funding, or governance-level exposure. |
Change control checklist
- Confirm whether the request affects a baseline.
- Analyze impact before approving or rejecting.
- Include scope, schedule, cost, quality, risk, resources, and stakeholder impact.
- Follow the defined approval path.
- Communicate the decision to affected stakeholders.
- Update affected documents after approval.
- Do not implement unapproved changes just because the requester is influential.
Quality checklist
- Distinguish quality assurance from quality control.
- Connect tests and inspections to requirements and acceptance criteria.
- Recognize prevention versus detection activities.
- Identify when root cause analysis is appropriate.
- Understand the role of user acceptance or customer validation.
- Track defects through resolution and verification.
- Avoid accepting deliverables that do not meet agreed criteria without formal approval.
Stakeholders, Communication, and Team Readiness
Stakeholder checklist
- Identify stakeholders early and update the list as the project changes.
- Assess interest, influence, expectations, and communication needs.
- Recognize hidden stakeholders, such as operations, security, compliance, support, or end users.
- Tailor communication by audience.
- Manage expectations when constraints conflict.
- Escalate only when the issue exceeds the project manager’s authority or cannot be resolved at the project level.
Communication method checks
| Communication need | Better method | Why |
|---|---|---|
| Resolve conflict or negotiate priorities | Interactive meeting or conversation | Immediate feedback is needed. |
| Send routine status to many stakeholders | Push communication such as email or report | Efficient distribution. |
| Store project documents for reference | Pull communication such as repository or dashboard | Stakeholders access when needed. |
| Communicate urgent risk or blocker | Direct interactive communication, then document | Speed and clarity matter. |
| Provide executive summary | Brief dashboard or status report | Focuses on decisions, risks, and exceptions. |
Communication channel count may appear in basic planning questions:
\[ \text{Communication channels} = \frac{n(n-1)}{2} \]Where \(n\) is the number of people in the communication group.
Team and conflict checklist
- Identify role ambiguity and fix it with a responsibility matrix or direct clarification.
- Recognize resource contention and coordinate with functional managers or sponsors as needed.
- Address performance issues directly and professionally before unnecessary escalation.
- Use collaboration/problem-solving when the relationship and outcome both matter.
- Know when compromise, smoothing, forcing, or withdrawal is less appropriate.
- Support team formation, onboarding, knowledge sharing, and clear working agreements.
- Recognize cultural, geographic, and time-zone communication impacts.
Tools, Documentation, and Reporting
Tool and artifact recognition
| Tool or document | Best use | Not best for |
|---|---|---|
| Gantt chart | Showing schedule, task timing, dependencies, progress | Detailed risk ownership |
| Network diagram | Understanding dependencies and critical path | Communicating executive status |
| Kanban board | Visualizing work in progress and flow | Formal cost baseline |
| Backlog | Prioritized agile-style work items | Final acceptance record by itself |
| Burndown or burnup chart | Showing progress across iterations or scope | Explaining contract terms |
| Dashboard | High-level project health and trends | Replacing detailed logs |
| Status report | Periodic communication of progress, risks, issues, decisions | Storing every project artifact |
| RAID log | Combined risks, assumptions/actions, issues, dependencies/decisions | Replacing formal change control |
| Risk register | Risk tracking and response planning | Tracking current defects only |
| Issue log | Active problem tracking | Managing possible future threats only |
| Change log | Tracking change requests and decisions | Approving changes without analysis |
| Requirements traceability matrix | Linking requirements to deliverables and tests | Scheduling resources |
Reporting readiness
- Interpret red/yellow/green status without ignoring supporting details.
- Identify when a dashboard hides a serious exception.
- Connect status updates to scope, schedule, cost, risk, quality, and stakeholder impact.
- Distinguish work performance data from analyzed information and formal reports.
- Include decisions needed, not just activity completed.
- Keep reports accurate, timely, and appropriate for the audience.
IT, Compliance, and Operational Context
CompTIA Project+ candidates often see project management concepts in technology-oriented scenarios. Be ready to apply project judgment without turning the question into a deep technical exam.
| Context | What to watch for | Project management action |
|---|---|---|
| Security or privacy requirement | Sensitive data, access control, audit concern | Involve appropriate stakeholders and document requirements. |
| Regulatory or compliance constraint | Required approval, documentation, retention, validation | Treat as constraint and governance requirement. |
| Production deployment | Cutover, rollback, outage window, communication | Plan transition, risks, approvals, and stakeholder notices. |
| Data migration | Mapping, validation, backups, data quality | Include testing, acceptance, and contingency planning. |
| Vendor implementation | Contract scope, deliverables, acceptance, delays | Manage through procurement documents and issue/change control. |
| Operations handoff | Support team readiness, documentation, training | Include transition criteria before closure. |
| Change advisory or release governance | Production impact or enterprise change process | Follow required approval and scheduling process. |
| Business continuity concern | Outage, recovery, critical service dependency | Add risk response and escalation if impact is high. |
IT project scenario checks
- If a deployment fails, can you identify rollback, communication, issue logging, and impact assessment steps?
- If security identifies a gap late, can you determine whether it is a risk, issue, defect, or change?
- If operations refuses handoff, can you check acceptance, documentation, training, and support readiness?
- If a vendor says work is out of scope, can you review the contract or statement of work before approving extra cost?
- If users reject the system, can you connect the problem to requirements, acceptance criteria, training, or stakeholder engagement?
Scenario Judgment Checks
Use these prompts to practice “best next action” questions.
| Scenario cue | Strong response | Weak response to avoid |
|---|---|---|
| A stakeholder asks for additional work after the scope baseline is approved. | Document the request, analyze impact, follow change control. | Add it because it is small. |
| A key risk has occurred. | Treat it as an issue, execute the planned response if applicable, update records. | Leave it only in the risk register. |
| A team member reports a task will be late. | Assess schedule impact, especially critical path and dependencies, then plan corrective action. | Immediately escalate without analysis. |
| A sponsor demands an earlier finish date. | Evaluate options such as fast tracking or crashing, including cost and risk. | Promise the date without a revised plan. |
| A vendor misses a deliverable. | Review contract/SOW, log the issue, assess impact, communicate through proper channels. | Replace the vendor without reviewing obligations. |
| Stakeholders disagree on priority. | Facilitate decision-making using objectives, value, constraints, and authority. | Let the loudest stakeholder decide informally. |
| A requirement is ambiguous. | Clarify with stakeholders and update documentation. | Let the team interpret it independently. |
| A defect appears during acceptance testing. | Compare to acceptance criteria, log it, triage severity, determine fix or formal acceptance decision. | Close the project because testing is mostly complete. |
| A new stakeholder appears late. | Update stakeholder information and communication plan; assess impact. | Ignore them because planning is done. |
| Agile team receives new feature request mid-iteration. | Evaluate priority through backlog/product ownership process. | Interrupt current work automatically. |
| Budget variance is unfavorable. | Determine cause, forecast impact, recommend corrective action. | Report only that the project is “over budget.” |
| Resource conflict occurs with another department. | Negotiate with functional manager; escalate if unresolved or authority is insufficient. | Reassign people without approval. |
“Can You Do This?” Core Skills Checklist
Foundations and roles
- Define project, program, portfolio, operation, deliverable, milestone, and baseline.
- Identify the sponsor, project manager, customer, end user, team, vendor, and governance body in a scenario.
- Determine who should approve funding, scope changes, acceptance, or closure.
- Recognize missing authorization or unclear authority.
Planning and baselines
- Build a logical sequence from charter to planning artifacts.
- Identify the correct artifact for scope, schedule, cost, quality, risk, communication, or procurement concerns.
- Explain how baselines are used for comparison and control.
- Identify assumptions and constraints that should be documented.
- Recognize when stakeholder engagement changes the plan.
Execution and monitoring
- Interpret status information and determine whether corrective action is needed.
- Choose between updating a log, submitting a change request, escalating, or communicating status.
- Distinguish corrective action, preventive action, and defect repair at a practical level.
- Track work performance against scope, schedule, cost, risk, and quality expectations.
- Keep stakeholders informed without over-communicating unnecessary detail.
Agile and hybrid judgment
- Explain backlog, iteration, increment, daily coordination, review, and retrospective at a high level.
- Identify who prioritizes product work in agile-style scenarios.
- Recognize that agile changes are still controlled through prioritization and transparency.
- Match hybrid methods to projects that need both governance and flexibility.
- Avoid applying predictive change control rigidly to every agile backlog adjustment.
Calculations and charts
- Identify the critical path from a simple activity network.
- Calculate or interpret float when early/late dates are provided.
- Interpret CV, SV, CPI, and SPI from given values.
- Use the communication channel formula when a team size changes.
- Read a Gantt chart, Kanban board, dashboard, burndown-style chart, or status report for decision-making.
Closing and transition
- Confirm deliverable acceptance before administrative closure.
- Ensure documentation, training, support handoff, and operational readiness are complete where relevant.
- Close vendor/procurement items when applicable.
- Release resources according to the plan.
- Archive records and capture lessons learned.
Common Weak Areas and Traps
| Trap | Why it hurts | Better habit |
|---|---|---|
| Confusing risk and issue | Risk is uncertain; issue is happening now. | Ask: “Has it occurred yet?” |
| Updating the wrong artifact | Many questions test documentation judgment. | Identify whether the scenario is about risk, issue, change, scope, or communication. |
| Skipping impact analysis | Change questions often require analysis before approval. | Assess scope, schedule, cost, quality, risk, resources, and stakeholder impact. |
| Escalating too quickly | The PM is expected to analyze and attempt appropriate action first. | Escalate when authority, governance, or unresolved conflict requires it. |
| Escalating too late | Some decisions exceed PM authority. | Escalate strategic, legal, funding, or major baseline conflicts. |
| Treating agile as informal | Agile still has roles, prioritization, reviews, and visibility. | Use backlog, product ownership, and iteration feedback. |
| Treating all delays equally | Only some delays affect the finish date. | Check dependencies, float, and critical path. |
| Memorizing formulas without interpretation | Questions may ask what the result means. | Translate variance or ratio into project health. |
| Ignoring stakeholder impact | Project decisions affect expectations and adoption. | Update stakeholder and communication plans when conditions change. |
| Closing too early | Closure requires acceptance, transition, documentation, and administrative wrap-up. | Verify acceptance and handoff before closing. |
| Confusing QA and QC | Prevention and process improvement differ from inspection/testing. | Ask whether the activity prevents defects or detects them. |
| Assuming the sponsor solves every problem | Sponsors handle authority and escalation, not routine management. | Let the PM manage within authority first. |
Final-Week Review Checklist
Seven-day readiness pass
- Re-read the current CompTIA Project+ exam objectives and mark each topic green, yellow, or red.
- Rebuild your artifact map from memory: charter, plan, WBS, schedule, risk register, issue log, change log, communication plan, quality plan, closure documents.
- Drill risk-versus-issue-versus-change scenarios.
- Practice schedule and cost interpretation until you can explain the result in one sentence.
- Review agile, predictive, and hybrid cues.
- Practice stakeholder and communication questions with “who needs what information, when, and by what method?”
- Review procurement, vendor, compliance, and IT handoff scenarios.
- Create a one-page error log of missed concepts and revisit it daily.
- Complete mixed practice questions rather than studying one topic at a time only.
- For every missed question, identify whether the miss was vocabulary, artifact selection, calculation, or scenario judgment.
Final 24-hour checklist
- Review formulas and what unfavorable values mean.
- Review common artifacts and their purposes.
- Review “best next action” patterns: document, analyze, communicate, control, escalate when appropriate.
- Stop adding new study sources unless a topic is truly unknown.
- Sleep and arrive prepared to read carefully.
Exam-question habits
- Notice words such as first, best, next, most likely, and except.
- Identify whether the scenario is asking about planning, execution, monitoring, change, risk, communication, or closure.
- Eliminate answers that skip documentation, approval, or impact analysis.
- Prefer actions that preserve project control and stakeholder alignment.
- Do not choose extreme escalation unless the scenario justifies it.
- When two answers seem correct, choose the one that happens earlier in the process.
Practical Next Step
Use this checklist to choose your next practice set for CompTIA Project+ (PK0-005). Start with the weakest readiness area, answer scenario-based questions, and keep an error log that records the missed concept, the correct artifact or action, and the clue you should have noticed.