CompTIA Project+ common mistakes
CompTIA Project+ · Understand the traps and how to avoid them.
Answering scenario questions from personal workplace experience - picking the action that worked on their own project - instead of the action the exam's framework prescribes.
Experienced practitioners have seen informal shortcuts succeed in small organisations and unconsciously treat those as the 'correct' answer, even when the question describes a formal, governed environment.
What to do instead
Before answering, re-read the stem for governance cues ('according to the project charter', 'the organisation requires', 'the PMO standard'). If a cue exists, eliminate any answer that bypasses that artefact or approval, then choose among what remains. Drill 20 stems where your instinct and the framework diverge, and write down the rule that overrode your instinct.
Collapsing the sponsor, project manager, PMO and team into one role - e.g. picking the project manager as the person who approves the charter, authorises funding, or accepts the final deliverable.
In many real organisations the PM drafts the charter and chases signatures, so the drafting and approving steps blur together in memory. The exam keeps them strictly separate.
What to do instead
Build a one-page role matrix with columns for sponsor, PM, PMO, functional manager and team, and rows for: charter, funding, scope baseline approval, change approval above threshold, deliverable acceptance, templates and standards. Memorise the sponsor/PM/PMO column as 'authorise and fund = sponsor, plan and deliver = PM, standardise and report = PMO', then test it against past-style scenarios.
Treating project, program, portfolio and operations as interchangeable labels, and mislabelling a scenario that describes ongoing work or a group of related projects as a single project.
The words are used loosely in job titles and internal documents, so the distinguishing criteria (temporary vs ongoing, unique output vs repeated service, related vs strategically grouped) never get learned as a decision rule.
What to do instead
Apply a fixed decision order every time: does it end? (no = operations). Is the output unique? Is it one coordinated effort producing one output? (no, but related projects sharing a goal = program). Is it a collection prioritised against strategy and funding? (= portfolio). Say the order out loud on every practice question that uses these terms.
Jumping straight from the scope statement to the schedule, and being unable to distinguish a deliverable, a work package and an activity when a question asks where a task belongs.
Scheduling tools let people create tasks without ever building a WBS, so the decomposition hierarchy is never internalised. Questions that hinge on the level of the WBS look like trivia rather than process.
What to do instead
Memorise the chain deliverable > work package > activity, with the work package as the lowest level the PM controls and estimates at, and the activity as what gets sequenced and assigned. Practise by taking one familiar deliverable and decomposing it three levels deep on paper, then labelling each level.
Confusing contingency reserve, management reserve, cost baseline and project budget - for example saying the cost baseline includes management reserve, or that contingency reserve is held by the sponsor.
The four terms are near-synonyms in everyday speech and most candidates never draw the stack, so they answer by feel on questions that turn on exactly one boundary.
What to do instead
Draw the additive stack once and redraw it from memory each study session: activity cost estimates + contingency reserve (for known-unknowns, controlled by the PM) = cost baseline; cost baseline + management reserve (for unknown-unknowns, controlled by the sponsor) = project budget; budget + profit = price. Then answer reserve questions by asking 'was this risk identified in the register?'
Identifying the critical path by picking the path with the most tasks or the longest-looking chain, and failing to recompute float and the critical path after a stated delay is introduced.
Candidates memorise 'critical path = longest path' but do not connect it to zero float, and under time pressure they skip the recalculation step the question is actually testing.
What to do instead
Always compute forward pass and backward pass on a scratch grid (ES, EF, LS, LF, float) rather than eyeballing, confirm the critical path is the set of tasks with zero float, and check for more than one critical path. When a stem adds a delay, recalculate before reading the options, and remember a delay beyond float changes which path is critical.
Approving or rejecting a change request before assessing its impact, or letting a change be implemented and documented afterwards.
Stakeholders pressure teams to move fast, and the assessment step feels like bureaucracy. Candidates compress the sequence to 'request, approve, do' and pick that compressed option because it sounds efficient.
What to do instead
Memorise the fixed order as a chain and apply it mechanically: log the request, assess impact on scope, schedule, cost, quality and risk, route to the CCB or designated approver, update the baselines and change log, then communicate. On any question where an option approves or performs work before the impact assessment exists, eliminate it first.
Swapping quality assurance and quality control - describing QA as testing and inspecting the product, or QC as auditing and improving the process.
In practice the same team often does both, and the words 'quality' and 'control' carry no hint of the process-versus-product distinction.
What to do instead
Anchor on one sentence: QA is preventive and process-focused (audits, standards, checklists for how work is done); QC is detective and product-focused (inspection, testing, comparing a deliverable to acceptance criteria). On each question, ask 'is the object a process or a product?' and select accordingly.
Mismatching risk response strategies - using 'avoid' when the scenario describes reducing probability or impact, using 'share' for a threat, or applying threat strategies to an opportunity.
The strategy names overlap in plain English (avoid/mitigate both sound like 'prevent'), and candidates learn the threat list only, then guess when an opportunity appears.
What to do instead
Learn the two lists side by side and say them as pairs: threat - avoid, mitigate, transfer, accept, escalate; opportunity - exploit, enhance, share, accept, escalate. Note that 'accept' and 'escalate' are common to both, and that transfer moves financial ownership (insurance, fixed-price contract) without eliminating the risk. Sort ten practice scenarios into the five strategies before reading any options.
Choosing 'escalate to the sponsor', 'update the risk register' or 'document the issue' as the first action on a 'what should the project manager do FIRST' question.
These are safe-sounding answers that are hard to argue with, so they survive elimination by default; candidates never check whether a fact-finding or plan-review step must come before any record-keeping or escalation.
What to do instead
Use a fixed first-action ladder: gather or verify the facts, then check the plan, charter, register or contract, then act within the PM's authority, and only escalate when the decision exceeds that authority. On FIRST/NEXT questions, eliminate any option that records, reports or escalates before the situation has been assessed, then choose the earliest step in the ladder that remains.