Software development changed. Procurement hasn't.

Procurement frameworks are engineering artifacts in disguise. They encode assumptions about how software gets built: that requirements can be specified in advance, that delivery takes quarters or years, that vendor selection is expensive enough to justify a long evaluation, and that the main risk to manage is a large commitment going wrong slowly.

Those assumptions produced sensible controls. Extensive up-front specification. Multi-stage evaluation. Contract structures that concentrate scope and price into a single commitment. Each control is a reasonable response to the risk it was designed for.

The difficulty is that the underlying delivery economics have moved and the controls have not. When useful working software can exist in weeks, a twelve-month evaluation cycle is not caution — it is the largest single source of delay in the programme, and it is one the organization imposes on itself.

The productive response is not to bypass procurement. It is to notice that the same governance objectives can now be met with better instruments. A small, defined first stage produces real evidence while preserving competition. A decision point after working software exists is a stronger control than a decision point after a document exists.

For public-sector organizations in particular, this is a defensibility argument rather than a speed argument. Committing at a smaller scale, on evidence, with options preserved is easier to explain to an oversight body than committing at scale on a projection. The question worth asking internally is simple: how much of the current process protects the institution, and how much of it protects a delivery model that has changed?