What is concurrency risk in defense acquisition?

In aerospace and defense, concurrency risk is the risk created when a program overlaps activities that would ideally be gated by evidence—for example, starting low-rate production, tooling, training, or supplier ramp-up before design maturity and testing are sufficiently complete. The issue is not parallel work by itself. The risk arises when downstream commitments are made before leadership has enough knowledge about technical performance, manufacturability, cybersecurity, mission suitability, cost, or reliability. When those assumptions prove wrong, the result is often retrofit work, schedule disruption, contract disputes, and avoidable cost growth.

What the term means

Concurrency is a deliberate overlap of phases or decision points in an acquisition program. In many industries that can be a rational way to compress time to market. In defense, however, the consequences are larger because platforms and subsystems are safety-critical, mission-critical, software-intensive, and acquired under formal budget, test, and oversight processes. A program may be technically concurrent if development continues while production begins, operationally concurrent if training and fielding move ahead before mission effectiveness is fully demonstrated, or industrially concurrent if suppliers buy long-lead material and add capacity before the configuration baseline is stable.

Under the current Department of Defense Adaptive Acquisition Framework, leaders still face concurrency choices across the major capability acquisition pathway. The most common overlaps are between engineering and manufacturing development, developmental test and evaluation, operational test and evaluation, low-rate initial production, and fielding preparations. Leaders may also create concurrency in software baselines, sustainment setup, technical publications, spares, and supplier ramp-up. The core question is simple: how much money, capacity, and contractual commitment is being put at risk before the program has demonstrated the knowledge needed to justify it?

Why it matters in defense programs

Cost growth and retrofit

If testing uncovers design issues after production has started, the program may have to rework completed units, scrap parts, modify tooling, renegotiate supplier orders, and revise support equipment and documentation. Those costs rarely stay isolated inside engineering. They show up in working capital, warranty exposure, modification labor, spares planning, and sustainment budgets. In large programs, concurrency can create a sizable retrofit population that is expensive to track and slow to clear.

Schedule and readiness disruption

Concurrency can look like schedule acceleration at first, but it often becomes schedule volatility later. A failed test event, unstable software drop, or late requirement change can stall production lots, delay operational testing, compress training timelines, and create a queue of assets waiting for modification. For military customers, that can mean capability arrives later than planned or arrives in a form that is not yet fully usable. For contractors, it means unstable resource demand, management distraction, and less predictable margin performance.

Supplier and investor exposure

Concurrency risk is not limited to the prime contractor. Tier-one and lower-tier suppliers may add specialized labor, buy material, or install tooling against forecasts that depend on an immature design. If the configuration changes, suppliers can be left with excess inventory, unrecoverable setup costs, and margin erosion. For investors and acquirers, highly concurrent programs deserve closer diligence on backlog quality, engineering change exposure, contract terms, and who ultimately bears the cost of rework.

How concurrency risk typically shows up

Most defense leaders recognize concurrency when production begins before testing is complete, but the pattern is broader than that. Common forms include:

  • starting low-rate initial production before the design baseline is stable or critical defects are closed;
  • placing long-lead material orders while requirements, interfaces, or software architecture are still changing;
  • building training devices, support equipment, and technical manuals against configurations that may soon be revised;
  • asking suppliers to invest in tooling and capacity before yield, quality, and process capability are proven;
  • fielding early units with the expectation that they will be modified later to a new hardware or software standard.

None of these decisions is automatically wrong. The problem is treating assumptions as facts. When governance focuses on near-term obligation or delivery milestones without a clear view of redesign, retrofit, and operational impact, concurrency becomes a hidden balance sheet item.

A practical example

The F-35 Joint Strike Fighter is one of the most cited examples of concurrency in modern defense acquisition. Production overlapped materially with ongoing development and testing, and oversight bodies have repeatedly discussed the resulting retrofit activity, software rework, and sustainment complexity. The takeaway for executives is not that every program with concurrency will fail. It is that concurrency can create very large downstream bills when hardware, software, test evidence, and sustainment planning continue to evolve after production commitments have been made.

A more routine example is a subsystem supplier that expands capacity based on an expected production ramp while interface requirements are still moving. Even if the prime eventually resolves the design, the supplier may absorb months of inefficiency through engineering change orders, material obsolescence, expedited freight, and labor instability. That is concurrency risk at the operating level, not just the headline program level.

When concurrency can make sense

Concurrency is not inherently irresponsible. In some situations, leaders accept it intentionally to deliver capability faster, preserve a critical industrial base, or learn from early manufacturing lots. Limited concurrency can also be sensible for derivative platforms, mature technologies, modular upgrades, or software-heavy increments where change can be absorbed without extensive hardware rework.

The key is to distinguish bounded concurrency from wishful thinking. A sound decision usually includes small and clearly defined early lots, explicit criteria for moving to the next commitment, funded reserves for retrofit, disciplined configuration management, and a credible plan for what happens if test results do not support current assumptions. In other words, the question is not whether concurrency exists. The question is whether the program is managing it deliberately.

What executives should watch

For boards, program executives, general managers, private equity owners, and functional leaders, concurrency risk is best viewed as a portfolio decision about knowledge, capital, and reversibility. Useful questions include:

  • What evidence is actually demonstrated in test or manufacturing, versus only modeled, forecast, or contractually assumed?
  • If a critical requirement changes or a key test fails, how many delivered or in-process units would need modification?
  • How much supplier investment is being made ahead of a stable configuration, and who pays if demand or design changes?
  • Are contract incentives pushing the organization to prioritize production tempo over defect closure and learning?
  • Is software iteration being managed in a way that avoids unnecessary hardware lock-in?
  • What is the current estimate of retrofit liability, rework hours, and schedule recovery cost?

A common misconception is that digital engineering or agile methods eliminate concurrency risk. They can reduce some uncertainty, but they do not remove the need for validated performance, controlled baselines, manufacturability proof, cybersecurity evidence, or operational suitability. Physical systems still have to be built, tested, maintained, and supported.

For primes, suppliers, and investors working through acquisition strategy, test and production overlap, supplier readiness, retrofit exposure, or diligence on defense programs, Umbrex Aerospace & Defense Practice can help connect organizations with independent consultants who understand program governance, industrial operations, cost and schedule risk, due diligence, and implementation tradeoffs.

How organizations can reduce exposure

Organizations do not eliminate concurrency risk by banning overlap. They reduce it by making the tradeoff explicit and measurable. Practical actions include:

  • Set knowledge-based gates. Tie production commitments to defined evidence on design maturity, defect closure, manufacturing readiness, and test results rather than calendar pressure alone.
  • Size early lots for learning. Early production quantities should support learning and industrial preparation, not create an oversized retrofit population.
  • Separate reversible from irreversible commitments. Long-lead buys, tooling, capacity additions, and fielding decisions should each have their own approval logic.
  • Track concurrency cost explicitly. Do not bury retrofit, rework, engineering change, and modification labor inside broad program accounts. Leadership needs visibility on the true cost of going fast.
  • Strengthen supplier communication. Lower-tier suppliers need timely notice of configuration change, test outcomes, and likely lot adjustments so they can manage inventory and labor responsibly.
  • Run integrated reviews. Engineering, test, operations, finance, contracts, and supply chain teams should assess the same risk picture, not separate versions of it.

Where programs are already highly concurrent, the immediate objective is usually not perfection. It is damage control: quantify the rework population, prioritize critical modifications, renegotiate commercial terms where needed, and reset governance so that the next decision is based on evidence rather than sunk cost.

At an executive level, concurrency risk is less about speed than about commitment without knowledge. Programs that surface the tradeoff early usually make better decisions on lot sizing, supplier investment, fielding timing, and capital allocation.

FAQs

Is concurrency risk the same as schedule risk?

No. Schedule risk is any risk to planned timing. Concurrency risk is the specific exposure created when later-phase commitments are made before earlier-phase knowledge is mature. A program can be on schedule and still be highly concurrent.

Why does the Department of Defense accept concurrency at all?

Because waiting for every uncertainty to close can delay needed capability, reduce learning, or undermine industrial capacity. The issue is not zero concurrency. It is whether leadership has bounded the exposure, priced the downside, and funded the consequences.

Is concurrency always a sign of poor acquisition discipline?

Not always. Some overlap is rational for urgent needs, mature derivatives, or modular upgrades. It becomes poor discipline when lot sizes, supplier investments, or fielding decisions outrun the evidence available to support them.

How is concurrency different from agile or spiral development?

Agile or spiral development is an incremental delivery approach. Concurrency risk arises when production, fielding, or sustainment commitments get ahead of validated requirements, test evidence, or stable configurations. Agile can coexist with good discipline, but it does not eliminate certification and manufacturing realities.

What leading indicators suggest concurrency risk is rising?

Watch open high-severity defects, repeated test discoveries, growing engineering change orders, unstable bills of material, supplier nonconformances, deferred operational test events, rising modification backlogs, and lot releases that depend on waivers rather than demonstrated readiness.

What should suppliers and investors examine first?

Start with configuration stability, responsibility for change costs, backlog assumptions, inventory exposure, capital expenditures tied to projected ramp rates, and the program’s estimated cost at completion. If those elements are unclear, concurrency risk is probably higher than the headline schedule suggests.

Have more questions about the Aerospace & Defense industry?

Find an independent consultant with experience in Aerospace & Defense

Prefer email? Write to [email protected]

Connect with the right consultant

Umbrex rapidly connects you with independent professionals who combine top‑tier consulting experience at firms such as McKinsey, Bain, Boston Consulting Group with hands‑on roles.

Find an independent consultant with experience in Aerospace & Defense

Prefer email? Write to [email protected]