One Bite at a Time
system is a new release every six to 12 months.
Agencies often attempt to hammer out every detail of a major system in advance. The trouble with that approach? New technologies and unforeseen requirements regularly trip up even the best-laid plans. So program chiefs are turning to rapid, incremental releases to keep better pace with change.
The efforts reflect, in part, the Office of Management and Budget's ongoing push for agencies to apply modular approaches to systems work and agencies' expanding use of enterprise architectures.
Both the Defense Department and the Internal Revenue Service can offer prime examples of management models that offer three ways agencies can speed program deliverables and keep projects on track. One approach is to speed releases based on priority. The IRS has done this with its Business Systems Modernization and improved turnaround on tax refunds. Alternately, an agency or IT shop can ramp up capabilities in each ensuing increment. The CIO Office in the Pentagon pushes Defense organizations to break up big projects into more manageable pieces in this manner. Finally, there's the use of a mass modular approach to customization. Defense's Office of Force Transformation relies on components-based development within a services-oriented architecture, which meshes with OMB's urging that agencies strive to reuse components when feasible.
DOD and IRS also have something else in common: a need to process data for current demands while improving operations and replacing dated technology. In Defense's case, it must support warfighters in the field and program overseers at headquarters, and the IRS must pay out taxpayer refunds in a timely manner.
Route 1:
Ratchet Up Releases
At the IRS, Richard Spires fast-tracks incremental releases based on need and funding.
Spires, who has spent the last two years as IRS associate CIO heading up the business systems development organization, keeps an eye on more than 400 legacy and new programs tied to the long-running Business Systems Modernization effort.
"Many of these systems need a yearly update for tax code changes" as well as routine maintenance, Spires says. "There's a regular rhythm with [tax season] testing beginning in January, plus enhancements that the various business units request. We prioritize the work based on our funding and staff strength."
About 20 of the systems support tax administration and internal management. But Spires' organization concurrently is also working on three major new systems in the BSM portfolio: the Customer Account Data Engine, Modernized e-File, and Filing and Payment Compliance.
After a slow start in 2004, processing a small set of initial 1040 EZ forms, and then 2 million last year, this year CADE has processed returns from more than 7 million taxpayers. "There's a long way to go" to take over handling all 200 million taxpayers' records, Spires acknowledges, but the IRS is moving cautiously after a checkered history in system rollouts. CADE eventually will replace the 1960s-era Master Files, written and still maintained in assembly language without any relational database capabilities.
"The Master Files can't be current" because they must be updated weekly with earnings and other data, Spires says, "and assembly language doesn't have the advantages of newer languages."
Earlier systems failures have taught the tax agency to build in safety features. "There's a fallback capability in CADE to return to the Master Files if necessary," he says.
Essentially, the service moves to the next phase of CADE but maintains the last version so that if a failure or glitch occurs, there is no work stoppage. It can immediately revert to the previous iteration for processing and still use its old flat-file database to manage blocks of new records brought over from the Master Files for the corresponding release. So far, the IRS has never had to launch its fallback scenario, Spires adds. This process means the agency can avoid downtime if it finds a problem in one of its incremental releases and that it's always building on a solid foundation from release to release, he said.
Next year's goal is to turn about 33 million taxpayers' data over to CADE, which processes on a daily basis much like
a bank and lets the IRS issue refunds faster. CADE has helped the IRS cut the average turnaround time for refunds from seven to three and a half days.
"The ultimate goal is [to build] foundation technology to replace old technology," he says. "I'm a firm believer in incremental releases. If you deliver business functionality as soon as possible to your customers, you get good feedback that improves the next release."
He calls the feedback from IRS users "crisp — they're not shy. That means more overhead but is well worth it." Besides giving voluntary feedback, IRS users also take part in focus groups and visit a usability lab in Ogden, Utah, to refine incremental releases. CADE now gets new releases about twice a year; Spires considers the ideal schedule for a major system is a new release every six to 12 months.
Route 2:
Bit at a Time
"I've spent four years encouraging program managers to break up programs and deliver capability by increments while they're moving toward the complete capability," says John R. Landon, deputy to the assistant Defense secretary for command, control, communications, space and IT. "Complete capability isn't achieved in the first increment, but you learn a tremendous amount."
That learning comes mostly from user feedback, "so you put the first increment in users' hands as early as possible," says Landon, who retired from the Air Force in 1996 as a pilot and unit commander. "The real users go through operational testing and come back to the program manager with what they like and didn't like. That experience helps define the later increments."
There are 11 major new DOD systems in the works, plus about 59 big updates that Landon says he knows of, "and that's just the tip of the iceberg. Every time you develop a new product, your ideas change. You build based on your best knowledge of what users want — and you usually can't get it right. But when you put it in their hands, they evolve it."
The department counts on feedback groups similar to the private sector's focus groups to give a program manager insight into the particular performance users want. "It's defined in writing and formalized in a contract between users and developers," Landon says. "Once the acquisition folks decide how to obtain the capability, there's another contract for time and cost."
Route 3:
Mass Appeal
A third approach to more efficient development is modular mass customization like that pioneered by the auto industry, says Terry J. Pudas, acting director of the DOD's Office of Force Transformation.
"You have to leverage the cycle times and the requirements" so that new technologies don't overwhelm the architecture, he says. "That way you can field a capability in a much shorter time and let the [military] forces turn it into action to co-evolve the concepts with the technologies."
DOD in the past "has very tightly integrated its major systems and built a lot of life into them," he says. "But if you instead develop an architecture that preserves your options, you can plug in a module and replace it later when something better comes along."
Through the use of service-oriented architectures, Defense can deploy services more quickly while also meeting OMB demands for reusable systems and programs that fit within the broader context of the governmentwide Federal Enterprise Architecture.
But, Pudas cautions, architectural choices can themselves impede turning out useful software faster. Open standards, interfaces and protocols get a great deal of lip service, but proprietary integration has been the IT industry's business model for a long time, he says. (See box above, "How to Make Smart Use of SOAs.")
That model needs to change to mass customization, Pudas believes. He cites OFT's 40- by 88-foot Stiletto carbon-fiber experimental watercraft, which can leverage its resources — networked sensors, space assets and unmanned aerial vehicles — to reconfigure for different kinds of combat.
"The ship is not intended to be a program of record," he says. "It's meant to spark new knowledge on a rapid cycle time."
Overlooked Factor
Even in small bits, agencies need to focus in on management of these IT projects, says McCoy Williams, the Government Accountability Office's director of financial management and assurance. GAO keeps seeing the same kinds of failure, he says.
"Whether they develop incrementally or however they do it, there are two key processes," Williams says. "They need the discipline to manage the requirements, and they need to test. Our March report on causes of system failure tells what happens if they don't do those things: More and more resources are spent on rework as time goes on." GAO auditors refer to this phenomenon as "thrashing."
"It's a common theme at many agencies," he says. The issue comes down to good management, Williams says. "You have to have the right mix of people to give oversight over requirements. You either pay now or pay later, because there are always trade-offs in cost, schedule and functionality."
The savings when agencies avoid thrashing can add up. "Spend a dollar up front to define the requirements," he urges, "because it will cost you $50 to $200 to fix after the system gets into production."
