How to Avoid a Multi-Billion-Dollar Blunder

By Sarah Khogyani 

As the sagely advice goes, there is no better way to set yourself up for failure than by having grandiose expectations. The U.S. military took expectations for the perfect software-defined radio technology to a $6 billion level, only to have failed monumentally. We should not catalog this as a mistake to be forgotten, but rather, as a blueprint on how to avoid such time-consuming and finance-depleting blunders.

The Joint-Tactical-Radio-System (JTRS) Ground-Mobile-Radio (GMR) agenda launched in 1997 with goals of delivering 32 different waveforms all at once, or as Bauman describes, “a recipe for disaster.” The problem with this en masse approach was that hardware designs were changing incrementally.

---

As a result, the JTRS program consistently delayed product execution. More money was spent to make the device better, but it also became bigger—so big that it weighed 207 pounds. The acquisitions officer, Ward, specifies that the “engineers continuously added features and functions and capabilities on paper, all of which made the design worse and made the users wait.”

So, what’s the moral of this multi-billion-dollar story?

With basis in Sean Gallagher’s evaluation of the program, lean startup methodology, and agile software development, I have broken it down into a few simple tips:

• A modular approach is better than en masse. The wireless consumer market shows that rapidly released products are more effective. When technology upgrades, it’s out with the old.
• More is not better. Rather, the simplest solution is the most effective. While waiting for JTRS GMR, the Marine Corps’ set up a satellite phone with wireless technology (CONDOR), a lower-cost and simpler alternative.
• Use Performance Engineering in the design process. You can’t produce complex products without testing every phase of the systems development life cycle. This includes creating various design alternatives, which would have prevented inadequate results.
  
• Responding to Change. If JTRS tested and shipped earlier, they could have measured effectiveness by assessing feedback from users. 
  

The problem with JTRS GMR, and many failed start-up companies, was that they spent too long perfecting a product and not releasing it to the users. Such a mistake can be avoided by following a practiced lean and agile methodology.

The agile manifesto suggests having:

• Working system that is continuously updated.
• Consistent customer collaboration.
  
• Adaptability to changing development.

Having this continuous innovation ultimately saves time and extensive labor. It’s the difference between cleaning your room a little bit everyday, or letting the mess pile up until the end of the month. You’ll probably have to spend an entire day cleaning, or hire help. Time and money.

StartupMonthly is rooted in lean startup, agile, and customer development methodologies. Our programs teach start-up companies how to operate in the most efficient ways. Learn more about how to participate in StM programs at startupmonthly.org

Sources:

Defense news:
(http://www.defensenews.com/article/20110812/DEFSECT05/108120302/Reduced-JTRS-Buy-To-Save-15B-Pentagon)
(http://www.defensenews.com/apps/pbcs.dll/article?AID=2011111140301)
Wikipedia:
(http://en.wikipedia.org/wiki/JTRS)
Sean Gallagher:
(http://arstechnica.com/information-technology/2012/06/how-to-blow-6-billion-on-a-tech-project/2/)
Foresight Systems-Mands:
(http://www.foresightsystems-mands.com/blog/software-defined-radio-sca/jtrs-gmr-a-cautionary-tale/)