When an Australian government IT project runs into trouble late in delivery, the post-mortem almost always surfaces something upstream: a technical standards decision made early, made quietly, and never revisited. The choice of API style, data exchange format, identity protocol, or interoperability standard gets locked in during discovery or early design, and then becomes the assumption underneath every other decision. By the time it causes pain, unwinding it costs more than continuing to build around it.
Technical standards selection is not glamorous work. It doesn't appear on programme roadmaps, rarely makes it into steering committee decks, and tends to sit in an ambiguous space between enterprise architecture, the delivery team, and vendor recommendations. That ambiguity is exactly why it goes wrong so often on government projects.
What "technical standards" actually covers
The term is broader than most project teams realise. At the federal level, the Digital Transformation Agency publishes whole-of-government standards guidance that covers areas including data formats, API design, accessibility, and identity federation. But those are framework-level mandates. Inside any individual project, the team also makes a second tier of decisions: which version of a standard to implement, which profile to follow, which vendor's interpretation to adopt, and how to handle gaps where no standard exists.
Both layers matter. A project can comply with the DTA's API standards at a surface level while still making proprietary choices in the underlying data model that prevent interoperability with the next system that needs to connect to it. Compliance with the letter of a standard and genuine alignment with its intent are different things. Government projects tend to achieve the former more reliably than the latter.
Where the decision actually gets made
In theory, technical standards selection happens during discovery and architecture phases, informed by enterprise architects, the agency's existing technology standards (if it has a current register), and whole-of-government guidance. In practice, three other forces tend to dominate.
First, vendors. Most government IT projects of any scale involve a systems integrator or a product vendor, and those vendors come with existing technology stacks. A vendor whose core platform is built on a particular messaging standard will naturally frame any standards discussion around that standard. Procurement documentation rarely explicitly prohibits this, and assessment panels often lack the technical depth to challenge it.
Second, the project team's existing skills. A delivery team that has built the last three systems in a particular way will default to that way unless someone actively challenges them. This isn't laziness; it's rational risk management. But it means technical standards decisions often reflect the past rather than the strategic direction the agency is trying to move toward.
Third, timeline pressure. As noted in coverage of how Australian agencies handle IT project discovery phases, compressed discovery phases push decisions that should take weeks into days. Technical standards selection is one of the first casualties. The team picks something that works, documents it minimally, and moves on.
The interoperability gap
The most consistent consequence of poor standards selection is broken interoperability. Government systems rarely stand alone. They need to exchange data with other agency systems, state government platforms, third-party providers, and increasingly, whole-of-government platforms like myGov. When technical standards are chosen without that ecosystem in mind, integration work consumes a disproportionate share of delivery effort.
This is not a new problem, but it persists because the incentives at project level don't naturally push toward ecosystem thinking. A delivery team is measured on delivering the system they've been asked to build. The cost of poor interoperability is borne later, by different teams, on different budgets. That separation makes it easy to defer.
The pattern shows up repeatedly in gateway reviews and post-implementation reports. A system ships on time and within budget, then immediately runs into integration friction that was entirely predictable at design time. The cost of resolving it often exceeds the cost of getting the standards decision right in the first place.
What good standards selection looks like
Agencies that handle this well share a few common practices. They maintain a live, current technology standards register at the agency level, not a document that was accurate two years ago. They involve enterprise architects in project inception, before vendor selection, not after. And they explicitly separate the standards compliance question from the vendor selection question, so that a vendor's preferred technology stack is evaluated against the standard rather than treated as equivalent to it.
The assessment process itself matters. A standards decision should produce a short written record: the options considered, the standard being applied, the rationale for the choice, and any known deviations. That record doesn't need to be long. It needs to exist, to be in the project's document repository, and to be reviewed at the next architecture checkpoint. Most projects produce none of this, which means later decisions get made without knowing what was decided earlier or why.
Reuse is another marker of maturity. Agencies that have done this well tend to build on patterns from previous projects rather than starting from scratch each time. That requires institutional memory, which is one of the reasons knowledge transfer practices have a direct bearing on standards quality. When experienced architects leave and take their reasoning with them, the next project team has no basis for understanding why certain choices were made.
The whole-of-government tension
Federal agencies operate under guidance from the DTA and, for security-relevant decisions, from the Australian Signals Directorate. State agencies operate under their own frameworks, which vary considerably. A project that needs to interoperate across jurisdictions, common in health, justice, and emergency management, faces a genuine challenge when the standards regimes don't align.
This tension doesn't have a clean resolution. The practical response is to identify the interoperability requirements explicitly during discovery, map the relevant standards frameworks for each jurisdiction involved, and make a deliberate choice about which profile to follow. That choice should be documented and signed off by the relevant authority, not left implicit in the vendor's integration design.
The alternative, letting the integration team sort it out during build, produces systems that work in the narrow sense of exchanging data, but do so through custom mappings and adapters that nobody outside the delivery team understands. Those adapters become technical debt immediately. They also become single points of failure when the team that built them moves on.
What project sponsors should ask
Technical standards selection is a governance question as much as a technical one. Project sponsors and steering committees don't need to evaluate the standards themselves, but they should be asking four questions before architecture decisions are locked in.
- Which whole-of-government or agency standards apply to this system, and has compliance been assessed against the current version of each?
- Where the project deviates from a mandatory standard, what is the documented rationale and who has approved the deviation?
- Has the enterprise architecture team reviewed the standards selections before vendor negotiations closed?
- What are the known interoperability dependencies, and have the relevant external teams confirmed compatibility?
None of these questions require technical depth to ask. They require the expectation that the answers exist in writing. On most government projects, that expectation is absent. Establishing it early is one of the cheapest quality controls available.
The pattern connecting poor standards decisions to poor delivery outcomes is clear enough. It isn't that agencies lack standards frameworks. The DTA, the ASD, and most large agencies publish guidance that covers the core decisions. The gap is in applying that guidance consistently at project level, before the decisions get made by default rather than by design.