How to Run a BI Requirements Workshop That Kills Dashboard Bloat

The Dashboard Graveyard and Why Discovery Fails

Every enterprise data team has built dashboards that nobody uses. An executive requests a custom reporting view, the data engineering team spends three weeks writing complex SQL transformations, the BI developer builds a 12-tab report with 18 dynamic filters, and after two weeks of active use, engagement drops to zero.

This failure mode rarely stems from bad data engineering or ugly visualization. It stems from broken requirement gathering. When data teams conduct discovery by asking stakeholders, "What metrics do you want to see?" the answer is inevitably a bloated wish-list. Department heads request every conceivable slice of data because they do not know what they will need six months from now.

To build business intelligence assets that endure, you must invert the discovery process. Instead of asking what reports users want, you must conduct a decision-centric discovery workshop. During our Systems Audit & Blueprint engagement, we run this exact process to map legacy reporting demands directly to operational workflows before writing a single line of dbt code or building a single semantic layer model.

Phase 1: Pre-Workshop Inventory and Query Extraction

Never start a requirement workshop with a blank whiteboard. Before sitting down with business leaders, audit their existing reporting artifacts. This includes scheduled Excel dumps sent via email, ad-hoc SQL queries saved on analyst laptops, and active queries hit against your data warehouse.

What to Audit Before the Meeting

• Ad-Hoc Query Logs: Extract the top 50 executed queries from your warehouse query logs for that specific department over the last 90 days. Identify which tables are joined most frequently.
• Shadow Spreadsheet Audits: Request the exact Excel workbooks department managers use for weekly operational reviews. Look for calculated columns, VLOOKUPs, and manual overrides; these manual edits highlight gaps where existing warehouse metrics fail them.
• Export Frequency: Track which existing dashboard visuals have the highest "Export to CSV" rates. High export volume is a primary signal that the current visualization fails to answer their operational questions directly.

Phase 2: The Decision Isolation Framework

Once you enter the room with business stakeholders, establish one rule: conversation about chart types, colors, and layout is banned. The entire first hour must focus strictly on business operations and decisions.

Structure the session using the Decision Isolation Framework. Ask the department head or business operational lead to walk through their past business week using three explicit prompt vectors:

1. The Monday Morning Trigger

Ask: "What is the very first operational metric you look at on Monday morning to determine if your unit is on track?" If they name a vague metric like "Total Sales," push deeper. Do they mean net recognized revenue, billed invoice amount, or booked orders? Force a precise definition.

2. The Interventions

Ask: "If that metric drops by 15% below baseline, what precise decision do you take? Whom do you call, and what action do you instruct them to execute?" If the metric dropping does not lead to a concrete business action, that metric belongs in a background audit log, not on a primary operational dashboard.

3. The Missing Variable

Ask: "Think back to a recent bad decision or missed operational target. What specific piece of information was missing when you made that call?" This reveals hidden data dependencies, such as un-modeled inventory stockouts or delayed payment settlement feeds from payment gateways.

Phase 3: Mapping Decisions to Metric Trees

Once you have a list of core operational decisions, convert them into a decision tree mapped to technical data inputs. A properly structured metric tree connects high-level business goals down to atomic schema columns.

For example, if the core decision is whether to approve discounting for a mid-market enterprise account, the required metric is net operational margin per client. To derive net operational margin, your semantic layer needs four specific inputs: gross invoice amount, variable delivery cost, channel acquisition fee, and tax liabilities.

Document this mapping in a simple shared matrix with four explicit columns:

• Operational Decision: Should field sales grant a custom payment schedule?
• Primary Metric Required: Customer Outstanding Days Sales Inventory (DSI) and Historical Default Rate.
• Underlying Data Sources: ERP Billing Tables, Bank Reconciliation Feeds.
• Refresh SLA Required: Daily at 06:00 IST (Real-time streaming is not required if decisions occur once weekly).

Phase 4: Integrating AI Copilots into Requirements Synthesis

Modern requirements gathering does not stop when the workshop room clears. Enterprise analytics teams now leverage local LLMs and AI coding tools to accelerate the translation of workshop transcripts into technical specifications.

By feeding raw workshop audio transcripts and notes into structured prompts, you can auto-generate draft metric definitions that adhere to open standards like the dbt Semantic Layer specification. This eliminates manual conversion overhead and establishes a clear lineage from business conversation to version-controlled YAML files.

We use AI models during this stage for three distinct tasks:

• Ambiguity Detection: Flagging instances where two different business leads used the same term (e.g., "Active Customer") to mean entirely different things (e.g., paid subscription vs logged-in user).
• Schema Draft Generation: Mapping spoken metric formulas directly into SQL expressions and dbt semantic metric structures.
• Gap Identification: Highlighting required metric attributes that lack an underlying source table in the production data catalog.

Phase 5: Sign-Off and the Minimum Viable Metric Set

Conclude the discovery cycle by establishing a strict Scope Freeze Document. Present the business team with a single-page specification containing no more than five core operational metrics for the initial release.

Categorize every other requested metric into a secondary tier. If a metric does not directly inform one of the documented weekly decisions, it is relegated to ad-hoc query access rather than taking up real estate on the core dashboard screen.

By enforcing this decision-driven requirements methodology, you transform BI delivery from an endless queue of ticket requests into an engineering workflow that delivers measurable business ROI.

When you ask a department head what dashboard they want, they will describe every report they have seen in the last decade. When you ask what decision they were unable to make last Tuesday, they give you an engineering spec.