Finished when your people can publish alone
A forward-deployed engagement does not end on a date or a demo. It ends when the site team publishes a version of the use case through their own approval, without an engineer's hands on it.
· 4 min read
IN SHORT
A forward-deployed E31 engagement is finished when the site team can publish the next version of the use case themselves: make a change in Agency Studio, send it through the approval the version names, and publish it on their own Czar with no engineer touching the work. That capability, not a demo or a date, is the end condition.
Ask most consulting practices when an engagement ends and the answer involves a date, a deliverable list, or a sign-off meeting. Ask E31 Consulting when a forward-deployed engagement ends and the answer is a thing the customer's team does: they publish the next version alone.
That is a deliberate choice of end condition, and it shapes the whole engagement before it. This article describes the test, what it covers, and what happens if the team is not there yet.
The test
Toward the end of a forward-deployed engagement, the engineers step back and the site team runs the full loop without them.
Someone on the team opens Agency Studio on the appliance and makes a change the desk actually needs. Material is added to the corpus. A bound is adjusted because the desk found it too tight. A route is updated because the system on the other end changed. The approving role is reassigned.
The change goes through the approval the version names. That approver is a person on the site team, in the role the version declares. They review it and approve it, or send it back.
The team publishes the new version. It runs on the appliance. They look at the run record and confirm the version is behaving the way the change intended.
The engineers watch. They answer questions if asked. They do not touch the work.
What the test is really checking
On the surface the test checks a skill: can the team use Agency Studio, route an approval, and publish. Underneath, it checks something more important.
It checks that the operating picture lives where the team can reach it. Who may publish, which model the version uses, where a person has to approve, which systems it may call: all of these are properties of the version. If the team can read them and change them, the picture is theirs. If they have to ask an engineer, it is not.
It checks that the documentation is the right documentation. The notes handed over are meant for operators making a change. If the team needs them during the test and the notes work, the handoff is real.
It checks that the approving role was set correctly. If the approver during the test is surprised by what they are asked to approve, the version was not built with them closely enough.
If the team is not there yet
Then the engagement is not finished. This is not a failure of the team; it is the definition of the end condition doing its job.
The engineers keep working alongside the team until the loop holds. Sometimes the gap is a skill, and more time with the keyboard closes it. Sometimes the gap is structural: the approving role has not been settled, or nobody has been named to own publishing. Those are fixed with the site, not around it.
What the practice does not do is declare the engagement finished and leave the team with a version they cannot change. That is the outcome the end condition exists to prevent.
Why this end condition and not another
A demo proves the version works today. A document proves the engineers understood it. Neither proves the team can keep it working when the desk changes, which it will.
A use case that cannot be changed by the people who run it is a liability with a short life. The first time a system on the other end of a route changes, or the desk's packet shifts, the version either gets changed or gets abandoned. The practice counts an engagement as finished only when the first of those is possible.
After the test
When the team has published alone, the engineers leave. Their access is withdrawn under the site's rules. Nothing leaves the building. The version, the corpus, the adapters, the run record, and the documentation stay on the appliance, where they always were.
The team now owns a use case they built, with a picture they can read and a loop they have run. How an engagement ends covers the full close for both engagement forms, and building with the people who will run it describes how the engagement gets the team ready for this test. The engagements page at /engagements sets out the forward-deployed form end to end.
Questions this raises
- What counts as a real change for the test?
- Something the desk would actually need: new material added to the corpus, a bound adjusted, a route changed, the approving role updated. The practice avoids toy changes because the point is to show the team can handle what the desk will throw at them.
- Who performs the approval during the test?
- The named role the version declares, which is someone on the site team. The engineers do not stand in for the approver, because the test is of the team's own loop.
- What if only one person on our team can do it?
- That is a weaker end state than the practice aims for, and it is a conversation to have before the engineers leave. The documentation handed over is written so a second person can follow it, and the engagement can extend to bring a second publisher through the loop.
KEEP READING