Spending Intelligence · IT Disasters
$30 Billion Burned. Six Audits Failed. The Pentagon's IT Modernization Catastrophe.
DIMHRS spent $1B+ over 12 years and was cancelled. The Air Force's ECSS burned $1B+ in 7 years and replaced nothing. The Army's LMP made $1B in assets unlocatable. DoD has been on the GAO High Risk List for 28 consecutive years and has never passed a financial audit. Here is what happened — and why it keeps happening.
Sources: GAO acquisition reviews · DoD IG reports · Congressional Research Service · DFAS financial reports · Army audit agency findings · DoD Comptroller audit reports · Reuters DFAS investigation (2013)
Annual DoD IT Spend
~$40B
FY2024 DISA/CIO estimate — all IT investments across components
On GAO High Risk List
28 yrs
DoD financial management continuously flagged since 1995
Consecutive Failed Audits
6
DoD has never passed a full financial audit — FY2018 through FY2023
Est. Wasted on Cancelled Programs
$30B+
Rough floor across DIMHRS, ECSS, LMP, cancelled IT programs (GAO/CRS)
Section 01
The Scale: $40 Billion a Year, Half of It Wasted
The Department of Defense spends approximately $40 billion per year on information technology — hardware, software, networks, and the programs intended to modernize them. This makes DoD one of the largest single IT buyers in the world. The return on that investment has been, by any honest accounting, catastrophic. The Government Accountability Office has included DoD financial management on its High Risk List continuously since 1995 — twenty-eight years of formal designation as a program at high risk of waste, fraud, abuse, or mismanagement. The primary driver is IT.
Historical studies of major DoD IT programs — GAO's annual IT acquisition reviews, CRS analyses, and DoD IG reports — have consistently found that approximately 40–50% of major IT programs either fail to deliver on their original scope, are cancelled before completion, or cost more than twice their initial estimates with less than the originally planned capability. In commercial enterprise IT, that failure rate would be catastrophic and career-ending for the executives responsible. In DoD acquisition, it is the base rate — a predictable outcome of a system that has been trying and failing to reform itself for three decades.
The dollar figure most often cited for waste in cancelled programs is $30B+. This is a floor, not a ceiling. It counts only programs formally cancelled after significant expenditure. It does not count the ongoing maintenance costs of legacy systems that successful modernization would have eliminated, the productivity costs of systems that work poorly but were deployed anyway, or the audit-related costs of financial statements that cannot be validated because the underlying IT cannot produce auditable data. Those costs are real, ongoing, and not captured in program acquisition budgets.
Major DoD IT Program Outcomes — Quick Reference
Defense Integrated Military Human Resources System · DoD-wide · 1998–2010
Intended to replace 80+ separate HR and pay systems across all services. Cancelled after 10+ years and over $1B spent.
$1B+
spent
Integrated Personnel and Pay System — Army · Army · 2012–2024+
The Army's attempt to do DIMHRS on its own. 12+ years, ~$900M, and still not fully functional as of FY2024.
~$900M
spent
Expeditionary Combat Support System · Air Force · 2005–2012
Oracle-based ERP for Air Force logistics. Cancelled in 2012 after 7 years and $1B+. Replaced exactly nothing.
$1B+
spent
Logistics Modernization Program · Army · 2003–2016
SAP ERP for Army Materiel Command. Initial deployment in 2003 caused Army to lose track of $1B+ in assets per GAO.
$2B+
spent
Global Combat Support System — Army · Army · 2008–2022+
$3.5B tactical logistics ERP. Deployed but widely criticized by supply NCOs for complexity and operational overhead.
$3.5B
spent
Navy Enterprise Resource Planning · Navy · 2003–ongoing
SAP ERP for Navy financial management. Significant implementation problems; tied to Navy's repeated audit failures.
$1B+
spent
General Fund Enterprise Business System · Army · 2007–2016
SAP ERP for Army general fund accounting. Deployed but consistently cited in Army audit failures for data quality and reconciliation issues.
$1.3B+
spent
Defense Agencies Initiative · Defense Agencies · 2008–ongoing
Oracle-based ERP for Defense Agencies and DoD Field Activities. Chronic schedule slips and cost growth per GAO.
$400M+
spent
Sources: GAO annual IT acquisition reviews; individual program audits; CRS reports on DoD ERP programs. Cost figures represent reported obligations or program cost estimates as published in official sources. All-in costs including government labor and legacy maintenance are higher.
Section 02 — Case Study
DIMHRS: The $1 Billion HR System That Spent a Decade Going Nowhere
The Defense Integrated Military Human Resources System was supposed to replace 80+ legacy personnel and pay systems across all services. It ran from 1998 to 2010, consumed over $1 billion, and was cancelled. The same 80+ legacy systems remain in use today.
The Promise
DIMHRS was conceived in the mid-1990s as the single system to end the Pentagon's HR and pay fragmentation problem. DoD maintained more than 80 separate HR, personnel, and pay systems across the services — each developed independently, each requiring separate data entry for the same transaction, each unable to talk to the others. A soldier separating from active duty might have their status updated in one system and not another for weeks. A promotion board could not query a single authoritative source for personnel records. Reserve component activations required manual data transfer between systems that had no interface. DIMHRS was supposed to fix all of this: one system, all services, all components, integrated HR and pay. The 1998 contract was awarded to PricewaterhouseCoopers (later acquired by IBM). The vision was sound. The execution was not.
Requirements Churn: Why the System Never Stabilized
The first and most persistent failure mode of DIMHRS was requirements churn — the constant addition and modification of system requirements after the contract was awarded and development was underway. Each service branch had its own view of what the system needed to do. The Army wanted features the Navy had not requested. The Marine Corps had pay rules distinct from the Air Force. Reserve component management had requirements that conflicted with Active Duty processing. Every time a stakeholder group revisited the requirements, the project scope expanded. GAO documented this pattern repeatedly, beginning with a 2004 report that identified requirements instability as the primary risk. By the time DoD seriously considered cancellation in 2009, the requirements document had grown to a scope that most enterprise software experts characterized as unbuildable under any conventional approach. The IBM team was not building a system; they were building a system that would accommodate every exception to every rule across all services. That is not a software product. That is a bureaucratic negotiation encoded in code.
The Governance Failure
DIMHRS suffered from a governance structure that guaranteed failure. The program had no single authoritative decision-maker. Each service had a representative with veto power on requirements changes. OSD had oversight but limited authority to force decisions. The contracting officer could not resolve inter-service disputes; those went up the chain, where they languished or were resolved by splitting the difference — adding requirements to accommodate both positions rather than choosing one. This is not unique to DIMHRS. It is a structural property of joint DoD programs: when multiple services must agree on a single system, the political equilibrium is usually to add requirements, never subtract them. The program office knew what was happening. Multiple Program Executive Officers raised concerns in internal reviews. The institutional incentives — no service wanted to be the one that "killed" a program they needed — kept the program alive years past any reasonable assessment of viability.
Contractor Performance and the IBM Question
PricewaterhouseCoopers won the DIMHRS contract in 1998. IBM acquired PwC's consulting arm in 2002 and inherited the program. IBM is one of the largest and most experienced enterprise IT implementers in the world. The fact that IBM could not deliver a working DIMHRS is instructive: it was not primarily a contractor competence problem, though contractor performance issues were cited in program reviews. The requirements the program office was providing were genuinely contradictory. No software contractor can deliver a system whose specification changes faster than development can proceed. IBM did receive criticism for cost proposal accuracy, for understating technical risk in its initial bids, and for being slow to escalate known technical problems to program leadership. But the root cause was not IBM. The root cause was that DoD could not agree on what it wanted, in time for those agreements to be buildable.
The 2010 Cancellation and Its Aftermath
DoD formally cancelled DIMHRS in December 2009, with the cancellation taking effect in fiscal year 2010. The official cost as reported to Congress was approximately $1 billion over twelve years. Some independent analyses, accounting for infrastructure, government labor, and program office costs not captured in the prime contract value, put the all-in figure higher. What did the DoD get for $1B? It got a decade of requirements documents, design artifacts, some partially developed software modules, and a set of lessons learned that have been partially absorbed into successor programs — and partially ignored. The 80+ legacy systems that DIMHRS was supposed to replace were still running in 2010. Most of them are still running today, some on hardware and operating systems that vendors no longer support. The total cost of maintaining those legacy systems for the decade-plus since DIMHRS was cancelled — a cost that would have been eliminated by a successful modernization — is not tracked centrally, but it is real and ongoing.
$1B+
Spent before cancellation
12
Years in development
80+
Legacy systems not replaced
0
Deployments completed
Section 03 — Case Study
IPPS-A: The Army Tried DIMHRS on Its Own. Twelve Years Later.
After DIMHRS collapsed, the Army decided it would modernize its own HR and pay systems without waiting for a joint program. IPPS-A launched in 2012. As of 2024, it is still not fully functional — and service members are dealing with the consequences daily.
What IPPS-A Is Supposed to Do
After DIMHRS collapsed, the Army decided not to wait for another joint DoD program. It would build its own. IPPS-A — the Integrated Personnel and Pay System for the Army — was conceived in 2012 as an Army-specific HR and pay modernization. The scope was still ambitious: replace the Standard Installation/Division Personnel System (SIDPERS), the Army's decade-old personnel management system, and integrate with pay systems. The contract went to Randstad Technologies, working on a commercial-off-the-shelf (COTS) platform from SAP. The theory was that using a proven commercial product would prevent the requirements-churn problem that killed DIMHRS. The practice proved otherwise.
Fourteen Years and Still Not Done
IPPS-A has been in development or deployment for more than fourteen years as of 2026. The program has undergone multiple restructurings, release reschedulings, and scope adjustments. Release 3, the most recent major deployment wave targeting the Reserve Component, was declared initial operating capability in 2023 — but with significant known deficiencies that the Army committed to resolving post-deployment. GAO has flagged IPPS-A's schedule and cost growth in multiple annual reports on major DoD IT programs. The program office has repeatedly defended the program by pointing to what has been deployed, while critics point to what has not. An Army internal review in 2022 found that units using IPPS-A were experiencing significantly higher administrative processing errors in pay and personnel actions than units on legacy systems. Some of those errors resulted in service members being underpaid or having benefits incorrectly administered.
What Service Members Experience
For soldiers, IPPS-A has meant a system that works differently depending on which component you are in and which phase of your career you are managing. Soldiers in the first deployment waves reported pay discrepancies, incorrect leave balances, missing training records, and personnel actions stuck in approval queues that were not visible to their unit HR personnel. Unit S1 shops — the administrative staff sections responsible for personnel management — describe IPPS-A as more complex to operate than the legacy systems it replaced, requiring more training and producing more errors during the transition period. The Army has acknowledged these transition pains and contends that the system will be more capable once stabilized. After twelve years and nearly $900M, "more capable once stabilized" is not a reassuring phrase.
The $900M Question
Precise cost figures for IPPS-A are difficult to pin down because program scope, contract structure, and government labor costs have all changed multiple times. The Army's reported expenditure is approximately $870M–$900M through FY2023, with additional costs projected through the remaining capability deployments. This does not include the government workforce costs — the Army program office, test personnel, and field implementation teams — which would put the all-in figure higher. For comparison: the commercial HR system on which IPPS-A is based (SAP SuccessFactors) is used by thousands of commercial companies to manage millions of employees. The base software license is not the expensive part. The expensive part is the requirements complexity, integration work, and government acquisition overhead that turns a commercial product into a multi-year DoD program.
What Soldiers Are Experiencing
Pay Discrepancies
Soldiers in early IPPS-A deployment waves reported incorrect pay, missing special pays, and leave balance errors that required manual correction through pay adjustment requests — adding weeks to resolution.
Missing Training Records
Records transferred from legacy systems had gaps and mismatches. Promotion boards working from IPPS-A records encountered soldiers with incomplete or incorrect training and education documentation.
S1 Workload Increase
Unit HR sections (S1 shops) report that IPPS-A transactions take longer and produce more errors during transition than the legacy SIDPERS system, increasing administrative burden at a time when S1 sections are chronically understaffed.
Reserve Component Problems
The Reserve Component deployment of IPPS-A has been particularly problematic, with AGR (Active Guard Reserve) soldiers and traditional reservists experiencing system behaviors that do not correctly handle part-time service records and activation status.
Section 04 — Case Study
Logistics Modernization Program: The SAP ERP That Lost Track of $1 Billion in Army Assets
The Army spent $2B+ implementing SAP for its strategic logistics command. When it went live in 2003, Army Materiel Command lost visibility on approximately $1.2 billion in inventory. This was not a small rollout glitch. It was a supply chain crisis during two active wars.
The $1B Asset Visibility Catastrophe
The Logistics Modernization Program was an SAP R/3 ERP implementation for Army Materiel Command — the industrial base of the Army, responsible for managing the storage, maintenance, and distribution of Army equipment and supplies. When LMP went live at its first site (Army Materiel Command, Redstone Arsenal) in June 2003, it created an immediate crisis. The Army could not reconcile its inventory. Equipment and supplies that had been tracked in the legacy systems (the Commodity Command Standard System and related legacy databases) did not transfer cleanly into SAP. Records were missing, duplicated, or had mismatched attributes. GAO's follow-up review, published in 2005 (GAO-05-150), found that the Army had approximately $1.2 billion in inventory that it could not locate or account for in the new system.
The SAP Implementation That Nearly Broke Army Logistics
The immediate operational consequence of LMP's go-live problems was that Army Materiel Command had degraded visibility into its own supply chain at a time when the Army was conducting two major combat operations (Iraq and Afghanistan) with high demand on logistics support. When a logistics system loses track of $1B in assets, the practical effect is not that those assets disappear — they are in warehouses somewhere. The practical effect is that fill rates for unit requisitions degrade because the system cannot confirm what is on hand and where. Units that needed repair parts had those parts in the Army's supply system, but the system could not reliably locate them. The workaround — expedited requisitions, manual searches, special handling — placed additional burden on logistics personnel and degraded readiness. SAP-trained civilians and government contractors worked to reconcile records manually, a process that took years.
Two Billion Dollars and Counting
LMP's total program cost through its designated lifecycle has exceeded $2B. This includes the initial SAP implementation, the multi-year remediation effort following the go-live crisis, subsequent upgrades and enhancements, and the government program office costs over the fifteen-plus years the program has been active. LMP was eventually deployed across Army Materiel Command and some subordinate commands, though with a scope significantly reduced from initial plans. Its successor for tactical logistics — GCSS-Army — was funded partly as a recognition that LMP could not be extended to brigade and below without replicating the integration problems at every echelon. The Army effectively paid twice: once for LMP to modernize strategic logistics, and again for GCSS-Army to modernize tactical logistics, with a period of confusion and operational degradation between them.
The Audit Connection
The $1B asset visibility problem created by LMP's failed implementation was not merely an operational problem. It was a financial reporting problem. Assets that cannot be located cannot be valued and reported on a balance sheet. The Army's inability to pass financial audits is directly connected to its inability to reconcile physical assets with financial records — and that inability was worsened, not improved, by LMP's implementation. An ERP that was supposed to create a single authoritative record of Army assets instead created a period of genuine confusion about what the Army owned and where it was. The audit trail for that period — the documentation that would allow a financial auditor to trace an asset from procurement through current location — is compromised. This is not a recoverable problem. The historical records are incomplete, and they will remain incomplete.
LMP By the Numbers
$2B+
Total program cost
$1.2B
Assets made unlocatable at go-live (GAO)
2003
Initial go-live — during active Iraq operations
Years
Required to reconcile post-go-live data errors
Section 05 — Case Study
GCSS-Army: $3.5 Billion. Deployed. And Still Driving Supply Sergeants Crazy.
GCSS-Army is not a cancelled program — it was deployed across the force. The failure is more subtle: a $3.5B system that improved institutional visibility while increasing the daily administrative burden on unit supply NCOs who have to operate it.
What GCSS-Army Is
Global Combat Support System — Army is an SAP ERP deployed at the brigade and below level, replacing the Standard Army Management Information Systems (STAMIS) that governed tactical logistics for decades. GCSS-Army handles property accountability, supply requisitioning, maintenance management, and financial management of unit-level logistics. The total program cost is approximately $3.5B over the program lifecycle. GCSS-Army reached full deployment capability in 2018, replacing the Property Book Unit Supply Enhanced (PBUSE) and Unit Level Logistics System (ULLS) systems that soldiers at the unit level had used for twenty-plus years.
What Supply Sergeants Actually Deal With
Unit supply sergeants and property book NCOs — the people who actually operate GCSS-Army daily — describe the system in terms ranging from reluctant acceptance to genuine hostility. The core complaints are consistent across units: the system is more complex to operate than PBUSE, which was itself considered complex. A transaction that took minutes in PBUSE may take 30–45 minutes in GCSS-Army, not because the underlying process is different but because SAP's workflow structure requires more navigation and data entry. Training requirements increased with GCSS-Army deployment: the Army had to stand up formal SAP training programs for NCOs who had never used enterprise ERP software. Units with high NCO turnover — which describes most Army units — face a recurring training burden as personnel rotate in and out of positions. The system is particularly challenging for Reserve Component units, which have less access to full-time logistics staff to absorb the administrative load.
The Property Accountability Problem
Property accountability — the formal tracking of all Army equipment by serial number and responsible hand receipt holder — is a core GCSS-Army function. It is also a persistent source of friction. When a soldier PCSs, their hand receipt items must be transferred in GCSS-Army before the out-processing is complete. When equipment is turned in to the Property Book Officer, the system transaction must reconcile with the physical turn-in. When equipment is lost or damaged, the system must generate a Financial Liability Investigation of Property Loss (FLIPL) within specific time parameters. Each of these transactions requires system access, user training, and — because GCSS-Army is an ERP — a degree of sequential process compliance that is difficult to maintain in operational units dealing with real-time requirements. The result is that many units carry significant GCSS-Army transaction backlogs, with hand receipts that do not accurately reflect current equipment status. This is an audit liability: an Army that cannot accurately account for its equipment in its own logistics system cannot pass a financial audit.
The $3.5B versus the Daily Grind
$3.5B is the number that gets cited in program briefings. The number that matters to a Motor Pool NCO at Fort Cavazos is the number of hours per week their supply sergeant spends on GCSS-Army transactions that used to take half the time in the old system. The Army has not published a systematic measurement of the administrative overhead GCSS-Army created versus the legacy systems it replaced. Anecdotal evidence from unit surveys and after-action reviews — collected by Army centers of excellence and published in logistics professional journals — consistently indicates that GCSS-Army increased administrative workload at the unit level while improving data visibility at the institutional level. This is a trade-off that made sense for DoD-level accountability. It is not obvious that it made sense for combat unit readiness.
Section 06 — Case Study
Air Force ECSS: $1 Billion Spent. Zero Wings Deployed. Nothing Replaced.
The Expeditionary Combat Support System was supposed to replace 240+ Air Force logistics systems with a single Oracle ERP. After seven years and more than $1 billion, the Air Force cancelled it in 2012 without deploying to a single unit. The 240+ legacy systems are still running.
The Oracle Contract
The Air Force awarded the ECSS contract to Computer Sciences Corporation (CSC) in 2005, with Oracle E-Business Suite as the underlying ERP platform. ECSS was intended to replace the Air Force's hodgepodge of logistics, supply chain, and maintenance management systems — over 240 legacy systems in total. The scope was comprehensive: asset management, supply chain, maintenance scheduling, financial management of logistics activities, and interfaces to flying hour programs and readiness reporting. The contract value at award was approximately $628M. By cancellation, the Air Force had obligated over $1B.
Seven Years of Configuration and Rework
ECSS ran from 2005 to 2012 without completing a major deployment to any Air Force organization. The Air Force conducted multiple pilot tests, each of which revealed functional gaps requiring rework. The program went through three Program Executive Officers and multiple restructurings. A 2011 Air Force Material Command assessment found that the system as configured would not support operational requirements at any wing scheduled for early deployment. The fundamental problem was the same as DIMHRS and LMP: Air Force logistics processes were so complex, and so many of those processes were embedded in the legacy systems as undocumented rules and exceptions, that configuring a commercial ERP to replicate them was more expensive than the ERP itself. The process reengineering required to make the Air Force operate the way Oracle's software expected was organizationally and institutionally impossible under the acquisition timeline.
The December 2012 Cancellation
Secretary of the Air Force Michael Donley and Chief of Staff General Mark Welsh announced ECSS cancellation in November 2012. The public rationale was that further investment would not produce a deployable system. What was left unsaid in the public announcement, but documented in the internal assessment: the program office had known for at least two years that ECSS was not going to work as designed, but had continued requesting funding through the annual budget cycle rather than surface the failure. This is a recurring pattern in DoD IT failures: the acquisition and budget incentive structures reward program survival, not honest assessment. A program manager who cancels their program is out of a job and their organization loses its budget line. A program manager who requests another year of funding to "resolve known issues" keeps the program alive. The institutional incentives are aligned toward continuation, not candor.
What Replaced Nothing
ECSS was cancelled without deploying to a single Air Force wing. The 240+ legacy systems it was supposed to replace are still running. Some of those systems are running on hardware that is no longer manufactured and operating systems that are no longer supported by vendors. The Air Force has pursued a successor program — the Logistics, Installations and Mission Support-Enterprise View (LIMS-EV) — as a more modest data aggregation and visibility layer on top of the legacy systems, rather than a replacement for them. LIMS-EV is not a modernization. It is an acknowledgment that modernization failed and the best available option is to make the old systems more visible. The legacy maintenance burden and interoperability gaps that ECSS was funded to fix remain unfixed.
Section 07 — Case Study
Navy ERP: Still Running, Still Failing Audits
The Navy Enterprise Resource Planning program began in 2003 as an SAP implementation for Navy financial management, supply chain, and workforce management. Unlike ECSS, it was not cancelled. Unlike GCSS-Army, it did not become a fully operational Army-wide system with a reasonable success story. Navy ERP occupies the uncomfortable middle ground: a system that works well enough to keep running, badly enough to keep failing audits, and expensively enough to have consumed over $1 billion in program costs since inception.
The Navy's connection to the Financial Improvement and Audit Readiness (FIAR) program is direct and documented. FIAR was DoD's multi-year effort to prepare the department's financial statements for audit — essentially, to fix the IT and process problems that prevented audit before the audit was attempted. The Navy's FIAR assessments identified Navy ERP as both a critical enabler and a persistent obstacle: the system was supposed to provide the clean financial data that auditors require, but documented data quality issues — transaction mismatches, inadequate audit trails, reconciliation failures between ERP modules — meant that the system as deployed did not meet the evidentiary standard for auditable financial statements.
The FY2023 Navy audit produced a disclaimer of opinion — the same result as FY2018–FY2022. The auditors' material weaknesses again included financial system deficiencies, property accountability gaps, and data quality issues in the ERP environment. Navy ERP, after twenty years of development, is not producing data that supports a clean audit opinion. The Navy has announced plans for ERP modernization as part of its broader digital transformation program. The plan is to move from SAP ERP 6.0 (the current foundation) to SAP S/4HANA. The migration is underway. Given the Navy's track record on ERP programs, skepticism about timeline and cost is warranted.
The FIAR-ERP Circular Dependency
DoD's Financial Improvement and Audit Readiness initiative was designed to prepare the department for audit by fixing the underlying IT systems. But the initiative itself required data from those systems to measure progress — data the systems could not reliably produce. Program managers reported FIAR progress using metrics derived from systems whose accuracy was the problem being measured. This is not an accusation of deliberate fraud. It is a systemic measurement problem: when the instrument you are using to measure improvement is itself flawed, the measurement is unreliable. FIAR ran from 2011 to the first audit attempt in FY2018 without producing a department that could pass an audit. The auditors found more problems than FIAR had disclosed.
Section 08
The Pattern: Why DoD IT Programs Keep Failing the Same Way
DIMHRS, ECSS, LMP, and IPPS-A are not independent failures. They are instances of the same failure pattern, driven by the same structural forces. Understanding the pattern is the prerequisite to changing it.
Requirements Churn
Every major DoD IT failure shares a core pathology: requirements that grow, change, and contradict themselves throughout development. DIMHRS, ECSS, LMP, and IPPS-A all expanded scope after contract award. The cause is institutional: DoD acquisition culture treats requirements as negotiating positions between stakeholder organizations, not as fixed technical specifications. When the Army, Navy, Air Force, and Marine Corps each have representation on a joint program, and each has veto power over requirements that affect their organization, the political equilibrium is to add requirements, never subtract. No service will voluntarily accept a system that does not accommodate its specific processes. The result is a system designed to accommodate every exception to every rule — which is, in software terms, an unbounded scope.
The COTS Fallacy
In response to the custom-development failures of the 1990s, DoD shifted to Commercial Off-the-Shelf (COTS) software — buying existing commercial products and configuring them for military use, rather than building from scratch. The theory was sound: Oracle and SAP have products battle-tested by thousands of commercial companies. Why not use them? The practice revealed a fatal assumption: that DoD processes could be adapted to fit commercial software. They could not. DoD logistics, personnel management, and financial management are not simply more complex versions of commercial equivalents — they have structural features (appropriation-based accounting, military-specific pay rules, readiness-based inventory management) that have no commercial analog. When COTS met DoD requirements, one of two things happened: the software was customized so heavily that it was no longer maintainable as a commercial product (the GCSS-Army outcome), or the commercial software won and the DoD processes it could not accommodate were dropped from scope (leaving the underlying problem unsolved).
Congressional Budget Cycle vs. Software Reality
Software development in 2024 operates on 6–12 week sprint cycles, with working software deployed continuously. DoD programs are funded through a 5-year Future Years Defense Program (FYDP) and an annual Congressional appropriations cycle that takes 18 months from Presidential budget request to enacted appropriations. The mismatch is not a nuisance — it is a structural barrier to modern software development. A program that needs to pivot its architecture in response to testing results cannot do so if its funding is locked in an appropriation for the original architecture. A program that discovers a commercial vendor's product is unsuitable cannot switch vendors without a re-compete that takes two years. By the time DoD can formally respond to a known technical failure, commercial technology has moved a generation.
Waterfall vs. Agile Tension
The DoD's acquisition framework — Defense Acquisition System, governed by DoD Instruction 5000.02 — was designed around hardware programs: design a fighter jet, build a prototype, test it, produce it. This sequential (waterfall) process is appropriate for physical systems where reversing a design decision is enormously expensive. It is catastrophically inappropriate for software, where the right response to discovering that an approach doesn't work is to try something different — not to document the failure, request a program review, await a decision authority response, and begin a re-planning process that takes 18 months. Every major DoD IT failure before approximately 2018 was managed under a waterfall process. DIMHRS, ECSS, LMP, and GCSS-Army were all designed, contracted, and managed as if they were aircraft programs. DoD has since adopted a Software Acquisition Pathway (2020) that supports agile development. Whether the new framework will work depends on whether the institutional behaviors around requirements, oversight, and contractor management also change — which is a separate question.
Contractor Lock-In
Once a defense contractor has been developing a system for three years, they possess the institutional knowledge of the program that no other contractor has. Switching would require the new contractor to rebuild that knowledge — an expensive multi-year process — while the original contractor held leverage. Program offices that contemplated switching contractors faced the practical reality that the transition cost was often higher than continuing the program. Contractors understood this. The incentive to lowball initial proposals, win the contract, and then recover margin through modifications and sole-source follow-on work — sometimes called "buying in" — is well-documented in GAO acquisition reviews. ECSS, LMP, and DIMHRS all had contract modifications that increased scope and cost well above the original contract values. None had the contractor replaced for performance.
Lack of Software Talent in Government
The DoD acquisition workforce that oversaw these programs was composed primarily of contracting officers and program managers with hardware procurement backgrounds. A Contracting Officer who managed aircraft component contracts has limited ability to evaluate whether a software contractor's technical approach to a data migration problem is sound. The government team's inability to evaluate technical work in real time meant that problems visible to any experienced software engineer were not surfaced to decision-makers until they had compounded into crises. The Defense Digital Service (DDS), founded in 2015, brought commercial software talent into DoD to address exactly this gap. But DDS was a small organization — roughly 80 people — assisting a $40B/year IT enterprise. The talent gap in the program offices, DCMA, and contracting community that oversee the bulk of DoD IT spending remained largely unaddressed.
The Oversight Paradox
DoD IT programs are subject to extensive oversight: Defense Acquisition Board reviews, Independent Cost Estimates, Test and Evaluation oversight, Congressional reporting requirements. This oversight is real and genuinely adds cost and time to programs. The paradox is that it also creates incentives to hide problems: a program that surfaces a major technical failure triggers a formal review process that can take a year to resolve, during which the program is effectively frozen. Program managers learn to manage their reviews — presenting findings in the most favorable light, deferring the surfacing of bad news until absolutely necessary. GAO has documented this pattern in multiple acquisition reviews: independent technical assessments frequently found more significant problems than the program office had disclosed to oversight bodies. The oversight machinery that was supposed to catch failures before they became catastrophes repeatedly failed to do so because the people being overseen had strong incentives not to share bad news.
The Fundamental Mismatch: 5-Year Budget Cycles vs. 18-Month Technology Cycles
When the DIMHRS contract was awarded in 1998, web-based enterprise software was new and client-server architectures were standard. By 2004 — six years into the program — cloud computing was emerging, mobile platforms were changing user expectations, and service-oriented architectures had become the commercial standard for enterprise integration. DIMHRS was still being designed for a technology landscape that was already obsolete. This happens in every long-running DoD program: the technology the system was designed around is outdated before the system ships. Commercial software companies respond to this by shipping continuously, updating the product, and retiring capabilities that no longer fit. DoD programs cannot do this without triggering a formal program modification process that takes 12–18 months. The result is that DoD IT programs arrive late, on old technology, to solve problems that have evolved since the requirements were written.
Section 09
Six Consecutive Failed Audits: How IT Failure Breaks the Financial Books
DoD has attempted and failed six consecutive financial audits (FY2018–FY2023). The connection to IT modernization failure is direct: the systems that were supposed to produce auditable financial data don't. The cost of that failure is not just embarrassment — it is billions in ongoing remediation, billions more in legacy system maintenance, and a financial transparency problem that makes waste harder to detect and prosecute.
DoD Audit Results — FY2018 Through FY2023
First audit attempt. 1,200 auditors. $400M cost. Disclaimer of opinion (could not complete audit).
Second attempt. Identified 2,409 notices of findings. Disclaimer again.
Progress on some findings. New material weaknesses identified. Disclaimer.
COVID impacted audit access. Disclaimer. Same core IT and property issues.
Fifth consecutive disclaimer. GAO: DoD has made limited progress on root causes.
Sixth consecutive disclaimer. Army, Navy, Air Force all disclaimed.
The Circular Problem
DoD has failed every comprehensive financial audit conducted since the first attempt in FY2018. Before that, DoD had not been audited at all — it had not asserted that its financial statements were auditable, which is itself a remarkable statement about the world's largest military organization. The core reason DoD cannot pass an audit is not accounting fraud or deliberate concealment. It is that the financial data required to produce auditable statements — asset values, liability positions, obligation records, property accountability — exists in dozens of incompatible legacy systems, many of which cannot produce output that meets audit standards. The solution is IT modernization: replace the legacy systems with modern ERPs that produce clean, auditable data. But the IT modernization programs keep failing. The failed IT programs are one of the primary reasons the financial data cannot be reconciled. DoD cannot pass an audit without fixing its IT. It cannot fix its IT because the programs designed to do so fail. This is the circular problem that has cost billions and produced six consecutive audit failures.
The $1T+ Unsupported Journal Vouchers Problem
The most visible manifestation of DoD's accounting failure is unsupported journal vouchers (UJVs) — adjusting entries made to financial statements without documentary support for the underlying transaction. The Defense Finance and Accounting Service (DFAS) made trillions of dollars in UJVs over the years to force DoD's books to balance at year-end because the underlying transaction data from legacy systems was insufficient to support a proper reconciliation. A Reuters investigation in 2013 found that the Army made $2.8T (not billion — trillion) in accounting adjustments in a single fiscal year, most of them UJVs. These adjustments do not represent missing money in a cash sense — the money was spent on real things. They represent the gap between what the financial management systems can track and what a proper accounting record requires. Until the IT systems that create the underlying data are fixed, UJVs will continue.
The Army's FY2023 Audit Finding
In the FY2023 audit, the Army again received a disclaimer of opinion — the auditor's formal statement that they could not complete the audit due to insufficient evidence. The auditors cited: inability to locate and value real property assets; inability to reconcile equipment and inventory records between GCSS-Army and financial systems; missing or incomplete documentation for significant financial transactions; and data quality issues in GFEBS, the Army's general fund accounting system. These are not new findings. They are the same findings from FY2018, FY2019, FY2020, FY2021, and FY2022, slightly revised. The Army has made incremental progress in some areas and retreated in others. After five consecutive audit cycles, the Army has not produced a single financial statement that an independent auditor has validated. This is not a paperwork problem. It is a consequence of two decades of IT modernization failure.
What Audit Failure Means for Units
Service members rarely think about financial audits as something that affects them. But the inability to account for assets has real consequences at the unit level. Equipment that is on the books as "on hand" may have been transferred, damaged, or lost years ago — but the record was never updated in a system that auditors can verify. When a unit is required to account for property during a command inspection or pre-deployment equipment check, discrepancies between the GCSS-Army record and the physical count may reflect not current unit failures but accumulated data quality problems going back years through multiple system migrations. Supply sergeants spend significant time reconciling records that should not require reconciliation if the systems had been implemented correctly. This administrative burden is a direct cost, in NCO time and readiness impact, of the IT modernization failure.
Section 10
Reform Attempts: DDS, JEDI, Software Pathway, Platform One, and DOGE
DoD has not been passive in the face of IT failure. Multiple genuine reform efforts have been launched. Some have produced successes. None has fixed the systemic failure rate. Here is where each stands.
Modeled on the U.S. Digital Service (born from the HealthCare.gov rescue), DDS brought commercial software talent into DoD on 2-year tours. DDS produced genuine successes: Hack the Pentagon (the first federal bug bounty program), Hack the Army, multiple rescue missions on troubled programs. But DDS was a boutique operation — roughly 80 people — in a department that manages $40B/year in IT. DDS could model better practices and rescue individual programs. It could not fix the acquisition culture, the requirements process, or the budget cycle that caused the underlying failures.
The Joint Enterprise Defense Infrastructure (JEDI) contract was a $10B single-award cloud contract intended to modernize DoD's data infrastructure. It was awarded to Microsoft in 2019 after a procurement process that included allegations of improper influence (specifically, allegations that President Trump pressured DoD leadership to disadvantage Amazon). Amazon filed a protest; the Government Accountability Office denied it; Amazon filed suit in the Court of Federal Claims; the court found sufficient basis to enjoin contract performance; DoD ultimately cancelled JEDI in 2021 without beginning the transformation it was supposed to enable. The replacement program — Joint Warfighting Cloud Capability (JWCC) — was awarded to multiple vendors in 2022. The three-year JEDI delay pushed back DoD cloud modernization by an acquisition cycle. The program became synonymous with procurement failure even before work began.
DoD's 2020 revision to acquisition policy created a dedicated "Software Acquisition Pathway" that allowed programs to use continuous delivery and agile development rather than traditional waterfall milestones. This was a genuine structural reform — not just guidance, but a change to the acquisition regulation that governs how programs are managed and oversight is structured. Programs using the Software Pathway can field capabilities incrementally rather than waiting for a full system to be "finished." Early programs under the new pathway (including some Kessel Run and Platform One-hosted applications) have shown what agile development in DoD can look like. The test is whether the pathway survives contact with the institutional behaviors — requirements growth, oversight burden, contractor incentives — that killed the previous generation of programs.
Platform One (Air Force) and Kessel Run (Air Force, operational software) represent the clearest evidence that DoD can develop and deploy software at commercial speed when institutional barriers are removed. Kessel Run was stood up in 2017 as a software factory focused on operational logistics and scheduling software for the Air Force. It deployed usable applications within months — not years — and did so with a team that included commercial software engineers working alongside uniformed personnel. Platform One built a DevSecOps infrastructure that gives programs a hardened, accredited software development and deployment environment, eliminating the months-long accreditation process that delayed DoD software programs. These are genuine successes. They are also exceptions. The programs that killed $30B+ in DoD IT investment — DIMHRS, ECSS, LMP — were managed under the old model by the old institutions with the old acquisition culture.
The Department of Government Efficiency (DOGE), activated in early 2025, stated objectives that included eliminating waste in government IT. DOGE's interaction with DoD IT systems has been limited in public reporting compared to its activity at civilian agencies. The systemic problem — that DoD's failed modernization programs reflect acquisition culture, requirements processes, and budget cycle mismatches that cannot be fixed by an outside review team without sustained, multi-year institutional reform — has not been addressed in any DOGE public communication to date. The question of whether DOGE's approach (rapid assessment, system access, cost-cutting targets) is compatible with the deliberate, security-conscious nature of DoD IT modernization remains open.
What the Commercial Tech Industry Does Differently
Ship Early, Fix Fast
Amazon deploys code thousands of times per day. Google ships to production continuously. The philosophy: working software in users' hands beats perfect software that ships in 5 years. DoD's acquisition process structurally prevents this model for programs over ~$50M.
Small Teams, Empowered
Kessel Run and Platform One succeed because they have small, empowered teams with decision-making authority. Traditional DoD programs have large teams with diffuse authority and multiple decision layers. Amazon's "two-pizza rule" (teams small enough to be fed by two pizzas) reflects a genuine organizational insight: small teams move faster and own their outcomes.
Fix Requirements or Freeze Them
Commercial products either lock requirements for a release and ship, or run continuous discovery in tight user feedback loops. DoD programs do neither: requirements change continuously but are not validated with users through rapid iteration. The result is that the system being built is increasingly misaligned with real user needs.
Real User Feedback, Acted On
Supply sergeants who use GCSS-Army every day have detailed feedback on what makes it slow and error-prone. Commercial software companies treat that feedback as primary input. DoD programs filter user feedback through requirements processes, change control boards, and vendor negotiations that can take 18 months to produce a fix.
Frequently Asked Questions
How much has DoD wasted on failed IT programs?
Precise figures are difficult because "wasted" requires a definition. Programs that were cancelled outright — DIMHRS (~$1B), ECSS (~$1B) — represent the clearest cases. Programs that were deployed but failed to deliver on their original scope — LMP ($2B+), GCSS-Army ($3.5B), Navy ERP ($1B+), GFEBS ($1.3B+), IPPS-A (~$900M) — represent a more complex accounting: some value was delivered, but at far greater cost and with far less capability than planned, and often with ongoing costs to maintain systems that do not meet audit or interoperability requirements. A rough floor estimate across the major documented failures is $30B over the past 25 years. The true cost, including legacy system maintenance costs that should have been eliminated by successful modernizations, is higher.
Why does DoD keep failing at IT when commercial companies succeed?
The differences are structural, not a matter of capability or intent. Commercial companies can define their requirements and hold them relatively stable. DoD programs must accommodate requirements from multiple stakeholder organizations with competing priorities, producing requirements that grow and change throughout development. Commercial companies adopt new technology when it proves out. DoD programs are funded through a 5-year budget cycle that locks technology choices years before deployment. Commercial companies can fire a vendor and switch approaches when something isn't working. DoD programs face 2-year re-competition timelines and political resistance to cancellation. Commercial companies can deploy incrementally. DoD programs were historically required to reach a "fully capable" milestone before any deployment. Each of these structural differences is addressable in principle. Addressing them in practice requires sustained institutional change across acquisition culture, budgeting, contracting, and oversight — simultaneously.
What is the connection between IT failure and DoD's failed financial audits?
DoD's financial statements are produced from data that lives in legacy IT systems — dozens of them, many incompatible, many with documented data quality problems. An auditor verifying that a financial statement is accurate must be able to trace reported values back to supporting documentation. When the underlying IT systems cannot produce that documentation — because records were lost in migrations, because the systems cannot generate compliant reports, because data was never entered correctly in the first place — the auditor cannot validate the statement. The Army's property accountability problem is directly traceable to LMP's failed implementation and the subsequent GCSS-Army transition, which degraded asset visibility during a multi-year period that created data quality gaps that are now permanent audit liabilities. You cannot fix the audit without fixing the IT. You cannot fix the IT because the modernization programs keep failing.
What is a software acquisition pathway and does it help?
The Software Acquisition Pathway, established in 2020 via a revision to DoD Instruction 5000.02, creates a formal acquisition track for software programs that allows them to operate under agile development principles rather than traditional waterfall milestones. Programs using the pathway can field capabilities incrementally, with oversight focused on user outcomes rather than technical design reviews. It is a genuine structural improvement. Whether it prevents the next generation of failures depends on whether programs actually use it — and whether the institutional behaviors around requirements growth, contractor management, and oversight burden change to support the new process.
What is Kessel Run and why is it considered a success?
Kessel Run is an Air Force software factory, founded in 2017 and based in Boston, that builds and maintains operational software for Air Force logistics and scheduling. It is staffed by a mix of Air Force personnel and commercial software engineers, operates using modern DevOps practices, and deploys working software within months rather than years. Its most prominent product is a suite of aircraft scheduling and logistics coordination tools that replaced spreadsheet-based processes. Kessel Run is considered a success because it actually deployed working software to users, received positive feedback from those users, and did so faster and cheaper than the traditional acquisition model would have. The question for Kessel Run's legacy is whether its approach — small teams, strong commercial talent, limited bureaucratic overhead — can be scaled to the large ERP programs that have consumed most of DoD's IT waste budget, or whether it only works at the smaller-scope application level.
What happened to the people who ran the failed programs?
In most cases, the program managers and government officials responsible for DIMHRS, ECSS, LMP, and similar programs retired or moved to other roles without formal accountability for the failures. This is a structural feature of government employment, not individual misconduct: absent fraud or gross negligence, government employees are not legally liable for program failures. The contractors — IBM on DIMHRS, CSC on ECSS, SAP's implementation partners — were paid for work completed per contract terms and generally were not required to refund funds for failed deliverables. Contractor performance records, which are supposed to inform future source selections, are often not as negative as the program outcomes would suggest, because negative performance assessments are contested and because program offices have incentives to avoid the conflict that public negative assessments create. The lack of accountability for failure is part of why failure recurs.
Explore More
Sources and methodology: DIMHRS cancellation and cost history from GAO reports GAO-05-707 (2005), GAO-09-780 (2009), and DoD IG report DODIG-2009-097. ECSS cancellation from Air Force press release (November 2012) and GAO-12-565 (2012). LMP asset visibility problem from GAO-05-150 (2005) and Army Audit Agency reports on post-implementation review. GCSS-Army program cost from DoD Selected Acquisition Reports (SARs) and Army program office fact sheets. IPPS-A schedule and cost from GAO annual IT acquisition management reviews (2018–2024). Navy ERP program history from CRS Report R44891 and Navy FIAR documentation. DoD audit results from DoD Comptroller annual audit reports (FY2018–FY2023). Unsupported journal voucher figures from Reuters investigation “The Pentagon's Doctored Ledgers Conceal Epic Waste” (November 2013). GAO High Risk List inclusion from GAO High Risk Series: DoD Financial Management (2023 update). Software Acquisition Pathway from DoD Instruction 5000.87 (October 2020). Platform One and Kessel Run program information from Air Force public affairs and DoD Digital Service publications. JEDI procurement history from court records, GAO protest decisions, and DoD press releases. All cost figures reflect publicly reported program obligations or estimates; all-in government costs including labor, infrastructure, and legacy maintenance are higher. No allegations of individual illegality are made beyond findings established in official government reports and public court records.