Scoping an FDE engagement: the first week decides the next three months

Most forward-deployed engagements that go wrong were already wrong at the end of week one.

Not because the engineer was bad. Because the scope was agreed before anyone had seen the systems, and the description the client gave in the sales conversation turned out to be a description of what they wished they had.

This is the part of the job no course covers, and it is the part that determines whether the next three months are productive or a slow renegotiation.

The gap between the pitch and the environment

You will be handed a brief. It will say something like: "Build an agent that answers questions about our inventory using our ERP data."

That sentence contains at least four unverified claims:

1. That there is an ERP with a queryable interface.
2. That the inventory data in it is current.
3. That someone can tell you what "our inventory" means, unambiguously, across the whole company.
4. That the people who will use the agent are the people who asked for it.

In my experience roughly one of those four holds on arrival. Your first week is not building. It is finding out which one.

The discovery week

Five days, structured. Resist the pressure to show code before Friday — an early demo built on a misunderstanding is worse than no demo, because it makes the misunderstanding official.

Day 1 — Read the systems, not the docs

Ask for read access to the actual systems before you ask for documentation. Documentation describes intent; the database describes reality, and where they disagree the database wins.

Three queries to run on day one, whatever the domain:

• Row counts by month for the last two years. Gaps and cliffs tell you when something changed, and nobody will mention it unprompted.
• Null rates on the fields your use case depends on. If the field you were going to key on is 40% empty, your scope just changed.
• Distinct values on anything that looks like a category. You will find seven spellings of the same warehouse.

You are not auditing. You are calibrating how much of the brief survives contact.

Day 2 — Find who actually does the work today

The person who commissioned the project and the person whose job it changes are almost never the same person, and the second one has not been consulted.

Ask to sit with whoever currently does the task manually. Not a meeting — sit with them for an hour while they do it. Every engagement I have seen go sideways had a version of this moment available in week one and skipped it.

What you are listening for: the steps that are not in any process document. The spreadsheet they keep on the side. The three exceptions they handle from memory. Those exceptions are usually 30% of volume, and they are always missing from the brief.

Day 3 — Establish what "working" means, in a number

This is the day that saves the engagement.

Push until you have a measurable definition of success, agreed by the person who controls the budget. Not "the agent answers inventory questions." Something like: "For the 20 questions the ops team asks most, the agent gives an answer the ops lead would have given, at least 17 times out of 20."

If you cannot get to a number, that is your finding. Report it as one. A scope without a definition of done is not a scope, it is an open-ended commitment, and you will be the one holding it in month four.

The eval framing here is the same one an internal AI Agent Manager needs — the difference is that you have to negotiate it with someone who is paying you.

Day 4 — Map the integration surface honestly

For each system you need to touch, write down four things:

	Question	Why it matters
Access	Do you have credentials, or a promise of credentials?	A promise is a two-week delay
Interface	API, database, file drop, or screen?	Screen means browser automation and a different estimate
Rate limits	What are they, actually?	The most common late-stage surprise
Owner	Who approves changes, and are they in this project?	An unlisted approver is a three-week delay

The internal AI stack architecture piece covers the technical shapes. The scoping question is narrower: which of these do I not yet have, and who do I need to ask this week.

Day 5 — Write the scope memo, and make it uncomfortable

Two pages, delivered Friday, containing four sections:

What I found. The state of the systems and data, in specifics. Numbers, not adjectives.

What I can build in [timeframe]. Concrete, and narrower than the brief. It should feel slightly disappointing to the reader. That feeling now is much cheaper than the same feeling in month three.

What I cannot build, and why. Name it explicitly. "Real-time inventory is not possible because the ERP syncs nightly" is a sentence that prevents a quarter of pain.

What I need from you, by when. Credentials, an approver's time, a decision. With dates. This section is how you convert your blockers into their blockers, which is where they belong.

Sizing: the multiplier that is actually real

A rule that has held for me across engagements: take your estimate for the same work in a codebase you know, and multiply by three.

Not because the engineering is harder. Because of the tax that is invisible from outside:

• Getting access to a system: days, not hours, and it recurs
• Discovering an undocumented constraint: at least once per integration
• Waiting on a decision from someone with four other priorities: the single largest line item
• The exceptions the manual process handles silently

If the client pushes back on the multiplier, do not defend the number — show the discovery-week findings that produced it. "We found 7 warehouse spellings and the ERP syncs nightly" argues better than an estimate.

Three scoping mistakes that cost the most

Agreeing to a deliverable defined by capability rather than outcome. "An agent that can query the ERP" is done the moment it returns any row. "The ops lead stops asking IT for stock reports" is a real finish line. Only one of these can be signed off.

Scoping around the person who hired you. They are frequently not the user, and sometimes their mental model of their own systems is a year out of date. Verify with the operators.

Treating the pilot as a smaller version of the real thing. It is not. A pilot on clean data with three enthusiastic users tells you almost nothing about a rollout to sixty. Scope the pilot to answer a question — usually "does the retrieval work on our real documents" — rather than to be a small deployment. Running your first AI pilot covers the design.

What good scoping looks like from the client's side

The engagements that go well share a pattern: by the end of week one the client knows something about their own systems that they did not know on Monday, and they are slightly alarmed by it.

That is the deliverable. You are not there to confirm their plan. You were hired because they cannot see their own environment clearly from inside it, and the first valuable thing you produce is an accurate description of it.

If your week-one memo tells the client only what they already believed, you have not done discovery. You have done onboarding.

Try this today — 30 minutes

Take an engagement or project you are currently on — client work, or an internal build, it works the same either way — and write the "What I cannot build, and why" section of the scope memo. Just that one section.

Three to five bullets. Each one a specific thing someone currently expects, and the concrete reason it is not possible as described.

Two things will happen. You will find at least one item you have been quietly hoping nobody asks about. And you will find one that turns out to be possible after all, once you write down the actual constraint rather than carrying a vague sense of difficulty.

Then send it. The discomfort of sending that list is the entire skill — it is much smaller now than the conversation you avoid by not sending it.

Related: What is a Forward Deployed Engineer · When the client's data is worse than they said · The handoff that survives your departure