If MIL-STD-881 Was The Right Tool, We'd Use It

McNamara called. He wants his WBS back

Been a little quiet for the past week and definitely behind on posting the next in the ethics series, as I’ve been deep in a (multi-)proposal hole. It’s always great to see the government driving opportunities out there and helping move things forward. But it would be really great to not stack them all on top of each other, at the same time. Thanks.

Credit where it is due. After decades of “buy commercial first” memos that never quite stuck, the Department is finally moving on it. Real policy. Real Executive Orders. Real top cover for the offices pushing commercial buying through the system. Programs that used to die in acquisition are getting traction. Companies that used to bounce off the DoD wall are finding the door. That shift matters, and it is the right move.

One major pain point has been watching efforts released as “commercial first” but still trying to jam them into big traditional program processes. The big one here is MIL-STD-881 and its amazingly enjoyable work breakdown structure.

Some of my colleagues at Forterra wrote up the policy case on the challenges of CSDR in When Bureaucracy Goes to War. It is the right argument at the right altitude and totally correct. This is the same fight from the engineering and program side. We see the contradiction in how we design the products and execute the programs. It shows up as wasted hours and false data created by forcing square pegs into round holes.

I’m not gonna lie. The following is not a well-researched look at the history of defense program management and the legacy of Robert McNamara or the after effects of Les Aspin’s “Last Supper.” It’s me stepping on a soapbox and yelling into the void.

---

There is no commercial version of MIL-STD-881. Industry has had sixty years to build one. Nobody picked it up. The avoidance is intentional.

The Department of Defense wants commercial off-the-shelf solutions. The latest technology. Faster fielding. Lower costs. Iteration at the pace of tech firms. Then it turns around and demands those same vendors decompose their costs into a Work Breakdown Structure designed in 1968, around vehicle architectures from the Cold War. Pick one. You cannot have both.

This contradiction shows up in every COTS-heavy DoD program. It is killing the speed advantage that commercial sourcing was supposed to deliver.

Evidence by Absence

If MIL-STD-881 captured something useful about how products actually get built, somebody in commercial industry would have adopted it. Or built an analog. Or written a competing standard. Sixty years on, nobody has.

Apple does not run product cost on 881. Tesla does not. Boston Dynamics does not. The major automakers do not. Inside defense-tech companies built around DoD work, internal product development runs on commercial frameworks. 881 lives in a separate compliance system from the one engineers and program managers actually use to make decisions. The companies building the most complex, software-defined, hardware-rich products on the planet all know that 881-style decomposition is not how you understand the cost of a product.

The sharpest data point sits inside the dual-use defense primes themselves. Boeing Commercial Aircraft and Boeing Defense run on different cost frameworks. When the same company builds for both markets, it does not unify its reporting around the DoD standard. It maintains two separate systems. That is a tell.

The standards bodies have had decades to bless something resembling 881. FASB. GAAP. IFRS. ISO 21500. PMBOK. None of them decompose product costs into “vehicle electronics” and “armament” and “armor.” Because those categories are not how engineers think, not how supply chains run, and not how products get built.

Let’s ignore the challenge of figuring out how to fit a quadrupedal robot’s leg actuator into engine/transmission/final drive/etc. How do you align a series hybrid?

What Industry Actually Uses

Industry runs on Bills of Materials. Product line accounting. Activity-based costing. Project ledgers tied to delivered features. Standard cost against actual cost, with variances tracked to operational decisions rather than pre-defined WBS buckets.

These frameworks share a common feature. They are organized around the way the work actually flows. They map to engineering reality, supply chain reality, manufacturing reality, software release reality. They evolve with the product. They scale across product generations. Any engineer worth their salt understands that the right way to structure a product is how you actually build it.

MIL-STD-881 does the opposite. It imposes a fixed taxonomy on a moving target. It assumes a clean-sheet development program with bounded subsystems that map to clean physical decomposition. That assumption was reasonable for an M1 Abrams in 1980. It is not reasonable for a dual-use/COTS uncrewed ground vehicle in 2026, where the autonomy stack updates monthly, weekly, or even daily; the compute module rolls every eighteen months; and the sensors get refreshed because better LiDAR hit the market.

And the “electronics” bucket itself stopped describing the vehicle. Compute is not a subsystem anymore. It is in the engine. In the steering. In the drive train. In the weapon. Zonal architectures and software-defined platforms run the same processor stack across navigation, power management, communications, and weapon control. You cannot allocate the cost of that processor cleanly into 881 categories. It lives in all of them at once. The buckets stopped matching the hardware two architectures ago.

You cannot run a commercial cadence inside a Cold War cost taxonomy. The taxonomy wins, and the cadence loses.

The Field Report

I lived this on the Robotic Combat Vehicle surrogate program. Real engineering hours, lots of them. Spent mapping previous development and rapid integration activities into work breakdown structures built for clean-sheet, long-term development of legacy weapon systems. All to fulfill CSDR requirements. Understanding the cost to develop and build the system was not worthless. But the framework forced false precision onto a process that is iterative, modular, and driven by commercial market forces rather than government milestone schedules.

The final BOM structure and cost model did not match the initial one. Not because of a requirements change. Because we were re-designing it at the same time we were building it, the system evolved as we identified challenges and solved problems. The cost framework (and related CSDR) treated that as an anomaly that demanded every deviation be explained and justified.

It got worse on the build side. CSDR wants to treat each individual vehicle build as if it is rolling down an assembly line. Sequential. Bounded. Repeatable. We were building first-of-a-kind systems during COVID supply chain disruptions. You worked on one assembly until you ran out of parts, then shifted to the next vehicle or the next subsystem. Batch building. Opportunistic sequencing. Whatever kept the program moving forward.

That dynamism was critical to the program’s success. We held the kickoff days after the USG shut down travel for COVID, saying “we’ll have the PDR in a few weeks in person.” Ten months later, we delivered the last vehicle early, still under COVID restrictions. That was pulled off by being flexible, adapting on the fly, a lot of hard work, and a good bit of luck.

Some of those activities did not have clean boundaries between them in the 881 structure. We were constantly drawing lines around work that did not respect the lines we were being asked to draw.

And the data that came out the other end? It eventually went into DoD cost models that estimate what future systems should cost (granted long after it was needed, but that’s another story). Models built on false decomposition, previously funded (internal, external, and at-risk) development overlooked as it wasn’t on contract. And that was work by an established defense contractor with an approved accounting system. Imagine how you do it in a commercial startup that doesn’t have the systems in place, or even a next-gen DefTech firm with years of aggressive venture-backed technology investment.

881 has no mechanism to capture those costs. The reporting burden is the annoying part. The feedback loop into the Department’s own future cost models is the dangerous part.

Two Worlds. Keep Them Separate.

Here is the honest concession. MIL-STD-881 still works for big traditional programs. Virginia-class submarines. F-35 production. The next aircraft carrier. The government funded the development, the cost structures repeat across lots, and the WBS maps to physical deliverables that exist in the real world. The data feeds reasonable estimates of similar future programs. Fine. Keep it there.

What does not work is forcing commercial-leveraged programs into traditional cost reporting. The two worlds run on different cost realities, different speed regimes, different assumptions about who funded what. Trying to push them through a single framework is what produces the false data, the wasted engineering hours, and the distorted future estimates.

Leveraging commercial technology is the right move. The Department’s own modernization strategy says so. The Executive Orders say so. Every “buy commercial first” memo for the last thirty years says so. But “leveraging commercial” means accepting commercial cost structures. It means BOMs and product accounting and refresh cycles. It means visibility into total cost of ownership, not a false decomposition of development costs the government never paid.

The fix is to stop trying to fold COTS-heavy programs into 881. Run the two acquisition tracks on the cost frameworks each one actually fits. Big traditional programs get their 881-grade decomposition (and the pace that comes with it). Commercial-leveraged programs get the cost reporting that commercial product builders already use. Different tools for different jobs.

Stop hammering the square peg into the round hole.

---

Bots of War is a publication by Jon Hastie, VP of Tactical Robotics at Forterra. Views expressed are his own proposal sleep deprivation driven rants and do not reflect those of his employer