“JCIDS is beyond redemption. The only responsible course is to put it out of its misery, carve it from the DoD’s body, bury it, and salt the ground so that nothing resembling it ever grows back.
Now is the time for courage, not to fix JCIDS but to kill it.”
Bill Greenwalt and Dan Patt, Required To Fail
We’ve called for killing JCIDS for years. Congress in the FY24 NDAA Section 811 required the Department to modernize the requirements process and the Department in response published the 811 Report. Bill and Dan’s report provided the death blow.
In November 2025, SECWAR signed a memo on the same day as the Acquisition Transformation Strategy focused on Reforming the Joint Requirements Process to Accelerate Fielding of Warfighting Capabilities. It directed the Vice Chairman of the Joint Chiefs to disestablish JCIDS and the Joint Requirements Oversight Council (JROC) to stop validating Service requirements documents to the maximum extent possible. The Joint Staff and OSW published the new charter and manual for a new Joint Force Requirements Process (JFRP).
SECWAR’s memo also required:
“Within 90 days, launch reviews of Military Service requirements processes, identifying reforms to expedite outcomes, strengthen force design, enhance industry engagement, and enable experimentation-led approaches.”
That’s where it stalled. The Service requirements organizations may have initiatives ongoing, but we haven’t seen them take bold steps toward a new model. They’re running Zombie JCIDS with the same documents, boards, and processes.
We’ve seen this before. We supported OUSD(A&S) in implementing the Middle Tier of Acquisition pathway. Congress specifically required in the FY16 NDAA Section 804 that “programs using [the MTA] pathway are not subject to JCIDS.” So what did the Services do? They built a JCIDS-lite process for rapid acquisition. Want to rapidly prototype new, innovative technology to demonstrate a military capability? No problem, you just need your 4-star Service Chief to approve your rapid requirements document. So much for wasting your “Get out of JCIDS Jail Free” card.
The answer isn’t another streamlined document or faster staffing process. The Services need to stop treating requirements as documents and start managing them as digital inputs into a portfolio process that connects missions, operators, threats, technology, experimentation, acquisition, and resources.
Service Chiefs and Secretaries should empower small teams to build a requirements system from first principles, not simply streamline legacy processes. Requirements, acquisition, and budget transformations must be aligned as one modern enterprise engine. Advancing one without the others is a recipe for failure.
Start From First Principles
Work closely with operational forces to understand their current and future needs.
Assess adversary threats and the operational environments, today and projected.
Engage industry to learn what they’re developing and producing and incorporate into requirements planning.
Establish a process and tools for Identifying which capabilities have the greatest mission impact for the cost.
Focus operators, acquirers, and developers on mission outcomes, not documents.
Think Portfolios, Not Programs
Acquisition pivoted from Program Executive Officers overseeing programs to Portfolio Acquisition Executives acquiring integrated suites of capabilities. Requirements should make the same move. Sunset most program requirements documents and shift to a dynamic portfolio environment.
Manage requirements as a dynamic repository of capability needs. Load the legacy ICDs, CDDs, and all their variants in your favorite LLM on GenAI.mil. Extract the small-r requirements into a comprehensive list, grouped and tagged by like elements. The requirement should be the data, not the document. Then map each requirement:
Satisfied by capabilities fielded or in production.
Addressed by capabilities prototyped or in development.
Unaddressed.
Mapped to mission threads and their operational impact.
Prioritized with and acceptable trade space defined.
Work with the operational commands to prioritize requirements within broader portfolio and sub-portfolio groupings. One outcome may be that current funded requirements are ranked lower than ones that deserve a lot more attention and acceleration. A ruthless rack-and-stack, owned by operational leaders with portfolio acquisition executives forces the investment decisions and acquisition roadmaps that the legacy system avoided.
With that in place, the acquisition and budget communities can finally have clear direction. They can find the smallest set of capabilities that addresses each need and get them delivered to the portfolio.
Work with Industry
Requirements written in isolation are inherently limited and overly influenced by technology and solutions already in the pipeline. Industry has a better pulse on what’s possible knows what’s possible before the requirements community does.
Share the capability needs, at the appropriate classification level, by portfolio. Frame them as problems, not specifications, so companies can propose approaches the government didn’t think of. Commercial Solutions Openings and OTAs are built for this. Run portfolio-level industry engagements on a regular rhythm rather than one-off industry days tied to a single program.
Make it a two-way street. When industry or experimentation demonstrate a better way to achieve the mission outcome, the requirement should change. A repository that updates only on a document cycle can’t keep up.
Let Experimentation Drive Requirements
SECWAR’s memo calls for experimentation-led approaches, and this is where Services can move fastest. Put prototypes in operators’ hands, learn what matters, and refine the requirement from what happens in the field. That beats a staff officer’s best guess years before anything exists. Whenever possible, validate requirements through operational evidence rather than staff review.
Way Ahead
JCIDS is dead. Anyone in the Services clinging to it is an anchor dragging on the Department’s push for greater speed, agility, and innovation. Service Secretaries and Chiefs must hold their requirements leaders accountable to purge the Pentagon of the JCIDS Zombies and empower a team to chart the future course. Start with three questions:
How long does it take to go from an identified need to something acquisition and industry can act on?
How quickly are requirements keeping pace with operations, threats, and technologies changes?
Can we see at the portfolio level the priority capability needs and how each are or will be addressed and which investments will have the greatest mission impact?
If the answers are years, we can’t, and we don’t know, you have some zombies to hunt.





Pretty good -- A few items that I believe critical if the enterprise (not just DOD/DOW, but also Congress, and Industry writ large) truly wants change.
1. Getting operational feedback is good for the 'now' and 'near term' requirements. It does little or nothing to solve truly long-term or strategic problems. It needs to be a priority early from a system's perspective, but should become less of a priority/resource draw once a real system is in place.
2. Dumping all the current documents with their requirements will show how you are meeting some of those current requirements -- but will also give you "false positives" in terms of meeting requirements that are not actually validated by M&S or that are themselves "lesser values" based on 'trades' made by PM shops to stay within budgets/timelines.
3. I would frankly demand a "clean slate" approach for any requirements in the 2035 and beyond time horizons. Demand the Joint Staff provide a comprehensive OE w/threats and risks within 6 months (it's doable, and it's hard -- but taking longer makes it useless), and then direct the services to conduct actual analysis using M&S to create service level and core operational unit level Concepts documents within a year. Absent these overarching concept documents there is little or no intellectual grounding for ANY requirements documents; they may solve tactical (platform/system, small unit) problems, but they do not address operational value of formations.
I had hope (small, and unfounded) that the November memos would yield something -- but the "frozen middle" of bureaucrats, aided and abetted by Acquisition elements that believe only they have the answer has once again stymied the defense ecosystem. Might as well blow it up and start from scratch; there is no substantial increase in strategic risk.
I guess I'm the skeptic here. Of course the services want a JCIDS-like process. I had past experience in the DoD CB Defense Program, so my view may be limited here, but I don't know how you can suggest that requirements people don't "work closely with operational forces" and don't "assess adversary threats." Of course they do this. That's the easy part. Industry is ALWAYS there to engage requirements and acquisition officials. They still require an objective analysis of some kind to demonstrate that they did the work of determining the capability shortfall requires a hardware solution instead of a doctrinal or organizational fix. But of course you know that.
If you're suggesting we should just trust the program managers to work with industry and do the right thing, then you're just part of the problem. The acquisition officials don't seem to be motivated by much other than "let's field something quick and get credit for it" whether or not it meets the services' requirements. The JPEO for CBD worked for a decade to get a new protective suit, and despite its failing to meet basic requirements and a significant higher cost, it tried to twist the services' arms to accept it. It was a loser. This isn't the only example. Industry isn't much better, making promises about technical capabilities that it can't deliver or knows aren't true. But hey, with a few million dollars a year and a few more years of R&D, just maybe it can work for them. And let's not pretend that industry isn't out there lobbying the combatant commands with their tech solutions. Of course they are. It's just business.
Experimentation on its face is fine. No one can argue with trying new stuff out, unless it's the acquisition office that is funding industry to do experimentation along a very specific line. Because acquisition's got the money, they can afford to throw hundreds of thousands of dollars at experimentation, we don't have any other funding mechanism available. Meanwhile we have all these service laboratories churning out technologies that the acquisition office ignores. What a great gimmick, to take credit for experimentation when you control the outcome.
Until you empower the requirements offices to make the acquisition people give them what they ask for, instead of the acquisition people saying "take this junk, we know better than you," then you're going to continue to have JCIDS-like processes that are intended to make defense acquisition deliver what they want.