CAPM common mistakes
CAPM · Understand the traps and how to avoid them.
Classifying every piece of work in a scenario as a 'project' - labelling ongoing production support, a recurring service, or a coordinated group of related projects as a single project - and then selecting project life-cycle answers for it.
Candidates skim for the word 'deliverable' or 'team' and default to project vocabulary, because in their own organization everything is called a project regardless of whether it is temporary or produces a unique result.
What to do instead
Before reading the options, apply a two-question test to the scenario: is the work temporary (has a defined end), and does it produce a unique product, service, or result? If either answer is no, it is operations; if it is a group of related projects managed together, it is a program; if it is the whole collection aligned to strategy, it is a portfolio. Only then read the answers.
Selecting an answer in which the project manager personally approves the project charter, authorizes the budget, accepts a high risk on the organization's behalf, or unilaterally reorders product features.
In small organizations the project manager often does all of these in practice, so the option feels natural and authoritative; candidates also gravitate to the answer where the PM takes decisive action.
What to do instead
Memorize the decision-authority boundary as a short list: charter and funding belong to the sponsor, product priority and backlog order belong to the product owner (or customer), team task assignment belongs to the team. When an option has the PM doing one of these things, eliminate it before comparing the survivors.
On questions that ask what the project manager should do FIRST or NEXT, choosing the most complete, most senior-sounding, or most resolution-oriented option (escalate, update the register, hold a meeting) rather than the earliest action in the sequence.
The distractor options are usually valid actions taken at some point, so they feel 'correct'; candidates respond to the problem described in the stem instead of to the ordering word in the question.
What to do instead
Circle the ordering word before evaluating options. Then rank all four options chronologically: which must logically happen before the others (understand/assess/verify before act; document before communicate; analyze before escalate)? Choose the earliest valid step, not the most decisive one.
Implementing a requested change, or approving it informally, in the scenario instead of routing it through Perform Integrated Change Control - and failing to recognize that an approved change must also update the affected baselines and plan components.
Candidates study the change-control process as a list of ITTOs and never build the causal chain (request → assess impact → decide → update plan/baselines → implement → verify), so 'do the work' reads as a reasonable next step.
What to do instead
Drill the chain aloud until it is automatic, and treat any scenario containing the words 'change', 'request', or 'new requirement' as a cue to look for the answer that assesses impact and obtains a decision, not the one that executes the work. When two change answers remain, prefer the one that also mentions updating the plan or baselines.
Guessing on quantitative items - earned value, schedule variance, PERT/three-point estimates, expected monetary value, communication channels, or number of iterations - instead of computing them on scratch paper.
Under time pressure, estimate and EVM questions look long, and candidates convince themselves they can 'eyeball' whether cost performance is good or bad; formulas memorized as symbols are also easily inverted under stress.
What to do instead
Write the formula and the known values before looking at any option, and keep a one-line cheat list in the last ten minutes of study (EV = BAC × % complete, CV = EV − AC, SV = EV − PV, EAC = BAC/CPI, channels = n(n−1)/2, PERT = (O + 4M + P)/6). Because options are designed around sign errors and inverted ratios, the arithmetic must be explicit, not estimated.
Treating the project management plan, the baselines, and the project documents as interchangeable - choosing 'update the project management plan' when the scenario describes a change to a log or register, or the reverse.
The two categories are taught as parallel ITTO lists rather than as a hierarchy, so candidates never learn that plans and baselines are formally controlled while logs, registers, and reports are working documents updated routinely.
What to do instead
Build a two-column sort of the standard artifacts and learn the rule that generates it: anything that is baselined or approved by a governance process lives in the plan; anything the team keeps current day to day (issue log, risk register, assumption log, stakeholder register, lessons learned register) is a project document. Apply the sort to the artifact named in the stem before choosing.
Answering an adaptive or hybrid scenario with predictive reflexes: creating a detailed upfront plan and baseline, sending a change through a change control board, having the project manager decompose work and assign tasks, or producing documentation 'for approval' before any delivery.
Most candidates' first exposure is predictive, so when an adaptive question appears without obvious Agile vocabulary they unconsciously map it onto the waterfall sequence they know best.
What to do instead
Scan the stem for adaptive signals (iterations, sprint, backlog, incremental delivery, empowered team, changing requirements) and, if present, eliminate every option containing baseline, change control board, detailed plan, assign tasks, or documentation-first. Then choose among the remaining options the one that shortens feedback or moves a decision to the team or customer.
Assigning responsibilities to the wrong Agile accountability - the product owner estimating or assigning daily tasks, the Scrum Master prioritizing the backlog or accepting the increment, the team committing the team to scope on the sponsor's behalf - or choosing an option where the project manager directs the team's daily work.
Scrum accountabilities are learned as three names on a slide rather than as distinct decision rights, so under pressure any option with the right vocabulary sounds plausible.
What to do instead
Memorize one line per accountability: product owner owns value and ordering; Scrum Master owns the process and impediment removal (servant leader, no delivery authority); developers own estimation, self-organization, and the increment. Test each option by asking which of those three owns the decision in the stem, and eliminate options that cross the boundary.
Selecting the option that builds, buys, or configures something (a prototype, a feature, a report) in response to a stated business problem, without any prior needs assessment, elicitation, or analysis step.
The stem typically names a stakeholder request or a visible symptom, and the solution-shaped option is the most concrete and satisfying of the four; the analysis options read as delays.
What to do instead
Read the stem for whether the need itself has been established: if the request is unvalidated, the stakeholder set is incomplete, or the problem statement is missing, the correct answer must be an elicitation, analysis, or needs-assessment action. Reserve solution-shaped answers for stems where the need, stakeholders, and acceptance criteria are already documented.
Mixing up verification and validation, or treating elicitation as analysis - for example answering 'confirm the requirement is well-formed and testable' when the question asks whether the solution meets the business need, or recording a single stakeholder's statement as the requirement without reconciling conflicting inputs.
The two pairs are defined in nearly identical language, and both sound like 'checking the work', so candidates match on the word 'confirm' or 'review' rather than on the object being confirmed.
What to do instead
Anchor both distinctions to their objects: verification asks 'did we build the requirement correctly' (requirement quality, traceability, testability); validation asks 'did we build the right thing for the business need' (value, fitness for use). Elicitation collects raw input; analysis models, prioritizes, and reconciles it across stakeholders. Identify the object in the stem first, then choose the matching activity.