The Fire Method
How Fast, Inexpensive, Restrained and Elegant Methods Ignite Innovation
In December 2010, at a tiny research facility in freezing-cold Rome, New York, U.S. Air Force scientists cut the ribbon on a supercomputer named the Condor Cluster. Operating at 500 TFLOPS—trillion floating-point operations per second—it was the fastest supercomputer in the entire Department of Defense and the thirty-third fastest in the world. Contributing to its awesomeness was the price tag—the Air Force only paid 10 percent of what it would cost for a comparable supercomputer. On top of that, the Condor Cluster uses a mere 10 percent of the electricity typically required by similar machines, which means it’s got a smaller carbon footprint and is less expensive to operate. Not a bad day’s work.
One other interesting fact about the Condor Cluster: It was built out of 1,760 Sony PlayStations. True story.
In other parts of the Department of Defense, results were decidedly less awesome. Just three months earlier, in September 2010, the U.S. Supreme Court agreed to hear arguments related to the U.S. Navy’s A-12 Avenger airplane, known to some as the Flying Dorito because of its triangular shape. Begun in 1983 and envisioned as an all-weather, carrier-based stealth bomber/attack jet, the Avenger program was terminated in 1991, at which point the Navy had spent $2 billion but received nothing for its money beyond a really exciting case study in failure for students at the Defense Acquisition University.
After almost 20 years of litigation, the nation’s highest court was finally going to consider whether the government’s decision to cancel this bloated project was justified. Resolution was apparently not to be, and in May 2011 the court returned the case to the lower appeals court instead of deciding, so the saga continued.
We could spend all day looking at similar examples from all the military services, highlighting the ups and downs of defense technology. The Army, Navy, Marine Corps and Air Force all have their own stories of critical new gear being delivered in a matter of weeks, right alongside stories where billions and decades are spent to deliver exactly nothing. Of course, these highs and lows are not limited to the military. NASA has some of the best failure and success stories around. For that matter, the federal government does not have a monopoly here.
Why do some programs deliver their product under budget, while others see their costs expand by orders of magnitude? Why do some deliver ahead of schedule, while others experience endless delay after endless delay? And, most critically, which products work better—the quick and thrifty, or the slow and expensive? Which situation leads to superior equipment?
After a few years of conducting informal research into these questions, I spent 18 months at the Air Force Institute of Technology looking at them more rigorously. The pattern that emerged is this: The most successful project leaders from government and industry alike tend to deliver top-shelf stuff with a skeleton crew, a shoestring budget and a cannonball schedule. In interviews I read and those I personally conducted, project leaders continually echoed one theme: “We had no time and no money. We were just lucky to have a small team of really creative, dedicated people and we got it done.”
In contrast, project leaders who are cursed with large budgets, large teams and long schedules generally have a difficult time delivering even a fraction of the promised capability, an outcome often blamed on an excessively cumbersome process. Interestingly, when faced with cancellation due to severe cost overruns and delays, these leaders typically respond, “If I had a little more time and money, I could fix this.”
Yes, those who had the largest budgets were most likely to ask for more money and least likely to deliver an actual working product. Those with the smallest budgets were most likely to have cash left over after delivering 10 pounds of awesome on a five-pound purse. The faster, cheaper stuff also tends to perform better in actual use than the slower, more expensive stuff. The idea that spending less time and money leads to better outcomes sounds a bit like claiming that moderate amounts of red wine and dark chocolate are good for you. Surely this is too good to be true. And yet, as with the aforementioned health benefits, the data are compelling.
We haven’t said much about complexity yet, so let’s remedy that right now. Successful project leaders tend to place a premium on simplicity in their organizations, processes, documentation and technologies. They tend to view simplicity as a desirable attribute and pursue opportunities to simplify when they are able.
FIRE codifies the practices, principles and tools used by some of the best technology developers in the world—people who sent spacecraft on intercept courses with asteroids or who built fighter planes that dominated the skies of World War II. FIRE also describes the way clever toy designers teach science lessons that are actually fun.
One final note: While improving one’s process might be a fun way to spend a sunny July afternoon, FIRE is emphatically not a process-improvement initiative. Given the modern popularity of process-improvement methodologies, that last sentiment bears repeating: FIRE is not about process improvement.
The primary objective is to improve our objectives and outcomes rather than our processes. There is a tremendous difference between them. Clever project leaders should certainly make an effort to streamline, simplify and accelerate their processes, but the bulk of their attention is rightfully spent on the product itself and on taking care of the people who make it.
The reason for this is simple. Process-centric improvement efforts have a maddening tendency to be process-centric, despite official protests to the contrary. This myopic orientation frequently overshadows both the team members and the product itself and instead focuses on delivering a set of lovely, full-color, hypothetical process flow diagrams that signify nothing.
In contrast, FIRE is all about helping people make good decisions as we design and create new things. These little guidelines don’t dictate behavior, nor do they represent a step-by-step formula. Good luck trying to build a process flow diagram out of them. Instead, this heuristic approach echoes Visa CEO Dee Hock’s explanation of how he succeeded in founding the Visa credit card association: “We have no precise plan, only a clear sense of direction.”
The four components of FIRE combine to create a heuristic-based approach. Here’s the meaning for each component:
F Is for Fast
This is about defining a project objective that can be satisfied on a short timeline, not one we know full well will require 20 years to accomplish. But here’s the twist: We must not be content with the superficial appearance of speed, where we appear to be moving quickly but are in fact spinning our wheels or running in the wrong direction. Nor should we pursue speed at the expense of doing good work. This means no cutting corners, no skipping essential steps in the development process. The project is only fast if we do quality work on a short timeline.
I Is for Inexpensive
It’s important to have a small budget. That may be an unpopular position in an environment in which budgets equal prestige, but in my experience I’ve found that the ability to deliver meaningful capabilities on a shoestring is actually a widely respected skill, even in the cash-rich defense business. Being inexpensive is about designing our organizations and processes with thrift in mind and solving problems with intellectual capital instead of financial capital.
R Is for Restrained
This is the common thread that runs through the whole FIRE concept. It is a preference for self-control, tight budgets and small teams, short schedules, short meetings and short documents.
E Is for Elegant
The E in FIRE stands for elegant in the sense of “pleasingly ingenious and simple.” It’s important to have a low level of complexity. Embracing elegant simplicity means designing our organizations and processes with simplicity in mind. It’s about stating goals clearly and incorporating mature, proven technologies into our designs. True sophistication, true design maturity and true process maturity are shown through deep simplicity, not through brain-meltingly complex diagrams and structures.
Book excerpt from F.I.R.E., How Fast, Inexpensive, Restrained, and Elegant Methods Ignite Innovation by Dan Ward. Copyright © 2014 by Dan Ward. All rights reserved. Published by HarperCollins Publishers.
Looking for the latest in product management news, articles, webinars, podcasts and more?