During the war in Iraq, a group of U.S. Army soldiers was tasked with carrying a document from one base to another to obtain a signature.
The convoy was attacked and one soldier lost his life. Disturbed by the need to put service members in harm’s way for a physical signature in the digital age, a colonel put in a request that the system be reconsidered.
Two days and less than $10,000 later, a digital signature system had been put in place. What allowed the system to be implemented so quickly is also what makes the acquisition approach behind it so different: The system was installed while its designer knew it was incomplete.
The company behind the system, Enterprise Information Management (EIM), has been carrying out a strategy that calls for the early deployment of so-called beta versions that produce improvements — but not full solutions — months if not years before systems would be delivered using traditional acquisition methods.
The early deployment is followed by the use of feedback to develop a final product that meets the war fighter’s precise needs without excess capability.
“The idea is to get it operational as fast as possible,” said EIM CEO Bruce Lyma. “You don’t need to wait for it to be perfect for you to deploy it, so long as you create an enterprise that can deploy things without this monolithic process.”
The concept of beta deployment of a product for the U.S. Defense Department, developed by EIM in 2002 on the back of a restaurant napkin, borrows a technique employed by many commercial technology companies today, in which beta versions are released to the public with the subsequent feedback integrated into the final product.
“You get an application, and it’s not perfect, and then you’re going to expect that it will be made better,” Lyman said.
The model, however, must mesh with a defense acquisition system that is not designed to handle product uncertainty. The end product cannot be determined up front because it is heavily shaped by the interaction with users, meaning that acquisition officers are agreeing to purchase a system’s potential, rather than a defined product.
“That may make an acquisition officer queasy,” said Jim Hasik of Hasik Analytics.
Lyman said that in these types of situations, communication is key.
“I’m going to make sure that you tell me everything that you want, and you’re going to describe what you want, and I’m going to go build it,” Lyman said. “But you don’t even know exactly what you want. So we have to create an environment where I can work with you to describe what you want, and as you see it, you’re going to see it very quickly and frequently.”
That feedback is critical if incremental development is going to work, said Peter Singer, a fellow at the Brookings Institution, a Washington think tank.
“It’s not like our current system delivers perfect products as is, so it’s a useful approach for some areas,” he wrote in an email. “The key is having it linked to a feedback loop, for the end users to be getting useful recommendations back, which are then worked back in for the next iteration.
“While there are obvious comparisons over to the civilian sector and how many IT [information technology] companies operate, it also echoes the early days of jet plane development, where the [U.S.] Air Force and the Navy would buy small numbers of various early fighter jets from a wide variety of firms, try them out, figure out what worked and what didn’t and, most importantly, what exactly the forces did and didn’t want and how they would use it.“
Instead, Singer wrote, “Today we try to act like we know what will be needed 20 years from now and then lock it in to firms with monopolies on the market, with poor incentives to produce it on time and at cost, let alone improve it.”
But beyond the ability to roll out a product quickly and cheaply, four to five times faster and six to eight times cheaper than traditional acquisition approaches, according to EIM, the beta model also presents savings by avoiding unnecessary add-ons and capabilities that are common in IT systems, Lyman said.
“In many cases, technology people, and I’m one, we tend to want to make it perfect,” he said. “It doesn’t need to be that hard, and we tend to walk down a path that makes it hard, and you don’t have to.”
When EIM was brought in to automate the officer and noncommissioned officer evaluation system for the Army, the company recognized that one of the customer requests — fully automating the sending of the completed forms — would take years because of the need to build a hierarchical structure into the system.
Instead, the company allowed users to send the forms themselves, as soldiers know who their commanding officers are. After the system was rolled out, the requirement for automated sending never resurfaced.
EIM was given a chance to use its model because of outreach by the Army’s Business Initiatives Council, Lyman said. But he believes that the model, applied more broadly, could save billions and help deliver IT products at a pace commensurate with the rapid changes in technology.
“People say that’s not possible because the acquisition cycle is not possible. It is possible, and in my mind, we have no choice but to do it,” he said. “If we don’t do it, we’re going to spend $800 million for a system and then have it not work.”
Hasik said that while smaller systems have not typically been accepted as a beta model, larger programs sometimes are accepted.
“The F-35 [Joint Strike Fighter] software is in beta, and we’ve been working on that for 15 years,” he said. “In a sense, they do this all the time, but there’s something about doing it on a small scale that seems scarier.”
Lyman said that while his approach might require some new thinking about IT and acquisition, it is doable.
“IT is hard. I’m not saying that this approach is magic, I’m saying it’s a solution to the problem.”
