ABORT, RETRY, FAIL? Fixing Army Software

ABORT, RETRY, FAIL?  Fixing Army Software

Crispin Burke, James King, and Niel Smith

During an otherwise uneventful Congressional hearing this past April, US Army Chief of Staff General Ray Odierno lambasted Representative Duncan Hunter (R-CA) over criticism of the US Army’s intelligence processing software, known as DCGS-A (Distributed Common Ground System-Army). 

General Odierno’s outburst was the latest salvo in an ongoing, bitter, and convoluted debate over the US Army’s suite of Army Battle Command Systems (ABCS)—a slew of computer systems designed to help the US military better communicate, coordinate, and consolidate information. 

On one hand, the Army’s senior leaders have vehemently defended DCGS-A, a program which has already cost taxpayers over two billion dollars.  Gen. Odierno, during his Congressional testimony, even went so far as to claim that DCGS-A gives today’s captains on the ground access to greater intelligence than he had as a division commander just ten years ago.      

But Rep. Hunter has taken a very different view, one which echoes the growing frustration from troops in the field over DCGS-A.  For Soldiers in Afghanistan, DCGS-A is slow, cumbersome, and awkward.  As a result, many units have become so frustrated with DCGS-A that they’ve turned to an off-the-shelf solution from a Silicon Valley-based software company, Palantir.

In fairness, both Rep. Hunter and Gen. Odierno are right.  Indeed, Palantir has proven to be a simple, effective software solution for tracking insurgent activity in Afghanistan—so effective, that Army leaders have considered incorporating Palantir into DCGS-A.  But while Palantir could supplement DCGS-A, it could never fully replace it.  Indeed, despite DCGS-A’s unwieldy design, DCGS-A is still far more capable than Palantir ever could be.

So why the vitriol?  Much of the debate arises from the generational divide between the generals who promote and purchase these systems, and the troops in the field who actually use them.

Like many service members of his generation, Rep. Hunter—a Marine who served in both Iraq and Afghanistan—is a “digital native”, having paid his way through college creating websites and databases for high-tech companies.  By contrast, most generals would have been in their twenties by the time they encountered their first personal computers.

Many assume that today’s tech-savvy troops would be comfortable with the Army’s Battle Command Systems.  But while programs like DCGS-A, Command Post of the Future (CPOF), and Movement Tracking System (MTS) may be capable, troops generally deride their atrocious user interface, and poor, almost non-existent interoperability.

Of course, no general wants their Soldiers to struggle with a poor product.  However, senior officers generally have little involvement in developing these systems.  As a result, generals have not personally vetted their ease of use, either through hands-on use or in-depth briefings with the soldiers who will use the system.  As a result, these programs move forward on the sole basis of the end capabilities they deliver, despite the challenges troops face in fully implementing them. 

What does this mean for the modern battlefield?  In practice, we have found that some Soldiers have been so frustrated that they choose not to use these programs, and in some cases, have created their own workarounds.  In other words, the DCGS-A’s interface is so poor, that troops often elect to fight without one of their most valuable tools. 

Interface: KISS

Poor user interfaces cost the Army time and money.  Contractors offer training courses to certify operators Battle Command Systems (for a fee, of course).  Depending on the software system, these courses can last anywhere from 40 to 120 hours of classroom instruction to teach the basic functions of DCGS-A.

The steepest learning curve for Soldiers lies in simply fighting the user interface.  In general, most Battle Command programs are counter-intuitive to Soldiers who grew up with the functionality of Microsoft Windows.  For example, CPOF, which is found in nearly every tactical operations center, is based on UNIX, meaning that most functions run completely counter to those of Windows.  Worse yet, there is little commonality among systems:  the skills required to master CPOF are of little use when trying to navigate DCGS-A or MTS.

Compounding the problem is that maintaining trained personnel in these systems is a Sisyphean task for many commanders.  The high personnel turnover inherent in Army units constantly leaves them short of trained operators.  The hours invested in training a competent operator often encourages commanders to hold trained personnel in positions longer than prudent for their own professional development, with negative consequences for promotion. 

In sum, the poor utility of ABCS systems means that Soldiers simply cannot get the greatest tactical advantage out of these billion-dollar systems.  Navigating awkward and often backward commands and menus hinder their ability to provide commanders with timely and relevant information.  Indeed, Soldiers spend an unacceptable amount of time fighting the very systems designed to produce the information commanders need to fight and win the battle.

A system of systems, each at odds with one another

Worse yet, many operators find it difficult, if not impossible, to get the Army’s various Battle Command Systems to communicate with one another.  Intelligence analysts often have to be creative when trying to send and transfer data, particularly since the DOD has disabled USB ports and restricted the ability to burn CD-ROMs.  The difficulties have so thoroughly vexed some intelligence analysts, that many have resorted to manually inputting and analyzing data in Excel and Power Point in order to more easily distribute intelligence, bypassing the Army’s billion-dollar DCGS-A program altogether.

Fortunately, there is light at the end of the tunnel.  During a recent training exercise at the National Training Center (NTC), a Colorado-based Army brigade was able to successfully disseminate graphics and intelligence from DCGS-A to CPOF, the Advanced Field Artillery Tactical Data System (AFATADS), and Force XXI Battle Command Brigade and Below (FBCB2)—a first for any unit at NTC.  The brigade, the 2^nd Brigade Combat Team of the 4^th Infantry Division, credited their success to months of coordination between their intelligence and communications section.

But while the 2^nd BCT’s success is certainly commendable, they should not have had to work so diligently in order for their various software programs to collaborate and share data.  The sheer inefficiency of these systems is unfathomable in the year 2013, in which most teenagers have little difficulty cross-posting between competing programs such as Twitter, Facebook, and Tumblr. 

Recommendations

Why does the Army pick such bad systems?  It certainly isn’t malicious intent on the part of the Army or its supporting contractors.  Rather, the generational divide between generals and troops in the field, can lead to conflicting ideas of what makes a good software program. 

The current practice of spelling out software requirements without associated usability metrics contributes greatly to the problem.   As long as the system performs the functions required in the contract deliverables, the vendor is in fulfillment of his contract.  Rarely are usability metrics related to usability included in the mix.  To that end, we suggest the Army’s proponents consider the following:

Establish a Common Army user interface.  One of the most frustrating aspects for soldiers is the lack of standardization between programs.  Most commercial desktop software utilizes some version of Microsoft’s standard interface, which places common commands in the same places, regardless of program.  Similar schemes are present in Google’s Android OS and Apple’s iPhone software, allowing users to quickly become productive with new programs and hardware with a gentle learning curve.  The Army should adopt and mandate a common user interface built around commercial software conventions.   When possible, the Army should also license and modify commonly used off the shelf commercial programs rather than design new interfaces. We have seen success with this in programs like the very popular TIGR software, whose intuitive interface was rapidly accepted by soldiers.

Require usability metrics as part of the contract deliverables.  Future program revisions should include clauses which mandate use of common interface heuristics.  Metrics should assess the number of dialogues, steps, or clicks required to perform basic tasks, receive help, or conduct file operations.  Contractors must conduct extensive beta testing with Soldiers, and Soldier feedback should be incorporated into the finished product.  

Code the software using open concepts, and design the software for user modding.   Army software is often locked into proprietary specifications of the vendors.  However, the commercial software and gaming industry often encourages add-ins and “mods” to their software that enhance the user experience.  In many cases, these mods are incorporated into later versions of the programs.  The Army should leverage the ingenuity of its tech-savvy soldiers to constantly improve and refine the systems they operate. 

Design software to export information into Microsoft Office formats.  Love it or hate it, but the Army runs on MS Office, especially PowerPoint.  Information from battle command systems must export seamlessly for presentation to senior officials.  Soldiers often spend countless hours manually transcribing information out of ABCS systems and into presentation-friendly formats that senior commanders demand.

Conclusion

The DCGS-A/Palantir debate unintentionally highlighted the problem of usability in major DoD software systems.  Soldiers overwhelmingly reject equipment and systems which are difficult to employ.  The Army’s must refocus on usability if it truly wants to maximize the capabilities of the ABCS systems and its successors.  Program managers must hold software designers accountable and provide clear incentives to build usability into each platform from the ground up, rather than as a design afterthought.   Failure to do so results in increased costs, unnecessary training hours, and frustration on the part of those tasked to use the systems on a daily basis.