The deck lands well. The client agrees with the finding, the sponsor nods at the roadmap, and then somebody in the room asks when it will run. Not when the next phase starts. When the thing described on slide fourteen will exist and produce numbers. That question converts an advisory engagement into a delivery engagement, and almost nothing about the first shape carries over into the second. Scope changes character. Staffing changes shape. Risk moves from being wrong to being late. Acceptance stops being agreement and becomes a test. The client relationship, which was built on judgment, now depends on something working. This is what actually changes, and how to bring in engineering without losing control of the room or the margin.
Precision Federal builds AI systems, data platforms, cloud infrastructure and full-stack software and delivers them into production, including inside U.S. federal agencies. We are brought into engagements at exactly this moment often enough that the pattern is familiar from the inside. What follows is written for the engagement manager or partner who now owns a build.
What changes the moment software is in scope
An advisory engagement and a delivery engagement look similar on a staffing plan and behave nothing alike.
The unit of progress changes. In advisory work, progress is a finding: something is now known that was not known before, and knowledge accumulates in a straight line. In delivery, progress is a working system, and it does not accumulate in a straight line. Weeks three through six can produce enormous work and no visible output, because integration and access are being solved. A partner who reports progress the advisory way during those weeks will be accused of stalling, and a partner who reports it the delivery way needs a client sponsor who understands why the demonstration is thin.
The failure mode changes. Advisory work fails by being wrong or by being ignored. Delivery work fails by being late, by being unusable, or by not passing a review nobody scoped. Late is the dominant one, and lateness in software is almost never caused by writing code slowly. It is caused by waiting: for data access, for an environment, for a security review, for a decision only one person can make.
The client's people become dependencies. An advisory engagement needs the client's time for interviews and steering. A delivery engagement needs the client's engineers, their identity administrators, their data owners, their security reviewer, and their change-approval process. Every one of those is a queue the engagement does not control, and every one has to be entered early.
Acceptance becomes binary. A report is accepted when the sponsor agrees with it. A system is accepted when it meets criteria or does not. That is better for everyone, provided the criteria were written down while the relationship was still warm.
What actually determines whether the build lands on time
Editorial weighting, illustrative rather than measured. The last row is deliberately low: headcount is the lever most often pulled and the least effective.
Rescoping the engagement before the price is quoted
The most expensive mistake at this juncture is quoting a build price from the deck. The deck describes an outcome. A build price requires knowing what the outcome sits on top of, and there are six questions that have to be answered before a number is defensible.
What system does the result live inside? Named by product and version. A recommendation engine that surfaces inside an existing customer platform is a different project from the same engine with its own interface, and the difference is usually larger than the engine.
What data exists, where does it sit, and who grants access? Not what data the client believes exists. What is actually retrievable, in what format, at what refresh cadence, with whose approval. This one question, answered honestly in week one, prevents most overruns.
Where does it deploy? The client's cloud account, their on-premise estate, a regulated environment with its own control requirements. The destination determines the security work, and the security work is frequently a third of the effort.
Who operates it after go-live? If the answer is nobody, the engagement is building a demonstration. If the answer is the client's platform team, that team's standards become requirements and should be gathered before the design is fixed.
What has to be true for the client to say it works? Written as a threshold on a named dataset, a latency figure at a stated load, a report that reconciles to a known source. Accurate, scalable and production-ready are adjectives, and adjectives never get accepted.
Who can approve a change of scope? One person, named, reachable. Engagements where three people can each add scope and none can remove it are engagements that end badly regardless of engineering quality.
A competent engineering partner can answer all six with the client in a few days and return a scoped, priced statement of work. The temptation to skip this because the client wants a number this week is exactly the temptation to resist.
The engineering the deck did not price
Decks price the visible system. Builds spend their time on three things that rarely appear on a slide, and an engagement manager who understands them will estimate far better than one who does not.
Integration is not a diagram. The diagram shows three boxes and two arrows. The reality is source systems exporting on different schedules, so a joined view is never consistent as of a single moment. Identifiers that do not match because one system pads them and another trims. Records restated after publication, so a figure computed in March differs from the same figure recomputed in May, and the client's finance team will notice within a week of go-live. Time values stored without zone information across years of history. Every one of these is discoverable in the first fortnight with real data and invisible for months without it.
Identity and access is the review that stops projects. Who may see which rows, enforced where the data lives rather than in the interface. Group membership pulled from the client's directory rather than maintained by hand. Approval paths that match the client's real delegation of authority, which never matches the org chart. Retention and deletion rules. Audit logging that shows who saw what and when. A build that treats this as a late-stage concern discovers in the security review that the data model needs changing.
Operations is what separates a system from a demonstration. Logging that answers a question at three in the morning. Alerts with named owners. Backups verified by restoring them. A documented upgrade path for dependencies. A runbook a person who did not build it can follow. Without these, the client has a thing that works until the first time it does not.
Where the effort goes on a build the deck did not price
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the model is the part every deck already scoped.
Bringing engineering in without losing the room
The concern behind hesitating here is not cost. It is that an outside engineering firm will build a direct relationship with the client and the engagement will be diluted or lost. That risk is real and it is almost entirely a governance question.
- Two leads, one channel. The engagement manager owns the client relationship, the scope and every commitment. The partner supplies a technical lead who owns architecture and schedule and speaks to the client through the engagement, not around it. No engineer agrees to new scope in a client meeting.
- Brand posture decided in advance. On commercial work the default is that the partner works under the firm's brand: the firm's account in the client's tooling, the firm's document templates, the firm's stand-up. That should require no negotiation. Revisit it only where naming the technical group demonstrably helps, such as a handover to the client's own engineers or a public-sector evaluation.
- Weekly working demonstration. Software running on a shared screen. A status document is a claim; a demonstration is evidence. Six consecutive weeks of written status with nothing to show is the reliable early signal of trouble.
- A shared plan the firm can read alone. Milestones with acceptance criteria, in the firm's own tracker. Two people on the firm's side should be able to state what is due next and what is at risk without asking the partner.
- A client-safe voice, tested early. Engineers in a client room should not advocate for technology choices, criticise the client's existing systems, or speculate about timelines. Put the technical lead in front of the client early and watch, rather than accepting a promise about conduct.
Pricing so the engagement margin survives
An advisory engagement prices judgment. A build prices risk, and the question is who carries it. Three shapes are available and they are not interchangeable.
Hours. The firm buys time and supplies direction. All estimation risk stays with the firm. This is only sensible where the firm has a technical lead who owns the design and the schedule, and most engagement teams do not.
A committed team. Named engineers at stated allocations for a stated period, with a technical lead. Scope flexes week to week; the cost does not. This suits work still forming, and it lets the firm quote a client a monthly figure with confidence.
Fixed-price milestones. The partner owns the estimate and the sequencing and accepts the risk of being wrong about either, in exchange for scope discipline. This is what lets a firm quote a number to a client and keep a margin on it, and it only works where acceptance is written as tests.
For an engagement that has to protect margin, fixed-price milestones for the parts with a written destination, plus a committed increment for the parts still forming, is the shape that holds. The rate matters less than the shape, because a fixed number is a markable line item and an open-ended hourly commitment is a liability the firm carries alone.
| Dimension | Advisory phase | Delivery phase | What has to change |
|---|---|---|---|
| Unit of progress | A finding, accumulating steadily | Working software, arriving unevenly | Weekly demonstration replaces the status memo |
| Acceptance | The sponsor agrees | Criteria are met or they are not | Thresholds written before the price is quoted |
| Client dependency | Interview time and steering | Data owners, identity admins, security review | Access requests filed on day one, not on readiness |
| Dominant risk | Being wrong or being ignored | Being late or failing a review | Risk register tracks queues, not tasks |
| Commercial shape | Time and materials or a fixed fee | Milestones with a defined result | Estimation risk moves to whoever owns sequencing |
| End of engagement | A document is delivered | A system runs and someone maintains it | Handover rehearsed and funded before final invoice |
The client conversation that has to happen this month
There is a version of this conversation that protects the relationship and a version that damages it. The difference is timing.
The protective version happens while the deck is still warm. It says: to make this run, here is what has to be true. We need this data, from these systems, with access granted through this person. We need to know where it deploys. We need to know who operates it afterward. We need one person who can approve a change. And here is what working will mean, stated as numbers we will both check. Asked in that week, these are ordinary planning questions and the client experiences them as competence.
The damaging version happens in month three, when the same questions arrive as explanations for a slip. Identical content, opposite effect. The client hears excuses, and the engagement spends its remaining credibility on process rather than product.
The same applies to the review gates. If the system will face a security assessment, an accessibility conformance test, or a model risk review, name those in the first conversation and put them inside the schedule rather than after it. A model used in a bank for a decision that affects customers, for instance, will meet an internal validation process, and the documentation that process requires is far cheaper to produce while the work is happening than to reconstruct afterward.
Federal engagements add a layer worth planning for
If the client is a government agency, the delivery phase carries obligations most commercial engineering has never met. The system has to reach an authorization to operate, which means controls documented and assessed against a recognized catalog such as NIST SP 800-53, produced as the build proceeds rather than assembled at the end. The deployment target is frequently a FedRAMP-authorized environment rather than an ordinary cloud account. Controlled unclassified information brings handling and storage rules that reach the development environment itself. Public-facing interfaces have to meet Section 508 accessibility requirements, verified with assistive technology rather than asserted.
None of that is exotic, and all of it is schedule. A build plan for an agency that treats security documentation as a closing activity is a build plan that will miss its date by a quarter. Engineering that has delivered into agencies plans these as parallel workstreams from week one, which is the single largest difference between a partner that has done it and one that has not.
A first increment structured to stay reversible
The best protection against an unfamiliar engineering partner is sequencing rather than diligence. Make the first commitment small enough that stopping costs a few weeks, and stage it so each step leaves the firm something it keeps.
Week zero is the scope: six questions answered, acceptance criteria written, a price attached. Week one is an environment and a running skeleton deployed through the path the finished system will use, building from a clean checkout. Week two is real data in a thin slice, with its real encoding problems and its real access controls. Week three is a working slice the client sponsor can operate: narrow, unpolished, functional end to end. Security and accessibility review runs alongside from the start rather than at the end. The final stretch is a handover rehearsal, where whoever inherits the system deploys it while the partner watches.
A firm that has run those five steps once can quote the next build with confidence, which is worth more over a year than the margin on any single engagement.
What the firm keeps
The client relationship, the framing, the analysis and its method, the account plan, and the credit. None of those transfer by building software. The margin stays with the firm because the partner's price is an input to the client number rather than a share of it.
The code stays with the firm if the agreement says so correctly. A work-made-for-hire recital is not enough for software: under 17 U.S.C. § 101, a commissioned work qualifies as a work made for hire only where there is a written agreement and the work falls within one of nine enumerated categories, and software is not among them. A written present assignment of copyright is what transfers ownership. Add a named carve-out for the partner's pre-existing tooling with a perpetual license back, so a future maintainer is never blocked, and an exit that is a deliverable rather than a favour: source, build pipeline, infrastructure as code, environment configuration, credential rotation, and a runbook, delivered as a condition of final payment.
How we come into an engagement
The first step is one email with a one-page brief. We answer the six scoping questions with the client, and return a scoped, priced statement of work with written acceptance criteria, named engineers with stated allocations, and a milestone schedule. There is no discovery phase billed before the scope exists.
In the first weeks the engagement gets an environment, a running skeleton on the real deployment path, real data in a thin slice, and a demonstration the sponsor can operate. Pricing is fixed-price milestones where the destination is written, or a committed team at a monthly rate where the scope is still forming. We work under the firm's brand on commercial engagements. The firm keeps the client, the code, the margin and the credit, and the handover is rehearsed before the last invoice rather than promised after it.
Bottom line
An advisory engagement that has to ship software is not the same engagement with a longer timeline. The unit of progress, the failure mode, the client dependencies and the definition of acceptance all change at once. The engagements that survive the transition do four things in the first month: they answer six scoping questions before quoting a price, they file data and environment access requests immediately, they write acceptance as numbers rather than adjectives, and they choose a commercial shape that puts estimation risk with whoever owns the sequencing. Bring in engineering under the firm's brand, with two named leads and a weekly working demonstration, and the firm keeps the room, the margin, and a build capability it can quote next time.
Frequently asked questions
Answer six questions before quoting a price. What system the result lives inside, named by product and version. What data exists, where it sits and who grants access. Where it deploys. Who operates it after go-live. What has to be true for the client to say it works, written as a threshold on a named dataset or a latency figure at a stated load. And who can approve a scope change. A build price quoted from a deck without those six answers is a guess, and the gap usually shows up as integration and access work nobody scoped.
Governance, decided before the partner meets the client. The engagement manager owns the relationship, the scope and every commitment. The partner supplies a technical lead who owns architecture and schedule and speaks through the engagement rather than around it. On commercial work the partner works under the firm's brand as a default. Add a weekly working demonstration, a shared plan the firm can read without asking, and a mutual non-solicitation drafted narrowly to the governing state law.
Fixed-price milestones where the destination can be written as acceptance criteria, and a committed team at a monthly rate where the scope is still forming. Hourly pricing leaves all estimation risk with the consulting firm, which then either pads the client number and loses the sale or holds it and absorbs the overrun. Fixed pricing puts that risk with whoever owns the sequencing decisions, and it works only when acceptance is stated as tests rather than adjectives.
Rarely because code is written slowly. Almost always because of queues the engagement does not control: data access approvals, environment provisioning, identity administration, security review, and decisions that only one person can make. Adding engineers does not shorten a queue. Filing every access request on the day the scope is signed does. The second common cause is integration reality discovered late, which is why real data should move through the real path within the first fortnight rather than after the design is fixed.
One page. What the client has decided and funded, the target system named by product and version, the data and who grants access to it, the deployment destination and any security or accessibility requirement, the date that matters and what happens on it, the contract instrument, and the person who can approve a scope change. Given those, a scoped and priced statement of work with acceptance criteria and named engineers comes back in days. Given only a deck, the partner spends two weeks reconstructing the same answers and the engagement pays for it.