BCD common mistakes
BCD · Understand the traps and how to avoid them.
Writing the business analysis deliverable (e.g. a SWOT, stakeholder grid, or process model) as a generic description of the technique rather than applying it to the specific scenario organisation and its stated facts.
Candidates memorise technique definitions during revision and then reproduce the textbook explanation under time pressure instead of doing the analysis the question asks for.
What to do instead
Before writing, extract the named organisation, its goal, and two or three scenario-specific facts; force every sentence of the answer to reference one of those facts, and delete any sentence that would still be true for a different organisation.
Treating the internal and external strategic context as interchangeable, so PESTLE factors are listed as if the organisation controls them or SWOT weaknesses are listed as external threats.
The categories overlap in everyday language and candidates sort items by topic (e.g. 'competition') rather than by locus of control.
What to do instead
Apply a control test to each item: if the organisation can change it through its own decisions it is internal (strength/weakness, value chain), otherwise external (PESTLE, five forces); re-sort any item that fails the test before writing it up.
Producing a flat list of stakeholders with no analysis of interest, influence, or attitude, and no resulting engagement action.
Candidates equate 'stakeholder analysis' with 'stakeholder identification' and stop once names are on the page.
What to do instead
Use an influence/interest grid, place each named stakeholder in a quadrant, and state one concrete engagement approach per quadrant (e.g. manage closely, keep informed); check every stakeholder has both a position and an action.
Ignoring or under-weighting stakeholders who are low in formal authority but high in impact, such as front-line staff, regulators, or customer groups, and over-weighting the most senior sponsor.
Candidates default to the hierarchy shown in the scenario and assume seniority equals importance to the outcome.
What to do instead
Assess each stakeholder on both power and interest/impact separately; explicitly justify the placement of any low-power stakeholder and name the risk of not engaging them.
Jumping to a solution or recommendation in the investigation section, describing the current situation only in terms of what is wrong with it and what should replace it.
Scenarios often describe a problem vividly, prompting an immediate fix; candidates conflate 'investigate' with 'recommend'.
What to do instead
Use structured techniques (e.g. CATWOE, rich picture, root cause analysis) to describe how the situation works now, separate symptoms from causes, and reserve all recommendations for the options domain.
Accepting the stated problem at face value and analysing symptoms rather than causes, so the root cause is never identified.
The scenario presents a visible symptom (falling sales, complaints) and candidates build analysis around it without testing alternative explanations.
What to do instead
Apply a technique such as the 'five whys' or cause-and-effect (fishbone) analysis, list at least two candidate causes, and state the evidence in the scenario that supports the chosen root cause.
Drawing process models with inconsistent notation, mixing elements (e.g. using a decision diamond as an activity, or omitting start/end events and gateways), or producing a model that cannot be read as a valid end-to-end flow.
Candidates sketch what feels intuitive rather than following a defined notation, and run out of time to check the model's logical integrity.
What to do instead
Pick one notation (e.g. BPMN) at the start and use only its element set; before submitting, trace every path from start to end and confirm each gateway has matching branches and each activity has an owner.
Evaluating only one option, or listing options without defined evaluation criteria, so the recommendation is asserted rather than justified.
The scenario may hint at a preferred direction, and candidates treat option generation as a formality to be skipped.
What to do instead
Generate at least three genuinely distinct options (including a 'do nothing/minimum change' baseline), define weighted criteria before assessing them, and show the scoring that leads to the recommendation.
Writing requirements that are ambiguous, untestable, or actually solutions in disguise (e.g. 'the system shall have a dashboard' rather than a stated need), and failing to distinguish functional from non-functional requirements.
Candidates write from the perspective of a proposed design and use vague qualifiers ('user-friendly', 'fast') that feel complete but cannot be verified.
What to do instead
For each requirement, apply a test: is it a need not a design, is it measurable, and could a tester confirm it? Rewrite any requirement containing subjective adjectives with a measurable criterion, and label each as functional or non-functional.
Presenting a business case that lists only benefits and costs without quantification, assumptions, risks, or a comparison of alternatives, and omitting the recommendation and decision sought.
Candidates treat the business case as a persuasive summary rather than an evidence-based decision document, and skip financial appraisal under time pressure.
What to do instead
Structure the case explicitly: options considered, quantified costs and benefits with stated assumptions, key risks and mitigations, and a clear recommendation with the decision requested; flag any figure that cannot be quantified as an assumption.