Departments and agencies buy the same analytics platforms as everyone else, and their teams are as capable as anyone's. What makes public sector reporting different is the set of requirements that apply from day one and cannot be added later without rebuilding. In the programs we have seen succeed, five of them were settled before anyone opened a report designer.
1. Who may see what, decided by role
Program managers, regional directors, executives and oversight bodies all need different views of the same data, and some information must never leave a classification boundary. Access defined by role in the identity platform, and enforced in the data model rather than in each report, is the only arrangement that survives staff turnover and audit. It also decides where the data may live, which settles the residency question early.
2. Both official languages, from the model up
Bilingual reporting is not a translation pass at the end. Measure names, labels, categories and comments all need both languages, and the cleanest way to deliver that is a semantic model with translations built in, so every report inherits them. Deciding this first avoids the most common late surprise: a hundred visuals to relabel.
3. Accessibility as a design rule
Keyboard navigation, contrast, screen-reader text and a consistent layout are requirements, not preferences. They are cheap when they are the template everyone starts from and expensive when they are a remediation project. We treat them as part of the report design standard, reviewed on every page before release.
4. Numbers that can be audited
An executive briefing that cannot be reproduced is a liability. Every published figure needs a definition, a source and a lineage back to the system of record, and month-end snapshots should be locked so that a number quoted to a committee is the same number a year later. These are properties of the data model and the refresh process, which is why they belong in the first weeks.
5. An owner for every measure
The question "whose number is this?" ends more reporting programs than any technical failure. Each measure needs a business owner who signs off on the definition, approves changes and answers when it moves. Writing the owners down, with the definitions, is the governance artefact that outlives the project team.
Then build in thin slices
With the five requirements settled, the build itself can move quickly: one program or one service standard at a time, a working report every few weeks, reviewed with the owners, published in both languages and tested for accessibility. The requirements do not slow the program down; discovering them late does.