Decision-Making When an AI Project's Scope Is Uncertain

Fixed-scope contracts work when the deliverable is known in advance, such as a brochure site, an app with a completed specification or illustrations in agreed dimensions. The delivery and price can then be defined precisely.

In AI projects, the specification often changes when the model is tested with real data. A planned integration may become a research question or be simplified by new software. This is not necessarily a planning failure. It reflects the changing technology and knowledge available during the project.

This does not mean that an AI project should proceed without firm contractual terms. It changes which terms can be fixed responsibly.

A pilot is a contract too

It has a term, a price, a definition of what counts as delivered and a named person on each side. Calling it a pilot does not remove any of that. It changes which clauses are fixed and which are deliberately left open.

So the question worth arguing about is narrower and more useful: which terms should be settled before the work starts, and which should not?

Common failure patterns in AI projects

Research provides a more reliable starting point than assumptions about why these projects fail.

RAND interviewed 65 data scientists and engineers with at least five years of experience building models in industry and academia.¹ Their leading root cause is not technical: industry stakeholders misunderstand or miscommunicate what problem is to be solved, so models get optimised for the wrong metric or do not fit the workflow they were meant to sit in. That is a failure that happens before any code, and a fixed scope document written in the same confusion does not catch it. It records it.

The project-management literature points the same way with an important caveat about how it is usually quoted. PMI's requirements work reports that among unsuccessful projects, 47 percent failed to meet goals due to poor requirements management.² That is a share of the failures, not a share of all projects, and it gets misquoted in the other direction constantly. PMI's 2021 Pulse puts scope creep at roughly a third of projects globally.³ Common, then. Not universal.

Cooper's stage-gate model made investment decisions between development stages explicit, while his later work argued for flexibility rather than rigid bureaucracy.⁴ Boehm's spiral model similarly puts repeated risk analysis before the next commitment.⁵ These methods do not remove uncertainty. They give it a scheduled place in the project.

Most disputes do not start in bad faith. They start with a document that describes something neither side fully understood when they signed it, and which nothing in the process was designed to revisit.

What a decision gate should determine

Forenta for Business makes this concrete through an explicit decision at the end of each stage.

A stage ends with one of three outcomes: proceed, revise or block. Revise and block are valid project outcomes. They ensure that proceed remains a substantive decision rather than a routine approval.

The next stage cannot begin while required items remain open. The verdict and the reason for the hold are recorded in the audit log. An unresolved item therefore requires action before the project continues.

A person can override it. That matters, because a process nobody can overrule gets routed around within a month. The override requires a written reason, it is recorded against the person who gave it, and the original verdict stays on the record rather than being rewritten. You can go ahead anyway. You cannot make it look like nobody objected.

If the running system was not inspected, the review states that its confidence is limited. A judgement about built software based only on a written description remains an inference and should be marked accordingly.

A shared record of findings and decisions

The thing a contract cannot do is stay current. It describes an agreement at one moment, and every conversation after that lives in email, calls and memory, which is where the two sides quietly build different versions of what happened.

Keeping findings, decisions and open items in one place reduces the need to reconstruct the project from emails and memory. It also limits conflicting interpretations of what was decided.

What this does not solve

Bounded engagements require setup time and agreement on what constitutes a sufficient result. They do not prevent a poor working relationship, but they can expose problems earlier and limit the initial commitment.

For work where scope genuinely is knowable, a fixed-price contract is still the right instrument, and reaching for a pilot there adds ceremony to a problem that did not have one.

The RAND and PMI evidence describes project failure broadly, and RAND's sample is 65 practitioners in interviews, not a controlled study. Treat it as well-collected experience rather than as measurement.

Forenta's pipeline runs as a controlled pilot for organisations, with pricing on request. It is not self-serve and describing it otherwise would undercut the point of this piece.

Fix only what can be determined in advance

The argument was never contract against no contract. It is that a bounded engagement lets you fix the terms that can honestly be fixed, and forces a real decision at the end instead of a renewal by default.

Which is only true if something at that decision point is allowed to say no.