Building what the slide deck promised

A transformation deck is a promise written in outcomes. Cycle time falls by a third. Underwriters see a recommendation instead of a spreadsheet. Analysts stop reconciling and start deciding. The document is not wrong, and the business case behind it is usually sound. It is just written in a language that does not compile. A system does not take an outcome as an input; it takes a data model, a set of interfaces, an access policy, and a definition of correct. Somebody has to perform that translation, and the partner who sold the transformation now owns the consequences of doing it badly. This is how the translation is done, what reliably gets lost in it, and how to run the build so the promised business case is measured rather than asserted.

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 frequently handed a deck and asked to make it real. What follows is written for the partner who owns that delivery.

The translation problem, stated plainly

A deck says the firm will move from manual review to model-assisted review. A build plan has to answer questions the deck never asked. Which decisions specifically. What does the model see at the moment of decision, and can that data be assembled at that moment rather than overnight. Who is accountable when the model is wrong. What does the reviewer do with a recommendation they disagree with, and where does that disagreement get recorded. What happens to a decision made last quarter when the underlying data is restated this quarter.

Those are not implementation details. They are the specification, and none of them appear in a strategy document because strategy documents describe the destination rather than the mechanism. The translation is therefore not a scoping exercise. It is the design, and it should be treated as the first real deliverable of the delivery phase.

The failure that follows from skipping it is consistent enough to describe. The build starts with the visible component, usually a model or an interface. Six weeks in, someone tries to feed it real data and discovers the data does not arrive in the shape or on the schedule the design assumed. The design changes. The interface changes with it. The original date is now impossible, and the conversation with the client becomes about process rather than product.

From outcome to milestone: how the translation actually runs

The method is unglamorous and it works. Take each promised outcome and walk it backwards until you reach something a person can build in a fortnight.

Name the decision, not the capability. "Improve risk assessment" is a capability. "A reviewer approving a limit increase sees a recommendation, three drivers, and a confidence indicator, before they decide" is a decision. Only the second can be built, tested, and measured.

Trace the data backwards from the decision moment. What must be known at that instant. Which system holds each element. How current is it. Is it current enough. This walk almost always turns up one element that exists only in a nightly batch, or only in a system nobody in the room controls, and finding it in week one rather than month three is the whole point of the exercise.

Define correct before building anything. Against what is the output judged. A labelled historical set. A parallel run against current human decisions. A reconciliation to a report the business already trusts. If nobody can say what correct means, the system will be argued about instead of accepted.

Find the accountable human. Every automated or assisted decision has a person who answers for it. Their workflow is a requirement, not an afterthought. What do they see, what can they override, what is recorded when they do, and what does their manager see in aggregate.

Establish the baseline while you still can. The business case claims an improvement. An improvement is a difference from a measured starting point. If the current cycle time, error rate or throughput is not measured before the system exists, the benefit can never be proven, only claimed. Measuring the baseline is a week of work in month one and impossible in month nine.

The three systems that are always underestimated

Across data and AI programmes the same three areas consume the schedule, and none of them are the thing on the slide.

Data integration

The architecture diagram shows sources joining cleanly. The reality has a specific and repeatable set of problems.

Cadence mismatch. One source updates continuously, another lands nightly, a third is refreshed by a monthly extract. A joined view is therefore never consistent as of a single instant, and the design must say which moment it represents. Skipping that decision produces a system whose numbers change depending on when you look, which destroys trust faster than being wrong.

Identifier drift. The same entity carries different keys in different systems, and the mapping is maintained by hand somewhere in a spreadsheet. One system pads identifiers, another trims them. Merged organisations carry two identifier schemes and a partial crosswalk. Entity resolution is a project, not a step, and it should be scoped as one.

Restatement. Records are corrected after publication. A figure computed in March differs from the same figure recomputed in May for the same period. If the system does not record the state of the world at the time of the decision, no decision can ever be audited. Building this in from the start is straightforward; retrofitting it means rebuilding the data model.

Meaning drift over history. A field's definition changed three years ago and the historical rows were never migrated. Training or reporting across that boundary quietly mixes two different quantities. Only a domain expert catches this, which is why the build needs sustained access to one.

Identity and access

This is where security review stops projects, and it is almost never in the plan at the right size.

Access has to be enforced where the data lives rather than in the interface, because an interface control is bypassed by the first integration or export somebody builds. Group membership should come from the client's directory rather than being maintained inside the application, or it will drift within a quarter. Approval flows have to mirror the organisation's real delegation of authority, which is never the org chart and usually has to be discovered by asking three people the same question. Retention and deletion rules need to exist before data is loaded, not after. Audit logging must record who saw what and when, in a form somebody can query during an incident.

Every one of these has a data-model consequence. Row-level access built in from the start is a design choice; added in month five it is a migration.

Operations

The difference between a system and a demonstration lives here. Logging that answers a question at three in the morning rather than merely accumulating. Alerts with named owners and a stated response. Backups verified by restoring them into a clean environment on a schedule. A documented upgrade path for every dependency, because the security team will require patching whether or not it is convenient. A runbook a person who did not build the system can follow. Capacity understood well enough to know what happens at twice the load.

A build plan that allocates nothing to operations has not been shortened. It has moved that work to the client, unfunded, after go-live.

Milestones that prove something

A milestone that says "data layer complete" is not a milestone; it is a category. Milestones that hold have a demonstration and a number attached.

The pattern is that every milestone produces a demonstration a non-technical sponsor can watch and a number a sceptic can check. Milestones without both are opportunities to be surprised later.

Measuring the business case instead of asserting it

The transformation deck contains a benefit figure. Six months after go-live, someone will ask whether it happened. There are two possible situations at that moment, and which one the engagement is in was determined in month one.

In the good situation, the baseline was measured from records before the system existed, the metric was defined precisely enough that two people compute it the same way, and the system emits the data needed to compute it continuously. The answer is a number with a method attached.

In the other situation, the baseline is a recollection, the metric has three plausible definitions, and the evidence is a survey of users who liked the new screens. The benefit becomes a matter of opinion, which means the client's finance function will treat it as zero.

Getting into the first situation requires four things in month one. Define the metric operationally: the exact numerator, the exact denominator, the exact population, the exact period. Measure the baseline from records rather than from interviews. Decide the comparison design, whether that is a before-and-after with a stated adjustment for seasonality, a parallel run against current human decisions, or a staged rollout where some teams get the system before others. And instrument the system to emit the components of the metric from the first day it runs, rather than adding measurement later and losing the early period.

None of this is expensive. It is roughly a week of design and a few days of instrumentation. It is the difference between a programme that renews and one that is quietly deprioritised.

Where a model needs governance rather than accuracy

In regulated environments, a model that affects customers or financial reporting will face an internal validation process before it is allowed to influence anything. That process asks for documentation of the data lineage, the design choices and why alternatives were rejected, the performance testing including on subgroups, the monitoring plan, and the controls around change. It asks who owns the model and who reviews it independently of the people who built it.

All of that is far cheaper to produce while the work is happening than to reconstruct afterward from memory and commit history. A build plan for a regulated client should carry documentation as a parallel workstream from the first week, with the validation team's requirements gathered before the design is fixed rather than presented to them at the end.

For federal delivery the analogous requirement is an authorization to operate, with controls documented and assessed against a recognized catalog such as NIST SP 800-53, deployment frequently into a FedRAMP-authorized environment, handling rules for controlled unclassified information that reach the development environment itself, and Section 508 accessibility conformance verified with assistive technology rather than asserted from a checklist. Same principle: evidence produced during the build, not assembled after it.

How an engineering partner runs this inside your programme

The first step is one email with a one-page brief: what the client has decided and funded, the target system named by product and version, what data exists and who grants access, the deployment destination and any review the result must pass, the date that matters, and who can approve a change of scope. We return a scoped, priced statement of work with written acceptance criteria, named engineers at stated allocations, and a milestone schedule of the kind in the table above. No discovery phase billed before a scope exists.

The first weeks produce an environment and a skeleton deployed through the real path, real data in a thin slice, a measured baseline, and a working demonstration the sponsor can operate. Pricing is fixed-price milestones where the destination is written, or a committed team at a stated monthly rate where the design is still forming. We work under the firm's brand on commercial engagements and are named on federal work where being named helps the firm win.

The firm keeps the client relationship, the framing, the analysis, the account plan and the credit. It keeps the margin, because our price is an input to the client number rather than a share of it. It keeps the code, provided the agreement carries a written present assignment of copyright rather than only a work-made-for-hire recital, which under 17 U.S.C. § 101 does not reach software because a commissioned work qualifies only within nine enumerated categories and software is not among them. And the handover is a rehearsal funded inside the schedule, where whoever inherits the system deploys it while we watch, before the final invoice.

Five ways the build diverges from the deck

The model gets the attention and the data gets the schedule. Teams spend weeks comparing model families while the integration work that determines the date sits untouched. Reverse the order. Get real data through the real path in the first fortnight, then choose the model with knowledge of what it will actually receive.

The baseline is never measured. The benefit becomes unprovable, and unprovable benefits are treated as absent when the next budget is set.

Access approvals start when the engineers are ready. They should start the day the scope is signed. Approval queues are organisational, and no amount of engineering shortens them.

The pilot is built where it can never be deployed. A prototype on a convenient account with a copy of production data dies in security review. Build in the destination environment, or against a stated authorization path, from week one.

Nobody is named as the operator. The system goes live and no team owns it. Within two quarters it is unpatched, its alerts are ignored, and the business case reverses. Name the operator before the first line of code.

Bottom line

A transformation deck describes outcomes; a system produces them, and the gap between the two is a translation that has to be done deliberately. Walk each promised outcome back to a named decision, trace the data backwards from the decision moment, define correct before building, find the accountable human, and measure the baseline while it is still measurable. Expect integration, identity and operations to take the schedule the model was going to get. Attach a demonstration and a number to every milestone. Do that, and six months after go-live the business case is a figure with a method behind it rather than an opinion. Skip it, and the deck remains the most concrete artefact the programme ever produced.

Frequently asked questions