Why do some projects deliver under budget and ahead of schedule, while others cost more and take longer than expected? More important, which products work better: the quick and thrifty or the slow and expensive? In a story-filled blend of quirky pop culture and practical engineering insight, Dan Ward’s F.I.R.E. answers those questions and more.
Ward’s extensive research and firsthand experience show how the world’s top technologists consistently deliver best-in-class results on shoestring budgets and cannonball schedules, and using skeleton crews. But this is not just a book about how to win. With unflinching candor, Ward shows how the FIRE method, even when followed wisely and well, can result in a flop.
Taking a deep look at several negative outcomes, he shows how to make failures optimal rather than epic. F.I.R.E. provides strategic concepts for leaders, decision-making principles for managers and practical tools for people working on anything from spacecraft and fighter jets to websites and children’s toys. Technology professionals and curious amateurs alike will come away with a deeper understanding of effective product design.
The FIRE Method
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 research into these questions, 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. 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 in 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.
Be forewarned: just because FIRE is possible does not mean it is necessarily easy to implement. 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. The project leaders who embrace speed, thrift, simplicity and restraint tend to deliver affordable equipment that is available when it’s needed and effective when it’s used.
FIRE is emphatically not a process-improvement initiative. The primary objective is to improve our objectives and outcomes rather than our processes. FIRE is all about helping people make good decisions as we design and create new things. Accordingly, there is a set of practical heuristics –– rules of thumb designed to help actual people make good decisions. These little guidelines don’t dictate behavior; nor do they represent a step-by-step formula. Instead, the 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.”
Before getting into the guidelines themselves, we need to take a closer look at the four components of FIRE, to see how they combine to foster that “clear sense of direction.”
F Is for Fast. The F in FIRE stands for fast, which says it’s important and good to have a short schedule. It’s 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. The precise definition of “short timeline” will naturally vary from context to context. As a general rule, speed is good. Slow kills. Speed fosters stability within a program and reduces our exposure to the forces of change.
Speed enhances accountability and learning for the team members. Speed increases the likelihood that the product will be well aligned with both the market’s interest and the available technologies. But here is 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. The I in FIRE –– for inexpensive –– says it’s important to have a small budget. That may be an unpopular position in an environment in which budgets equal prestige, but the ability to deliver meaningful capabilities on a shoestring is actually a widely respected skill, even in the cash rich defense business. Ask yourself, would you rather be known as the person who manages a $50 billion project that is late or over budget or the guy who makes great things happen without busting the bank? But just as fast does not mean hasty; inexpensive is not the same as cheap. A low-cost solution that doesn’t work is actually a pretty expensive solution.
Inexpensive does not mean simply picking the low bidder or settling for an inadequate component. Being inexpensive is about designing our organizations and processes with thrift in mind and solving problems with intellectual capital instead of financial capital. It’s about setting program goals that can be satisfied on lean budgets and finding thrifty ways to perform even the expensive-sounding functions. The key is to treat the budget as a constraint, not a starting point to be expanded later. We’re trying to get the most bang for our buck.
R Is for Restrained. The third piece of FIRE stands for restrained. This is the common thread that runs through the whole FIRE concept. It is a preference for self-control, for tight budgets and small teams, for short schedules, short meetings and short documents. Yes, there’s a point at which an organization isn’t large enough to do the work and a point at which a document or briefing doesn’t convey all the necessary information. As a general rule, we could get a lot closer to that boundary than we typically do.
E Is for Elegant. The E in FIRE stands for elegant in the sense of “pleasingly ingenious and simple.” Simplicity is an ironically complex topic. Embracing elegant simplicity means designing our organizations and processes with simplicity in mind. It’s about stating our 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. A certain degree of complexity is inevitable in any situation. While we may not be able to avoid complexity entirely, we can certainly take steps to minimize it. But merely simplifying our design without making it better is a superficial application of simplicity. For simplicity to be elegant and virtuous, it needs to improve the project’s quality, performance or usability.
