F.I.R.E. by Lt. Col. Dan Ward, USAF
http://www.armedforcesjournal.com/book-excerpt-f-i-r-e/
By DAN WARD
Editor’s note: Lt. Col. Dan Ward is well known to AFJ readers for his clear-eyed pieces on military acquisition (“Acquisition reform … for real; What the Pentagon can learn from NASA’s ‘faster, better, cheaper’ approach” and “How to build good stuff: Five rules for a sensible approach to acquisition“). Here is an excerpt from the introduction to his new book, which comes out today.
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 twenty years to accomplish.
Now, the precise definition of “short timeline” will naturally vary from context to context. Some applications might deliver new capabilities every day and be considered hopelessly slow if they clock in on a monthly schedule, while for others, delivering in a year would represent a world-class commitment to speed. For military technology, a 2008 report from the Government Accountability Office says “system development should be limited to about five years,” and anything longer than that probably counts as “slow.” The point is, there is some amount of time that represents rapid delivery, so aim for that.
Being fast means we don’t try to solve problems by adding days to the schedule. As the book progresses, we’ll look at some strategies for speed to help us accelerate our development timelines and to solve problems using more thoughtful techniques than simply asking for more time. The key is to treat the schedule as a constraint to be lived with, not as a starting point to be extended later.
Although process improvement is not a central aspect of FIRE, it does have something to say about process. Specifically, FIRE proposes designing our organizations and processes with speed in mind and remaining on the lookout for opportunities to remove speed bumps from the process. This is where process improvement techniques can come in handy. The difference is that FIRE treats these techniques as tools rather than goals, as mechanisms to help achieve a larger objective rather than an objective to be pursued for its own sake—as so often happens in process-centric approaches.
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.
For example, most of the time we still need to design, document, and test the thing we are building. Rather than skipping those activities entirely or accomplishing them halfheartedly, FIRE offers ways to perform each essential step with speed in mind. So a performance test may only take a minute instead of a year, and it may be performed simultaneously with other activities, but failing to do any tests at all is not what we have in mind when we talk about being fast.
Remember the lesson from the famous race in Aesop’s fable: the tortoise was faster than the hare because he got to the finish line first. So by all means, be fast. But don’t be hasty.
There is also a big difference between being fast and being frantic. Fast is about speed with discipline, focused speed that efficiently moves us from where we are toward where we need to go. Frantic activity, in contrast, spins in circles and creates the appearance of rapidity without actually producing much in the way of forward momentum. Running around like a chicken with its hair on fire is the antithesis of productive action, no matter how exciting it might feel.
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 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. 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? Which one do you think makes a better impact? Who sleeps better at night—the guy in charge of building the second Death Star, which is so far behind schedule it requires a Sith Lord to straighten things out, or Q, the head of James Bond’s quartermaster division, who always has a freshly tweaked vehicle ready for Her Majesty’s secret agent to take on his next mission?
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. It’s a ceiling, not a floor.
But just as fast does not mean hasty, inexpensive is not the same as cheap. You see, 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. What we’re trying to do is maximize bang for the buck, get the most rumble for our rubles, the most sound for our pound.
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. To demonstrate this, that’s all I’m going to say about restraint.
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 and will be covered in future chapters, so for now let’s start by pointing out that it is important and good to have a low level of complexity. This sentiment may seem obvious, but given so many people’s love affair with complexity, I think it is worth saying out loud.
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. In other words, complexity is nothing to brag about.
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. We’ll look at several strategies for doing exactly that.
Copyright © 2014 by Dan Ward. Reprinted courtesy of Harper Business, an imprint of HarperCollins Publishers.
No comments:
Post a Comment