How to Scope a Forward Deployed Engineering Engagement
To scope a forward deployed engineering engagement, settle five things before anyone builds: whether this should be forward deployment at all, whether the customer will let you in, the one workflow and the one number, who’s in the room, and how it ends.
Most scoping advice covers the build plan. These five decide whether it matters.
- Is this forward deployment?
- Will they let you in?
- One workflow, one number
- Who’s in the room?
- How does it end?
- Workflow
- Number
- Counterpart
- Day-one access
- Definition of done
- Review date
Should this be forward deployment at all?
If you already know exactly how your product gets deployed at a new customer, you need implementation, documentation and a good customer success team. Forward deployment earns its cost when every customer’s version of the problem is different enough that nobody can write the playbook in advance. A lot of teams call their implementation group FDE because the title is fashionable, so be honest here. I wrote about when you shouldn’t use FDE separately.
Will the customer let you in?
Forward deployment needs real access to systems and data, a sponsor with authority to change how work is done, and people who answer questions the same day. A customer who wants to “see what you come up with” from a distance won’t give you any of that, and no amount of engineering talent makes up for it. Test it before you commit. Ask for a named counterpart, and ask what access exists on day one. Then spend an honest hour on reconnaissance: have a model map their tools and sketch the integration, so you find the compliance wall on day zero and not on day four. Your own cost was never the scarce part here. The buyer’s attention, their data access and the hours of the person who checks the output are what an engagement spends, which is why a free one has nobody accountable for the result.
One workflow, one number
Scope it like your calendar depends on it. One workflow, one number to move, in their environment, with their data. If it wants to be three workflows, it’s three engagements, and you should say so while saying so is still easy. The number needs a baseline, a date and an owner, and it’s worth more care than it usually gets, so I wrote a separate piece on the exit criterion.
Who has to be in the room?
Security, legal and ops get invited on day one, not discovered in week six. Someone also has to own the business problem. A technical spec without a business owner is the mirror image of an engagement that works. And write the spec with the customer, in their language. That’s the job, and it’s most of what separates this from a handoff.
When to say no
Four situations, every time. The first is no counterpart: no named person, no real data, no same-day answers means no deal, whatever they offer to pay. The second is a segment of one, the fascinating customer with a workflow nobody else has. It’s flattering and lucrative, and it won’t compound, so take it only if you’re consciously billing it as agency work. The third is anything you can’t measure. “Make our ops smoother” isn’t a scope, and “cut ticket resolution time” is. The fourth is endless maintenance, because support for past customers eats the calendar unless it’s priced and templated.
Name the ending first
Start with what the customer’s team will know how to do the day you leave that it didn’t know the day you arrived. If the capability never moves inside, the day you leave is the day the system starts to rot. Then pick the day the engagement gets judged, and send the review invite when it starts, titled go or no-go, with the budget holder on it.
The page to agree before anyone builds
One call, then one page: the workflow, the number, the counterpart, day-one access, the definition of done, the review date. How you price it changes what belongs on it.