Three projects. None of them failed on the technology. All five mistakes below showed up in more than one of them.
Fabric Lab · Issue 09 · By Dave Goyal
Three mid-market Fabric projects I have direct knowledge of quietly stalled or were shelved in the first quarter of this year. None of them were killed by a Microsoft product limitation. Names removed, details generalized enough that no one project is identifiable, but the five mistakes below are real and repeated across all three.
The Five
1. Nobody owned the semantic model. Two or three teams built overlapping definitions of the same metric before anyone noticed. By the time it surfaced, the fix required renegotiating whose number was “right,” which is a political problem dressed as a technical one.
2. The license and capacity math was never modeled past the pilot. A ten-user pilot ran fine on a small SKU. Nobody projected what happened at two hundred users before the rollout committed to a timeline the capacity could not support without a mid-project renegotiation.
3. The data readiness gap was discovered after the AI use case was already promised to the board. The Copilot or agent use case got announced before anyone confirmed the underlying master data could support it. Walking back a board commitment costs more credibility than the delay would have.
4. One person held all the pipeline knowledge, and left. A single engineer built and understood the Data Factory pipelines. When that person moved on, the project effectively stalled until someone could reverse-engineer what had been built, sometimes for weeks.
5. Governance was scheduled for “after we prove value.” Sensible in theory. In practice, “after” never arrived, workspace sprawl set in early, and the eventual governance retrofit cost more than building it in from the start would have.
What These Five Have In Common
Every one of them is a sequencing mistake, not a capability gap. Fabric could have supported all three projects. What was missing was the boring, unglamorous discipline of assigning ownership, modeling the real numbers, and building governance in from day one instead of promising it later.
This is the same pattern behind the ten boring projects worth shipping before touching Copilot. The unglamorous work is not optional groundwork. It is the actual project.
What This Means For You
If your current Fabric project has no single owner for the semantic model, fix that this week, not after the next incident forces it.
If your pilot’s capacity math has not been re-run at your real target user count, do that before you commit a rollout date to leadership.
If your AI use case has already been promised to the board before data readiness was confirmed, that is a hard conversation worth having now rather than at the missed deadline.
If your pipeline knowledge lives in one person’s head, document it this month. It costs an afternoon now or weeks of stalled work later.
If governance is scheduled for “after,” move it earlier. The retrofit always costs more than the upfront build.
The One Ask
If you want a second set of eyes on which of these five is quietly present in your own project, reply here or DM. No pitch, a real read on where the risk sits.
Which of the five have you seen firsthand? Tell me in the comments.
I read every reply.
Sources
- Patterns observed across client and prospect Fabric project reviews conducted by Think AI Consulting Corporation in 2026; all project details generalized and anonymized, no single project is identifiable.
Dave Goyal
Founder, Think AI Consulting Corporation
Host, The Think AI Podcast
New here? I write Data and AI Demystified, the hidden costs and reality checks on Microsoft Fabric most partners won’t publish. Subscribe here.
Click here to read Dave’s Demystify Data and AI newsletter on LinkedIn.