Planning the Analytics Approach

Planning the Analytics Approach

Quick Answer: CBDA Competency 1.2 is about planning how analytics work will be performed: which activities and deliverables you will produce, in what order, with which methods and roles, and with approval of the approach including the research question. Tool choice is secondary to a coherent path from business question to decision influence.

Scope sets the fence. The analytics approach is the path inside the fence. Without an approach plan, teams oscillate between random queries and impressive charts that do not answer the research question. Domain 1 weights this heavily because poor plans create avoidable rework in sourcing, analysis, and storytelling.

What “plan the analytics approach” means on CBDA

Planning the approach is not writing a 40-page project charter. It is agreeing on a fit-for-purpose plan that a mixed team can execute:

• Research question(s) and success criteria for “answered well enough.”
• Activities the team will perform (stakeholder alignment, source assessment, preparation, analysis, validation, packaging, decision workshop).
• Deliverables stakeholders will receive (assumption log, data profile, analysis notebook/report, visualization pack, recommendation brief).
• Methods and models at the right altitude (descriptive baselines first; diagnostic drill-downs; predictive only if the question and data support it).
• Sequence and checkpoints where findings can refine the question.
• Roles and RACI-style clarity for BA, data roles, and business owner.
• Risks, constraints, and dependencies carried forward from scoping.
• Approval that leadership understands the question, limits, and expected decision use.

On exam items, the best next step is often agree the approach and research question with stakeholders before heavy analysis—especially when multiple groups want different outcomes.

Activities, deliverables, and models in the plan

Think of the approach plan as three linked layers.

1) Activities (work the team does)

Typical activity sets for a CBDA-aligned effort:

• Confirm business decision and research question wording.
• Validate critical assumptions and access paths.
• Inventory candidate sources and assess fitness (coverage, grain, latency, quality).
• Prepare and document data (definitions, joins, sampling, privacy steps).
• Analyze using techniques matched to the question category (descriptive, diagnostic, predictive, or prescriptive—without forcing a more advanced category than needed).
• Validate that results still answer the business question (not only model metrics).
• Interpret findings into insights and options.
• Package for the audience and facilitate decision discussion.

2) Deliverables (artifacts the team produces)

Deliverables should map to decisions, not vanity:

CBDA candidates should notice when a scenario confuses deliverable with activity. “Run a regression” is an activity (or method). “A validated model card and business interpretation for pricing leadership” is a deliverable.

3) Models (representations used to think and compute)

“Models” in approach planning include more than machine learning:

• Business / decision models: how the organization decides (thresholds, policies, who approves).
• Conceptual data models: entities and relationships needed for the question.
• Analytical models: statistical or ML methods if warranted.
• Communication models: storyline structure for the audience.

A mature plan names which of these are in play. Many CBDA scenarios need a solid decision model and descriptive/diagnostic analysis—not a neural net.

Sequencing: question → source → analyze → interpret → influence

A reliable default sequence mirrors the CBDA knowledge areas:

1. Question — Confirm the research question, hypotheses if used, success criteria, and scope boundaries.
2. Source — Identify, assess, acquire, and prepare data that can actually answer the question.
3. Analyze — Apply techniques appropriate to the question and data; iterate with quality checks.
4. Interpret — Translate outputs into business meaning, limitations, and options.
5. Influence — Support a decision or action with ethical, audience-fit packaging.

This is a logic order, not a ban on iteration. Good teams loop:

• Analysis may reveal the question is unanswerable with current data → return to question/scope.
• Interpretation may show the audience needs a different grain → return to source or analysis.
• Influence workshops may surface a new decision criterion → refine validation and narrative.

Exam traps include skipping to analysis because “we already have a dashboard,” or building predictive models before confirming the decision and data grain. Another trap is treating influence as “send the deck” without planning how decision makers will use the evidence.

Lightweight milestone pattern

Obtain approval on the approach—including the research question

Approval is not bureaucracy for its own sake. It is shared commitment that:

• The research question is the right question for the decision.
• Stakeholders accept what is out of scope for this cycle.
• Resource owners understand time, access, and SME needs.
• Leaders understand that results may challenge prior beliefs.

How formal approval is depends on culture. In some organizations it is a signed one-pager; in others it is a recorded decision in a product backlog refinement. On the CBDA exam, look for answers that secure alignment before large sunk cost, especially when sponsors disagree.

What to put in an approval package (minimum)

• Research question and why it matters now.
• In/out scope and key constraints.
• Planned activities and timeline at a high level.
• Data sources expected and major dependencies.
• Deliverables and decision forum.
• Risks (assumption failure, low data quality, decision delay).

If sponsors refuse to approve a question but demand “insights,” the BA’s job is to make the trade-off visible, not to invent a false sense of direction.

Roles: BA, data scientist, data engineer, business owner

CBDA sits at the intersection of business analysis and analytics. Scenario answers often reward collaboration, not heroics by one role.

Collaboration pitfalls that appear in exam stems:

• Data science optimizes AUC while the business owner needed an explainable driver list for ops managers.
• Engineering builds a perfect pipeline for the wrong grain.
• The BA polishes a research question that no data source can support.
• The owner delegates “just tell us what to do” without stating decision criteria.

A strong approach plan names who decides, who executes, and who validates definitions.

Agile vs planned analytics approaches (high level)

CBDA does not require a single methodology. It requires a conscious fit.

More planned (heavier up-front design)

Useful when:

• The decision is high stakes (regulatory, safety, large capital).
• Data access and definitions need formal control.
• Multiple functions must approve methods and outputs.
• The question is relatively stable.

Characteristics: clearer stage gates, documented validation, fewer midstream question changes.

More agile / iterative

Useful when:

• Uncertainty is high and learning value is high.
• Stakeholders can review thin slices of evidence weekly.
• Data is partially ready and exploration is part of discovery.
• The decision window allows re-framing.

Characteristics: short cycles from mini-question → profile → insight demo; backlog of analysis stories; rapid invalidation of weak questions.

Hybrid reality

Most analytics work is hybrid: plan the decision path and privacy/constraints firmly, iterate on exploratory analysis and visualization. Exam answers that rigidize “always waterfall” or “always agile” usually lose to answers that match approach style to uncertainty, risk, and readiness.

Putting it together: a short approach sketch

Business decision: Whether to expand a retention offer to mid-tenure subscribers.

Research question: Which mid-tenure segments show elevated voluntary churn risk that is actionable with the current offer catalog?

Approach highlights:

1. Align retention VP and CRM data owner on definitions of voluntary churn and mid-tenure.
2. Source 12 months of subscription, support, and offer history; profile completeness.
3. Descriptive baselines by segment; diagnostic comparison of churned vs retained; only then evaluate a simple propensity model if data supports it.
4. Interpret with cost-to-serve and offer constraints; package options for a decision workshop.
5. Influence: recommend pilot segments, success metrics, and what not to claim.

Roles: BA facilitates question and decision workshop; analyst runs profiling and models; engineer secures extract; owner prioritizes segments and budget.

Style: Two-week planned spine with mid-cycle demos (hybrid).

If a critical assumption fails (no offer history), the plan re-scopes to diagnostic churn drivers without offer-effectiveness claims—rather than pretending the original question is still answerable.

CBDA exam habits for approach planning

• Prefer options that sequence work from question to decision, not tool-first leaps.
• Prefer stakeholder approval of the research question when conflict or ambiguity is present.
• Prefer role collaboration over single-hero analysis.
• Prefer method fit (often simpler) over advanced techniques that ignore constraints.
• Prefer explicit iteration when evidence invalidates the question—not silent continuation.