Stop Commissioning a New Dashboard for Every Question

A new page for every question is how you get sprawl. It feels like service. It is demand with no intake.

Mid-market leaders get a Slack ping, a hallway ask, a board follow-up. Someone commissions a dashboard, and a week later there is another pbix. The original question was one filter on a model you already had, or should have had. You funded a brochure and underfunded the product.

This is intake, not the cleanup of last year’s files

Dashboard sprawl is a tax deals with the estate you already have: inventory, certify, retire. This piece is about how the next file gets born. It is demand management, and it decides who may turn a question into a build.

If you only retire, the hose is still on. If you only freeze publishing, questions move to email, and you have installed a backlog in the inbox.

The searches are real: “too many dashboard requests,” “Power BI intake process.” People are not asking for a portal. They are asking how to stop saying yes to a page every time a VP gets curious.

The first test is whether the question supports a decision at all. This post is the operating rule after that test. Recurring questions go to the model. One-offs do not get a workspace.

How a question becomes a file

Someone needs a cut by region, product line, or week. The certified app does not have that slicer, or nobody looked. A builder copies a report, publishes it, and the question is answered once.

Next month the question returns with a different week. The copy is stale, so someone makes another. Now you have three brochures and one unmet product need: a dimension and a measure with an owner.

Self-service was supposed to mean exploring on the model. Commissioning a dashboard means exploring by fork. Forks are how every team builds their own model when the ask is big, and how sprawl returns when the ask is small.

IT feels this as a ticket queue, as covered in the hidden cost of waiting on IT. The wait is real, and so is the reflex to skip the queue with a side file. Both are intake failures.

What a page-per-question policy costs

1. You pay for answers that cannot be reused. A one-off page does not accumulate, so the next similar question starts at zero. The model would have compounded. The brochure does not.

2. Builders never get to the product. Every sprint is a new canvas and grain never settles. The semantic model is the product, and if funding follows pages, the product starves. You end up rebuilding the same report every quarter.

3. The official app gets quieter. Leadership cannot find the number because the last answer lived in a side workspace named after a person. Adoption falls, they commission another page, and the loop feeds itself.

4. No one can say no, so nothing gets done. A program without cuts is a queue, which is why analytics programs fail in delivery. Each yes is polite, and the certified measure slips another month.

5. Questions that should stay ad-hoc become assets. A board follow-up is not a product. Treating it like one creates a report that must refresh forever. Capacity groans, ghosts pile up, and then you buy headroom instead of a rule.

6. Finance inherits twins it will not sign. Extra pages carry drifting filters, the controller sees a total that does not tie, and finance refuses the whole app. Sign-off is a feature, and intake that bypasses the steward is how you earn that refusal.

What not to do

Do not stand up a request portal that still ships a dashboard for every ticket. A form is not a policy. The policy is model first, and a page only if the question is recurring and owned.

Do not make executives wait two months to slice a certified model. That is how they commission a rebel file. Self-service on the official model is the release valve. Self-service as a new dataset is the leak.

Do not use inventory as a substitute for intake. Cleaning up last year’s mess without a rule for how work enters is a one-time hero project.

Do not measure the BI team on tickets closed. Measure it on certified measures in use, and on requests answered without a new file.

How to fund the model and starve the one-off page

1. Install one intake path. Every ask hits the same backlog with the requester, the decision, whether it already exists on the model, and whether it recurs. Shadow commissions are how sprawl returns. If a VP can spin up a workspace without that card, you do not have a program. You have a suggestion box with licenses.

2. Triage into three buckets, out loud. Already in the app means train, bookmark, and stop. Model change means a new grain, measure, or dimension, with a steward. Working paper means Excel or a sandbox connected to the model, with no official stamp and no 6 a.m. SLA. Most hallway questions land in bucket one or three, and they stop becoming pages once you say so.

3. Answer from the model before you open Desktop. Ask whether a filter, field, or measure on the certified semantic model can settle it. If yes, do that and publish nothing new. Ask the model instead of screenshotting a one-off. If the model cannot answer because the grain is wrong, that is a product backlog item, not a new canvas.

4. Require a steward for anything that will refresh twice. A page that must live needs an owner who can freeze the definition. No steward means no schedule, and that rule alone kills vanity dashboards. It is the same ownership split as a project with no owner.

5. Time-box one-offs and do not promote them by default. A sandbox report can live for one board cycle and then expire. Promotion to the app is a decision that requires the question to be recurring, signed, and tied out. The first ninety days should prove this loop in one domain before you scale intake theater.

6. Review demand like a PMO, not a help desk. Rank requests against the P&L, cut, and publish the no’s. Change leadership is part of the work, as in data project management. If the backlog is only pages, rewrite it as products. Strategy without cuts needs a roadmap that names decisions, not a longer wish list.

Start where the hose is worst: one VP and one standing meeting. Prove that questions can be answered with a filter.

What good looks like

The ELT still asks sharp questions. It gets answers from the app the same day, a dated working paper, or a date for a model change. It does not get a new workspace by default.

Builders spend more time on grain than on themes. The certified set stays short, sandboxes are labeled, and expiration is real. When sprawl creeps back, you have a retire list and an intake rule. Cleanup without demand management is a season. Intake is the climate.

If your backlog is a list of dashboards, you are taking orders. If it is a list of model changes and refusals, you are running a program.

Frequently asked questions

Won’t this slow us down? It slows the first yes. It speeds up the tenth question.

What do we do with true one-offs? Answer them, in Excel connected to the model or in a sandbox with an expiry. Do not put them on the 6 a.m. refresh the close depends on.

How is this different from dashboard sprawl? Sprawl is the inventory you already have. This is the tap. Retire without intake and you will write that post again next year.

Get started

Fund the model, put every ask through one intake, and answer from the product you already paid for.

Want to know which requests should never become a file? Book a session with Alluvium. We will sort the backlog into model changes, working paper, and no. To check the model those answers depend on, request a free Model Health check.