How to prepare a dashboard project before hiring

1. Start with the decisions

List the decisions the dashboard should support. A sales manager may need to see which products are slipping this week. An owner may want to know whether cash will last the quarter. A marketer may want to compare channels by cost per customer. Write each decision as a question: what do we sell most, where are we losing customers, are we on target? Questions keep the dashboard focused on action instead of decoration.

2. Choose the key measures

For each question, pick the measure that answers it and the comparison that gives it meaning: last month, the same month last year or a target. Aim for a small number of headline figures, with detail available underneath. If everything is highlighted, nothing stands out. Define each measure precisely, because terms like revenue, active customer or conversion can mean different things in different teams.

3. List the data sources

Write down where the numbers live: spreadsheets, an online shop, an accounting tool, advertising platforms, a customer database or analytics software. Note who owns each source, how clean it is and how often it changes. Say whether data can be connected automatically or must be exported by hand. The more sources and the messier they are, the more time the project will take.

4. Know who will use it

Describe the people who will open the dashboard and how: on a laptop in meetings, on a phone while traveling or on a large screen in an office. Executives usually want a short summary, while analysts want filters and detail. Consider whether different people should see different data, since some information may need restricted access.

5. Pick the tool and access

Choose a tool your team can open and, ideally, maintain. Check licenses and costs, since some tools charge per user. Create or confirm the accounts in your own name and decide how the specialist will access data safely. Prefer read-only access where possible and avoid sharing passwords; use the permission features of each platform instead.

6. Think about design and updates

Ask for a simple layout with clear titles, consistent colors and honest charts. Share any brand colors or examples of dashboards you like. Agree how the dashboard will be refreshed and who will fix it when a data source changes. Request documentation that explains where each number comes from, so you can trust it and so someone else can maintain it later.

Questions to ask the specialist

• Have you built dashboards from sources like mine?
• How will you check that the numbers match my existing reports?
• How is data refreshed, and what happens if a connection breaks?
• What documentation and training are included?
• Who owns the finished files and accounts?
• How many revision rounds are included?

Budget and timing

A simple dashboard from one clean source is quick, while one that combines several messy sources takes much longer. Ask for a first version with a few key charts before the full build, so that you can react to real numbers early. Keep some budget for adjustments after people start using it, because the first week of real use always reveals what is missing and what is noise.

Rolling it out to your team

A dashboard only helps if people use it. Introduce it in a short session, explain what each number means and show where to click for detail. Decide who checks it and when, for example in the Monday meeting. Collect feedback after a couple of weeks and ask the specialist for a small round of improvements. Remove charts nobody looks at; a smaller dashboard that people trust beats a large one they ignore.

Common mistakes

• Showing everything instead of the few measures that matter.
• Using terms that mean different things to different people.
• Skipping a check against figures you already trust.
• Building something nobody has time to keep updated.