PMI CD-BA common mistakes
PMI CD-BA · Understand the traps and how to avoid them.
Reading the scenario and jumping straight to the answer choice that names the correct technique (e.g., "conduct a focus group") without first identifying which business analysis task the question is actually testing.
The CD-BA exam scenarios are short and technique-dense, so candidates pattern-match on familiar keywords like 'stakeholder' or 'requirement' and pick a plausible-sounding tool. Questions are built so that several techniques are defensible in general but only one matches the task, input, or stage described.
What to do instead
Before scanning options, write one phrase: what BA task is in play (e.g., 'plan business analysis approach', 'define future state', 'verify requirements')? Then eliminate any option that belongs to a different task even if it is a good practice. Practice by covering the options and stating your own answer first.
Treating the exam as a waterfall-only or agile-only mindset, choosing 'document everything in a formal requirements document' or 'hold a daily standup' regardless of the methodology the scenario implies.
Candidates come from one delivery environment and unconsciously apply its rituals. The exam explicitly tests tailoring: the correct answer depends on whether the context is predictive, adaptive, or hybrid, and on organizational and stakeholder factors stated in the scenario.
What to do instead
Highlight context clues in the stem (regulated, fixed-price, frequent change, distributed team, executive sponsor) and map them to approach choices. Memorize that BA planning is about selecting and tailoring techniques, not defaulting to a template.
Confusing 'needs' with 'solutions' - accepting a stakeholder's stated request ('we need a new CRM') as the underlying problem and picking an answer that begins building or estimating it.
Stakeholders routinely present solutions as needs, and experienced BAs are used to accommodating them. The Needs Assessment domain rewards digging to the business problem, goal, or opportunity before any solution is evaluated.
What to do instead
When an option starts with designing, building, or estimating before the problem, goal, and success measures are established, treat it as a trap. Look for the option that clarifies the business need, current state, or desired outcome first.
Skipping or superficially doing stakeholder analysis and choosing an answer that engages only the requesting sponsor or the loudest user group.
Scenarios often name a sponsor who is pushing a deadline, and candidates mirror that pressure by limiting scope of consultation. The exam tests identifying all affected parties, including regulators, support staff, and those who can block adoption.
What to do instead
For any engagement or elicitation question, check whether the option accounts for the full stakeholder list, their influence and interest, and communication needs. Prefer answers that plan engagement rather than answers that satisfy one powerful stakeholder.
Choosing an elicitation technique by personal comfort (usually interviews or brainstorming) rather than by the information sought, the stakeholder group size, geography, or the level of agreement needed.
Technique selection questions look easy because every option is a real technique. Candidates pick the one they use at work instead of reasoning about fit - e.g., using a survey when the goal is to resolve conflicting views, or a workshop when stakeholders are unavailable.
What to do instead
Build a small decision table: need consensus among many stakeholders → workshop; need breadth from a large dispersed population → survey/questionnaire; need to observe actual work → observation/job shadowing; need to understand underlying motivations → interview. Match the stated constraint in the stem.
Failing to distinguish verification from validation, and requirements quality criteria from acceptance criteria, when the question asks what to do next with a set of requirements.
The terms sound interchangeable in everyday speech, and many candidates never had to separate 'built correctly' from 'correct thing built'. Exam items exploit this by offering both activities as options.
What to do instead
Anchor definitions: verification confirms requirements are well-formed, complete, consistent, and testable; validation confirms they support delivery of the business need and stakeholder value. Read the stem for words like 'ambiguous', 'conflicting', or 'traceable' (verification) versus 'meets the business need' or 'stakeholder agrees' (validation).
Treating traceability as paperwork - rejecting traceability answers as bureaucratic, or selecting 'create a traceability matrix' without linking it to the change or coverage problem described.
In many workplaces traceability is done poorly or not at all, so candidates undervalue it. The exam tests traceability as a tool for impact analysis, coverage confirmation, and scope control, and expects the answer to say what the artifact is used for.
What to do instead
When a scenario involves a change request, a missed requirement, or unclear test coverage, look for the option that traces requirements back to business need and forward to design, build, and test. Choose the answer that uses traceability to answer a specific question, not one that merely creates a document.
Managing change requests by either rubber-stamping them or refusing them, instead of following a defined change control process that assesses impact and routes to the right authority.
Candidates conflate being helpful with being compliant, or conflate scope protection with saying no. The correct behavior is usually to analyze impact on scope, schedule, cost, risk, and other requirements, then escalate per the approved process.
What to do instead
For any change scenario, pick the option that (1) logs the request, (2) performs impact analysis using traceability, and (3) routes the decision to the accountable authority. Avoid options that unilaterally approve, deny, or silently absorb the change.
Jumping to solution evaluation conclusions from user opinion alone, without defining or using measures, baselines, or acceptance criteria.
Scenarios often include a persuasive stakeholder who declares the solution a success or failure. Candidates side with the narrative rather than with evidence, and the Evaluation domain rewards measurement against agreed criteria.
What to do instead
Look for the option that establishes or applies defined measures (KPIs, acceptance criteria, baseline metrics) and compares actual results to them. If no measures exist, the correct next step is usually to define them or gather data, not to render a verdict.
Ignoring the enterprise context - picking a locally optimal BA action that conflicts with organizational strategy, governance, or the solution scope boundary stated in the scenario.
Candidates focus on the immediate task and forget that the exam consistently rewards alignment with business goals, architecture, and governance. Distractor options are often technically correct but out of scope or misaligned.
What to do instead
Before answering, re-read the first and last sentence of the stem for strategy, scope, or governance constraints. Eliminate any option that expands scope, bypasses governance, or optimizes a sub-team at the expense of the stated business objective.