IIBA-CBDA common mistakes
IIBA-CBDA · Understand the traps and how to avoid them.
Writing the data request ("pull 18 months of churn records and build a dashboard") as the research question, then starting the extract the same day, without ever stating the question as a question and without naming the decision it is meant to inform.
Stakeholders usually arrive with a proposed solution, and candidates want to look responsive and productive. Extracting data feels like progress, so the elicitation step gets compressed into a five-minute conversation.
What to do instead
Before any data work, draft a one-page research question statement containing: the question in interrogative form, the decision it supports and who makes it, the unit of analysis, the population and time window, and the criteria for a satisfactory answer. Get the sponsor to sign off on that page.
Leaving the question unbounded on population, time period, geography, or success threshold, discovering mid-analysis that 'customers' could mean 40,000 or 400,000 records depending on definition, and then restarting the analysis.
Ambiguity is invisible at the start and only becomes expensive later. Candidates assume shared definitions rather than confirming them, and scope creep is easier to absorb than to push back on.
What to do instead
Build an explicit scope and definitions table with the question, listing each entity (customer, active, churned, region), its agreed operational definition, and who owns that definition. Circulate it for confirmation before sourcing data, and re-confirm when scope changes.
Selecting data on convenience - the table already in the local warehouse, the export someone emailed, the sample the vendor supplied - and never recording where it came from, when it was extracted, what transformations it passed through, or whether it is fit for the question being asked.
Access friction is real and deadlines are short, so the easiest dataset wins. Candidates also confuse 'available' with 'appropriate', and lineage documentation feels like overhead when the data looks plausible.
What to do instead
For every source, complete a short source assessment: owner, system of record, extraction date, refresh frequency, known gaps, and a fit-for-purpose judgment against the research question. Maintain it as a living register so findings can be traced and reproduced.
Skipping data profiling and reconciliation - never checking row counts against the source system, never counting duplicates, nulls, or out-of-range values, never testing whether the join quietly dropped 12% of records - and analyzing the raw extract as if it were clean.
Profiling produces no visible output and candidates fear it looks like wasted time. Silent join loss and duplicated keys are hard to notice because aggregate results still look reasonable.
What to do instead
Run a standard profiling pass before analysis: record counts before and after every join, duplicate key checks, null and range distributions on every field used, and a reconciliation of at least one measure to its source system total. Document the results even when everything passes.
Choosing analytic technique and summary statistics before inspecting distributions - reporting the mean of a heavily skewed measure, or applying a test whose independence and normality assumptions are visibly violated - and never stating the assumptions that were checked.
Candidates default to the techniques they learned most recently or most comfortably, and summary tools output a mean by default. Assumption checking is often taught as a footnote rather than a gate.
What to do instead
Plot the distribution of every variable used and match the statistic to the shape (median and IQR for skewed data, mean for roughly symmetric). Before applying any inferential technique, list its assumptions, test each one, and record in the analysis log what was checked and how violations were handled.
Building the analytical population out of whatever records happen to exist and then generalizing to everyone - analyzing only current customers when the question is about churn, only completed transactions when the question is about abandonment - and presenting the result as characteristic of the full population.
Missing records are invisible; the dataset looks complete because nothing inside it flags what is absent. The bias is structural rather than arithmetic, so no validation rule catches it.
What to do instead
Before analysis, explicitly enumerate who or what should be in the population versus who is actually in the data, and quantify the gap. Where records are systematically missing, either obtain them or state the bias as a limitation alongside the direction it is likely to push the result.
Delivering a deck of charts organized by analytic step ('data prep', 'segmentation', 'model output') with the research question restated nowhere and the answer stated nowhere, leaving the audience to assemble the conclusion themselves.
Candidates narrate the journey because that is the order in which they did the work, and they worry that leading with the answer looks oversimplified or unsupported.
What to do instead
Structure every report answer-first: the question as asked, the answer in one sentence, the three findings that support it, then the method as an appendix. Walk through it with a colleague who has not seen the analysis and check whether they can restate the answer after the first slide.
Presenting a result as definitive - no confidence interval, no sample size, no mention of limitations or assumptions - and treating a statistically significant but operationally trivial difference as a reason to act.
Uncertainty feels like weakness, and candidates want to give a clean recommendation. Significance thresholds are easy to apply mechanically without asking what size of effect would actually matter.
What to do instead
For every reported result, state the effect size in business units, the uncertainty around it, and the threshold at which it would matter operationally. Add a standing limitations section covering data gaps, assumptions, and what the analysis cannot conclude.
Handing over a recommendation ('shift budget to segment B') with no decision criteria, no trade-offs considered, no assessment of whether the organization can actually execute it, and no alternative options presented.
Candidates treat the recommendation as the endpoint of the analysis rather than the input to someone else's decision, and they may not have elicited the constraints, risk appetite, or capacity of the decision maker.
What to do instead
Frame recommendations against explicit decision criteria agreed with the sponsor (cost, risk, feasibility, speed), present at least two options with trade-offs, name the assumptions the recommendation depends on, and state what would have to be true for the alternative to be better.
Ending the engagement at handover - never confirming which recommendation was adopted, never defining the measure and review date that would show whether it worked, and no path to feed the outcome back into the next research question.
The project is measured by delivery and the analyst moves to the next request. Outcomes surface months later, often to someone else, and there is no assigned owner for follow-up.
What to do instead
Agree a post-decision measurement plan before closing: the metric that will move, its baseline, the target, the review date, and the named owner. Schedule the review as part of the deliverable and record the decision outcome so the next question starts from evidence rather than assumption.