I have been doing analytics work in a state government context for some time now. The pace and the constraints are different from enterprise work. The most useful thing I have learned is that the modernisation problem is not a technology problem. It is an institutional fit problem. The technology that wins is the technology that fits the institution.
Why "modernisation" projects fail
The pattern is familiar. A modernisation programme is funded. Consultants arrive with a reference architecture. The reference architecture assumes a private-sector cadence and risk profile. Procurement, security review, and accessibility review take longer than the project plan budgeted. The architecture is delivered late, partially, or shelved. The next administration funds another programme.
The failure is not in the architecture. It is in the assumption that public-sector engineering can move at private-sector speed without acknowledging the constraints that make public-sector engineering different.
The constraints that actually shape the work
Procurement timelines are months, not weeks. The vendors that can be engaged on a quick contract are a small subset of the market. The cost ceiling for a no-bid engagement is low. Anything larger requires an RFP. RFPs take a quarter or two before a contract is signed.
Security review and authorisation are non-negotiable. New systems require an authority to operate. Cloud services require specific configurations. Data classifications drive what can run where. These reviews exist for good reasons. The systems that ignore them either get blocked or create real risk.
Accessibility is a legal requirement. WCAG conformance is not a nice-to-have. Section 508 obligations apply. Any user-facing artefact has to pass review. This is engineering work, and it has to be in the schedule.
Data sharing across agencies is governed by data use agreements. These take months to negotiate. They constrain what data can be joined, by whom, and for what purpose. The architecture has to work within those constraints, not around them.
What boring engineering looks like
The architectures that ship in this environment are quieter than the ones that win conference keynotes.
Use the cloud accounts the agency has already authorised. Do not propose a new cloud provider. The authorisation cost will swamp the technical benefit.
Use the data warehouse the agency already operates. Do not propose a new lake on top. Modernise the warehouse with better modelling and governance. The political and security cost of a parallel platform is rarely worth it.
Build pipelines with tools that are already on the approved software list. dbt is often on the list. Airflow is often on the list. A new tool that is not on the list will face a procurement review before it can be used in production. That review is a quarter you do not have.
Treat accessibility and security review as features in the backlog, not as gates at the end. Run accessibility checks on every dashboard before it ships. Run security review against the architecture diagram in week one, not in week twelve.
The work that actually moves the needle
The highest-leverage projects in this environment are usually simple. They are not new platforms. They are well-modelled core datasets that several teams can use, replacing the spreadsheets the agency has been running on for fifteen years.
A canonical, governed view of clients across programmes. A canonical view of staff and assignments. A canonical view of case outcomes. These three datasets, well-modelled and well-governed, unlock more analytical capability than a new platform does.
That work is unfashionable. It does not photograph well. It does not produce a press release. It does, however, produce durable analytical capability that survives the next political transition.
What I would tell a new public-sector analytics leader
Spend the first ninety days mapping the institution, not the technology. Find out which data use agreements are in place. Find out which tools are on the approved list. Find out which security review the agency uses and how long it takes. Find out which agency relationships are productive and which are strained.
Then propose work that fits the institution as it actually is. The work that fits will get done. The work that ignores the institution will not, regardless of how good the architecture diagram looks.