Discovery is where Australian government IT projects are most often lost, even when the final delivery report calls them a success. Agencies feel pressure to show progress, ministers want announcements, and a discovery phase produces no visible deliverable. So it gets cut short, or treated as a box-ticking exercise before the real work begins. The consequences play out months later: scope that doesn't match actual user needs, architecture decisions made on wrong assumptions, and a scope creep problem that nobody can explain cleanly.
What discovery is actually supposed to do
A discovery phase has one purpose: to establish whether the problem the project intends to solve is the actual problem users and the agency face. That sounds obvious. In practice, most Australian government IT projects begin with a solution already in mind, and discovery becomes a process of confirming that solution rather than interrogating it.
Good discovery answers three questions before a single line of code is written or a vendor is engaged. First: what is the problem users actually experience, not the problem the policy brief describes? Second: does the existing landscape, including legacy systems, existing processes, and adjacent programs, constrain the solution in ways the brief doesn't acknowledge? Third: is the proposed investment proportionate to the problem?
The Digital Transformation Agency publishes a service design and delivery process that names discovery as the explicit first phase, with alpha, beta, and live following in sequence. The framework is sound. The gap is in how agencies apply it.
Where discovery goes wrong in practice
The most common failure is time. Agencies allocate four to six weeks for a discovery that genuinely needs four to six months. Four weeks is enough to interview a handful of internal stakeholders and produce a slide deck. It isn't enough to surface the edge cases, the workarounds users have built into their daily routines, or the data quality problems sitting inside the systems the new solution will depend on.
A second failure is who does the discovery. Many agencies run discovery using the same team that will build the solution, or using a vendor that has already been selected for delivery. Neither group has an incentive to find reasons the project shouldn't proceed in its current form. Independent discovery, where the team assessing the problem has no stake in building the answer, produces different results. It also produces more friction, which is why agencies avoid it.
User research is the third weak point. Government agencies frequently substitute consultation for research. Consultation means asking stakeholders what they want. Research means observing what users actually do, and those two things diverge constantly. A benefits recipient describing how they interact with a portal and a researcher watching that same person attempt to complete a task in a test environment will surface entirely different information. Most Australian government discovery phases do the former and call it the latter.
The political economy of skipping ahead
There's a structural reason agencies rush discovery, and it has nothing to do with incompetence. Budget cycles, ministerial priorities, and election timelines all push toward visible activity. A project in discovery produces reports. A project in build produces screenshots, demos, and progress milestones that can be reported upward. Senior executives who have committed to a delivery date in front of a Senate estimates committee cannot absorb a discovery finding that says the original approach was wrong.
This dynamic sits inside a broader pattern in IT project budget reforecasting, where the cost of early mistakes doesn't appear until deep into delivery. By then, the project is too far committed to stop, and the discovery failures have compounded into architecture problems, vendor lock-in, and rework cycles.
The practical consequence is that discovery findings rarely say "don't proceed." They say "proceed, with these caveats." The caveats get noted in the risk register and forgotten. Three years later, those caveats are the reasons the project is over budget.
What well-run discovery looks like
The agencies that run discovery well share a few consistent practices. They separate the discovery team from the delivery team, even if that creates a handover cost. They set a clear decision gate at the end of discovery: proceed, pivot, or stop. And they treat stop as a legitimate outcome, not a failure.
Well-run discovery also produces specific artefacts. Not just a problem statement, but a set of user journeys that expose where the current service breaks down. Not just a list of constraints, but a technical assessment of the systems the new service will integrate with, including their real data quality and their real API capability, not what the documentation says they can do.
Timeboxing matters, but it has to be honest. A discovery phase should have a fixed end date, but the end date should be set based on what the problem actually requires, not on when the delivery phase needs to start. Agencies that set the delivery start date first and work backward to set the discovery end date are planning a confirmation exercise, not a discovery.
How the DTA framework interacts with agency reality
The DTA's service design process gives agencies a defensible framework to point at. What it can't do is override the budget pressures, procurement timelines, and organisational incentives that push agencies toward speed over rigour. Agencies that genuinely use the framework treat discovery as a decision-making tool. Agencies that gesture at it treat it as a compliance step.
The difference is visible in how discovery outputs are used. In agencies where discovery works, the findings actively reshape the project scope, sometimes substantially. In agencies where it doesn't, the discovery report sits in a SharePoint folder and the project proceeds exactly as originally planned. The report exists. The discovery didn't happen.
Federal and state agencies are not uniformly bad at this. The Australian Taxation Office has built internal capability that treats discovery seriously, partly because it has experienced enough late-stage failure to understand the cost of skipping it. Services Australia has developed similar muscle through its welfare payments modernisation work. But these are exceptions built over years of hard experience, not the default.
Procurement timing and its effect on discovery integrity
One of the least discussed problems in Australian government discovery is procurement sequencing. Agencies frequently begin procurement for a delivery vendor before discovery is complete, sometimes before it has started. The vendor gets selected based on a problem statement that hasn't been validated. The delivery contract is signed. Then discovery concludes with findings that contradict the contract scope.
At that point, the agency faces a choice between two bad options: renegotiate the contract using findings the vendor will dispute, or suppress the findings and build to the original scope anyway. Most agencies choose the latter. The discovery findings become a document that informed nothing.
The fix is sequencing: complete discovery before procuring delivery. This is standard advice and genuinely difficult to follow in a system where procurement takes six to eighteen months and ministerial timelines don't wait. Agencies that manage it do so by running discovery on internal funding before a project formally enters the capital works pipeline, keeping it off the schedule entirely until the findings are ready to inform a procurement brief.
It's not a perfect solution. But it's the closest thing to one that works inside real Australian government constraints.