How Forward Deployed Engineers Stop Scope Creep on AI Projects

Scope creep on an AI project almost never begins with an unreasonable client. It begins on the day you finish discovery, hand back a diagnosis, and start writing code without a document that says what you are — and are not — going to build. In a delivery engagement, everything you left unsaid is assumed to be in scope. That is the entire mechanism, and it is why the fix is not better project management. The fix is a piece of writing.

The piece of writing is a scope contract: one document, produced after discovery and before the first line of code, that states what the system will do, what you are assuming about the client's environment, what is explicitly out of this phase, what you need the client to hand you before engineering can start, and what happens to their organisation if you succeed. My cohort teaches it as RAPID — Requirements, Assumptions, Priorities, Implications, Dependencies. Treat the acronym with care: Bain uses RAPID® for something else entirely — Recommend, Agree, Perform, Input, Decide — a tool for assigning decision rights, not scope. Nobody at a client will ask you for either by name. Call this one a BRD, a discovery readout, a scoping memo. What matters is that the five things get said out loud, in writing, while you still have the standing to say them.

#Where scope creep starts: a problem is not a product

A good discovery call ends with a Problem Definition Sheet: the real problem, the decision makers, what success looks like, the fears in the room, the constraints, the accuracy you need, the urgency. It is an excellent artefact. It is also completely useless to an engineer.

Hand that sheet to a developer on Monday morning and ask what they are going to code. Alert fatigue is the root cause. The false-positive rate is one in three. High-risk drugs must stay human-reviewed. All true, all diagnostic, and none of it is a product. What gets built — a suppression engine, a confidence score, an audit log, a supervisor dashboard, a labelling pipeline, a doctor-side tool — is a set of decisions nobody has made yet. That gap, between a diagnosis everyone agrees with and a product nobody has specified, is exactly where scope creep lives.

The case my cohort works through makes the gap concrete, so I will use it throughout. A hospital network has had three adverse drug events in six months — cases where interacting medications, prescribed by different specialists, reached a patient. The safety net is a rule-based engine that flags potential interactions for a pharmacist to approve. The engine is deterministic and cautious, so it flags anything with any interaction in the literature: one in three of its alerts is a false positive. Pharmacists spend more than ten hours a day, across the network, clicking through noise. And somewhere in that clicking, a real interaction gets dismissed with the rest. The chief medical officer, under board pressure, wants an AI recommendation agent. The head of pharmacy — the person whose team will actually use it, and the person who can veto it — is not convinced an AI can be trusted with any of it.

The problem is not a shortage of AI. It is alert fatigue caused by false positives. Everyone can agree on that sentence and still walk out of the room with five incompatible ideas about what is being built. So you write the contract.

#R — Requirements: without a number, it's a wish

A requirement is business pain converted into specific system behaviour with a measurable threshold and a boundary. It comes from three fields on the Problem Definition Sheet: what success looks like, the constraints, and the accuracy the client needs.

"Reduce alert fatigue" is not a requirement. This is:

The system suppresses low-risk interaction alerts such that the false-positive rate falls from roughly one in three to under one in ten. No suppression is ever applied to high-risk drugs, which route to a mandatory two-stage human sign-off.

That has an action, a threshold, and a boundary. Notice what it is not: it is not "zero adverse drug events." Zero adverse events is the outcome the hospital cares about, and a client will absolutely push to make it the requirement. It cannot be. No tool can promise it — a human-in-the-loop workflow produces it, over time, with the pharmacist still in the chair. Confusing the outcome with the requirement is how engineers end up contractually liable for a number their software does not control. The requirement is the measurable behaviour of the thing you are actually shipping.

#A — Assumptions: the unverified dependency that kills the project

Every assumption is a dependency you haven't verified yet. It looks harmless in a document precisely because it looks obvious.

You have just promised to suppress alerts on a pharmacist's screen. Suppression means a pop-up that appears today stops appearing tomorrow — which means you can write to the hospital's legacy pharmacy system, or at minimum sit in front of it. Have you read that vendor's API documentation? Have you spoken to their head of IT? In a two-week discovery, almost certainly not. So it is an assumption, and it gets an ID, an owner, and a date: A-001 · Legacy pharmacy system exposes an API that permits an external service to modify what pharmacists see · Owner: Head of IT · Verify by: Week 1.

The reason this is worth the bureaucracy is a rule with no exceptions:

Log it and it breaks — that's a scope change, and the client pays for the delay. Don't log it and it breaks — that's your failure.

The canonical version of this failure, one my cohort teaches from a banking engagement, is a team that assumed historical transaction data was reachable over a REST API. It was in a mainframe, behind a six-week procurement. Nobody had written the assumption down, so there was nothing to point at. The delivery team absorbed the six weeks in silence, and the client remembered them as the vendor who ran late.

A useful way to sort these, offered by someone in my cohort and better than the version I had: dependencies are your known unknowns, assumptions are your unknown unknowns. Every assumption eventually resolves into one of two things — a dependency you now have to chase, or a design choice you can make yourself. Neither of those is dangerous. The dangerous ones are the assumptions that stay invisible until the sprint they break.

#P — Priorities: Won't-Have is a trust move, not a refusal

Priorities are where the feature catalogue in your head becomes a scope you can defend. The tool is MoSCoW — Must have, Should have, Could have, Won't have — and it is old, unfashionable, and the single highest-leverage table in the document. If you hand a client an undifferentiated list of ten features, every one of them is a must-have in their head, and all ten are due in eight weeks.

Two of the four boxes are principled and two are negotiation currency.

• Must have is the smallest thing that genuinely solves the problem inside the timeline. Here: suppression of low-risk false positives to the agreed threshold, plus the mandatory two-stage human sign-off on high-risk drugs. Not elegant. Sufficient.
• Should have and Could have are your phasing — a confidence score beside each suppressed alert, an audit log of every suppression for the head of pharmacy to review, a weekly trend dashboard for the CMO. There is no science to which goes where. You populate them knowing you will lose two and win three.
• Won't have is the interesting one, and it is not where you put the features you rejected.

Won't-Have is where you put the biggest fear of the person who can block you. The head of pharmacy has told you, plainly, that she will not allow an AI to touch high-risk drug alerts. The CMO — who has lost some trust in her team after three adverse events — wants exactly that, and is going to ask for it. That misalignment already exists. It is not between you and the client; it is inside the client, and it is the kind of stakeholder fear that quietly decides whether your project ships.

So you write the line — "Phase 1 will not automate high-risk drug alerts" — into a formal document and put it in front of both of them. You are not refusing anything. You are making two people who report to the same board have their argument in week one, in front of you, while it is still cheap. Swallow the misalignment and it does not disappear; it waits until week six and then kills you, whichever of them wins. This is the difference between a scope contract's Won't-Have and a PRD's: in a PRD it means "we decided against this feature." Here it means "this is out of this phase, it is the thing you two need to agree on, and I have no vote."

#I — Implications: what happens after you succeed

Most engineers document what they build. The ones who survive delivery document what happens once it works.

Suppose the system does exactly what you promised. Pharmacists across five hospitals get back ten hours a day. That is the win. It is also, to a P&L owner, a headcount question — and the head of pharmacy knows it. So here is the sequence you can set your watch by: your most enthusiastic user, the one who gave you the real problem in the first place, hears the word "downsize," and the champion becomes a blocker overnight. Suddenly your working system has edge cases everywhere. A system that hit every number gets remembered as a failure.

You cannot solve this. It is not your organisation. What you can do is write one line — "cutting the false-positive rate from one in three to under one in ten frees roughly ten pharmacist-hours per day across the network; pharmacy management will need a plan for that capacity before go-live" — and hand the problem to the people whose problem it is. Surfacing it is the job. Solving it is not. The alternative is being told, accurately, that you never mentioned it.

#D — Dependencies: one owner, one date

Dependencies are what blocks Day 1 of engineering. Each one gets a single named owner and a single date, because a dependency owned by "the client" is owned by nobody.

1. The clinical definition of "low-risk." You are about to suppress alerts based on a category no one has defined, and you are not qualified to define it. Owner: the CMO and the head of pharmacy, jointly. Due: week 1. Without it, every sprint is blocked.
2. A labelled dataset. A sample of past alerts marked correct or incorrect — a few hundred rows, minimum. Owner: the pharmacy team. Due: week 2. Without labels you are not measuring anything; model quality is simply unknowable.
3. A regulatory and accountability sign-off. If a suppressed alert turns out to have been real, who is accountable? That is a legal answer, not an engineering one. Owner: the hospital's legal and compliance function.

Unless you say this explicitly, the operating assumption on the other side of the table is that they hired you and you will now magically deliver. Delivery is a joint process, and the half of it they own has to be written down with the same specificity as the half you own.

#The two fights you should expect

Hand this document over and you will get pushback in two predictable shapes, and the point of the document is that you get to have both arguments on paper instead of in production.

Must-have inflation. "A natural-language explanation for every suppressed alert is a must-have." "Why is zero adverse events not the requirement?" The second one you answer on principle — it is an implication, not a requirement. The first is a trade, and you should walk in knowing your currency: a feature moves up, and the timeline moves out, or a dependency you need in week two arrives in two days instead.

Won't-Have negotiation. "High-risk drugs are where the adverse events actually happen — you're missing the whole point." That is a fair challenge, and it is precisely the conversation you wrote the box to provoke. It is not yours to win. It is theirs to settle, in front of you, before anyone writes code.

#Keep the architecture out of it

The reflex — mine included — is to answer "what are you building?" with a diagram. Resist it. A head of pharmacy cannot evaluate your retrieval strategy, and burying the scope inside an architecture guarantees that nobody aligns on the scope. Rules engine, classifier, or LLM is a real decision with real trade-offs, and it belongs in the next meeting, in the PRD, and in how you bound the agent itself. This document answers one question only: what did you learn, what will you build, in what order, and what do you need from us.

#Stress-test the document before the client does

Before this goes in front of anyone, paste it into Claude or ChatGPT with a deliberately hostile prompt: "Act as a hostile IT director at a hospital network. Find the dangerous assumptions and the missing technical dependencies in this scope document." It is very good at the structural audit — thresholds with no number, assumptions with no owner or date, MoSCoW items with no justification, dependencies that block Day 1 and have no deadline.

What it cannot find is everything that makes the engagement real. That the CMO has not actually told the head of pharmacy the scope is limited to low-risk drugs. That two doctors define "low-risk" differently. That the EMR vendor has a history of blocking third-party integrations. That the person with veto power was not in the room when the project was approved. A model can audit the structure of your document. Only the discovery call gives you the room. That division of labour — the model checks the artefact, you supply the intelligence — is a fair description of the whole job.

#The real test: is the client aligned?

None of this is new, and it is worth knowing where it comes from. Mapping a room into champions, sponsors, blockers and end-users is a classic consulting two-by-two. The problem definition sheet is McKinsey's habit of pinning a problem down on paper before anyone proposes anything. The acronyms are teaching scaffolding — useful while you are learning the moves, and quietly discarded once you can make them.

Because in the field, nobody asks you whether you produced a scope contract. A project leader asks two questions, and they are the only two that matter: Is the client aligned? Will there be any surprises? Every requirement with a threshold, every logged assumption, every dependency with an owner and a date exists to let you answer yes and no. Scope creep is simply the most common surprise, and an unaligned client is how it gets in. If you can honestly say there will be no surprises, you have done the job — whatever you called the document.

One honest limit, because I would rather state it than oversell the method: alignment is with people, and people leave. If your sponsor moves on halfway through and their replacement does not care about this outcome, a signed scope document softens the landing — it does not save the project. The first question to ask a new sponsor is not whether they have read the contract. It is whether the thing you are building is on their agenda at all. If it isn't, no amount of documentation will put it there, and the sooner you know, the better.

#You don't get to negotiate what you didn't say

For most of my career my instinct has been that the reward for a good diagnosis is permission to start building — that once you genuinely understand the problem, the document is overhead standing between you and the interesting part. It reads as bureaucracy because it is bureaucracy. It is also the only artefact that makes the interesting part survivable, and learning to write it is a large part of what separates a developer from a forward deployed engineer.

Every line in it is written for a negotiation you have not had yet. The client will still push. They will still change the goalposts, still add features in week six, still miss the dependency they promised in week one. The document does not prevent any of that. What it gives you is something to point at when it happens — and, more importantly, it forces the expensive conversations to happen in week one, when they are still conversations.

You will negotiate everything. But you don't get to negotiate what you didn't say.