How do you gather requirements for a new dashboard?
The main risk in BI work is building something technically correct that nobody uses, so show that you interrogate the request.
- Start with the decision, not the fields. Ask what action they would take differently depending on what the report shows. If there is no answer, the report has no purpose and you should say so early.
- Identify the audience precisely. An executive summary, an operational monitor, and an analytical exploration tool are three different products. Trying to serve all three in one report produces something that serves none.
- Agree definitions in writing. "Active customer" and "revenue" mean different things to different departments, and a disagreement discovered after launch destroys trust in the whole report.
- Establish granularity and refresh frequency. Real-time is expensive and usually unnecessary — ask what decision requires it.
- Check the data exists before promising anything. This is where most requirements gathering fails.
Note: Mentioning that you build a rough mock-up early and iterate is a strong point. People cannot specify a dashboard in the abstract, but they can react to one immediately.





