CPIT BA common mistakes
CPIT BA · Understand the traps and how to avoid them.
Treating the business analysis planning and monitoring tasks as a one-off document produced at project start, then never revisiting the plan when scope, stakeholders, or governance change. Candidates describe planning as an activity done once rather than as ongoing monitoring of actual performance against the plan.
The domain name emphasizes 'Planning' and candidates skim past 'and Monitoring'. Study material often presents the plan as a deliverable, so candidates memorize its components without internalizing that the business analyst continuously compares actual stakeholder engagement, requirement progress, and change activity against what was planned and adjusts accordingly.
What to do instead
For every planning artifact (stakeholder engagement approach, business analysis approach, governance approach, information management approach), practice stating the trigger that causes it to be revised and the evidence used to judge whether it is working. When a question asks what the BA should do next after a change in stakeholder availability or a spike in change requests, prefer the option that reassesses and updates the plan over the option that simply follows the original plan or escalates immediately.
Choosing a plan-driven or predictive business analysis approach by default for every initiative, or conversely choosing an adaptive approach whenever the word 'agile' appears, without weighing requirement volatility, regulatory constraints, stakeholder distribution, and the delivery life cycle in use.
Candidates look for a keyword match in the scenario instead of applying the selection criteria. They also assume adaptive is inherently better or that a fixed-price contract implies a fully predictive approach, which conflates commercial terms with the analysis approach.
What to do instead
Before answering, extract from the scenario: how likely requirements are to change, how much regulatory or contractual formality applies, how many stakeholders and how accessible they are, and what the delivery team's life cycle is. Then justify the approach against those factors. Remember that a single initiative can mix approaches, for example predictive approval gates with iterative elicitation.
Confusing elicitation with requirements gathering: treating elicitation as transcription of what stakeholders say, skipping preparation, and failing to confirm or validate what was captured. Candidates then pick answers where the BA simply documents stated wants.
Everyday language frames requirements as something that exists and is 'collected'. Elicitation is active investigation, and the exam tests whether the candidate prepares for the activity, selects techniques deliberately, and closes the loop by confirming results with participants.
What to do instead
Frame each elicitation scenario in four steps: prepare (objectives, participants, technique, logistics), conduct, document, and confirm. When a question asks for the next step after a workshop, the answer is usually validating the captured information with the participants rather than moving straight to specification. Also match technique to context: observation for tacit or hard-to-articulate work, prototyping when requirements are unclear or visual, document analysis for existing rules, interviews for depth with few stakeholders.
Ignoring the collaboration half of elicitation and collaboration: not planning stakeholder engagement, not managing difficult stakeholder dynamics, and not recognizing that confirmation happens throughout rather than only at sign-off.
Candidates focus on technique mechanics (how to run an interview) and neglect the human and communication layer. Scenarios involving conflicting stakeholders, absent decision makers, or unresponsive reviewers are then answered with escalation or unilateral decisions rather than facilitation and engagement adjustment.
What to do instead
When stakeholders conflict, look for the option that facilitates shared understanding, surfaces underlying interests, and uses the agreed governance approach to resolve or escalate only after facilitation is attempted. Distinguish communication (transmitting information) from collaboration (working jointly toward shared understanding) and prefer collaboration options where the scenario shows misunderstanding rather than ignorance.
Treating requirements traceability as paperwork and choosing answers that skip or defer it, or failing to distinguish traceability relationships (derive, satisfy, depend, validate, allocate) and their direction.
Traceability is perceived as administrative overhead, so candidates underestimate how often it is the correct answer for impact analysis, coverage, and rework prevention. The relationship types are also easy to blur under exam pressure.
What to do instead
Memorize the relationships as directional pairs: a requirement derives from a business need or higher-level requirement; a design or solution component satisfies a requirement; requirements depend on each other; a test case validates a requirement; a requirement is allocated to a component. Then recognize that when a change request arrives, the correct next action is usually to use traceability to identify affected requirements and stakeholders before assessing impact.
Approving or rejecting change requests on personal judgment or urgency rather than routing them through the defined change control process and impact analysis, and treating requirement baselines as immutable or as meaningless.
Candidates conflate the BA's role with the decision authority. The BA analyzes impact and recommends; the authorized body decides. Separately, candidates either refuse all change (treating baseline as frozen) or accept all change (treating baseline as irrelevant), missing that baselines exist to make impact visible.
What to do instead
In change scenarios, separate three steps: perform impact analysis (using traceability), present findings and a recommendation, and let the authorized decision maker approve, defer, or reject. Choose answers that preserve the baseline record while allowing controlled change. When a requirement must be reused or maintained, prefer the option that keeps attributes, relationships, and versions current rather than the option that archives everything.
Skipping or rushing current state analysis and jumping to a solution, and confusing the four strategy analysis states: current state, future state, transition state, and the risks and change strategy that connect them.
Candidates are eager to reach requirements and design, and scenarios that describe a problem invite immediate solutioning. Also, transition state and change strategy are the least familiar concepts, so candidates collapse them into the future state or into project planning.
What to do instead
For any strategy scenario, first state the business need and the current-state problem, then define measurable future-state goals, then define the transition state and change strategy (what must change in the organization to realize the future state, and how). Remember that defining change strategy is a strategy analysis task, not a planning task, and that gap analysis compares current to future to identify what must be built or changed.
Conflating requirements analysis with design definition: producing solution designs when the task is to analyze and model requirements, or refusing to specify design when the task calls for it. Candidates also mislabel models, for example calling a process model a data model or treating a use case as a state diagram.
The domain title pairs analysis and design, and in practice they interleave. Candidates therefore lose the boundary: requirements describe what is needed and under what conditions, while design describes a selected way to satisfy them. Model naming is also memorized loosely.
What to do instead
Use a boundary test: if the statement constrains the solution's structure or technology, it is design; if it describes a need, condition, or capability independent of implementation, it is a requirement. Practice matching purpose to model: process models for workflow and handoffs, data models for entities and relationships, state diagrams for an object's lifecycle, decision tables for complex rule combinations, use cases for actor-goal interactions. For verification scenarios, check requirements against characteristics such as unambiguous, complete, consistent, and testable.
Assessing solution performance without first defining measures and acceptance criteria, or measuring only that the solution was delivered (on time, on budget) rather than whether it delivers the intended value. Candidates also fail to distinguish solution limitations from enterprise limitations when diagnosing underperformance.
Candidates carry project-success thinking into solution evaluation, where the question is whether the delivered solution actually meets the business need. Root cause categories are also blurred, so candidates attribute a shortfall to the software when the constraint is organizational.
What to do instead
Always establish measures and acceptance criteria before evaluating, and tie them to the business goals from strategy analysis. When performance falls short, classify the cause: solution limitations (defects, missing capability, usability), enterprise limitations (policy, skills, incentives, process, culture), or external influences. Recommend a change only after the category is identified, since enterprise limitations usually call for organizational change rather than a technical fix.
Treating the core concepts and competencies as background reading: failing to distinguish the six core concepts (change, need, solution, stakeholder, value, context) and answering competency questions with generic virtues such as 'good communicator' instead of naming the underlying behavior, and ignoring the BA's role boundaries.
This domain reads like introductory material, so candidates deprioritize it, yet many scenario questions hinge on correctly identifying who the stakeholder is, what the need versus the solution is, or what value means to a particular stakeholder group. Competency questions reward precise behavioral description.
What to do instead
Drill the core concepts with contrasts: need versus solution, value as perceived by each stakeholder group, context as the set of circumstances shaping the work. For competencies, learn the underlying competencies (analytical thinking and problem solving, behavioral characteristics, business knowledge, communication, interaction, tools and technology) and answer with the specific behavior each implies. When a scenario asks who should do something, check whether it is the BA's accountability or the sponsor's, the project manager's, or the solution owner's.