A data or AI diagnostic sells well. The client has a problem they cannot name precisely, six weeks of structured work names it, and the report lands with recommendations everyone agrees with. Then the engagement ends. Six months later the client has done two of the eleven recommendations, the sponsor has moved, and someone else is selling them the next assessment. The fee was real and the relationship went nowhere, because a report is a product that finishes. A running system is a product that keeps needing you. The difference between those two outcomes is almost never the quality of the analysis. It is whether the engagement was structured, from the day it was sold, to continue into a build.
This is written for the partner who sells the diagnostic and wants the follow-on. Precision Federal builds the systems on the other side of that transition. What follows is the structure that makes it one continuous piece of work rather than two sales, what the client signs at each gate, and why the engineering team has to be present from day one of the assessment rather than recruited after it.
Why the follow-on usually does not happen
The standard failure is not a lost competition. It is decay. The diagnostic ends, and between the last presentation and the next budget cycle four things go wrong at once.
The urgency evaporates. During the assessment the problem was in front of the sponsor every week. After it, the problem returns to the pile with everything else, and the pile is long. Momentum in a client organization is a real asset with a short half-life, and a gap of two months usually spends all of it.
The recommendation is not buildable as written. A report that says the firm should build a unified customer data platform is a direction, not a scope. To fund anything the client needs a number, and to get a number someone has to do the engineering work of specifying it, which nobody was paid to do. So the recommendation sits until an internal team gets around to specifying it, which is to say indefinitely.
The sponsor cannot self-fund the next step. The diagnostic was affordable from a discretionary budget. The build is not, so it must enter a capital process with its own calendar, its own template and its own competition for money. If the engagement did not produce the artifacts that process needs, the sponsor has to construct them alone, and they usually will not.
And the knowledge is in a document rather than in people who are still there. Whoever builds it in six months starts by rediscovering what the assessment already learned about the data, the systems and the constraints. That rediscovery costs weeks, and its cost is a reason the business case looks worse than it should.
Every one of those is structural, which is the good news, because structure is something you control when you write the proposal.
What makes a diagnostic continue into a funded build
Editorial weighting, illustrative rather than measured. The last row is low on purpose: the report is the thing firms optimize and the thing that predicts the follow-on least.
One engagement, three phases, three gates
The structural change is small and it happens at proposal time. Instead of selling an assessment with an implied next step, sell one engagement with three phases and a client decision at each boundary. The client is not committing to the whole thing. They are committing to phase one and to a decision date, which is an easier sale than an assessment, not a harder one, because it tells them where this is going.
Phase one, the assessment, four to eight weeks. Understand the problem, the data, the systems and the constraints. Ends with a finding and a recommended path, and with something the standard diagnostic does not produce: a scoped, priced plan for phase two, and an outline plan for phase three with a range.
Phase two, the pilot, six to twelve weeks. Build the narrow thing that answers the question the assessment could not answer from documents. Runs on real data, in an environment on the path to production. Ends with a measurement against a threshold agreed before it started, and with a firm price for phase three.
Phase three, the production build, three to nine months. The system the business uses, deployed where it will live, with the security, accessibility and operational work included rather than deferred. Ends with the receiving team deploying it while the build team watches.
The gates are what make this honest. At each one the client can stop, and stopping leaves them with something whole: after phase one a finding plus a priced plan; after phase two a measured answer and a working prototype; after phase three a system. A client who knows they can stop commits more readily than one who suspects they are being walked into an open-ended program.
What the client signs at each gate
Gate documents are short. Their job is to record a decision in a form that survives a change of sponsor, and to prevent the ambiguity that turns a phase boundary into a renegotiation.
| Gate | What the client sees | What they sign | What stopping here leaves them |
|---|---|---|---|
| Before phase one | Proposal naming all three phases, price for phase one, ranges beyond | Phase one order plus the gate dates | Nothing yet; the commitment is weeks, not budget |
| Gate one | Finding, recommended path, scoped and priced pilot, phase three range | Pilot order with its success threshold written in | A finding and a buildable, priced plan |
| Gate two | Measurement against the threshold, working prototype on real data, firm build price | Build order with acceptance criteria as tests | A measured answer and code they own |
| Mid-build gate | First increment running in the target environment, security review status | Confirmation of remaining increments | A working slice, deployable, plus the plan |
| Gate three | Acceptance run against each criterion, handover rehearsal complete | Acceptance and any support increment | The system, the code, the runbook |
Two details matter more than the rest. The pilot's success threshold is written and signed before the pilot starts, not argued afterward, and it is a number on a named data set rather than an adjective. And the build's acceptance criteria are written as tests at gate two, when everyone is calm and informed, rather than at the end when there is money on the table.
Why engineers belong in the assessment
This is the part most firms get wrong, and it is the one that changes the outcome most. An assessment staffed entirely with analysts produces a recommendation that has to be re-specified before anyone can price it. An assessment with an engineer in it produces a recommendation that is already a scope.
Concretely, here is what an engineer does during a six-week assessment that an analyst does not.
Profiles the actual data rather than the documentation of the data. Row counts, null rates by column, cardinality of the keys people intend to join on, how far the values drift from the schema, how many records fail the business rules everyone believes are enforced. This is a few days of work and it is the single largest source of estimate error in a build. A recommendation written from a data dictionary is written from fiction; the dictionary describes what the system was supposed to store.
Reads the integration surfaces. Not "the system has an API" but which endpoints, what they return, what the rate limits are, whether there is a batch path, what authentication is required and who owns the credentials. The difference between a documented modern interface and a nightly file drop from a customized decade-old installation is months of build, and it is invisible in an interview.
Establishes the deployment destination. Which cloud, which accounts, who approves a new service, what the security review requires, whether the result must reach an authorization before the business may use it, and what the accessibility requirement is. Federal destinations in particular carry control sets and evidence obligations that are ordinary planned work when known in week two and a crisis when discovered in month five.
Builds a small thing that runs. Not a pilot. A script that reads the real extract and produces a real number, or a stub service that authenticates against the real identity provider. It takes a day or two and it converts several assumptions into facts.
Starts the access and governance clocks. Directory accounts, source control, a development environment, a privacy review for the data the pilot needs. These are queues with owners, and starting them in week one of the assessment rather than week one of the pilot removes the most common cause of a pilot that stalls before it starts.
The cost of this is one engineer, part-time, for the duration of the assessment. The return is a phase two that can be priced firmly rather than guessed, a phase three range the client can take to a capital committee, and a pilot that begins building on its first day rather than its twentieth.
The pilot is a question, not a demonstration
Pilots fail as sales instruments when they are built to impress rather than to decide. A demonstration that works on curated data proves nothing the client did not already believe, and the client's technology organization knows it, which is why an impressive demonstration is often followed by silence.
A pilot worth funding is designed around one question that genuinely cannot be answered without building. Can this model reach the accuracy the business decision requires on the client's real data, including the awkward segments. Can the pipeline process a real day's volume inside the window operations needs. Will the users in this role actually complete the workflow, or will they go back to the spreadsheet.
Three design rules make it decisive.
Real data, including the parts nobody shows visitors. The hard segments, the legacy records, the entities with missing identifiers. A pilot that only handles the clean eighty percent has not tested the thing that decides the build.
The success threshold agreed in writing before it starts. Tied to the business decision, not to a benchmark. Accuracy that beats the current process by a margin that changes what someone does is the standard, and it is often lower than the number people reach for in a meeting.
Built on the path to production. The same cloud, the same identity, the same data boundary, deployed by a pipeline rather than by hand. A pilot on somebody's personal account with a copy of production data is a pilot that must be rewritten and will probably die in security review. Building in the destination costs a little more in week one and saves the entire rebuild.
A pilot designed this way sometimes answers no. That is a successful pilot and it should be sold that way from the start: this phase costs a defined amount and answers a question worth far more than that, and if the answer is no, the client has avoided a build that would have failed expensively. Firms that say this openly get more pilots, not fewer, because it is obviously true and it makes everything else they say more credible.
What separates a pilot that reaches production from one that does not
Editorial weighting, illustrative rather than measured. The last row is low because a curated demonstration proves nothing the client's engineers will believe.
Staffing the build from day one of the diagnostic
Continuity is a delivery mechanism, not a courtesy. The people who profiled the data during the assessment should be the people who build the pipeline, because the knowledge that makes a build fast is mostly undocumented: which columns lie, which team actually owns the credential, which of the client's stated rules is enforced and which is aspirational.
Practically, that means the engineering firm commits named people across phases at proposal time, with the allocation stated for each phase and a substitution path if a date slips. It also means the assessment carries a slightly higher cost than a pure analyst team, which is worth saying to the client plainly: this assessment costs somewhat more and produces a priced, buildable plan and a team that can start immediately, rather than a report that has to be re-specified before anyone can quote it.
The other half of continuity is the artifact set. An assessment that ends in a deck ends. An assessment that ends in a data profile, an integration map, a constraint list, a decision log and a scoped plan ends in a set of documents the build phase opens on day one. None of those take long to produce if the engineer was doing the work anyway; they are byproducts of the assessment being done properly, not additional deliverables.
Keeping the momentum between phases
Even a well-structured engagement has gaps, because a client needs time to decide and sometimes to find money. A few things keep the gap from spending the momentum.
Set the gate date at the start, in the calendar, with the decision-makers invited. A gate that floats is a gate that slips.
Keep something running. If the assessment built a small thing on real data, leave it running and keep it current. A dashboard someone opens weekly, or a report that lands on a Monday, is a live reminder that the work exists. This is worth more than any follow-up note.
Do the funding paperwork inside the paid phase. If the build must go through a capital process, the assessment should produce the material that process needs: the scope, the price, the benefit case with its assumptions stated, the risk register and the option analysis. Leaving the sponsor to write that alone is where most follow-ons die, and it is work you can do far better than they can.
And use the gap to advance the things that gate the build anyway. Access requests, the privacy review, the security architecture conversation. If the client says yes in six weeks, those six weeks were not lost.
How we work across the three phases
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 consultancy, that is both a route to government revenue for your clients and the reason our assessments treat the deployment destination as a first-week question rather than a final-month surprise.
In phase one we put an engineer alongside your team, part-time, for the duration. That engineer profiles the real data, reads the integration surfaces, establishes the deployment destination and its control requirements, builds one small thing that runs, and files the access requests. Your team owns the framing, the business analysis and the client relationship. What we hand back at the gate is a data profile, an integration map, a constraint list, a scoped and firmly priced pilot with its success threshold written, and a range for the production build with the assumptions behind it stated.
In phase two the same engineers build the pilot in the target environment against real data, with the threshold signed beforehand, and the gate produces a measurement rather than an impression. In phase three we build the production system in fixed increments against acceptance criteria written as tests, billed at milestones tied to demonstrable events, with security and accessibility work inside the increments rather than after them, and the handover is a rehearsal in which the receiving team deploys while we watch.
You keep everything that matters. 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.
The first step is one email with a one-page brief: what the client is trying to decide, the systems and data involved, the deployment destination if it is known, the date that matters, and who can approve a change. We return a scoped, priced statement of work for the assessment with the gate structure and the phase two pricing method written in. No call required.
Bottom line
A diagnostic that ends in a report is a fee. A diagnostic that ends in a running system is a relationship, and the difference is decided when the engagement is sold, not when the report is delivered. Sell one engagement with three phases and a client decision at each boundary, so stopping is always available and always leaves something whole. Put an engineer in the assessment so the recommendation arrives as a priced scope rather than a direction. Design the pilot around one question, on real data, in the environment the system will live in, with the threshold signed before it starts. Start the access and governance clocks in week one. Do the funding paperwork inside the paid phase. Each of those is cheap, and together they are the difference between a report on a shelf and a system the business runs on.
Frequently asked questions
Sell the whole path as one engagement with three phases and a client decision at each boundary, rather than an assessment with an implied next step. The assessment then has to produce a scoped, firmly priced pilot and a costed range for the production build, which is only possible if an engineer was part of it. Set the gate dates in the calendar at the start, keep something running between phases, and produce the capital-funding material inside the paid phase rather than leaving the sponsor to write it alone.
Because they produce facts an analyst cannot. Profiling the real data rather than the data dictionary is the single largest source of estimate error removed. Reading the actual integration surfaces distinguishes a documented modern interface from a nightly file drop, which is months of build. Establishing the deployment destination and its security requirements early turns them into planned work. And filing access requests in week one of the assessment removes the most common cause of a pilot that stalls before it starts.
Three things. It runs on real data including the difficult segments, not a curated sample, because the clean eighty percent does not test what decides the build. Its success threshold is written and agreed before it starts, tied to the business decision rather than a benchmark. And it is built in the environment the system will live in, with the same identity and data boundary and a real deployment pipeline, so security review is a step rather than a rewrite.
At gate one, the pilot order with its success threshold written in. At gate two, the build order with acceptance criteria expressed as tests, agreed while everyone is calm rather than at the end with money on the table. At a mid-build gate, confirmation of the remaining increments after the first one is running in the target environment. At the final gate, acceptance run against each criterion plus any support increment. Each gate should leave the client with something whole if they stop.
That is a successful pilot and it should be sold that way from the beginning. The phase costs a defined amount and answers a question worth far more, and a no means the client avoided a production build that would have failed expensively. Saying this openly tends to produce more pilots rather than fewer, because it is obviously true and it makes the rest of what the firm says more credible. It also requires the threshold to be written down beforehand, or there is no such thing as a clear no.