Requesting a new report or dashboard from your IT team: the question it answers, who uses it and when it is retired

A manager writes to the IT team: "Can we get a dashboard with sales by region?" Two weeks later it exists. It looks good in the first meeting. A month later nobody opens it, because the regions in it do not match the regions in the sales plan, and the numbers differ from the ones in the monthly spreadsheet.

This is the usual fate of reports requested as pictures. This article is for the owner or operations manager of a company with a small IT team or an outside developer, who wants requests that lead to reports people actually use.

Start with the question, not the chart

A chart is an answer. Before anyone builds it, write down the question in one sentence, in plain words:

• "Which customers have not ordered in 60 days, so that sales can call them this week?"
• "Are we on track to ship this month's orders on time?"
• "Which projects are running more than 10 percent over the planned hours?"

If you cannot finish the sentence "so that we can decide...", the report is not ready to be requested. Often the question turns out to be small enough for a saved filter in a tool you already own. That is a good result: it costs an hour, not a project.

Five facts to put in the request

A request that fits on half a page is enough. Ask for the same five things every time:

1. The question and the decision it supports.
2. The data source. Which system holds the numbers today, and who owns that system? If the data lives in three places, say so.
3. The reader and the rhythm. Who looks at it, how often (daily, weekly, monthly) and in which situation, for example in the Monday management meeting.
4. The definitions. What exactly counts as a "sale", a "late order" or an "active customer".
5. The end. When the report will be reviewed or switched off.

The developer may ask follow-up questions. That is the point of the half page: the questions are asked before the work, not after it.

Define each number once

Most disputes about reports are disputes about definitions. "Revenue" can mean invoiced, paid or ordered. "Customer" can mean a company or a contact person. "This month" can mean the calendar month or the last 30 days.

For every number in the report, write a one-line definition and keep it next to the report itself, ideally on the same page. A good test: a colleague who has not seen the request should be able to recalculate one value by hand from the source system and get the same result. If they cannot, the definition is not finished.

Also decide what happens with corrections. If an invoice is cancelled next week, does last month's figure change? Either answer is acceptable; having no answer is not.

Who uses it, and when

A report without a named reader has no one to complain when it breaks and no one to notice when it is wrong. Put a name on it, and a deputy.

Also fix the rhythm. A report read once a month does not need to refresh every five minutes, and a live view is usually more expensive to build and to keep running. Ask how fresh the data really needs to be. "Yesterday's close" is enough for most management questions. For a dashboard that supports daily operations, the reading moment matters more than the refresh speed: build it for the meeting or the shift where it will be looked at.

Decide the end before the beginning

Reports pile up the way access rights do: easy to add, never removed. Every one of them has a cost, because someone has to keep the data connection working, answer questions and fix it after a change in the source system.

Agree at the start on one of these:

• A review date. Three months after launch, the reader and the IT team look at whether it is still used and whether the question is still asked.
• A trigger for retirement. For example, "switch off if nobody has opened it for 60 days" or "when the old process it supports is replaced".
• A named owner who confirms every year that the report stays.

Switching a report off is not a failure. It is the sign that the question was answered or that the business has moved on. If you want a model of how few numbers a regular report really needs, the one-page monthly marketing report is a useful example of keeping it short.

What the IT team needs from you

• A sample. If the report replaces a spreadsheet, send the spreadsheet and mark the cells that matter.
• A test case. Give two or three known values, for example "March: 128 orders, 9 of them late", so the developer can check the result against something real.
• A single contact who answers questions within a day or two.
• Access rules. Say who may see which rows. Salary, margins or customer details may need to be hidden from some readers, and this is much easier to build in from the start.

Common mistakes

• Requesting a tool instead of a question. "We need a BI platform" is not a request. Describe the first report you need.
• One report for everyone. A report for the owner, the warehouse and the accountant ends up useful for nobody. Make one per reader group, or a short common core.
• Too many numbers. If the reader needs to ask "which of these matters?", cut it to the few that drive a decision.
• No test against reality. The first version should be compared with the existing figures before anyone relies on it.
• No review. A report that was never revisited is probably wrong in a place nobody looks at.

A short plan for this month

1. Take the last report you asked for and write its question in one sentence. If you cannot, mark it as a candidate for retirement.
2. Create a half-page request template with the five facts above and share it with your IT team or developer.
3. Ask for the next report with the template, including a test case and a review date.
4. Put the review date in the calendar for the named reader.
5. After three months, count how many reports are still opened. Keep those, retire the rest.

You do not need to rebuild your reporting at once. Applying the template to the next request is enough to see the difference.

Sources

• Practical guidance based on common small-business reporting and software-request practice, offered as a planning aid. The example questions, time limits and review rhythm are illustrations to adapt to your own company. No client results or performance figures are claimed in this article.