CGDA
Finding where a defence bill actually stalls

One bill, five roles, no shared view of where it stood.

Employee bill clearance at the Controller General of Defence Accounts moves through preparation, review, correction, and approval - different people, different responsibilities, different information needs, one workflow. The department's opening request was a visual refresh of the internal system supporting it. This study is what was done instead of starting there.

It is presented here as a research case study only. The interface work that followed the submission is deliberately out of scope on this page: what is worth reading about this project is how the problem was located, not what the screens ended up looking like.

• Organisation Controller General of Defence Accounts (CGDA)
• Contribution Research design, process mapping across all five roles, workaround audit, thematic analysis, and the recommendation set submitted to the department
• Status Professional work, presented here as a sanitised reconstruction
• Constraint No confidential screens, employee data, or financial records shown; no individual participant is identifiable
• Fieldwork Working sessions across all five roles a bill passes through – Auditor, Senior Auditor, Assistant Accounts Officer, Accounts Officer and Senior Accounts Officer – three participants per role, fifteen in all, run separately per role, alongside a review of existing paper-workaround practices

Three questions, none of them about a screen.

The brief could have started with the existing pages. It started with the process instead, because five roles each had a different relationship to the same workflow and no screen audit surfaces that on its own. The questions were written to be answerable by observation rather than opinion.

• RQ1 - Where does a bill actually stall? Not which screen breaks, but which handoff between roles a bill stops at, and what it is waiting for when it does.
• RQ2 - What fills the gap when the system doesn't? If each role in the chain had informal workarounds, what were those workarounds compensating for?
• RQ3 - Who is responsible for the next move? Whether the system itself made ownership of a pending bill legible, or left it to be inferred by asking someone.

RQ2 is the load-bearing one. A workaround is the cheapest available evidence of an unmet need, because someone has already paid to build it.

Ask each role for its own account, not the department's summary of it.

Two methods, chosen so that each covered the other's blind spot. Process mapping could establish the sequence but not what people did when the sequence failed them; the workaround audit could show the failures but not where they sat in the flow.

Why sessions per role, not one workshop

A five-role workflow needed each role's own account of the sequence, not one department's summary of how the other four operate. Run as a single stakeholder workshop, the account would have converged on the official process - which was already documented, and was not the thing in question. Held separately, the accounts disagreed, and the disagreements were the findings.

Why the workarounds were audited alongside, not after

Workarounds rarely surface when you ask someone to describe their job; they are experienced as "how the work gets done", not as compensation for a defect. They show up when you trace the sequence and ask what happens at the point where the system stops helping. Mapping the artefacts against the digital flow is what put each one at a specific handoff instead of on a general list of complaints.

Code by what stopped the bill, not by which page it happened on.

Observations from the sessions were written up as discrete statements, each kept separate from my reading of it - what a participant did or said in one column, what I thought it meant in another. Codes were generated from those statements rather than from a prior framework, then clustered by shared underlying cause rather than by surface topic or by screen.

That last choice is the analytical step that mattered. Coded by screen, the output would have been a page-by-page audit and the department would have got its visual refresh. Coded by what prevented the bill from reaching its next stage, the same observations resolved into four recurring blockers - and those four sat under two themes.

Four blockers, each one traceable to a handoff.

These are generalised descriptions. The work involves financial and employee records, so specific figures, bill references, and individual identities cannot be published.

Blocker 02 is the one I would lead with again. A single word standing in for at least four distinct states is not a labelling problem - it is a missing concept, and every social workaround in the audit existed to supply it.

The workarounds contradicted the process, politely.

Nobody in the study described the official process inaccurately. The gap was between that description and what the desks showed - and in a hierarchical setting, the desk is the more honest source. Each artefact below was doing a job the system had left undone.

Reading those three together is what made the diagnosis structural rather than cosmetic. The workarounds were not evidence that people disliked the interface. They were evidence that three specific pieces of information - what is required, whose turn it is, and what happened before - had no home in the system, and had been rehoused in paper and phone calls at a cost nobody was counting.

What went to the department, and what it changed about the brief.

The findings were submitted as a recommendation set rather than as a screen critique, with each recommendation named against the blocker it answered so the department could accept or reject them individually.

• R1 - Move requirements upstream of submission Present what a bill requires as part of preparing it, so documentation gaps are caught before a correction cycle starts. Answers Blocker 01.
• R2 - Replace the status word with an explicit stage Distinguish preparation, review, correction, and completion, so a bill's state also says who has to act next. Answers Blocker 02 - the highest-priority recommendation.
• R3 - Structure the work around responsibility Give reviewers and approvers a view built for their part of the job rather than a copy of the preparer's form, keeping the fuller record reachable. Answers Blocker 03.
• R4 - Keep a correction attached to its cause Connect a flagged issue to the specific part of the submission it came from, so a returned bill keeps its context. Answers Blocker 04.

The evidence had to outweigh the instinct to restyle

The department's early expectation was a visual refresh; the pages looked dated and a cosmetic pass was the obvious next step. What moved the brief was not an argument about design quality, it was the workaround audit. Showing that a single "pending" label was standing in for at least four real states - and that people had built phone habits to compensate - was a traceable gap between what the system said and what the work required. Walking stakeholders through those artefacts directly, rather than summarising them in a deck, is what shifted the scope from a restyle to a structural change.

What the department pushed back on, and rightly

Not every recommendation survived intact. A proposed change to how corrections were tracked ran into legitimate audit and record-keeping requirements that an interface cannot design away; the accepted version had to carry that complexity rather than simplify around it. That was the correct outcome - the requirement was real, and I had underweighted how much of the existing density was doing legal work rather than accumulating by accident.

What this study cannot claim.

• No measured outcome The department did not run a before/after measurement programme on this system, so there is no time-to-clearance or correction-rate figure to report, and I have not manufactured one. What followed the submission was structural change and qualitative feedback, not a tracked metric.
• Participants were nominated within a hierarchy Access ran through the department, which biases a sample toward people comfortable being observed. Sessions were held per role partly to offset that; it does not remove it. Three per role is enough to see where a handoff breaks and not enough to quantify how often it does.
• Self-report and observation were not separable everywhere Some of the sequence had to be reconstructed from description rather than watched end to end, because a single bill's clearance spans days and desks.
• Sanitisation costs specificity Publishable findings are generalised. The internal version carried the concrete artefacts and references that make each one checkable.

What I would instrument if I ran this today

Time-in-stage per handoff, correction-cycle frequency per bill, and the volume of status-check contact between roles - that third one being the direct measure of Blocker 02, and the cheapest of the three to collect. Agreeing those three measures before the change went in is the single thing I would do differently.

The research was the deliverable.

Nothing in the submitted recommendation set came from a best-practice checklist. Each one traces to a blocker that only appeared once the process was mapped across five roles instead of one screen at a time, and the strongest evidence in the whole study was a physical file that somebody had decided to keep carrying. A bill-clearance system does more than collect data - it has to let five people trust the same record of a decision. Finding out where that trust was being rebuilt by hand was the work; the interface that followed was the easy part.