Inside a federal digitalisation: lessons from PTAD & TDARS

When people picture digitalising a government agency, they picture software. In practice, the software is the smaller half of the problem. The larger half is the institution: its records, its approval chains, its statutory obligations and the people who have done the job a particular way for years. Ignore that half and even excellent code will stall at go-live.

Start with the records, not the screens

Legacy data is rarely clean, and it is almost never in one place. Before a single screen is designed, the existing records need to be inventoried, de-duplicated and validated. Data migration is the phase most likely to be underestimated and most likely to sink a timeline — so we treat it as a workstream in its own right, with its own acceptance criteria, not as a task appended to the end of the build.

Model the real approval chain

Public institutions run on accountability. Every consequential action has an approver, and often several. A system that flattens that hierarchy for the sake of a tidy interface will simply be bypassed. Role-based access control, delegated approvals and a complete audit trail are not compliance decorations; they are what makes the system trustworthy enough to be adopted.

• Map who approves what — before you design the workflow.
• Build an immutable audit trail from day one; it cannot be retrofitted credibly.
• Phase the rollout by module, so each go-live is survivable.
• Train the people who will actually use the system, not only their supervisors.

Phase the go-live

Delivering eight modules at once means eight ways to fail on the same morning. Sequencing them — each with its own pilot, training and stabilisation window — keeps risk contained and gives the institution time to absorb the change. Momentum comes from a series of successful, visible go-lives, not from one dramatic switch-over.

The lesson we keep relearning: technology is the easy part. Delivery is the discipline.