Procurement is a structural constraint, not an excuse.

Every conversation with a government legal function or a large in-house department reaches the same point, usually within twenty minutes. Someone explains that procurement takes two quarters, that data residency rules out most of the market, that security review is queued, and that the enterprise architecture board meets monthly. There is often a slight apology in the tone, as though this were a local failure of will.

It is not. These constraints exist for reasons, most of them good ones, and they are properties of the institution rather than obstacles to be overcome with better change management. An adoption plan that assumes they will yield is a plan that will fail, and the failure will be blamed on the technology.

But the conclusion people draw from this is wrong in an important way. They conclude that nothing can start until procurement concludes, and so nothing starts. Two quarters pass. The approval arrives, or does not, and the organisation is exactly where it was.

The observation that changes this is simple: the work with the highest value has the lowest procurement dependency. Naming your primitives is a writing exercise. Defining what a request is, listing the action sequences for your highest-volume request types, mapping who does and who approves each step, locating where prior advice actually lives - none of that requires a purchase, a security assessment, or a competitive tender. It requires attention, which is scarce, but not permission, which is slow.

Systematising is nearly as unconstrained. Request templates, action checklists, approver charts, an evidence-anchoring rule - all of these can be built in tools the organisation already runs and has already approved. And each one improves throughput before any AI is involved, which has a second benefit: it builds the internal credibility that the later, harder phase will need.

So the sequencing is: start the naming work in week one, and start the approval track in week one, in parallel rather than in series. Arrive at the procurement conversation with a specified requirement derived from documented process, rather than a general desire for AI. That single change is worth a full quarter, and it converts procurement from a blocker into a background process running alongside real work.