The business says "we need a dashboard" and gives you a three-week deadline. Walk me through what you do first.

Do not start by asking what they want on it

A request for a dashboard is a solution somebody has already chosen, so the first job is to recover the problem it was chosen for. If you open with what charts they would like, you will get a list, you will build the list, and in three months it will be open in nobody's browser because a chart nobody acts on is decoration.

So the opening question is about action, and it is worth asking almost literally: when you look at this on a Monday morning and the number is bad, what will you do differently? A good answer sounds like "I would move two people onto the exceptions queue" or "I would call the supplier whose rejection rate is worst". A vague answer — "we would have visibility" — tells you the decision has not been identified yet, and identifying it is now the work. Visibility is not a requirement; it is the feeling somebody has when a decision they already make gets easier.

What to listen for in the first conversation

Alongside the decision, four things are worth extracting before you leave the room. Who will open it, how often, and in what setting — a screen glanced at daily by a team leader is a different artefact from a monthly pack a director takes to an executive meeting. What they do today instead, because there is nearly always a spreadsheet, and that spreadsheet is the best requirements document available to you. What triggered the request now, since a dashboard request rarely arrives spontaneously: something went wrong, or somebody was asked a question they could not answer. And who else will read the numbers, because a figure that leaves the department will be challenged by whoever owns the source system.

The trigger is the highest-value question of the four. "The regulator asked us for our complaint-handling times and it took us four days to answer" is a completely different brief from "the new director wants to see the operation", and the second is far harder to satisfy because there is no test for done.

Pin the words down before designing anything

Every metric contains at least one word that two people in the business define differently, and the deadline dies on those words rather than on the build. Write the definitions out and get them agreed in writing. A table like this takes an afternoon and pays for itself repeatedly.

Metric      Active corporate customer
Definition  Customer with at least one posted transaction in the trailing 30 days,
            excluding internal transfers and reversals
Grain       One row per customer per day; dashboard shows the daily count
Source      core.transactions (posted date, not value date), core.customer
Excludes    Accounts in closure, staff accounts, test customers (flag = Y)
Refresh     Overnight batch, available by 07:00; not intraday
Owner       Head of Corporate Sales agrees the definition; Data owns the source
Decision    Whether to trigger the dormancy outreach campaign this week
Known gap   Reversals are only flagged from Nov 2024; earlier trend overstates by
            an unmeasured amount

Two lines in there are the ones that stop a late argument. Posted date rather than value date will change the number, and somebody will notice. And a stated known gap in the historical trend means the comparison to last year is caveated on the dashboard rather than defended in a meeting.

Check the data before promising the picture

Now go to the data, early, and personally if you can. Query the source and see whether the field exists, whether it is populated, at what grain, from what date, and whether it agrees with the spreadsheet the business currently trusts. If it disagrees, you have found the real project, because reconciling a new number with the number people already believe is usually a larger piece of work than presenting either.

This step is what converts the deadline from a hope into a plan. Data that exists, is clean and is already in the warehouse makes three weeks generous. Data that requires a new feed from a supplier, or a field that operations have been filling in inconsistently, makes three weeks impossible no matter how the charts are drawn — and knowing that on day two is worth more than any amount of design.

Interrogate the date before accepting the scope

Ask what the deadline is attached to. A board meeting, an audit response, a regulatory submission, a campaign launch and a new director's second week are five different constraints. A fixed external event means the date is genuinely immovable and the scope must move, which is a straightforward conversation once you say it plainly. A date with nothing behind it is usually a proxy for impatience and can be renegotiated on evidence. Either way, establish what specific thing must be possible on that date — often it is one number for one audience, in which case the first release is small and the rest is a roadmap.

Then be explicit about the exchange, because this is the point candidates skip: accepting a date before agreeing what is delivered on it means you have accepted an unbounded commitment. Fix the date and fix the scope in the same sentence, in writing.

What you take back at the end of two days

The output of the first two days is not a design. It is a one-page note that the requester can correct, containing the decision the dashboard supports and who makes it, the two or three metrics with their agreed definitions, the source and refresh for each, what is in scope for the date and what is explicitly deferred, the assumptions you are proceeding on, and the risks you found in the data. Send it, ask for a reply confirming it, and start building against it.

If the requester reads that note and says the decision is wrong, you have saved three weeks. If they cannot say what decision it supports even after seeing it written down, escalate that as the finding rather than building anyway. A dashboard commissioned with no decision attached is one that will be quietly abandoned, and being the analyst who says so early is more valuable than being the one who delivered on time.