PMI-PBA common mistakes
PMI-PBA · Understand the traps and how to avoid them.
Choosing an answer that names a solution (a new system, a training program, a process redesign) before any work has been done to define the underlying problem, opportunity, or current-state gap.
The scenario usually describes a symptom and a frustrated sponsor, which feels like an instruction to act; candidates unconsciously adopt the requester's proposed solution as the problem statement and pick the option that moves fastest toward delivery.
What to do instead
Before answering, locate the deliverable being asked for. If the scenario has no documented problem statement, root-cause analysis, or current-state assessment, the correct option is almost always the one that establishes the need first. Treat any option that commits resources to a solution as wrong until the need is described in measurable business terms.
Recommending an option on the strength of a single criterion (usually lowest cost or fastest delivery) without comparing it against alternatives and a 'do nothing' baseline using agreed criteria.
Cost and schedule are the numbers most visibly present in the scenario, so they anchor the decision; candidates also assume the option with the most detail in the stem must be the intended answer.
What to do instead
Look for the option that defines evaluation criteria, weights them with the sponsor or key stakeholders, and compares at least two viable options plus the status quo against those criteria, including feasibility and risk. A recommendation without a documented comparison is a guess, not an analysis.
Selecting the most formal, most document-heavy approach offered (full requirements package, every model, every review) regardless of the size, risk, or regulatory context described.
Candidates trained on 'more rigor is better' read formality as professionalism, and PMI-style exams reward thoroughness so heavily that tailoring feels like cutting corners. It also removes the need to make a judgment call.
What to do instead
Read the scenario for tailoring signals: team co-location, regulatory oversight, fixed-price contract, distributed stakeholders, safety-critical product. Then pick the option whose rigor matches those signals. If an option is described as 'per organizational standards and tailored to the project characteristics', it usually beats the maximal option.
Producing a communication plan or governance approach without first identifying and analyzing stakeholders, so the plan is generic rather than based on influence, impact, and attitude toward the change.
Stakeholder analysis feels like overhead and the scenario often lists stakeholders explicitly, so candidates assume identification is done and jump straight to scheduling meetings or writing status reports.
What to do instead
Treat the presence of a stakeholder list as stage one only. The right answer analyses each stakeholder's influence, interest, and support or resistance, and derives communication frequency, format, and level of involvement from that analysis. If an option describes personalized, differentiated engagement, prefer it over a uniform plan.
Treating verification and validation as interchangeable, e.g., selecting 'walk the stakeholder through the prototype to confirm it meets the requirement' as verification, or 'check the model follows modeling standards' as validation.
Both activities involve reviewing a requirement artefact and both happen with stakeholders present, so the words blur under time pressure and the stem rarely uses either term explicitly.
What to do instead
Anchor on the object of the check: verification asks whether the requirement is written correctly and consistently (complete, unambiguous, testable, conforms to standards); validation asks whether it correctly represents the stakeholder need. Ask yourself 'against a standard or against a person's need?' before choosing.
Choosing an elicitation technique because it is the most thorough or most popular, instead of matching the technique to the situation described (geographically dispersed stakeholders, stakeholders who cannot articulate their process, a need for rapid consensus, a large population to sample).
Technique names carry strong associations (workshops are collaborative, interviews are deep, observation is thorough) and candidates select on reputation rather than on the specific constraint planted in the scenario.
What to do instead
Extract the constraint first, then map it: dispersed or hard-to-schedule stakeholders point to surveys, virtual sessions, or asynchronous techniques; unarticulated or habitual work points to observation and job shadowing; conflicting views that need resolution point to facilitated workshops; sensitive or political topics point to one-on-one interviews. The scenario always contains the discriminating clue.
Treating the traceability matrix as an artefact to be produced for approval and then filed, so change requests are assessed only against the change description rather than against the requirements, designs, and tests it touches.
Traceability is taught as a documentation obligation, and in the scenario the matrix already exists, which makes it feel complete. The impact-analysis purpose is easy to forget because it only shows up when a change arrives.
What to do instead
Whenever a scenario introduces a change, look for the option that traces the change outward to affected requirements, designs, test cases, and downstream deliverables, then assesses cost, effort, and risk before a decision. The right answer never approves a change on the requester's justification alone.
Approving or rejecting requirement changes without establishing a requirements baseline first, so the team cannot tell an authorised change from gradual scope creep.
Baselines sound like project-management bureaucracy and candidates skip past them; meanwhile everyday 'small adjustments' in the scenario look harmless individually, so no single decision appears to need control.
What to do instead
Ask whether the scenario shows an agreed, approved set of requirements at a defined point in time. If not, the correct action is to establish and agree the baseline and define who may approve changes to it. Then route the change through that defined authority rather than deciding case by case.
Concluding that a solution has been evaluated once acceptance testing is complete and the sponsor has signed off, skipping the assessment of whether the solution actually delivers the intended business value.
Acceptance and sign-off are visible, dated events with clear completion criteria, whereas benefit realisation is diffuse and delayed, so candidates equate 'accepted' with 'successful'. The exam also offers tempting options that stop at sign-off.
What to do instead
Separate the two questions: sign-off confirms the solution met acceptance criteria; evaluation confirms it solved the original business problem. Select the option that measures defined outcome metrics against the baseline from the needs assessment, and that plans for measuring after implementation, not only at delivery.
Escalating to the sponsor or project manager decisions that belong to the business analyst, such as which elicitation technique to use, how to resolve a conflicting requirement, or how to word a requirement.
Escalation reads as safe, collaborative, and risk-averse, which matches the instinct that the exam rewards caution. Candidates pick it whenever a scenario describes disagreement, without checking whether the BA holds the authority or expertise to act.
What to do instead
Before choosing an escalation option, confirm the decision is genuinely outside the BA's remit (funding, priority trade-offs across business units, scope authority). If it is a technique choice, a modelling decision, or a facilitation step, the right answer is the one where the BA acts and then communicates the outcome to affected stakeholders.