The BI Workflow

• Run a structured BI discovery: question → metric → model → report
• Turn vague requests ('I need a dashboard') into testable requirements
• Introduce review and iteration so reports get used, not abandoned

• Most dashboard failures are requirement failures: a beautiful chart answering the wrong question.
• Nailing the metric definition up front avoids rework across model, report and consumers.
• Review loops keep reports alive; delivered-and-forgotten dashboards rot into noise.
• A named owner and a refresh SLA turn a one-time artifact into live infrastructure.

You don't pour a foundation before knowing room count and who lives there. BI reports need the same up-front discovery, then a build, then — unlike a house — continuous remodeling as questions change.

• Discovery: capture the decision, the user, the cadence and the question in plain words.
• Define the metric precisely: numerator, denominator, filters, grain, timezone and caveats.
• Verify the data: can the modeled layer produce it? If not, model first.
• Prototype and build: sketch the visual, validate against known values, test edge cases.
• Deliver: publish with refresh schedule, row-level security, and an owner.
• Review: check usage, gather feedback and iterate or retire the report on a set cadence.

• A sales director wants a 'pipeline health' dashboard. Discovery reveals the real decision is forecast accuracy, so the team defines pipeline-to-forecast conversion rather than a pipeline bar chart.
• A finance team requests 'costs'; the workflow surfaces three separate definitions (COGS vs opex vs run-rate), and the report is rebuilt around the one they can actually action.
• Post-launch, usage analytics show the report has 3 weekly viewers; the team interviews one and simplifies it to a single actionable page.

• Write a one-line decision statement before any chart: 'This lets {user} decide {what} every {cadence}'.
• Define metrics as equations with named filters so nobody infers the numerator.
• Validate against a hand-computed sample before publishing; never ship an unverified number.
• Book a 30-day review: usage is the only honest quality metric for a report.

• Skipping discovery and building to the literal request — 'dashboard' means ten different things.
• Defining the metric in the report instead of the model, so the next report forks it.
• Publishing without a refresh SLA or owner, leaving the report to go stale silently.
• Iterating forever without shipping; a good-enough live report beats a perfect draft.

• If feedback says 'numbers feel wrong', validate the metric against a manual or source-level calculation.
• If nobody opens the report at review time, interview one user before adding features.
• If two consumers interpret the same number differently, tighten the metric's definition and documentation.
• When scope balloons, re-read the decision statement and cut anything that doesn't serve it.