How to Save the U.S. Air Force $8 Million
Little radar pod was a defense program done right
by DAN WARD
I’d triple-checked the numbers already, but I asked my deputy one last time to be sure.
“Eight million dollars. I am reading this correctly, and these figures are up to date, right?”
“Yes sir. We are eight million dollars under budget.”
“Excellent. Let’s go tell the colonel the good news.”
I’d taken over as program manager for the Dismount Detection Radar system—a.k.a., DDR—nine months earlier, when the previous manager was reassigned to Germany. Under his watch, the program underwent a major down-scaling activity, which reduced the budget and requirements, and shortened the schedule.
In fact, the purse string holders in the Pentagon established a hard stop date for when the contract would end. I was brought in to shepherd what remained of DDR across the finish line.
Believe it or not, I saw this as a fantastic opportunity, exciting enough to make me postpone my planned retirement date by six months. With its tightly constrained budget, shrinking team, and near-term, set-in-stone termination date, DDR was my favorite kind of project to lead.
The program was also exactly the sort of thing I advocated and wrote about in my articles and books, so how could I say no? DDR is an airborne test-bed for third-party software incorporated into conventional radars. If it worked, we could develop future radars that would cost far less money.
Plus, after nearly 20 years in a blue uniform, this would be my first airplane-related gig, which was a nice change of pace from my usual space and cyberspace projects. The fact that our goal was just this side of crazy added a lot to the appeal as well.
The first test flight of this little radar pod was just five months away when I took over. Both the hardware and the software were still incomplete—very incomplete.
The remarkably tight schedule made some of the team nervous, particularly when outside advisers argued that seven years would be a more reasonable time frame. To me, five months sounded just about perfect, or perhaps even a tad generous.
We ended up hitting our first flight a month early. By the time it was all over, we’d accomplished twice as many test flights as originally planned, collected more than twice as much data as promised, and operated perfectly in challenging environments that we were able to add at the last minute.
Plus we had $8 million ready to give back. I was thrilled.
How did this happen? What made the DDR crew so great? A big difference between this team and others was our approach to speed, thrift, and simplicity … particularly simplicity.
From the day I arrived it was abundantly clear that adding time and money to the project was not an option. There was no more time or money to be had.
Rather than fighting against this reality and seeking clever ways to expand and delay, my team and I embraced our constraints with enthusiasm. We decided to make simplicity a point of pride, in our operations and our technology.
This did not come automatically and it wasn’t easy. Rather, it was a deliberate choice and required constant focus and effort, but together, we did it.
The focus took shape in one of our initial meetings when an engineer asked the question “What if we do a little more?” We turned that question around and asked “What if we do a little less?”
This phrase became our mantra and it shaped virtually every discussion from that point on. We applied the question to our processes and organization as much as our software and hardware.
What if we have fewer meetings? What if they were shorter? Less formal? What if the first software delivery and the first flight only do one thing instead of 10 things? What if we never get around to that tenth thing? What if we shift some flight tests to the ground-based test bed? How will these reductions affect our project’s objectives? How will they affect our customers?
The answer to these questions was not always “Yes, do less.” Sometimes the impact of doing less was unacceptable. But regardless of the specific answer, it was always a worthwhile question to ask, and the effect was tremendous.
One of the first things we did was consolidate and trim our meetings by half, which made our discussions more focused and productive. Simplifying our meeting schedule not only freed up time for more productive activities, it also fostered a greater degree of trust which helped us simplify things further.
This virtuous circle of trust and simplicity established a strong foundation for genuine teamwork. The relationships we built because of this shift towards simplicity got us through some truly hairy challenges.
On the technical side of things, we scaled back the focus of our first flights and simplified the mission, which allowed us fly sooner and learn faster. The lessons from those early flights paid huge dividends as the weeks progressed.
Doing less on the first flight meant we were able to do much, much more on the later flights. We had actual flight data to incorporate into our planning.
The simpler approach was less fragile and more flexible, which allowed us to try new ideas without fear of the whole thing falling apart. The result was a remarkable success for the DDR team, which won a big stack of awards and accolades throughout that busy, exciting summer.
And then, as quickly as it began, it was over. It would have been great to unleash the DDR team on some new project, but that wasn’t in the cards.
DDR’s tiny-but-successful team was mostly disbanded even before the dust settled, all for good reasons. One captain left the Air Force so he could go to medical school. Another was selected for a highly competitive opportunity to attend Intelligence Officer training.
A third volunteered to deploy to Afghanistan, then came home in time to pack up his family and move to his next assignment a few months later. Our chief engineer moved up to a Branch Chief position.
The various civilians found roles in other projects, as did our counterparts on the contractor side. A skeleton crew hung on long enough to find good homes for the reports, the data, the hardware and the software. And I finally was able to submit my retirement papers and join the civilian world.
I learned a lot from this project. But one of the most important observations was that small, inexpensive, simple projects can have a huge impact and deliver tremendous value.
That wasn’t exactly a new discovery. Before taking over DDR, I wrote a whole book about the relationship between constraints and innovation.
Still, it was nice to have yet another first-person instance of these principles in action. And in a world where the complexity of the defense acquisition business and the technology it produces is responsible for all sorts of cost overruns, schedule delays and technical difficulties, it was fantastic to be able to show once again that simple practices can deliver world-class solutions … and still have millions left over.
Dan Ward is the author of The Simplicity Cycle and F.I.R.E.: How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation. He holds three engineering degrees and served in the U.S. Air Force for more than two decades researching, developing, testing and fielding military equipment.
