Scope, Assumptions, Constraints, Dependencies

Scope, Assumptions, Constraints, Dependencies

Quick Answer: Before you refine research questions or pull data, CBDA Domain 1 expects you to define what the analytics effort will and will not cover, what you are assuming will be true, what limits you must work within, and who or what the work depends on. Confusing these four concepts is a frequent reason candidates pick the wrong next step in scenario questions.

After you frame the business problem and current state (covered in the previous Domain 1 chapter), you still should not jump straight into dashboards or models. The CBDA competencies treat scoping and planning hygiene as part of Identify the Research Questions (about 20% of the exam). Scope without assumptions becomes fiction; assumptions without constraints become overpromise; constraints without dependencies leave you blocked at the first data request.

Why scope comes before “more analysis”

Scope is the agreed boundary of the analytics effort: the business outcomes in focus, the population or process included, the time horizon, the decision the work will support, and the work products expected. Scope answers questions such as:

• Which customer segments, products, regions, or channels are included?
• What time period is in bounds (last 90 days, last fiscal year, post-policy change only)?
• Which outcomes matter (churn, cycle time, claim denial rate, conversion)?
• What decisions will the results inform—and which decisions are out of scope for this effort?
• What level of rigor is required (directional insight for a pilot vs. defensible evidence for a board decision)?

In-scope items are those the team commits to analyze or support. Out-of-scope items are deliberately deferred or excluded so stakeholders do not expect them later. On the CBDA exam, good answers often narrow an over-broad request (“analyze all data to improve the business”) into a measurable, time-bounded effort tied to a decision.

Example scope statement (retail churn)

In scope: Identify factors associated with voluntary churn among online subscribers in the U.S. over the past 12 months; produce a ranked driver list and a short recommendation brief for the retention VP.

Out of scope: Building a real-time scoring service, redesigning pricing, analyzing international markets, and predicting next-quarter revenue for finance planning.

Notice what this statement does not do: it does not pick algorithms yet, and it does not claim that every data source is ready. It only locks the boundary of the effort so later technique choices stay honest.

Assumptions: beliefs treated as true (for now)

An assumption is something you treat as true for planning purposes even though it is not fully verified. Common analytics assumptions include:

• Data availability: “Customer-level churn flags exist and are complete for the last year.”
• Data quality: “Product IDs match between CRM and billing.”
• Stakeholder access: “The retention VP will attend a 60-minute interpretation workshop.”
• Time and capacity: “The BA and analyst can dedicate three weeks of calendar time.”
• Process stability: “The definition of ‘active subscriber’ did not change mid-year.”
• Decision readiness: “Leadership is willing to act on evidence if confidence is reasonable.”

Assumptions are not free—they create risk. A CBDA-ready practice is to list assumptions explicitly, assign an owner to validate critical ones early, and revise scope if a key assumption fails. On scenario items, if a stakeholder “assumes” data will appear next week without checking the data owner, the best action is usually to validate or time-box the assumption, not to build a complex model on hope.

Constraints: hard limits you must design around

A constraint is a real limit that restricts options. Unlike assumptions, constraints are typically known or imposed rather than hoped for:

• Budget and tools: no license for a commercial ML platform; must use approved warehouse SQL.
• Privacy and regulation: PII masking required; cannot export raw health or payment data to personal laptops.
• Systems access: read-only warehouse access; no production write rights; batch jobs only overnight.
• Calendar: decision meeting is in 10 business days—analysis depth must fit that window.
• Policy: external data purchase requires legal review that takes 30 days (so external enrichment is off the table for this cycle).
• Skill and staffing: no dedicated data scientist on the roster this quarter.

Constraints shape approach, not just schedule. A privacy constraint may force aggregate reporting. A 10-day decision window may force descriptive and diagnostic work instead of multi-model predictive experimentation. Exam scenarios often plant a constraint in the stem; the correct choice respects that constraint rather than ignoring it for a “best practice” that cannot be executed.

Dependencies: external things the work needs

A dependency is something outside the analytics team’s direct control that the effort needs to progress:

• Upstream systems that generate or land the data (POS, claims adjudication, LMS).
• Data owners who must approve extracts or explain field definitions.
• Subject-matter experts (SMEs) who define “defect,” “qualified lead,” or “resolved ticket.”
• Governance or security reviews that unlock access.
• Prior projects whose data dictionary or feature store the team plans to reuse.
• Business decisions that must land first (for example, “which product line is strategic?”).

Dependencies create sequence. If the claims SME cannot define denial reason codes until week three, diagnostic analysis of “why denials rose” cannot honestly finish in week two. CBDA thinking links dependencies to the analytics approach plan: you surface them early, negotiate SLAs, and design parallel work where possible (for example, profile open datasets while waiting for a restricted extract).

Assumption vs constraint vs dependency (CBDA examples)

Use this table when a scenario blurs language. “We only have two weeks” is usually a constraint. “We believe the data warehouse has two years of clean history” is an assumption. “We need the finance data steward’s sign-off” is a dependency. “We will not redesign the website” is out of scope.

How undocumented assumptions create exam traps

CBDA scenarios rarely say “the assumption is wrong.” They show symptoms of undocumented assumptions:

1. Silent data hope: A sponsor asks for next-quarter demand forecasts. The team starts modeling without confirming whether item-level sales history exists for new SKUs. Trap answer: dive into advanced forecasting. Better answer: validate data availability and adjust the research question (for example, forecast only mature SKUs; treat new SKUs separately).

2. Definition drift: Operations “assumes” ticket reopen rate means the same thing across regions. Analysis ranks regions; leadership argues definitions. Trap answer: present the ranking as final truth. Better answer: surface definition as an assumption, align SMEs, then re-run.

3. Access optimism: The plan assumes the BA can interview five regional managers this week. Three are unavailable. Trap answer: proceed with whatever opinions are handy and treat them as representative. Better answer: revise stakeholder sample, document bias risk, and constrain claims.

4. Constraint disguised as preference: Legal requires aggregation. A teammate wants customer-level risk scores for a pilot. Trap answer: ship the scores “just for internal use.” Better answer: redesign deliverables inside the constraint or escalate for an approved path.

5. Hidden dependency: Marketing wants competitive pricing analytics but the competitive feed is owned by a vendor with a 45-day onboarding. Trap answer: promise competitive analysis this sprint. Better answer: re-scope to internal price elasticity first; place competitive data as a future dependency.

Practical documentation checklist

For Domain 1 scoping, a lightweight artifact is enough for most CBDA scenarios:

• Scope statement (in / out / decision supported).
• Assumption log (assumption, owner, validation method, due date, impact if false).
• Constraint list (source of constraint, design implication).
• Dependency map (what, who, when needed, fallback).
• Change rule: how scope changes are approved when assumptions fail.

You do not need enterprise PMO theater. You need enough clarity that a second analyst could continue the work without inventing the boundaries.

Linking scope hygiene to later domains

Scope, assumptions, constraints, and dependencies are not only “project management.” They protect later CBDA domains:

• Source Data: dependencies and constraints determine which sources are realistic.
• Analyze Data: constraints and assumptions drive model simplicity and sampling choices.
• Interpret and Report: out-of-scope claims must not sneak into storytelling.
• Influence Decisions: stakeholders trust recommendations more when limits are transparent.
• Org strategy: repeated assumption failures signal maturity and governance gaps (Domain 6)—but you still document them in Domain 1 framing for the current effort.

CBDA exam habits for this topic

When a stem describes a messy request, ask:

1. What decision is this analytics effort supposed to support?
2. What is clearly in vs out?
3. Which statements are assumptions that need validation?
4. Which limits are constraints that redesign the approach?
5. What dependencies gate progress?

Pick the option that clarifies boundaries, validates critical unknowns early, and respects real limits—not the option that sounds most technically sophisticated.