Bridging the Gap: Connecting Ground-Level Operators with Acquisition Process Writers

Introduction

The U.S. military’s acquisition system is often described as rigid and slow-moving, whereas modern conflicts—such as the war in Ukraine—demand rapid adaptation and innovation. A significant disconnect exists between those on the ground experiencing operational challenges and those writing the processes defining solutions that can be acquired and deployed. This forum post explores how warfighters and capability developers can better collaborate to streamline the acquisition process.

See the guide on the wiki here

Key Discussion Points

1. Agility in Acquisition: Waterfall vs. Iterative Fielding

  • The U.S. follows a structured, long-term acquisition model, while conflict zones like Ukraine showcase the necessity of rapid fielding and iteration.
  • Industry should be engaged in ongoing development cycles rather than static, requirement-heavy contracts that delay innovation.

2. Fixing Requirement Writing to Align with Operational Needs

  • Common Issues:
    • Overly complex, contradictory, or unrealistic requirements.
    • “Kitchen sink” requirements that try to do everything and end up doing nothing well.
  • Solutions:
    • Shift to objective-based requirements that clearly define the operational problem.
    • Adopt leaner, mission-focused requirements, as demonstrated by the USMC reducing a 200-line requirement document to a two-page Statement of Need.

3. Integrating Rapid Prototyping & Field Testing

  • Tactical field testing (e.g., Tactical Innovation and Combat (TiC) initiatives) is in motion but lacks clear pathways within DOT&E oversight.
  • Establish defined yet flexible evaluation processes for real-world validation before full-scale procurement.

4. Interoperability & Standards: The Weak Link

  • Current acquisitions often result in stovepiped systems that cannot communicate.
  • Government agencies must enforce modular, plug-and-play standards across systems (e.g., the Joint sUAS Capability Development Document mandates adherence to Joint Reference Architectures, but enforcement remains weak).

5. Government Bureaucracy & Bottlenecks: Overcoming the Slow Lane

  • While legal avenues exist for rapid acquisition, internal resistance to change hinders execution.
  • Funding mechanisms often require complete solutions before validation, blocking iterative development.

6. Avoiding Duplication & Fragmentation

  • Commands fund separate, incompatible Common Operational Picture (COP) tools instead of integrating existing solutions.
  • A concerted effort is needed to unify joint capability initiatives rather than reinvent the wheel in every branch.

7. Cultural & Structural Resistance to Change

  • Leadership is often risk-averse, rejecting disruptive innovations (e.g., resistance to FPV drone acquisition despite securing $68M in funding).
  • Institutional inertia prevents rapid adoption of emerging technology unless a champion pushes it through the system.

Steps to Bridge the Gap

For Ground-Level Warfighters:

  1. Learn How to Write Requirements:

    • If you don’t define what you need, someone else will—often poorly.
    • Educate yourself on writing clear, operationally grounded capability statements.
  2. Utilize Existing Rapid Acquisition Processes:

    • JUONS/JEONS: Joint Urgent Operational Need Statements for critical, fast-tracked capabilities.
    • SOCOM DIR 71-4: Special Operations’ rapid prototyping directive.
    • TiC (Tactical Innovation and Combat) Initiatives: Real-world field testing.
  3. Build Relationships with Capability Developers:

    • Find out who writes the requirements at your unit or higher command.
    • Engage them early and often; explain your needs in operational terms.

For Requirements Writers & Capability Developers:

  1. Engage Directly with End Users:

    • Walk the flight line, visit field units, and see the problem firsthand.
    • Create direct channels for feedback from deployed units.
  2. Simplify and Focus Requirements:

    • Don’t let bureaucratic bloat kill good ideas.
    • Cut unnecessary specs—focus on solving one problem well.
  3. Push for Institutional Change:

    • Advocate for enforcing interoperability and modular standards.
    • Work within existing rapid acquisition programs to bypass bureaucratic slowdowns.

Open Questions for the Community

  • What are examples of bad requirements, and how do we fix them?
  • How can we consolidate redundant Joint COP tools into a unified system?
  • What’s the best approach for accelerating DOT&E oversight?
  • How do we institutionalize faster procurement while maintaining accountability?

Conclusion

The frustration with slow acquisition is real, but solutions exist. By fostering direct engagement between those in the trenches and those writing the processes, we can push for more agile, effective, and mission-driven acquisition strategies.

For those in the fight: Seek out your capability developers. For those writing the requirements: Listen to the end users. Only through collaboration can we ensure our forces have what they need when needed.


Additional Resources


:busts_in_silhouette: Join the Discussion: What has your experience been with acquisitions? Have you seen success in cutting through bureaucracy? Let’s share lessons and ideas below!

Breakdown of the Discussion: Main Points and Context

For those who down arrowed. And removing all named context.

1. Rigid Acquisition vs. Agile Fielding

  • Problem: The U.S. acquisition system is rigid, relying on a waterfall approach, whereas Ukraine’s necessity-driven model demonstrates the need for agility.
  • Proposed Solution: Shift to iterative fielding and improvement, prioritizing operational capability over “perfect” solutions.

2. Issues with U.S. Military Requirements Writing

  • Key Issues:
    • Overly complex, unrealistic requirements.
    • Requirements often dictated by industry rather than operational needs.
  • Proposed Solution:
    • Adopt clear, narrowly focused requirements aimed at solving specific operational challenges.
    • Follow a government-defined objective framework, where industry aligns solutions rather than defining needs.

3. Rapid Prototyping and Field Testing

  • Challenge:
    • Efforts like Tactical Innovation and Combat (TiC) are limited by unclear oversight pathways under DOT&E.
  • Proposed Solution:
    • Define clear, flexible evaluation processes for field validation before scaling programs.

4. Interoperability and Standards

  • Problem: Siloed systems with no modular, plug-and-play interoperability.
  • Proposed Solution:
    • Enforce modular standards (e.g., cabling, software, Joint Reference Architecture).
    • Strengthen enforcement of standards like the Joint sUAS CDD to avoid stovepiped systems.

5. Government’s Resistance to Fast Iteration

  • Problem: Bureaucratic inertia prevents exploitation of legal avenues for rapid acquisition.
  • Proposed Solution:
    • Institutionalize government-owned architectures and standards to avoid vendor lock-in.
    • Create a culture that prioritizes rapid, iterative development.

6. Challenges with Joint Capabilities & Duplication

  • Problem:
    • Commands independently fund separate, redundant solutions, such as incompatible COP (Common Operational Picture) tools.
  • Proposed Solution:
    • Consolidate efforts into unified, interoperable systems to avoid redundancy.

7. Acquisition Bureaucracy and Bottlenecks

  • Problem:
    • Slow JCIDS/SOFCIDS processes hinder rapid adoption of cutting-edge technology.
    • Funding constraints require fully funded solutions before validation.
  • Proposed Solution:
    • Leverage existing programs like JUONS/JEONS, SOCOM’s DIR 71-4, and APFIT for rapid acquisition.
    • Streamline requirements using examples like USMC’s two-page Statement of Need.

8. Examples of Successful Streamlining

  • USMC Example:
    • Simplified 200-requirement systems into a two-page Statement of Need, reducing costs by 40%.
  • SOCOM Example:
    • SOCOM’s DIR 71-4 outlines a rapid prototyping process, demonstrating success despite limited awareness among personnel.

9. Cultural and Structural Resistance to Change

  • Problem:
    • Risk-averse leadership resists disruptive innovation.
    • Examples of resistance include FPV drone programs and IVAS despite substantial funding.
  • Proposed Solution:
    • Encourage a culture of calculated risk-taking and innovation at leadership levels.

10. The Role of Passionate Individuals in Change

  • Problem:
    • Systemic inefficiencies frustrate individuals who push for change, often leading to burnout.
  • Proposed Solution:
    • Support and empower capability developers by providing clear pathways and reducing bottlenecks in processes.

Referenced Documents & Regulations

  1. DOT&E Oversight: Governs testing & evaluation for major acquisition programs.
  2. JCIDS/SOFCIDS: Frameworks for structuring Joint and Special Operations requirements.
  3. TiC Initiatives: Emerging tactical testing program for rapid deployment.
  4. DIR 71-4: SOCOM’s rapid prototyping directive.
  5. Joint sUAS CDD: Defines interoperability requirements for UAS systems.
  6. AR 71-9: Army regulations on force development and requirements writing.
  7. TRADOC Capability Development Document Writer’s Guide (2012): Framework for writing operational requirements.
  8. JUONS/JEONS: Mechanism for addressing urgent operational needs.
  9. APFIT: Accelerated funding for innovative technologies.
  10. MIL-STD-2525: Military standards for symbology and data structures.
  11. SOF RAPTOR IV (SR-IV) IDIQ: Contract vehicle for rapid technology acquisition.

Highlighted Questions & Answers

Unanswered/Unclear Questions

  1. What specific examples of bad requirements exist, and how do we fix them?

    • Discussion required on identifying flawed requirements and actionable steps to streamline or redefine them for clarity and operational alignment.
  2. What is the best way to consolidate Joint COP tools into one functional system?

    • Exploration of strategies and frameworks to unify disparate Common Operational Picture (COP) tools into a singular, interoperable system.
  3. How can we accelerate DOT&E oversight for rapid fielding?

    • Addressing bottlenecks in the Department of Defense’s testing and evaluation process to enable quicker deployment of validated systems.
  4. What steps need to be taken to enforce interoperability standards across services?

    • Proposals to institutionalize adherence to standards like the Joint Reference Architecture and enforce compliance across all branches and programs.

Answered Questions

  1. How can requirements be streamlined?

    • Transition from hard, detailed specifications to objective-based frameworks.
    • Follow successful models like the USMC’s two-page Statement of Need, focusing on essential operational requirements.
  2. What acquisition processes can bypass traditional delays?

    • Unfunded Requirement Justification: Mechanisms to justify acquisition without initial budget allocation.
    • Technology Transfer Bypass: Leveraging existing systems for rapid deployment.
    • SOCOM’s SORRD (Rapid Prototyping/Fielding via MTA): Utilizing streamlined acquisition pathways for Special Operations needs.
  3. Can anyone write a JUONS/JEONS?

    • Yes, but it must be validated by a Combatant Command (CCMD) to ensure alignment with operational priorities and urgent needs.
  4. What is a fast-track procurement model?

    • Example process: JUON → Limited Fielding → Capability Development Document (CDD) → Joint Requirements Oversight Council (JROC) → Program of Record (PoR).
  5. Who writes and validates requirements?

    • TRADOC Capability Developers: Primary authors of requirements for Army programs.
    • Program Offices: Responsible for Navy, Air Force, SOCOM, and other branch-specific programs.
    • Combatant Commands (CCMDs): Validate urgent requirements for operational priorities.
    • Service Component Commands: Includes units like the 75th Ranger Regiment or USASOC, contributing to specific operational capability development.

If you were to enable more service members to provide the ground truth one of the largest gaps might be on what current capabilities exist.

The ground levels may be fending for themselves on what exist or has been funded to really be able to say not only that xyz capability exist but why it doesn’t meet the mission requirement.

Some automation can be used to help get people started as they then take it up to the appropriate level.

This is the community research tool which already had a section for dotmlpfp, minor adjustments based on the TRADOC Capability Developer PDF.