Army IVAS HoloLens program shows DoD how to do iterative requirements

Soldier input directly shaped many of the headset’s key features. Early prototypes included a HoloLens headset that engineers had affixed cameras to, goggles with weights attached, and various 3D-printed devices. The devices met the Army’s requirements of rugged, waterproof and shockproof. But no one had considered, for example, that the headsets needed to allow users to brace a rifle against a cheek.

“If a soldier wanted to put his or her cheek on the butt of their weapon, if there were sensors on the bottom of the headset, they wouldn’t be able to do that,” Krugh says.

Feedback from soldiers also identified that the rim of the goggles needed to be redesigned for better peripheral vision. Dozens of prototypes were created, tested and refined…

Microsoft initially designed a dial for the compute pack – known as the “puck” – that soldiers wear on their chests to control the headsets, with the thought that it would be easy to manipulate. But when soldiers put the pack on and crawled on the ground, the carefully designed dials promptly broke off.

“We designed this beautiful dial that you can use with one finger and I’m super proud of it,” Kipman says, “and if we shipped the product with it, we would have passed the spec, and they would have broken and not worked for many soldiers.

“There are literally thousands of examples like that throughout this program, and it’s why we do what we do,” he says.

That was from a Microsoft article, “U.S. Army to use HoloLens technology in high-tech headsets for soldiers.”

The Army’s IVAS program that Microsoft won used Middle Tier acquisition authorities and Other Transaction contracting authorities to speed up development. It started without an approved acquisition strategy, without an independent cost estimate, and without a schedule risk assessment. These processes could have added up to two years themselves.

Perhaps because of Middle Tier and OT authorities, and perhaps because the technology maturity was already high, the program raced into a fielding decision. Unlike other defense programs claiming agile software delivery, IVAS delivered code every month.

But the main point is the iterative process of requirements. The irregularity of IVAS provided an opportunity to show how the traditional predict-and-lockdown requirements process is fundamentally flawed.

“No one had considered” the headsets would need to accommodate a rifle braced on a soldier’s cheek. A bureaucratic reaction would be: “Hey! That’s obvious, even I would have known that should be a requirement! You need to spend more time defining what you need to create a water-tight contract!“

That would be the wrong lesson, though one that seems to have prevailed in times past. Consider, if the IVAS program instead did one large development cycle and then one big test at the very end, then OT&E would have caught all these problems and hit the program over the head.

The fact that they used agile development meant they didn’t need to know all the product features in advance. Instead, they released to a basic level of specifications like water- and shock-proof, and then got quick user feedback to smooth out other issues before it got to OT&E.

Testing feedback should be continuous, not a discreet event with production money already planned. That creates all sorts of bad incentives to push through test, make quick fixes that cost you later, and then go into an LRIP contract that never gets to full-rate due to the persistent issues.

Lessons for Requirements

I don’t think a “capabilities” based requirements approach would have solved this problem. For example, rather than specifying that the product must allow the soldier to shoot an M-4 rifle braced on his or her cheek, must allow a soldier of 250 pounds to army crawl through rocky terrain, etc., the Army could have said: product must not impede a soldier’s regular combat movement.

OK great! But maybe developers think about shooting rifles, but forget about the army crawl. So high level outcomes or capabilities based requirements doesn’t fully solve the problem. It provides tradespace to developers, but the developers still need quick feedback from testing and users.