CCBA common mistakes
CCBA · Understand the traps and how to avoid them.
When a scenario asks how the BA should plan the work, the candidate selects the most formal artifact available (full RACI, detailed communications plan, elaborate governance structure) regardless of the team size, co-location, regulatory context, or delivery approach described in the scenario.
Exam candidates transfer instincts from project management exams, where 'more documentation and more formality' reads as the safest answer. The Business Analysis Planning and Monitoring knowledge area rewards proportional planning, so the 'safest' option is often a distractors.
What to do instead
Before answering, extract the situational cues (team size, virtual vs co-located, regulatory oversight, predictive vs adaptive lifecycle, stakeholder experience) and pick the planning approach that matches them. Practice writing one sentence linking each cue to the level of formality it justifies.
The candidate treats the business analysis plan and the stakeholder engagement approach as deliverables created once at the start, and fails questions about what to do when a new stakeholder appears mid-initiative, a key stakeholder disengages, or scope shifts.
Planning feels like an up-front phase, so candidates picture a plan being written and then simply followed. They miss that planning and monitoring is iterative and that stakeholder analysis and engagement approaches must be re-run when the situation changes.
What to do instead
Memorise the loop: plan, perform, monitor, adjust. For any 'something changed' question, look for the answer that revisits stakeholder analysis or the BA approach rather than the one that documents the change and moves on. Also learn that performance measures exist to tell the BA when re-planning is needed.
The candidate answers elicitation questions with a default technique (usually interviews or a workshop) even when the scenario describes dispersed stakeholders, a conflict-ridden group, tacit knowledge held by workers who cannot articulate it, or requirements that nobody can describe in words.
Interviews and workshops are the techniques candidates have actually used, so they become the mental default. The exam instead tests whether you can select a technique from the characteristics of the information needed and the constraints of the audience.
What to do instead
Build a technique-to-purpose table and rehearse it: observation for tacit or unspoken process steps, document analysis for as-is state in a documented area, prototyping for unclear interfaces or user expectations, focus groups for attitudes and opinions, workshops for cross-functional consensus and conflict resolution, surveys for large dispersed populations. On every elicitation question, first name what is being elicited and who holds it, then choose.
The candidate treats elicitation as finished once information has been captured, and rejects or overlooks answer options involving confirming elicitation results with the source, reconciling conflicting inputs, or verifying that what was heard matches what was meant. They jump straight to documenting requirements.
In practice many BAs hand notes to a technical writer and never close the loop. Candidates therefore do not recognise confirmation as a discrete, examinable activity and read those options as redundant steps.
What to do instead
Learn elicitation as four activities: prepare, conduct, confirm, communicate. When a question mentions conflicting stakeholder statements, ambiguous input, or information from a single source, expect the correct answer to include a confirmation or reconciliation step with the source before the requirement is recorded or used.
Faced with a change request, the candidate selects 'approve it' because the requester is senior, or 'reject it to protect the baseline', instead of choosing the option that performs impact analysis across traceability links, stakeholders, and solution components before a decision is made.
Change control is often reduced in candidates' minds to a sign-off meeting. The subtle distinction - that approval authority and impact assessment are separate, and that assessment always precedes the decision - is what is being tested.
What to do instead
Drill the sequence: raise, analyse impact (using traceability and requirements attributes), decide, communicate, update artifacts. Any answer that recommends a decision before impact analysis, or that skips updating the affected artifacts, is wrong regardless of who requested the change.
Given a scenario about a new initiative, the candidate moves directly to defining the future state or comparing solution options, skipping any analysis of the current state, the underlying problem or opportunity, or the gaps between the two.
Solution-first thinking is common in practice and the questions are worded so that a future-state or solution option sounds thorough and forward-looking. The exam is checking whether you can separate problem understanding from solution selection.
What to do instead
For every Strategy Analysis question, ask 'has the current state and the business need been established first?' If a scenario states that the problem is poorly understood or stakeholders disagree on what is wrong, the correct answer will address current state or business need definition rather than solution options. Practise drawing the chain: business need, current state, future state, gaps, change strategy, solution options.
The candidate accepts vague directional statements such as 'improve customer satisfaction' or 'increase revenue' as objectives, and does not distinguish a business need from a business goal, or a goal from a measurable objective.
These terms are used interchangeably in most workplaces, so the distinctions feel artificial. Candidates answer on the basis of what sounds aspirational and well-intentioned rather than on measurability and traceability.
What to do instead
Memorise the hierarchy and its test: the need is the problem or opportunity, the goal is the desired outcome direction, the objective is the measurable target that shows the goal is met. Any option phrased as a direction without a measure, timeframe, or baseline is a wrong answer when the question asks for an objective.
The candidate treats verification and validation as synonyms, choosing 'validate' when the question is about completeness, consistency, and correct use of standards, or 'verify' when the question is about whether the requirement delivers value and aligns to the business need.
Both words mean 'check' in everyday speech, and candidates rely on that intuition rather than on the BABOK distinction. Questions are often worded without either keyword, describing only the activity.
What to do instead
Anchor on two questions. Verification asks 'is this requirement well formed and correct as written?' - checkable against quality standards by the BA and peers, without reference to the business need. Validation asks 'does this requirement deliver the value the stakeholders actually need?' - checkable only with stakeholders and against the business need. Classify the described activity by who performs it and what it is compared against.
The candidate answers questions about modelling or specification by choosing the most elaborate model, or by assuming a full written specification is always correct, without regard to the audience, the delivery approach, or whether the item is a requirement or a design.
Candidates equate rigour with document volume. They also blur requirements (what is needed) and designs (how it will be delivered), so they select design-flavoured options when the question asks for requirements, or reject design options that are legitimate in an adaptive context.
What to do instead
For each answer option, ask two questions: who is the audience and what do they need to act on, and is this stating a need or a chosen way of meeting it? In adaptive contexts, requirements and designs are intentionally elaborated at the last responsible moment, so 'produce a complete specification up front' is usually wrong there. Learn the requirement types and their classification so you can tell a business, stakeholder, solution, or transition requirement from a design.
The candidate assesses solution performance using usage, adoption, or output measures (number of users, features delivered, transactions processed) and concludes the solution is successful, instead of selecting measures that show whether the business need and expected value were actually achieved against a pre-change baseline.
Adoption and delivery metrics are the ones teams report weekly, so they feel like success measures. The exam tests whether you can distinguish solution performance from delivered value, and whether you know that a meaningful comparison requires a baseline captured before or independent of the change.
What to do instead
For Solution Evaluation questions, sort the metrics in each option into output, usage, and outcome/value. Prefer outcome measures tied to the stated business objectives, and prefer answers that reference a baseline and the defined performance measures. Also distinguish a solution limitation or a missing capability from a defect, since the correct response differs: defects are corrected, limitations feed recommendations to increase value.