Choosing between forward-deployed and a project
The choice turns on one question: is the work understood well enough to describe, or does someone have to go and learn it? A practical guide to picking the engagement form.
· 4 min read
IN SHORT
Choose forward-deployed when the work lives in the heads of the people doing it and someone has to sit with the desk to learn the real packet. Choose an in-house project when the owner can already describe what arrives, what a good result looks like, who approves, and where it lands. Both end with the customer holding a version their team can change.
Customers sometimes ask which engagement form is better. The honest answer is that neither is, and the question that decides it is not about the practice at all. It is about how well the customer already understands the work they want built.
If the work can be described in a sitting, a project can carry it. If the work has to be learned by sitting with the people who do it, forward-deployed engineers go and learn it. This article lays out the signals that point each way.
Signals toward forward-deployed
The packet is not written down. Ask the person who owns the desk what arrives, what a good result looks like, which step a person still takes, and where the result lands. If the answer is "it depends" more than once, the packet lives in practice rather than on paper, and someone has to go and watch.
The exceptions are the job. Some desks spend most of their time on the main path and a little on exceptions. Others are the reverse: the main path is easy and the whole value is in handling what does not fit. Exceptions are rarely described well at the start of a project. They are learned on site.
The approving role is not obvious. If nobody can say cleanly who should approve before an action lands, the engagement will spend time discovering that, and it is better spent inside the segment with the people involved.
The team wants to own it from the first day. Forward-deployed work builds with the people who will run the use case. If the site team wants their hands on it as it takes shape, that is the form.
Signals toward a project
The outcome is clear and the owner can state it. A corpus of named documents that a named role can question. A desk whose inbound and outbound formats are already fixed by the systems on either side. A product whose behavior is specified because it is going to ship under the customer's name.
The materials, approvals, and systems are already known. A project scope names the material the use case may read, the calls it may make, the role that approves, and the systems of record. If the customer can fill in all four without a discovery phase, the scope is ready.
The site does not want engineers inside the segment for the build. Some sites prefer a scoped environment and a returned version. A project respects that, as long as the result runs on the customer's appliance in the customer's posture.
The work is a second version of something understood. Once a forward-deployed engagement has built the first version and the team has lived with it, the next version often has a clear enough shape to hand to a project.
When the result is a product
A product that customers run under the customer's own name is nearly always a project. The reason is that products have specifications. The customer's brand goes on it, the customer's terms apply to it, and the behavior has to be stated before it ships. That statement is the scope.
Czar Chassis is the path for this kind of work. The engineers build on the customer's appliance and the result carries the customer's name. A product that ships under your name describes what that engagement looks like.
When the posture decides
Posture does not force a form, but it shapes it. On an air-gapped site, forward-deployed engineers work inside the building with no path out, and material and versions move by the site's own procedures. A project for an air-gapped site has to be built in a scoped environment that matches the posture and returned by the same procedures.
Both are done regularly. The point is that the posture is taken as given at the start, and the form is chosen inside it. Forward-deployed on an air-gapped site covers the first case.
Picking wrong
The form is a starting decision, not a permanent one. A project that opens up a desk nobody had described becomes a forward-deployed engagement for that desk, with the scope renamed to match. A forward-deployed team that finds the work is simpler than feared can finish early and hand a clean scope to a project for the next version.
What does not change when the form changes is what the customer holds at the end: a published version on their appliance, the operating picture inside it, a record of how it behaves, and a team that can change it. The engagements page at /engagements describes both forms, and two ways an engagement can run sets them side by side.
Questions this raises
- Can a first engagement be a small project to see how the practice works?
- Yes, if there is a use case small enough to describe fully. A corpus people can question is a common first project because the scope is clear: these documents, this role, this appliance. It leaves the team with a running version and a feel for the stack.
- Is forward-deployed only for large sites?
- No. It is for work that has to be learned on site, regardless of the size of the site. A single desk with a complicated packet is a better forward-deployed candidate than a large floor with a simple one.
- What if our team wants to build it themselves with guidance?
- That is close to the forward-deployed form. Engineers build alongside the team, and the engagement finishes when the team can publish alone. The team does more of the hands-on work from the start, which is a question of pace, not of form.
KEEP READING