Incumbents lose recompetes to a story, and the story is almost always the same one. The challenger says the program has been run competently and conventionally for five years, that the technology has moved, and that the customer deserves something better. That argument is effective because it is partly true and because it is hard to rebut with words. An incumbent responding with a proposal section about innovation is answering a demonstration with a promise, and the evaluators know which is which. The defense that works is not rhetorical. It is to have already done it, on this program, in front of this customer, with numbers the customer has seen with their own eyes before the solicitation was written.
This is written for the capture director defending a program where the modernization argument is available to a challenger. The question is not whether to add AI and data capability. It is when to start, what to build, how to make sure the customer notices, and how to convert that into evaluated content in the proposal rather than a claim in the executive summary.
Why the challenger's argument works
Four things make the modernization pitch effective against a competent incumbent, and each has a counter.
First, the incumbent's record reads as continuity. Five years of meeting service levels is exactly what the customer asked for and it is not exciting. A challenger's technical volume, unconstrained by having to be true yet, can propose whatever the customer's leadership has been reading about.
Second, the customer's own leadership has changed. The people who wrote the original requirement have often moved on, and the current leadership has goals the current contract was not written for. A challenger addressing those new goals sounds responsive, while the incumbent sounds like the status quo.
Third, incumbency advantages sit in past performance and transition risk, and both are defensive scores. They rarely produce the highest technical rating, and in a best-value evaluation the technical difference is where the award moves.
Fourth, the incumbent's real knowledge is invisible unless it is demonstrated. The incumbent knows the data, the exceptions, the workflows and the things that break. That knowledge is a large advantage in building anything that works, and it counts for nothing in a proposal unless it has been converted into something the customer has already used.
Evidence types by how much they move a technical evaluation
Editorial weighting, illustrative rather than measured. The last row is deliberately low: every offeror has a roadmap and none of them cost anything to write.
The sequence, worked backwards from the award date
Timing is the whole strategy, and it is worked backwards from the estimated award rather than forwards from today. The intervals below are the ones that recur; adjust them to the acquisition's actual rhythm, which the customer's forecast and the program's own history will tell you.
Roughly two years out. Decide the capability thesis. Not a list of technologies. One or two things the customer will care about most by the time they write the requirement, chosen from what is actually broken or slow in the current program. The evidence for that choice is in the program's own data: where cases queue, where errors get corrected, where staff spend hours on work a system could do, where the customer's leadership keeps asking for numbers nobody can produce quickly.
Roughly eighteen months out. Build the first thing, small, inside the current contract. This is the step most incumbents skip, usually because the current scope seems not to cover it and nobody wants to fund it. Both objections are solvable. Many modernization items sit inside existing scope as process improvement, and where they do not, a modification or a small task order is a conversation the program manager can have. Where neither is available, funding it as an investment is a capture cost, and it is cheaper than losing.
Roughly twelve months out. Get it in front of real users and start measuring. The measurement must be defined with the customer, before the results exist, and it must include what the process did before. A number the customer helped define is evidence; a number the contractor produced alone is marketing.
Roughly nine months out. Make it visible at the level that will influence the requirement. That means the program office sees it working, and it appears in the routine reporting the customer already reads rather than in a separate briefing. If there is a market research phase, the response describes what is running today rather than what is possible.
Roughly six months out. Second increment, and the partner arrangement settled. By this point the specialist partner who will be named in the bid should be delivering, not negotiating. The teaming agreement, the scope split and the workshare percentages should be written while there is still time to change them.
Solicitation release. The technical volume describes a running system with measured results, delivered by a named team, and proposes the next increment. The transition section becomes trivial because there is nothing to transition. The challenger's roadmap is competing against something that already works.
One more sequencing point is worth naming because it is where good plans quietly fail. The capability has to reach the customer's routine reporting, not a special briefing. A separate briefing is an event the customer attends once and remembers vaguely. A number that appears in the monthly status package for nine consecutive months becomes part of how the customer understands the program, and by the time the requirement is drafted the customer is describing something they already rely on. Getting a new measure into that package is an administrative task the program manager can do in a week, and it is worth more than any single demonstration.
The second failure is funding paralysis. Teams debate for months whether the work belongs inside current scope, and the debate consumes the window that made the work valuable. The resolution is to size the first increment so it is small enough to be an obvious process improvement, deliver it, and use the result to justify the modification that funds the second. A working thing changes a funding conversation in a way that a proposal for a working thing does not.
Choosing what to build
The selection criteria are narrower than they first appear, because the thing has to satisfy four constraints at once: it must matter to the customer, be buildable inside the remaining period, be measurable in a way the customer accepts, and be visible to people whose opinion shapes the requirement.
That combination rules out most of the obvious candidates. A platform replacement is too large. A back-office optimization nobody sees fails the visibility test. A capability whose benefit appears in three years fails the measurement test. What survives tends to be a specific workflow where staff time is visibly consumed, where the data already exists inside the program, and where a measurable improvement can be attributed cleanly.
Common shapes that fit: triage or prioritization that changes what a person works on first, with the measure being cycle time and the rate of items handled by the deadline. Document or case processing where extraction removes manual keying, measured against a human-adjudicated sample. Quality checking that catches errors before they reach the customer, measured by defects found before versus after. A retrieval system over the program's own accumulated material, measured by resolution time and by whether staff still ask the same questions. Anomaly detection that surfaces problems earlier, measured by lead time to detection.
In each case the measurement design matters more than the technology choice. Define the metric with the customer, capture a baseline before deployment, choose a comparison approach that survives scrutiny, and make sure the improvement can be attributed to the change rather than to something else that happened that quarter.
Candidate capabilities by fitness for a pre-solicitation demonstration
Editorial weighting, illustrative rather than measured. The last row is deliberately low: the right idea on the wrong calendar scores nothing.
Where the specialist partner fits
The incumbent's program team can often build this. The reason to bring a specialist in is rarely capability in the abstract; it is three specific things.
Speed against a fixed calendar. The window is defined by the acquisition, not by the program's hiring cycle. A team that has built the same class of system several times reaches a measured result in weeks rather than in a ramp.
Evaluated content in the bid. A named subcontractor with a defined technical scope, relevant delivered work and named key personnel is scoreable material. Corporate capability described in general terms is not, and evaluators consistently reward the specific over the general.
A capability story the challenger cannot copy quickly. The challenger will also name a partner. What they cannot name is a partner already working on this program, on this data, with results the customer has already seen.
The structure that works keeps the prime in control of everything the prime should control. The partner holds a defined technical scope with measurable acceptance criteria and delivers into the prime's repositories under the prime's program management. The customer relationship stays with the prime. The partner is visible in the bid to the extent that visibility scores, which on federal work usually means named with a real scope, because key personnel and workshare are evaluated and an anonymous resource pool reads as filler.
Two defenses, compared
| Dimension | Proposal-stage modernization narrative | Demonstrated capability before the solicitation | What the evaluator sees |
|---|---|---|---|
| Cost to write | Low, and identical for every offeror | Real, spread over eighteen months | Content only one offeror could have produced |
| Risk rating | Unproven approach, standard risk language applies | Running system with an operating record | Lower risk on the factor that usually decides |
| Effect on the requirement | None; the requirement is already written | Shapes what the customer asks for | A requirement the incumbent already satisfies |
| Past performance value | Cites other programs the evaluator must translate | Cites this program, this customer, this data | Directly relevant recency and relevance |
| Transition story | Standard incumbent continuity language | Nothing to transition; the capability is in place | The challenger inherits a transition risk |
| Copyability | Any offeror can write the same paragraph | Requires access the challenger does not have | A discriminator rather than a claim |
Making the results count without overreaching
A measured result is only worth what it survives. Three habits keep the numbers usable when the challenger's proposal team goes looking for weaknesses.
State the method with the number. Every claim should carry the population, the period, the comparison and who verified it. A number without a method is an invitation to have it discounted, and evaluators read enough proposals to know the difference.
Attribute honestly. If staffing changed at the same time, say so and address it. A claim that survives an obvious objection is stronger than a larger claim that does not.
Let the customer own part of the number. A metric the program office defined, reviewed and has been reading monthly is not something a competitor can characterize as vendor marketing. This is the single strongest form of the evidence and it costs nothing except involving the customer earlier than is comfortable.
Converting it into proposal content
Capability that exists and is not converted into evaluated content scores nothing, and this conversion is a discipline of its own.
Write to the evaluation factors rather than to the story. If the technical factor has subfactors, the running system needs a paragraph under each subfactor it touches, with the evidence in that paragraph rather than in a general section at the front. Evaluators score against their sheet.
Put the measured result where risk is assessed. The strongest use of an operating record is not to claim excellence; it is to remove risk. A system that has been running for a year on this data has an answer for every risk the evaluator is required to consider.
Name the people. Key personnel with relevant delivered work on this class of system, including the partner's named staff, is scoreable. A resource category is not.
Show the artifact. Where the solicitation permits an appendix, a screenshot of the running interface, a measurement summary, an architecture diagram of the deployed system and the monitoring page carry more weight per page than prose. Anything outside a page limit is free score and should never be thin.
Propose the next increment, priced. Having demonstrated one thing, the bid should propose the second with the same specificity: scope, method, measurement and schedule. This is the point where the incumbent takes the modernization argument away from the challenger entirely, because the incumbent's version has a working precedent attached to it.
How we work on a recompete defense
Precision Federal is a small business engineering firm. We build AI systems, data platforms, cloud infrastructure and full-stack applications, and we deliver them into production inside U.S. federal agencies. On a recompete defense we work as a specialist subcontractor to the incumbent prime, under the prime's program management, on a scope the prime defines.
The first weeks follow the calendar backwards. Week one is grounding: the program, the data as it actually is, the workflows where time is spent, the environment and the approval path for anything new. By the end of week two we deliver a written recommendation naming the one or two capabilities worth building, why each is measurable, what the baseline measurement would be and how it would be captured, and a schedule laid against the estimated solicitation date. Weeks three through ten produce a working increment in the program's environment, in the program's repositories, with tests in the program's pipeline and a measurement approach agreed with the customer before results exist.
The prime keeps everything. The customer relationship stays with the prime; we do not carry a separate line to the program office unless the prime asks. Code, models, tests, infrastructure definitions and documentation are delivered into the prime's repositories and assigned to the prime under the subcontract. Our pre-existing tooling is named, carved out and licensed back perpetually. Data handling terms are written before the first extract.
We also write the technical material our scope supports, in the prime's format, on the prime's schedule, reviewed by the prime's proposal team: the architecture description, the measurement narrative with its method, the risk paragraphs the operating record answers, and the appendix artifacts. Key personnel are named with committed percentages and a substitution path.
Pricing takes one of two shapes. Fixed-price milestones against written acceptance criteria, which fits a capability build with a defined measurement. Or a committed team at a defined allocation with a written stopping point when the target is still being shaped.
The first step is one email with a one-page brief: the program, the estimated solicitation date, what the customer's leadership is asking for that the current system does not do, the environment and who grants access, and the contract instrument. We return a scoped, priced statement of work with acceptance criteria written as tests. No call required.
When there is not enough time
Sometimes the solicitation is four months out and none of this happened. The strategy compresses rather than disappearing.
Build the smallest real thing on the program's actual data, in the program's actual environment, and get it in front of users even at limited scale. Two months of operating record on real data beats a prototype built for the proposal, and evaluators can tell the difference between a system running in the customer's environment and a demonstration built on a presenter's machine somewhere.
Where a demonstration is part of the evaluation, build it on the customer's real workflow with the customer's real data patterns, and show the failure handling rather than only the success path. Evaluators remember which offeror showed what happens when the input is bad.
And name the partner properly, with a real scope, real workshare and named people. A late partner with a defined scope still scores better than a general capability claim, and it sets up the following period regardless of the outcome.
Bottom line
The modernization argument beats incumbents because it is a promise competing against a record of doing what was asked. The counter is to convert the incumbent's real advantage, which is knowing the data and the workflow, into something running on the program with results the customer has already seen. That takes roughly eighteen months, one or two carefully chosen capabilities, a measurement defined with the customer before the results exist, and a named specialist partner delivering rather than negotiating by the time the solicitation lands. Done that way, the technical volume describes a working system and the challenger's roadmap is competing against evidence. Started at the solicitation, the incumbent is writing the same paragraph as everyone else.
Frequently asked questions
Work backwards from the estimated award. About two years out, choose the capability thesis from what is actually slow or broken in the program. About eighteen months out, build the first small increment inside the current contract. About twelve months out, get it in front of real users with a measurement defined jointly with the customer. About nine months out, make it visible in the reporting the customer already reads. By solicitation release the technical volume describes a running system rather than a plan.
Something that satisfies four constraints at once: it matters to the customer, it can be built in the remaining time, its benefit can be measured in a way the customer accepts, and it is visible to the people who shape the requirement. That usually means a workflow where staff time is visibly consumed and the data already exists in the program. Triage and prioritization, document processing, quality checking, retrieval over the program's own material, and earlier anomaly detection are the shapes that recur.
State the method with the number: the population, the period, the comparison and who verified it. Capture a baseline before deployment rather than reconstructing one afterward. Address the obvious confounder directly, since a smaller claim that survives an objection is worth more than a larger one that does not. Best of all, have the customer define and review the metric, because a number the program office has been reading monthly cannot easily be characterized as vendor marketing.
On federal work, named with a real scope generally reads better. Key personnel and workshare are evaluated, and an anonymous resource pool reads as filler next to named staff with relevant delivered work. The structure that keeps the prime in control is straightforward: the partner holds a defined technical scope with measurable acceptance criteria, delivers into the prime's repositories under the prime's program management, and the customer relationship stays with the prime throughout.
Compress rather than abandon it. Build the smallest real thing on the program's actual data in the program's actual environment and get it in front of users at limited scale, because two months of operating record beats a prototype built for the proposal. If a demonstration is evaluated, build it on the real workflow and show the failure handling as well as the success path. Name the partner with a real scope, real workshare and named people, which still scores and sets up the next period.