Data and analytics projects have a sequencing problem that most planning processes do not address. A conventional software delivery project begins with requirements, moves to design, and proceeds to build. The requirements can be fully specified before the build begins because the inputs to the build — the data, the integrations, the business rules — are known at the time the plan is written.
A data and analytics project begins with a question — what do we want to know, or what decision do we want to automate — and then discovers the data that would answer that question. The discovery is not a planning formality. It is a substantive investigation that determines whether the question is answerable at all, on what timeline, with what level of data preparation, and with what residual uncertainty. It cannot be compressed into a week of scoping. It cannot be assumed to have a predetermined outcome. And it cannot be sequenced after the project deadline has been agreed.
The ANAO's 2022 performance audit of the Australian Taxation Office's data and analytics capability found this sequencing error recurring across multiple initiatives. Commitments were made, timelines were set, governance gates were scheduled — and the data readiness assessment that would have revealed whether those timelines were achievable came later, after the commitments were already in place. The result was a repeated pattern of scope reduction, quality compromise, and delivery of outputs that technically met their deadline but did not meet the programme's underlying needs.
What the ANAO audit established
The ANAO's audit — Australian Taxation Office's Use of Data Analytics, published in 2022 — examined the ATO's data analytics programme across multiple use cases including compliance risk assessment, debt management, and taxpayer service. Its findings on planning and sequencing are the most instructive for any organisation building enterprise AI capabilities.
The audit found that project timelines were typically established in response to business demand and organisational planning cycles, not in response to technical readiness assessments. Data quality issues, integration complexity, and model validation requirements were discovered during execution rather than surfaced during planning — which meant that the organisation repeatedly faced a choice between delivering something on time that did not fully meet the stated need, or delaying a commitment that had already been made to senior leadership and governance bodies.
The pattern is not unique to the ATO. It is the default outcome when a planning process imports conventional software delivery sequencing into a data project, without adjusting for the fundamental difference: in conventional software delivery, requirements precede build. In data and analytics delivery, data assessment precedes — and constrains — requirements.
"The ATO does not have a consistent approach to assessing data readiness prior to committing to project timelines. In several cases examined by the audit, data quality issues and integration complexity were identified during project execution rather than during the planning phase, resulting in scope reductions and quality compromises that affected the utility of the outputs delivered. The absence of a structured data readiness assessment as a precondition for timeline commitment was a recurring finding across the initiatives examined."
The EU AI Act's Article 10 requires that training, validation, and testing data for high-risk AI systems be subject to appropriate data governance practices — including assessment of data quality, coverage, and representativeness before model development begins. This is not a documentation obligation. It is a sequencing obligation: the data assessment comes before the model development plan, which means it comes before the timeline commitment that governs the model development plan.
Why deadline-first sequencing is structurally difficult to avoid
The deadline-first pattern is not a failure of individual judgement. It is the output of a planning system that treats data and analytics projects as conventional software delivery projects and schedules them accordingly. The budget cycle demands a delivery date. The governance calendar needs a milestone. The stakeholder communication requires a committed timeline. All of these pressures arrive before the data assessment — because the data assessment is not a scheduled event in the planning process; it is something the project team is expected to do once the project is underway.
The ANAO's finding is that this sequence produces predictable, recurring outcomes: scope is reduced to meet the deadline, quality is compromised to preserve scope, or both. None of these outcomes are failures of the delivery team. They are the inevitable result of a plan that committed to a timeline before the inputs to that timeline were understood.
What a data readiness assessment produces
A data readiness assessment is not a data quality audit in the conventional sense. It is a structured investigation that answers five questions, the answers to which determine whether a timeline commitment is defensible before it is made.
The first question is coverage: does the data that exists cover the population, time period, and variables required to answer the business question or train the model? The second is quality: what proportion of the required data has quality issues — missing values, inconsistent schema, known inaccuracies — and what is the cost and timeline to remediate them? The third is access: what organisational, legal, and technical barriers exist to accessing the required data, and what is the timeline to resolve them? The fourth is representativeness: is the available data representative of the population the model will be applied to, or does it reflect historical patterns that differ from the deployment context? The fifth is provenance: is the data sufficiently documented and lineaged to satisfy the Article 10 data governance requirement, and if not, what is the remediation path?
These five questions can be answered in two to four weeks for most enterprise data projects. They cannot be answered in a planning meeting. And the answers to them determine, more than any other factor, whether a given business question is answerable on any given timeline — or whether the honest answer to "when can we have this?" is "after the data work, not before it."
Before any data and analytics project timeline is committed to governance, add a single mandatory gate: a data readiness assessment that answers the five questions above and produces a written finding on whether the proposed timeline is achievable given the data's actual state.
The assessment does not need to be a lengthy document. It needs to be a one-page answer to each question, produced by the team that will build the system — not by a business analyst who has not yet examined the data. And it needs to be produced before the governance presentation, not as part of it.
The gate has one rule: the timeline cannot be committed until the data readiness assessment is complete and its findings are reflected in the plan. If the assessment reveals that the data requires six months of preparation before model development can begin, the timeline reflects that. If the assessment reveals that the required data does not exist, the question is escalated before commitments are made, not after the scope has been reduced to fit a deadline the data could never have supported.
The ATO pattern — delivery on time, not what the programme needed — is the outcome of skipping this gate. The gate takes two to four weeks. The rework it prevents takes considerably longer.