A scoped project prices certainty: a defined deliverable, a defined fee, and a change order every time the question moves. An embedded consultant prices flexibility instead. Choose scoping when you can describe the output precisely, and embedding when the shape of the work is what you are still working out.
What is an embedded consultant?
An independent working inside your team for a defined period, on your systems, in your meetings. The deliverable is capacity and judgment rather than a document, and the engagement is measured in time rather than in output — which is how a sector practice most often buys one.
That makes it flexible and it makes it harder to hold. An embedded engagement without a named outcome tends to become general assistance, which is expensive and not what anyone intended.
| Embedded | Scoped project | |
|---|---|---|
| You are buying | Capacity and flexibility | A defined deliverable at a defined price |
| Handles scope change | Absorbs it | Re-prices it |
| Fails when | Nobody owns the outcome | The question changes halfway |
What does a scoped project buy?
Certainty about the deliverable and the price. That is genuinely valuable when the question is settled, and it transfers delivery risk to the firm doing the work.
It also imposes discipline on the buyer. Writing a scope forces you to state what you want, which frequently reveals that you do not yet know — the discipline a research desk applies to every incoming brief.
Which work suits which model?
Scope it when you can describe the output precisely and the question will not move. Embed when the shape of the work is what you are still working out — and settle separately whether the person doing it should be a consultant or an operator.
The tell is how many times the brief has been rewritten. Work that has been rescoped twice before anyone was hired will be rescoped again after.
Rescoping history is a usable signal because it is a matter of record rather than of judgment. Anyone can count how many versions of the brief exist and how far apart they are, and a brief that has been through three drafts in two months is describing a question still in motion. That is a scoping decision made from evidence rather than from a preference about engagement models.
What happens when scope moves?
A scoped engagement re-prices. Every change order carries a negotiation, a delay and a small amount of relationship cost, and three of them consume the price advantage the scoped model started with.
An embedded engagement absorbs the change and carries a different risk: nobody notices that the work has drifted until someone asks what was delivered.
Both risks have the same remedy, applied at different points. A scoped engagement needs a change-control process quick enough to use, and an embedded one needs a review point frequent enough to catch drift. Neither is expensive, and the failure in each case is that the mechanism existed on paper and nobody ran it.
When should you switch models?
Once the question stabilizes. The moment you can describe the output precisely, a scoped engagement is cheaper and easier to hold someone to, and continuing to embed is paying for flexibility you no longer need. Whether that scope goes to an individual or a firm turns on what the leverage model is actually buying.
The reverse switch is rarer and usually a sign that the original scope was written too early.
The switch also works better as a scheduled review than as a judgment call. Agreeing at the outset that the engagement will be reassessed at a named point, with the explicit option of converting to a scoped deliverable, makes the conversation routine. Without it, proposing the switch reads as dissatisfaction with the person rather than as progress on the question.