Dashboards & Reporting

What this covers

Dashboards give managers and elected officials a current picture of service delivery, budgets, and performance. HQT designs and builds reporting in tools such as Power BI, Tableau, and open-source alternatives, on top of a governed data platform.

Typical activities

• Requirements workshops with department heads and analysts
• Metric definitions with owners and calculation logic
• Dashboard design following accessibility and plain-language principles
• Row-level security so departments see their own data
• Scheduled distribution and alerting
• Performance management frameworks tied to strategic plans

What you receive

Published dashboards, a metric dictionary, security configuration, and a maintenance guide.

Considerations for public agencies

Public-facing dashboards must be accessible and must not expose personal information through small cell counts or overly granular maps. We design suppression and aggregation rules into public reports.

Signals that this work is due now

Agencies rarely set out to buy reporting. They notice symptoms first:

• Different departments give the governing body different figures for the same measure, and each can defend its own.
• The recurring performance packet is assembled by hand, and one analyst is the only person who knows the steps.
• A routine question from an elected official waits on a new extract before anyone can answer it.
• Dashboards exist, but managers keep private side spreadsheets they trust more.
• Records requests keep arriving for figures the agency could publish once and point to.

Each of these points at a definition or an ownership gap rather than a missing tool. A new visual built on an unsettled definition reproduces the same disagreement in a better looking format.

What a working implementation looks like, and how it fails

The properties are observable. Every figure traces to query logic a second analyst can read without the author present. Each view states the period it covers and when the data last refreshed. The dashboard replaces the manual packet instead of running beside it. Filters match how managers already think about the work, by division, fund, and fiscal period. At period close the figures reconcile to the system of record, and where they do not, the reason is written down.

Common failure modes:

• Calculation logic buried in individual visuals instead of a shared semantic model, so one measure drifts between views.
• A launch demonstration that goes well, attached to a refresh job nobody monitors.
• Access handled by hiding pages rather than by row-level rules, so an export reveals what the page hid.
• Public views nobody outside the publishing department can interpret, with no note on scope, exclusions, or reporting lag.

Fitting reporting to the systems and licensing you already have

Reporting capability already exists inside the ERP, permitting, utility billing, case management, and dispatch systems. Canned vendor reports handle operational lists within one system. They fall short when a question crosses systems, needs history the vendor product trims, or has to be published outside the agency. Three constraints shape the design:

• Access method. Decide per subject area whether the reporting layer reads from a vendor-supported reporting replica, a documented API, or a scheduled extract, and confirm it in writing. Direct queries against a live transactional database are commonly restricted by support terms.
• Licensing. Some platforms license per viewer, others by capacity, and publishing outside the agency is often licensed separately from internal viewing. Settle this before sizing the audience, because assuming every employee can open a dashboard changes the cost under per-viewer terms.
• Existing standards. If the agency already standardizes on a platform under a statewide or cooperative purchasing agreement, build there. For anything mapped, take boundary and address layers from the GIS team rather than recreating them.

What to specify in the contract, and how to judge it after go-live

Name these as deliverables rather than assumed effort:

1. Acceptance by reconciliation to an agreed source over a defined period, not by a demonstration.
2. Accessibility test results for the delivered dashboards rather than a platform-level claim. State and local government web content and mobile applications fall under ADA Title II, where a United States Department of Justice rule sets WCAG 2.1 Level AA as the technical standard, with compliance dates that depend on the size of the entity.
3. The underlying artifacts in the agency's own repository rather than only inside the platform: dataset and semantic model definitions, transformation code, and refresh schedules, with no build step only the vendor can run.
4. A support period that covers refresh failures, definition changes, and source schema changes that break a dataset.

After go-live, judge behavior rather than appearance: whether the manual reports this was meant to retire stopped circulating, whether the named audience opens it in an ordinary week, how long a new question now takes to answer, and whether a failed refresh is caught by monitoring or by a manager noticing a stale number.

Working with HQT on this

HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.

Frequently asked questions