Enable breadcrumbs token at /includes/pageheader.html.twig

Guest Blog: Lowering Walls and Blurring Lines

By Dr. Louis S. Metzger

The latest Incoming column from Lt. Ben Kohlmann, USN, titled “Link Warfighters to Technologists at the Lowest Possible Level” (SIGNAL Magazine, April 2013), resonated with observations I’ve made and conclusions I’ve reached over the years. I’ve been involved with the research and development and acquisition communities for a long time, including serving as the Air Force chief scientist from 1999 to 2001. Perhaps my adding to Lt. Kohlmann’s advice will help it gain additional traction, and stimulate further discussion and activity.

Leveraging technology to provide our military with improved capability requires diverse insights, multiple skills and varied roles. The insights cover current understanding of user needs, the operational environment, and the potential of existing and emerging technology. The skills span science and engineering, contracting, testing and training. And the roles include requirements developer, laboratory investigator, acquirer and support provider. The realities of specialization demand that multiple communities come together to provide all these ingredients. Unfortunately, interpretation of rules, processes and culture have built walls, and suspicion between different communities to the extent that the teamwork and collaboration needed to expeditiously develop and field new capabilities often islacking.

Too frequently, we still see a “throw it over the wall” mindset between the laboratory, requirements and acquisition communities, and gaps may exist even between the users in the field and their own requirements agencies. New ways of working must be found. During a trip to visit bases in the Pacific when I was Air Force chief scientist, I invited along a representative from each community—requirements, laboratory and acquisition. We traveled as a group and together we heard directly from the users in the field about their operations and needs. It was amazing how our group quickly started to collaboratively solve problems, bringing to bear each home organization’s strengths and resources to make things happen. Clearly, this approach can’t create a major new acquisition program of record or funding for the next F-35, but fortunately many problems in the field are amenable to much simpler and less costly solutions.

I witnessed a similar example in Turkey while visiting Incirlik Air Base during Operation Northern Watch. I ran into a young captain I knew from an acquisition program office. He was on a temporary deployment working on communications for an air operations center. Despite having been on the receiving end of requirements in his old job, his exposure to real-world problems in the field was eye opening for him, and it caused him to reach back to his program organization for assistance in ways different than they had been providing. When the walls between communities are lowered, person-to-person communications is encouraged and innovation is allowed to flow freely, good results are seen.

Taken to the next level, consider not just lowering the walls but adjusting what’s on each side. Walls not only impede the flow of ideas but the “we/them” mindset they foster destroys trust. We hear a lot about the advantages of 80 percent solutions that can be fielded much more quickly and for much less money. The problem is that “we” don’t trust “them” to deliver the right 80 percent solution. This is why it is difficult for the user community to agree beforehand to accept an 80 percent solution from the acquisition community, yet the users are more than happy to employ an 80 percent solution that they themselves help develop. Such user developed solutions, however, are often relegated to shelf-ware once the initial developer moves to his or her next assignment, because structures for adequate training and support are neglected. Moreover, lack of enterprise insight can result in homebrew developments having integration difficulties or introducing security vulnerabilities. Might the roles of various communities be redefined to remedy this situation?

Consider what might result if a different relationship is forged between acquisition programs of record and users, especially for information technology-intensive applications. A productive new role for the acquisition community could revolve around:

  • Setting the architecture and providing the infrastructure
  • Prototyping and experimentation with users–serving as the “application engineer,” assisting user-driven developments with guidance, facilitation and design help
  • Rapid integration and test, leveraging an always-on, distributed capability
  • Rapid certification and accreditation
  • Training and sustainment support.

The idea is to blur the lines to create a more collaborative partnership that overcomes the “we/them” distrust and speeds the fielding of useful capability. This will not be easy. Significantly expanding the scope of what’s permitted, and expected, of at least a subset of programs of record, including their flexibility to spend money, will have to be accepted and enabled by many stakeholders. Users will also have to accept their partnership role. The payoff may be worth it. The Defense Science Board study report, “Enhancing Adaptability of U.S. Military Forces,” published in January 2011, voiced some similar suggestions.

Link warfighters to technologists at the lowest possible level. Lower the walls between communities, encourage person-to-person communications and let innovation flow freely. Blur the lines between communities, consider a new partnership between the acquisition and user communities, and redirect the expectations for certain programs of record. These ideas are related and all are focused on the same goal–more effectively supplying better capability to our military.

 

Dr. Louis S. Metzger is a fellow of The MITRE Corporation and its corporate chief engineer. He has served on the Air Force Scientific Advisory Board, and was the Air Force chief scientist from 1999 to 2001. He received AFCEA’s Benjamin H. Oliver Gold Medal for Engineering in 2005. A more extensive biography can be found here.

The views expressed by our guest bloggers are their own and do not necessarily reflect the views of AFCEA International, SIGNAL Magazine, The MITRE Corporation or any other organization.