The Delivery Lead Role in AI Projects: What 'Done' Actually Means

Delivery leads and project managers on AI projects often describe the same experience: the team is moving, the sprints are happening, but the usual markers of progress don't quite fit. "Is the model good enough?" isn't a question your standard Definition of Done answers. And "when does it ship?" depends on an eval report you've never seen before.

This is the part nobody prepares delivery leads for. Here's the frame that actually works.

## Why AI projects fail at handoff

Traditional software projects fail for predictable reasons: scope creep, missed deadlines, technical debt. The moment of failure is usually visible — the feature is late, or broken, or incomplete.

AI projects fail differently. The development phase often goes smoothly. The model gets built, it seems to work in demos, and the pressure to ship is real. But something goes wrong at handoff: the AI behaves unexpectedly in production, users find edge cases nobody anticipated, or a high-stakes decision made by the AI turns out to be wrong.

The root cause is almost always the same: the team never defined what "good enough" meant before they built the model. The eval criteria were negotiated at the end under launch pressure, not set at the beginning with rigor.

As the delivery lead, this is your job to prevent.

## What delivery leads own in the ADLC

The AI Development Lifecycle gives delivery leads a defined lane across all six phases:

**Discovery**: Facilitate the AI suitability conversation. Is this actually a problem AI solves? Who's the Spec Owner (the PM who'll write the behavioral contract)? What's the risk if the AI is wrong? Document the answers.

**Framing**: Track the Specify document. The PM and BA produce it; you make sure it exists and is signed off before Architecture begins. A project that moves into Architecture without a Specify document is already behind schedule in the ways that matter.

**Architecture**: Run the standard design review process, but add one gate: is the eval plan documented? The eval plan (what the model needs to achieve before it ships) should be produced in Architecture, not in Eval.

**Build**: Run sprints, manage dependencies, track velocity. Same as always. The new addition: maintain the decision log. When edge cases surface during Build that required changes to the Spec, document the decision and who made it. This protects everyone at Eval.

**Eval (the critical one)**: This is where your role diverges most sharply from traditional project management. See below.

**Production**: Own the readiness checklist. See below.

## The Eval phase: your new Definition of Done

In a traditional project, "done" means the feature is built, tested, and signed off by QA. In an AI project, "done" before Eval means the feature is built. "Done" after Eval means something different:

The model has been run against the golden set. It has hit the pre-defined eval threshold. The QA engineer (or equivalent) has produced a GO / CONDITIONAL GO / NO-GO verdict with documented evidence. The Spec Owner has reviewed the report and signed off.

Your job as delivery lead: make sure this process happened. Not that the model passed — that's QA's call — but that the process was followed and the decision is documented.

**The questions to ask at the end of Eval:** - Was the golden set run? Against what inputs? - What was the pass rate on each eval dimension? - Did the model hit the pre-defined threshold? If not, what was the decision and who made it? - Is there a signed GO / COND / NO-GO verdict? - If CONDITIONAL GO, what are the conditions, who owns them, and are they documented in the incident playbook?

If you can't get clear answers to these questions, the project isn't ready to ship — regardless of what the launch date says.

## The Production readiness checklist

Before any AI system goes live, run this checklist. Add it to your sprint closure process:

**Behavioral controls** - [ ] Spec document is finalized and signed off by the Spec Owner - [ ] Guardrail conditions are implemented and tested - [ ] Fallback behavior is implemented and tested - [ ] Human-handoff trigger is implemented and tested

**Eval completion** - [ ] Golden set has been run and results documented - [ ] All eval dimensions hit their pre-defined thresholds (or exceptions are documented) - [ ] A formal GO / COND / NO-GO verdict exists with signatory

**Monitoring and observability** - [ ] The AI system produces logs that can be reviewed - [ ] There is a monitoring rubric: what signals indicate the system is behaving unexpectedly? - [ ] Someone owns the monitoring rubric and has capacity to review it

**Incident response** - [ ] An incident playbook exists: if the AI does something wrong in production, what's the triage process? - [ ] Who is notified first? - [ ] What's the rollback plan? - [ ] Who has authority to pull the AI offline?

**Stakeholder alignment** - [ ] All stakeholders understand what the AI can and cannot do - [ ] Leadership understands the eval threshold and what the CONDITIONAL GO conditions are (if applicable) - [ ] Customer support (if applicable) has been briefed on what the AI does and what it doesn't

This checklist won't slow down launches. It will surface the conversations that would have caused crises in production — and surface them before launch, when they're still fixable.

## The delivery lead as the person who defines "done"

On an AI project, the delivery lead who knows this framework becomes the person who defines what "done" means. That's a significant role upgrade from "the person who runs standups."

When you're the person who knows that the eval report needs a signed verdict before you ship, that the Specify document gates Architecture, and that the incident playbook is a pre-launch deliverable — you're running the AI project, not just facilitating it.

[See how the Forward Deployed course teaches this to delivery leads →](https://forwarddeployed.app/seminars)