BCS BA Foundation common mistakes
BCS BA Foundation · Understand the traps and how to avoid them.
Treating 'business analysis' as a synonym for 'requirements gathering', so questions about the BA's wider role (internal consultancy, facilitating change, improving business processes) get answered with a requirements-only framing.
Candidates study the requirements chapters hardest because they feel concrete, and then over-apply that lens to every scenario question, missing the strategic and change-oriented competences the syllabus also tests.
What to do instead
Before answering, ask which competence the question is really probing: is the BA analysing a situation, defining needs, or supporting change? Build a one-page map of the BA's responsibilities across the whole business change lifecycle and test each practice question against it.
Confusing the three levels of requirements (business, stakeholder, solution) and labelling a scenario at the wrong level, for example calling a user's task description a business requirement.
The levels overlap in real narratives, and candidates latch onto the word 'requirement' rather than asking who the requirement serves and what it describes.
What to do instead
Apply a two-question test to every requirement: who is it for (the organisation, a stakeholder group, or the solution), and what does it describe (a goal, a need, or a capability/behaviour)? Practise sorting a mixed list of twenty requirements into the three levels and justify each placement.
Describing a technique by name only, or listing its steps from memory, when the question asks when and why the technique is appropriate and what its limitations are.
Revision notes often capture definitions and procedures but not selection criteria, so candidates can recite SWOT or MoSCoW yet cannot choose between them in context.
What to do instead
For each technique, build a card with four fields: purpose, when to use, when not to use, and output produced. Then practise scenario questions by first identifying the decision the BA needs to make, and only then selecting the technique that serves it.
Choosing a technique because it is familiar rather than because it fits the situation, e.g. defaulting to interviews for a large, geographically dispersed stakeholder group, or to a workshop when stakeholders are in conflict and will not speak openly.
Exam pressure pushes candidates toward the best-remembered option, and familiarity feels like correctness under time constraints.
What to do instead
For every 'which technique' question, write down the situational constraints first (numbers, geography, conflict level, time, need for consensus versus individual depth) and eliminate options that violate a constraint before comparing the survivors.
Treating stakeholder analysis as a one-off list-making exercise, so questions about ongoing engagement, changing influence, or managing resistant stakeholders are answered as if analysis ends at categorisation.
Textbook diagrams (power/interest grids) are memorable and give a false sense of completion, while the syllabus expects analysis to drive a continuing engagement approach.
What to do instead
Always link analysis to action: for each stakeholder category, state the engagement approach, communication frequency, and what would signal a change in their position. Practise questions by asking 'what happens next?' after any analysis output.
Handling stakeholder conflict by seeking compromise or majority agreement when the scenario calls for escalation, evidence-based facilitation, or recognising that some stakeholders hold authority over the decision.
Candidates import a general belief that consensus is always good, and the exam's emphasis on rational analysis is underweighted in favour of conflict-avoidance instincts.
What to do instead
Learn to distinguish disagreement about facts (resolvable with evidence), about values or objectives (needs negotiation or escalation), and about authority (needs the decision owner). Match the response to the type of conflict rather than defaulting to compromise.
Mixing up investigation techniques that look similar, such as observation versus shadowing, or prototyping versus scenario analysis, and selecting the wrong one for the stated purpose.
The distinctions are subtle and often learned as short definitions, so recall fails under distractor pressure when two options are both plausible.
What to do instead
Create contrast pairs: for each confusable pair, write one sentence on what each produces and one situation where only one is suitable. Test yourself by reading a scenario and naming the technique before looking at the options.
Answering questions about the business change lifecycle by naming the stage correctly but misidentifying what happens in it, particularly confusing definition with design, or implementation with realisation of benefits.
Stage names are easy to memorise, so candidates learn the sequence but not the activities, deliverables, and decision points inside each stage.
What to do instead
For each lifecycle stage, record the key question it answers, the main deliverables, and the decision or gate at its end. Rehearse by placing a described activity into a stage and explaining why it cannot belong to the adjacent stage.
Ignoring the exam's command words, so an answer that should evaluate options instead describes them, or an answer that should identify gives lengthy justification and picks the wrong option.
Candidates focus on subject content and treat the question stem as background, missing that the verb signals the depth and type of reasoning required.
What to do instead
Underline the command word and the subject in every stem before reading the options. Build a short glossary of command words used in the exam (identify, describe, explain, evaluate, justify) and check that the chosen option matches the required cognitive level.
Applying a preferred methodology or framework dogmatically to scenario questions, instead of reasoning from the situation described and the principles behind the approach.
Candidates often learn one approach in depth (for example a particular agile or waterfall model) and use it as a template, while the exam tests judgement about tailoring.
What to do instead
For scenario questions, extract the situational factors first (regulatory certainty, stakeholder availability, rate of change, risk tolerance) and reason from principles. Practise by arguing for two different approaches to the same scenario and identifying what evidence would decide between them.