How to Scope a Forward Deployed Engineer Engagement
Most failed FDE engagements fail in the first week, when nobody wrote down what 'done' means or who grants access. This is the scoping process we use, and the one-page document it produces.
By the TARDIS Solutions engineering team · Updated
1. Write the outcome as an observable fact
Not 'integrate the AI assistant'. Instead: 'Analysts at Customer X use the assistant on their own documents, inside their VPC, with answers citing sources, by 15 March.' An outcome is something a third party could check. If you can't write it in one sentence, the engagement isn't ready to start; do a short discovery first.
2. Map the environment before anyone writes code
- Where does it run: your cloud, the customer's cloud, on-prem, air-gapped?
- What data does it touch, who owns that data, and what are the rules for moving it?
- Which systems must it integrate with, and who maintains each one?
- Which models are allowed: hosted APIs, open-weight models on local hardware, or both?
- What security review does the deployment have to pass, and how long does that take?
Every unanswered question here is a future delay. Write the unknowns down explicitly with an owner for each.
3. Agree access on day one
The single biggest cause of slow starts is access: repositories, cloud accounts, VPN, test data, a named contact at the customer. Make a list, assign each item to a person, and treat 'FDE has working access' as the first milestone. The goal for week one is a merged pull request, which is impossible without it.
4. Define success metrics you can measure weekly
| Type | Example |
|---|---|
| Delivery | Pipeline running in the customer environment; first users onboarded |
| Quality | Answer accuracy on an agreed test set of 100 real questions |
| Operations | Runbook covers restart, upgrade and rollback; on-call can follow it |
| Adoption | Number of weekly active users at the customer |
| Cost | Cost per completed task or per query within an agreed budget |
5. Set the cadence
- A written weekly update: what shipped, a short demo, decisions taken, risks, next week's plan.
- A decision log anyone can read, so choices survive the engagement.
- One named owner on your side who can make product decisions within a day.
- An overlap window in both time zones for live work.
6. Define the hand-over up front
Decide at the start what must exist at the end: architecture notes, runbooks, a recorded walkthrough, alerts wired to your on-call, and a list of known limitations. If hand-over is an afterthought, the system will depend on the FDE forever, which defeats the purpose.
The one-page scope template
- Outcome (one sentence, observable, dated)
- Environment (where it runs, data rules, model rules, security review)
- Integrations and their owners
- Access checklist with an owner per item
- Success metrics (delivery, quality, operations, adoption, cost)
- Cadence (weekly update, decision log, owner, overlap window)
- Hand-over deliverables
- Known unknowns and who resolves each
- Commercials (retainer or fixed push) and the conditions for extending or stopping
If the scope doesn't fit on one page, split it. Two short engagements with clear outcomes beat one long one with a vague goal.
Frequently asked questions
How long should scoping take?
Usually one call plus a written note within 48 hours. If the environment is unknown, add a paid discovery of a few days before committing to the full engagement.
Should the engagement be fixed-price or time-based?
Fixed-price when the outcome and environment are well understood; a monthly retainer when the work is ongoing or the environment is still being discovered. Either way the outcome and metrics should be written down.
What if the customer environment blocks the plan?
That's normal, which is why the scope lists known unknowns with owners. The weekly update surfaces blockers early and the decision log records how they were resolved.