The strategy phase closes well. The recommendation is agreed, the sponsor is committed, and the final document is the best thing the team has produced this year. Then it is handed to whoever will build the result, and something odd happens: the engineers read it and cannot start. Not because it is wrong, and not because they are being difficult. Because a document written to persuade a decision-maker and a document written to begin engineering work are different objects with different contents, and almost nothing that makes the first one good appears in the second. The gap between them is usually weeks of rediscovery, paid for twice and enjoyed by nobody.
This is fixable with a short artifact and about two days of work at the end of a strategy phase. Precision Federal receives these handoffs and turns them into priced plans, so we have a clear view of which ones work. What follows is what a real handoff contains, why each item is there, and how a partner converts it into a scoped, priced plan inside a week.
Why the strategy document cannot be the handoff
A strategy deliverable is built to move a decision. It leads with the conclusion, argues from evidence, handles objections, and quantifies a benefit. That is exactly right for its purpose, and it means several things are deliberately absent.
Options are collapsed. The document presents the chosen path, because presenting three live options would weaken the recommendation. An engineer reading it cannot tell whether the alternatives were rejected on grounds that also constrain the build, or simply not chosen.
Constraints appear as assumptions in an appendix, if at all. The build's cost is driven almost entirely by constraints: this must run in that environment, this data may not leave that boundary, this must be usable by people with assistive technology, this must be live before that regulatory date. In a strategy document those are footnotes. In an engineering plan they are the shape of the work.
Systems are named at brand level. "Integrate with the customer platform" is a sentence that covers a documented modern interface and a decade-old customized installation with a nightly file drop. Those are different projects with the same description, and the difference is months.
And success is described in business terms, which is correct for a business case and untestable as an engineering obligation. "Improve underwriter productivity" cannot be accepted or rejected. Something has to convert it into a statement that is either true or false on a given day.
None of this is a criticism of the strategy work. It is an argument that a second, small artifact is required, and that writing it is a task with an owner and a deadline rather than something that happens by itself.
What a handoff document needs in order to be priced without guesswork
Editorial weighting, illustrative rather than measured. The last row is low because the persuasive document and the buildable one answer different questions.
The six sections of a handoff that works
A working handoff is four to eight pages. It is not a specification and it should not attempt to be one; specifying the system is the engineering team's job and doing it in advance without them produces a specification nobody can build to. Its job is to close the questions only the strategy team can answer.
1. The decision
One page. What has been decided, what has been funded, what remains open and who will close each open item. Include the options that were rejected and why, in a sentence each, because a rejected option is often the first thing an engineer proposes and rediscovering the reason costs a meeting. If part of the decision is conditional, say what the condition is and who tests it.
State the ambition level plainly: whether this is a system for one team, an enterprise capability, or something that must eventually serve external users. That single sentence changes the architecture more than any other fact in the document, and it is regularly left out because inside the strategy team it is obvious.
2. The constraints
A list, not prose. Each constraint stated as a fact with a source. The cloud or data centre the result must run in. The technologies the client's operations team supports and will support at handover. Data residency and any boundary the data may not cross. Whether the result handles regulated, personal or controlled information. The accessibility requirement, which for public sector work and increasingly for large commercial buyers is not optional. Any authorization the system must reach before the business may use it. The dates that carry a consequence and what the consequence is.
Mark each constraint as firm or negotiable, and name who can negotiate it. A constraint list where everything is firm is usually a list nobody has tested, and it is the fastest way to a price that is higher than it needed to be.
3. The data inventory
For each data set the result needs: what it is, which system holds it, who owns access, how it is obtained today, roughly how much of it there is, how often it changes, its known quality problems, and whether its permitted use covers this purpose. That last item deserves its own column, because a data set that exists and is accessible but whose permitted use is unclear will sit in a governance review while the build waits.
If the strategy phase profiled the data rather than reading the data dictionary, include the profile: null rates on the columns that matter, cardinality of the join keys, the share of records failing the business rules everyone believes are enforced. This is the single most valuable page in the entire handoff. Data that is worse than documented is the most common cause of a build overrun, and a profile converts that risk from a surprise into a planned piece of work.
4. The integration map
Every system the result touches, named by product and version, with the direction of flow, the mechanism available today, who owns it, and whether a change to that system is required. A system requiring a change owned by another team is a dependency with a different calendar, and it must be visible from the first day rather than discovered in week seven.
Include what already exists and works, because reuse is cheap and reinvention is not. Also include the systems the result must not touch, which is a real constraint and rarely written down.
5. The acceptance criteria
The section that most improves the quality of what comes back, and the one most often skipped because it feels like the engineers' job. It is not. Only the business side can say what would count as success. The engineering side turns those statements into tests.
Write each as something that is either true or false on a stated day. A threshold on a named data set. A response time at a stated concurrent load. A named role completing a named workflow without help. A deployment that runs from a clean checkout into the target environment. A report reconciling to an existing source within a stated tolerance. Where the target is genuinely unknown, say so and mark it as a question for a pilot phase rather than writing an aspiration and hoping.
6. The owner
One named person who can approve a scope change, and the time within which they can do it. Plus the business owner whose work the system changes, the technical contact who can grant access, and whoever holds the budget. Four names, four roles, with the escalation path and its time limits.
An owner who requires a monthly committee is a real fact and should be written down, because a partner will price the delay it implies and should. It is better to fix the governance than to hide it.
What it looks like beside the usual handoff
| Item | Typical strategy deliverable | What an engineering team needs |
|---|---|---|
| The decision | The recommended path, argued | What is decided, what is open, what was rejected and why |
| Systems | Named at brand level in a diagram | Product and version, interface available today, owner |
| Data | Described qualitatively, sized approximately | Inventory with owner, access route, permitted use, measured quality |
| Success | A business outcome and a benefit case | Statements that are true or false on a stated day |
| Constraints | Assumptions in an appendix | A marked list: firm or negotiable, and who can move each one |
| Timing | A target date | Dates with consequences, and the dependencies that gate them |
Where the weeks go when a handoff is incomplete
Editorial weighting, illustrative rather than measured. The last row is low because reading the deliverable is the fast part; everything it omits is the slow part.
Running the handoff as an event, not a delivery
Sending the document is not the handoff. Three sessions across a week make the difference between a plan and a guess, and they are short.
A walkthrough with the strategy team, ninety minutes. The engineering team reads the document beforehand and arrives with questions. The purpose is to surface the things that are obvious inside the strategy team and invisible outside it, which is always the largest category. Every question that cannot be answered in the room becomes an open item with a name and a date.
A systems session with the client's technology people, two hours. The engineers and the people who actually run the systems, without the business audience. This session routinely changes the plan, because it is where the file drop that is documented as an interface, the environment that cannot take new services until the next quarter, and the credential that requires a signed agreement all come to light. Skipping it is the most expensive economy available in this process.
A data session with the owners and, where relevant, governance, ninety minutes. What can be released, to whom, on what timetable, and what has to be requested formally. Start the requests in this session rather than after it. Access is a serial dependency and the queue does not begin until someone files.
Between these, one useful piece of work: someone builds a small thing that runs against the real data. A script that produces a real number, or a stub service that authenticates against the real identity provider. Two days of effort that converts a handful of assumptions into facts, and it is the reason a plan produced in this way holds up.
Turning it into a priced plan inside a week
With those six sections and those three sessions, a competent engineering firm can return a scoped, priced statement of work in about a week. Here is what happens inside that week, so the shape of the answer is predictable.
The acceptance criteria are turned into tests and the gaps are named. Anything untestable comes back as a question rather than being priced with silent contingency.
The work is decomposed into increments of a few weeks, each ending in something demonstrable rather than in a document. The first increment is deliberately about the riskiest unknown, not the easiest feature, so that a bad surprise arrives while it is still cheap.
Each dependency is dated and its owner named, and the client-side ones are stated with a consequence: if this extract arrives more than two weeks late, these dates move by the delay and the price is revisited at a stated rate. This single practice removes the most common cause of a margin dispute later.
The pricing shape follows the certainty. Where the scope is testable, fixed increments against written criteria billed at milestones. Where genuine unknowns remain, a short committed-team increment with a hard stop and a written finding, and a commitment to price the rest firmly at the end of it. A partner who quotes fixed price for something nobody can specify has either loaded the number heavily or is going to be back for a change order.
And the assumptions are stated explicitly enough that the client can correct them. An assumption written down is a question. An assumption left implicit is a dispute with a delay fuse on it.
Making this the firm's default
A handoff template is worth adopting across a practice rather than writing per engagement, and it pays back in three ways.
It changes what the strategy phase collects. A team that knows it must produce a data inventory with permitted use will ask about permitted use during interviews rather than assuming it. The work happens once, at the moment when access to people is easiest.
It makes the follow-on build sellable. A recommendation accompanied by a buildable, priced plan is a proposal. A recommendation alone is a direction the client must convert to a proposal themselves, which mostly means it waits until someone else sells them the conversion.
It makes engineering quotes comparable. When every handoff has the same shape, quotes from different partners differ on approach and price rather than on how much each firm guessed about a vague brief, and the firm gets better at reading the differences.
Assign the template a single owner in the practice, review it after each use, and keep it under eight pages. A handoff template that grows into a thirty-page standard will not be completed and will quietly stop being used.
How we take a handoff
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack web and mobile software, and delivers them into production, including inside U.S. federal agencies where a system must pass security authorization, handle controlled information and meet accessibility requirements. For a firm closing a strategy phase, that matters twice: it is a route to government revenue for your clients, and it is why we treat the deployment destination and the control requirements as first-week questions rather than late surprises.
Send the six sections in whatever form you have them. Within about a week we return a scoped, priced statement of work: acceptance criteria written as tests, increments of a few weeks each ending in something demonstrable, the riskiest unknown addressed first, every dependency dated with an owner, client-side dependencies carrying a stated consequence, and a pricing shape that matches the certainty rather than the one that is easier to sell. Where the brief has gaps we come back with questions instead of pricing them silently.
You keep everything. You keep the client relationship, and we do not approach your client independently during the engagement or after it without your agreement. You keep the code and the intellectual property, transferred by a written present assignment rather than a work-for-hire recital, with our pre-existing tooling named, carved out and licensed to you perpetually. You keep the data, held inside the boundary we agree and never used to train anything. We work under your brand where you prefer it, and handover at the end is a rehearsal in which the receiving team deploys while we watch.
The first step is one email with a one-page brief, and it does not need to be the full six sections to start: the decision the client has funded, the systems involved named by product and version, what data exists and who grants access, the deployment destination, the date that matters, and who can approve a change. No call required.
Bottom line
The document that closes a strategy phase is built to move a decision, and it is missing the six things an engineering team needs in order to start: what is decided and what is still open, the constraints marked firm or negotiable, a data inventory with owners and permitted use, an integration map naming products and versions, acceptance criteria stated as tests, and one owner who can approve a change within days. Writing those takes about two days at the end of a phase when the knowledge is still fresh and the access is still open. Run the walkthrough, the systems session and the data session in the week that follows, and build one small thing that actually runs. Do that and a scoped, priced plan comes back in a week instead of a month, and the weeks usually spent rediscovering what the strategy team already knew are simply not spent.
Frequently asked questions
Six sections in four to eight pages. The decision, including what is still open and which options were rejected and why. The constraints, listed and marked firm or negotiable with a named person who can move each one. A data inventory with owner, access route, permitted use and measured quality. An integration map naming products and versions. Acceptance criteria written as statements that are true or false on a stated day. And one owner who can approve a scope change, with a time limit.
Because it is built to move a decision, which means options are collapsed, constraints sit in an appendix as assumptions, systems are named at brand level, and success is described in business terms that cannot be tested. Each of those omissions is correct for a persuasive document and each one costs an engineering team days or weeks to reconstruct. The gap is normally weeks of rediscovery, and closing it takes about two days of writing while the knowledge is still fresh.
Both sides, in that order. Only the business side can say what would count as success, so they write the statements. The engineering side turns each one into a test: a threshold on a named data set, a response time at a stated load, a named role completing a workflow unaided, a deployment that runs from a clean checkout. Where the achievable target is genuinely unknown, mark it as a question for a short pilot phase rather than writing an aspiration and hoping it holds.
About a week, if the handoff is complete and three short sessions happen: a walkthrough with the strategy team, a systems session with the people who actually run the client's systems, and a data session with the owners and governance where relevant. The systems session is the one most often skipped and the most valuable, because it is where the documented interface turns out to be a nightly file drop. Expect questions back rather than silent contingency where the brief has gaps.
The data profile, if the strategy phase produced one. Null rates on the columns that matter, cardinality of the keys people intend to join on, and the share of records that fail the business rules everyone believes are enforced. Data being worse than its documentation is the most common cause of a build overrun, and a measured profile converts that from a surprise in month three into planned work in the estimate. It takes a few days and it changes the price honestly in both directions.