Earned value and agile on an AI workstream: making the two agree

Earned value management wants a baseline: scope decomposed into work packages, each with a budget and a schedule, each earning value against an objective measure of completion. Machine learning work is uncertain in a way that resists all three. You do not know at baseline how many experiments it takes to reach a performance threshold, whether the data supports the threshold at all, or which of four approaches will win. The usual outcome is a program control lead reporting percent-complete numbers that engineers invented, a chief engineer who has stopped reading the variance report, and a customer program office that finds out about a problem two months after the team knew. This is written for the person who has to make earned value and iterative development tell the same true story on the same program.

The good news is that this is a solved problem in shape, if not in comfort. Agile programs have been reporting earned value for years, and the technique that makes it work also happens to be good engineering discipline. The adaptation for machine learning is one extra idea: the objective completion criterion for a research-flavored work package is a measurement, not a demonstration and not a percentage.

Why the usual mapping breaks

The standard agile-to-earned-value bridge sets the work package at the feature or capability level, uses story points as the sizing currency, and earns value when a story meets the definition of done. It works because software features are largely decomposable and largely knowable: you may be wrong about how long a feature takes, but you are rarely wrong about whether it can be built.

Machine learning breaks that assumption in two places.

The outcome is not guaranteed by effort. A feature gets built if you spend enough hours. A model does not reach a target metric because you spent hours on it; it reaches it if the data supports it. A work package written as "achieve ninety percent accuracy on the classification task" has a real probability of never completing regardless of budget, and a baseline containing such a package is a baseline that will breach.

Progress is not monotonic. Software mostly accumulates. Model development often goes sideways: three weeks of experiments that establish an approach does not work is genuine progress and produces nothing to demonstrate. If the earning rule requires a working increment, that period earns nothing while consuming budget, and the resulting variance is real on the report and meaningless in fact.

Both problems have the same root: the work package was written as an outcome the team does not control. The fix is to write work packages around things the team does control, and to put the uncertain outcome where uncertainty belongs, in a decision gate.

Capability-based work packages

Decompose the AI workstream by capability the way an agile program decomposes by feature, and size the packages so each closes inside one or two reporting periods. Short packages are the single largest improvement available to a program reporting earned value on uncertain work, because they convert an argument about percentage into a series of small binary facts.

A workable decomposition on a typical AI delivery looks like this. Data access and ingestion, closing when the pipeline pulls production data and passes its schema and distribution validation. Evaluation infrastructure, closing when the suite runs end to end on the locked held-out set and produces a report. Baseline measurement, closing when the current process or a simple reference model has a measured number with an interval, which is the comparison every later claim depends on. Then a series of capability increments, each closing on a measured improvement or a written negative result. Then integration, deployment, monitoring and transition packages, which behave like ordinary software work and cause no trouble.

Notice what the first three do. They are not research, they are engineering, they are highly predictable, and they produce the instruments that make every later package measurable. Front-loading them stabilizes the whole baseline. A program that starts model development before it has an evaluation suite has chosen to make every subsequent completion claim subjective.

Evaluation milestones as objective completion criteria

Here is the core technique. A capability work package completes when a stated measurement has been produced on the locked evaluation set and recorded in the experiment registry, regardless of whether the number was good.

That last clause is what makes it work and what makes people uncomfortable, so it is worth being precise. The package is not "reach 0.85 F1." The package is "measure the ceiling achievable on this task with the available data using the two candidate approaches, and produce a recommendation." That package always completes. It completes in three weeks with a result of 0.91 and a recommendation to proceed, or it completes in three weeks with a result of 0.62 and a recommendation to change the data strategy. Either way the work was done, the budget was consumed for a purpose, the program learned something it needed to know, and the value was earned honestly.

The performance target does not disappear. It moves to a decision gate between work packages, where it belongs, because it is a program decision rather than a unit of work. At the gate the program office looks at the measured number and decides: proceed to productionize, fund another increment against a specific hypothesis, change scope, or stop. That decision is visible, dated, made by the right people with a number in front of them, and it does not corrupt the earned value data.

Three rules keep this honest. The evaluation set is locked before the work package opens and held on the program side, so nobody can move the target. The metric, the segments and the interval method are written into the work package description, so nobody can change the measurement after seeing the result. And a negative result is delivered as a written finding with evidence, not as a verbal update, so the package is auditable months later.

The research budget and its burn plan

Some fraction of an AI workstream is genuinely exploratory, and pretending otherwise produces the fiction that damages the program. Make it explicit instead. Carve a stated portion of the workstream budget, commonly in the range of ten to twenty percent depending on how novel the task is, into a research allocation with its own control account or its own planning package.

Give it a burn plan the customer can see. Each research increment is time-boxed, opens with a written hypothesis and a decision rule, and closes with a finding. The allocation earns value on findings delivered rather than on outcomes achieved. The burn plan states how much of the allocation is expected to be consumed by each program milestone, so a program office watching it consumed at twice the planned rate learns early that the task is harder than scoped, which is exactly the signal earned value exists to produce.

Two guardrails. First, cap what any single hypothesis may consume before it must produce a finding, so exploration cannot quietly become the program. Second, require that each finding name what would change the answer, so a negative result is a decision input rather than a dead end.

This structure also solves a political problem. When exploration is hidden inside development packages, every failed experiment shows up as a cost overrun on a delivery package and the team learns to hide bad news. When exploration has its own labelled budget, a consumed research increment is a normal event and the team reports it accurately.

Reporting the customer's program office understands

The variance report tells the customer whether the program is on plan. On an AI workstream it should also tell them something the standard format does not carry: whether the technical risk is resolving. Those are different questions and a program can be green on one and red on the other.

What we provide each reporting period, alongside the standard cost and schedule variance data, is a short technical status that a program office can read in five minutes.

The measured position: the current primary metric with its interval, on the locked evaluation set, and the same number from the previous period. This is the single most useful line on the report because it is the only one that shows whether the technical problem is being solved.

The gap to the acceptance criterion, stated plainly, with a judgment about whether the remaining gap looks reachable from the current trend or requires a different approach. Making that judgment monthly and in writing is how a program avoids the twenty-second month surprise.

Research allocation consumed against plan, with the findings produced. If sixty percent of the allocation is gone and the ceiling question is still open, that is the earliest available signal that the scope needs to change, and it costs nothing to report.

Data and access risks, because on federal AI work these are the most common schedule driver and they are usually outside the engineering team's control. An access request that has been pending three weeks is a schedule fact and belongs on the report where somebody with authority sees it.

Blocked and pending decisions, named, with the date each was raised. A decision the government owes the program is a schedule risk with an owner, and putting it on the report in the period it arises is the difference between a variance explained and a variance argued about.

What we provide as the subcontractor on the workstream

Precision Federal is a small business engineering firm. We build machine learning systems, data platforms, cloud infrastructure and full-stack applications and deliver them into production inside federal agencies, working as a specialist subcontractor, teaming partner or nontraditional partner on an other transaction. On a program reporting earned value, we structure our workshare so your program control team gets clean data without chasing it.

Concretely: a work breakdown for the AI workstream with objective completion criteria written as measurements, sized to close inside one or two of your reporting periods. Registry entries and evaluation reports that serve as the objective evidence for each milestone, so a completion claim has an artifact behind it that an auditor can open. A monthly technical status in the format above, delivered on your reporting calendar rather than ours. Estimates at completion that we update against measured position rather than against optimism, including telling you early when a target looks unreachable.

What arrives in the first weeks: week one, the proposed work breakdown with completion criteria and the evaluation set locking plan, reviewed with your control account manager before anything is baselined. First month, the evaluation suite running in your environment, the experiment registry recording every run, and a measured baseline for the current process, which gives every later variance report a real comparison point.

The prime keeps everything. The customer relationship is yours. Code is written into your repositories under your configuration management from the first commit. Data stays inside the environment your security agreement permits. Our background tooling is named at award, excluded from assignment, and licensed to you and to any follow-on team. We work as a named subcontractor with an evaluated scope where that strengthens your proposal, or inside your delivery organization without a public role.

Pricing takes one of two shapes. Firm fixed price against milestones that are the measured completion criteria themselves, which reports cleanly and puts the estimating risk on us. Or a committed team at a stated allocation with the research increments time-boxed and separately identified. Either shape gives your control account manager an objective earning rule rather than a conversation.

The first step is one email with a one-page brief: the program, the AI workstream, the reporting requirements you are under, the target environment, the schedule and the contract instrument. We read it and return a scoped, priced statement of work with the work breakdown and completion criteria written as tests. Days, not weeks, and no cost.

Five ways this goes wrong

Work packages are written as performance targets. The package cannot complete unless the data cooperates, so it either breaches or gets quietly redefined. Write the package as the measurement and put the target at a decision gate.

Percent complete is estimated by the people doing the work. The estimate is optimistic early and honest late, producing the classic ninety-percent-for-four-months pattern. Milestone earning on short packages removes the judgment call entirely.

Exploration hides inside delivery packages. Failed experiments surface as cost variance on delivery work, the team learns that bad news is expensive, and the reporting stops being true. A labelled research allocation with a burn plan fixes this.

The evaluation set is not locked. Without a fixed measurement instrument, completion evidence is not comparable across periods and the trend line means nothing. Lock it before the first capability package opens and hold it on the program side.

Technical status is not reported alongside cost and schedule. The program is green on the variance report and failing on the technical question, and nobody with authority sees it until acceptance. Five lines a month prevent this.

Bottom line

Earned value and iterative AI development agree when work packages are written around what the team controls. Decompose by capability, size packages to close in one or two reporting periods, front-load the data pipeline, the evaluation suite and the baseline measurement, and make each capability package complete on a measurement produced rather than a target achieved. Move the performance target to a decision gate where the program office looks at a number and decides. Carve out a labelled research allocation with a time-boxed burn plan that earns on findings. Then report the measured position and the gap alongside cost and schedule every period. That structure gives program control objective evidence, gives the engineering team room to be uncertain honestly, and gives the customer the early warning that earned value was invented to produce.

Frequently asked questions