The Short Version
When you describe your data to us during scoping, we're working from your understanding of it. When we connect to your system for the first time, we see how it actually lives technically. Those two things are often different -- and that gap isn't a mistake by either party. It's a structural challenge in every software implementation, and it's worth explaining why.
What Happens During Scoping
Before we start your implementation, we hold discovery sessions to understand what data you need, where it lives, and what it should look like in Cube. You tell us something like:
"We need our headcount data. It's in Microsoft Fabric."
That's a clear, reasonable answer. Based on it, we scope the connection as a single table pull -- which is the simplest, fastest path to getting your data into Cube.
The problem is: that's your view of the data, not the system's view.
How Systems Actually Store Data
Most modern data warehouses -- including Microsoft Fabric, Snowflake, BigQuery, and others -- don't store data the way it appears in the reports and dashboards you're used to seeing. What looks like a single clean table in your BI tool or spreadsheet is almost always the result of multiple underlying tables being combined behind the scenes by a query someone wrote years ago.
Here's a simplified example:
| What you see | What the system stores |
| "Headcount by Department" | Employee table + Department table + Cost Center table, joined by employee ID and org code |
| "Revenue by Region" | Orders table + Territory mapping table + Customer table |
| "Budget vs. Actuals" | Actuals from the GL + Budget entries from a separate planning table |
The presentation layer you're familiar with is a finished product. The raw data warehouse is the kitchen.
Why We Can't Always Know This Upfront
You might reasonably ask: why didn't we ask the right questions during scoping to catch this?
The answer is that this information isn't discoverable until we have direct access to your system -- and often, the people we're working with during scoping don't have that visibility either.
This isn't a gap in preparation. It's the nature of enterprise data architecture. In most organizations:
- The person who can describe what data exists (a finance leader, a department head) is not the same person who built the underlying tables
- The person who built the underlying tables may no longer be at the company
- The documentation of how those tables relate to each other is frequently incomplete or nonexistent
- Business-facing tools like Power BI or Excel often sit on top of a data model that was built by a contractor, a data engineer, or an IT team years ago with no handoff documentation
Until we're in the system, we are working from the same mental model you are.
What Changes When We Get Access
Once we establish a live connection to your warehouse, our team can see the actual structure: the table names, the fields, the relationships, and what queries are needed to reconstruct the dataset you described.
When the data turns out to span three tables instead of one, a few things have to happen:
- We identify the correct tables and map how they relate to each other
- A query (usually a SQL JOIN) needs to be written to pull those tables together into a usable dataset
- Someone on your side needs to validate or write that query, because it lives in your system and reflects your data model -- we can guide you, but we can't author logic that depends on business rules only your team knows
This is the moment where scope expands, timelines shift, and frustration is highest. We understand that. It feels like something we should have caught sooner.
Why This Is Genuinely Hard to Predict
The reason this comes as a surprise -- even to experienced implementation teams -- is that data warehouses are designed to be flexible, not self-documenting. Unlike a SaaS system with a known schema, a warehouse like Fabric or Snowflake can be structured in hundreds of different ways depending on the decisions made when the data was loaded.
There is no standardized way a company's headcount data "should" look in Fabric. Every organization's instance is unique. The only way to know what's inside is to look inside -- and looking inside requires access, which only happens after scoping is complete.
This is true across the industry. Every FP&A implementation team encounters this challenge. It's not a solvable problem during the sales process; it's a discovery problem that becomes visible during build.
How We Try to Minimize the Impact
When we hit this situation, our goal is to move as quickly as possible and create as little disruption as possible. That means:
- Clearly explaining what we found and why scope needs to expand
- Identifying the smallest viable path forward (often a pre-built query you can copy/paste)
- Working with your team to get the right technical stakeholder looped in
- Keeping the rest of the implementation moving in parallel while the query piece gets resolved
We want to be your partner in solving this -- not a source of surprise work.
What You Can Do to Help Reduce This Risk
If you're heading into an implementation and want to reduce the likelihood of mid-project scope changes, a few things help:
- Involve your IT or data engineering team early -- even if they're not the primary stakeholder, having them in discovery calls can surface these issues before contracts are signed
- Ask for table-level access before scoping is finalized -- if we can do a brief technical pre-assessment of your warehouse, we can often catch multi-table scenarios in advance
- Share any existing reports or dashboards and ask whether those are pulling from raw tables or from a transformed data layer
None of these are guarantees -- but they close the gap significantly.
The Bottom Line
When scope expands mid-implementation, it's not because we missed something we should have known. It's because the data architecture inside your system is only visible once we're inside your system -- and that architecture is almost never as simple as the reports it powers. We consult with you throughout the process because your team holds the business context that no technical team can infer from a schema alone.
We take pride in getting your data right. And getting it right sometimes means navigating complexity we couldn't have anticipated from the outside.
Have questions about your specific implementation? Reach out to your Implementation Manager or contact support@cubesoftware.com.