<img alt="dcsimg" id="dcsimg" width="1" height="1" src="//www.qsstats.com/dcs8krshw00000cpvecvkz0uc_4g4q/njs.gif?dcsuri=/index.php/c/a/Projects-Processes/Soldiering-On/1&amp;WT.js=No&amp;WT.tv=10.4.1&amp;dcssip=www.baselinemag.com&amp;WT.qs_dlk=XYknEb2M@YPFSbfw4o7DkAAAAAc&amp;">

A Long Way Back

By John McCormick  |  Posted 2004-04-04 Print this article Print

Veterans Affairs didn't have much to show for the half-billion dollars it spent on two projects—until some discipline helped muster the troops.

A Long Way Back

In January 2001, at his Senate confirmation hearing, incoming Veterans Affairs Secretary Anthony Principi had a harsh assessment of the VA's information-technology efforts. "The VA has absorbed billions of dollars allocated to improving its ability to collect, process and communicate data,'' he testified. "Frankly, I do not see improvement proportional to the resources consumed."

One of Principi's first goals was to cut the backlog of unrated—and, therefore, unprocessed—claims to 250,000. But a lack of discipline was delaying the delivery of the new claims-processing system, which was supposed to ease the paper jam.

"Like a lot of large enterprises, there was no real focused vision of where the organization needed to be," says John Gauss, the VA's chief information officer from 2001 until June of last year.

Principi told Congress that the "lack of focus" and "inadequate management" were killing the claims-processing project. He had history on his side.

The VA's Veterans Benefits Administration embarked on its new claims-processing, -tracking, and -payment system in 1986. Ten years later, the General Accounting Office (GAO) concluded that after "numerous false starts" and an ante of $300 million the VA had little to show for its effort. The GAO castigated the VA's software-development practices as "extremely weak...with no identifiable strengths or improvement activities." Investigators cited a failure to identify the business requirements of the system. Years of delay resulted from confusion over what features and functions actually were needed.

Nevertheless, in 1996, the VA tried again. The new initiative, dubbed the Veterans Service Network, or VetsNet, was expected to take two years and cost $8 million. By mid-2000, despite $100 million spent on VetsNet and related systems, according to the GAO, the project wasn't anywhere near completion.

The GAO said the VA still was inept at defining, and sticking with, the claims processes to be embodied in its software. In fact, Edward Meagher, deputy CIO at the VA, says requirements were allowed to change "on the fly."

By March 2002, the GAO still wasn't seeing results and expressed "uncertainty" about whether VetsNet could be saved. But Principi, a decorated Vietnam veteran, was determined to turn things around. "He said, 'We're going to fix this,'" Meagher recalls.

Principi wasn't flying blind. He had held several managerial positions in the private sector, including a stint at Lockheed Martin IMS Corp., a systems-integration specialist that was bought by Affiliated Computer Services in 2001.

Principi brought in Gauss as his CIO; Gauss brought military-like discipline to the project. One of his first moves was to "freeze the requirements,'' telling all team members to take no additional suggestions on features or functions from users.

"If your requirements change on a daily basis, you're never going to deliver a product," Meagher says.

For instance, in response to suggestions from doctors, administrators and clinicians, the project team had continually fiddled with the number of fields to display in menus on VetsNet screens. The aim: Gather more information on claims and claimants, in each screenful of options. "Nice things," Meagher says. "But they're changes. Whatever the screens were, they got frozen."

Even changing a single field reverberates throughout the development process, he says. Each revision means the software that touches the revised code needs to be inspected to make sure the rest of the system is not affected in an unexpected way.

The freeze allowed the project team to assess how far away they were from final development of the system. The team then identified the "gaps," wrote whatever software was needed to finish the system and tested the software to make sure all parts of the system worked.

"It's nothing very exciting," Meagher says. But it did get the project back on track.

eWeek eWeek

Have the latest technology news and resources emailed to you everyday.