R&D operations

Reducing delivery risk in an AI R&D project: governance patterns that work

The most common sources of delivery risk in AI R&D projects, the governance patterns that actually mitigate them, and concrete examples of what each looks like in practice.

AI R&D projects fail differently from regular software projects. The risks are different, the signals are subtler, and the governance patterns that work for predictable development often make things worse when applied to genuinely uncertain technical work. Here are the recurring failure modes and the patterns that counter them.

The three main sources of delivery risk

Unclear or shifting technical uncertainty. The project was approved with a specific R&D question, but six weeks in, the team is answering a different question — a more tractable one, or a less commercially relevant one — because the original was harder than expected. The project is “progressing” but not toward the outcome that justified the investment.

Vendor or team misalignment. The technical team and the stakeholders have different models of what success looks like. The technical team is optimising for model performance; the commercial stakeholders are waiting for a deployable feature. Neither is wrong, but without a shared definition of done, the project will drift until the gap becomes a crisis.

No kill criteria. The project has a plan but no conditions under which the plan changes. When results come in below expectations, the team adjusts the target downward rather than surfacing the problem. This continues until the budget runs out or someone senior forces the conversation.

Governance patterns that work

Fixed uncertainty definitions

Write down, before the project starts, what the R&D question is and what “answered” means. Not vaguely (“we will have a working model”), but specifically: what accuracy threshold, on what evaluation dataset, at what latency, under what conditions, would constitute a successful outcome.

This definition is not the ceiling of ambition, it is the floor of success. If results come in below it, that is not failure, it is information. The definition makes the information legible instead of deniable.

Revisit this definition at the end of each work package, not just at the end of the project. If the question has changed, acknowledge it explicitly and decide whether the new question is still worth answering.

Milestone-based vendor accountability

Vendors working on AI projects are often paid on time rather than on outcomes, which creates an incentive to stay busy rather than deliver. The counter is milestone-based agreements: specific, testable deliverables at defined intervals, with explicit acceptance criteria.

A milestone is not “complete the fine-tuning phase.” It is “achieve X% accuracy on the held-out evaluation set by date Y, using the data available as of date Z.” If the milestone is not met, there is a defined process: a brief root-cause analysis, a revised timeline with specific recovery actions, and a clear trigger for escalation if the recovery fails.

This sounds adversarial. In practice, it is clarifying. Most vendor relationships deteriorate not because of bad faith but because expectations were implicit and accountability was diffuse.

Kill criteria written in advance

Before the project starts, agree on the conditions under which you would stop the project entirely. This might be technical (if we cannot reach X accuracy after phase 2, the approach is not viable), commercial (if the market condition that justified this project changes materially), or resource-based (if the project is consuming more than Y% above the plan, it needs a full review before continuing).

Kill criteria feel pessimistic to write. They function as permission to be honest. Without them, projects that should stop accumulate sunk cost and gradually lose the momentum to call the outcome. With them, stopping is a decision rather than a defeat, and the information extracted from the stopped project can be used to make the next one better.

A working risk register

A risk register in an AI R&D project is not a compliance exercise. It is a living list of the things that could make the project fail, with an owner for each risk and a current status. It gets reviewed at every milestone checkpoint.

The discipline is in the updating. A risk register that reflects the project’s state from three months ago is worse than useless, because it creates a false sense of governance. The register should be uncomfortable to look at: it should contain things the team is genuinely unsure about. If every risk is green, either the project is unusually well-managed or the register is not being used honestly.

A worked example

A healthtech company running a 14-month AI R&D project to develop a clinical risk scoring model had reached month eight with positive results internally but no deployed feature. The commercial team was expecting something by month six.

The governance failure was dual: there was no shared definition of “deployable” (the technical team had been optimising for AUC; the clinical team needed explainability features the technical team had deprioritised), and the vendor doing the integration work was on a time-based contract with no milestone accountability.

The fix required two things: a joint session to agree a written definition of deployable that included the explainability requirement, and a renegotiation of the vendor contract to add three specific milestones with testable acceptance criteria. The project delivered a deployable feature four months later, inside the project period. Without the governance reset, it would have delivered either late or not at all.