Modular procurement and the dark side of the force

In a 2011 essay on military acquisition, U.S. Air Force Lt. Col. Dan Ward turned to "Star Wars" to make his case. The Death Star was the "undefeatable ultimate weapon" that was "brain-meltingly complex and ravenously consumed resources," he noted. The first Death Star fired its main weapon only once before being destroyed. The second was much bigger than the first; it also had great difficulty firing.

Time and again throughout the "Star Wars" series, Ward concluded, "war-winning weapons tend to be simple, inexpensive and small."

The problem with the Death Star project was that it was too complex for any program manager to properly design or oversee. In "Return of the Jedi," Darth Vader even complains that construction is behind schedule.

Government faces similar problems today and not just with weapons systems. Too often, agencies attempt to build the IT equivalents of Death Stars.

HealthCare.gov's catastrophic launch happened despite the tens of millions of dollars the government spent on development. Yet three 20-somethings took three days to build HealthSherpa.com -- a site that quickly and simply matches people with health care plans. It didn't meet every goal of HealthCare.gov, to be sure. But it provided the bulk of what customers needed, and while the government's massive undertaking collapsed, HealthSherpa kept serving citizens.

Shortly after U.S. Citizenship and Immigration Services CIO Mark Schwartz joined government in 2010 straight from the fast-paced world of startups, he requested a few small changes to a USCIS web page. He was told they would take a year to complete. The changes had to follow a Department of Homeland Security rulebook called Management Directive 102 -- a couple of hundred pages on how the agency should procure, develop and test software.

"If you wanted to instruct a large group of people that they must use the waterfall approach," Schwartz said, "you couldn't possibly write it better."

MD 102 is designed to efficiently create Death Stars. It incorporates extensive competing interests and expects to wrangle big, overbudget, complex projects.

"What tends to happen in our environment...is that we build big programs," Schwartz said. "You can't tackle one mission need unless you have a lot of mission needs that you can put together into a program [that's easy to send] through the oversight and appropriations process."

The problem is that trying to build the electronic equivalent of the Death Star contradicts a key rule of IT: The bigger and more complicated your project, the more likely it is to fail. And the cycles become much too long because each individual feature is now part of a complex, multi-million dollar effort.

Waterfall's thorough, slow approach is useful, but it reflects an outdated attitude about failure. A space shuttle can only fail once. Yet for digital projects, with information stored at little cost on the public cloud, failure is relatively cheap.

So Schwartz has taken a fast, modular approach to procurement and development, and effectively ripped up MD 102. Instead of trying to build large, complex programs all at once, his team takes on small groups of requirements at a time and pushes them all the way through to production.

In agile, that is known as a continuous delivery pipeline. "This lets us minimize risk in a big way," Schwartz said, "because all you're really committing to...is a small batch of requirements and time. When you can do that, oversight needs are much less, procurement needs are much less, and everything else follows from there."

So for the past five years, Schwartz had spent most of his time aligning contracting, quality assurance and security to an agile approach. Once such systems are in place, a modular approach will be even cheaper.

"If we could do this across the government, it would be revolutionary," he said.

Fast, simple weapons often are.