It's about time.

"An unreasonably long acquisition cycle ... is a central problem from
which most other acquisition problems stem."
Packard Commission Report, 1986

As James Gleick observed in his book Faster, the pace of just about everything is accelerating and has been for some time. But while the pace of activity throughout the world is increasing, the DoD technology development community is often locked in processes and systems that operate on a Cold War-based timeline. And according to the 1986 Packard Commission report, that timeline was too slow even for Cold War forces.

A Brief History of Speed

Please pardon us as we bust it out "old skool" style for a moment. You see, the idea that we need to decrease the technology development timeline predates the Revolutionary War, so we understand if some readers are a little tired of hearing this refrain. Sadly, despite the vast consensus on the need for speed, progress in this area has been pokey, to put it politely.

But for any newcomers out there, here are a few comments on the topic of DoD development cycle times from the past 20 years (emphases added).

1986: "Many have come to accept the ten-to-fifteen year acquisition cycle as normal ... We believe that it is possible to cut this cycle time in half."--Packard Commission Report

1986: "The most important way technology could enhance our military capability would be to cut the acquisition cycle time in half."--Chairman of the Joint Chiefs of Staff

1994: "Deliver emerging technology to troops in 50% less time."--Federal Acquisition Streamlining Act (FASA)

1996: "25% cycle time reduction target for MDAPs [major defense acquisition programs] by 2000."--DoD's National Performance Goal

1997: "We need a fast-paced acquisition system."--William Cohen, secretary of defense

1999: "Reducing the time to develop ... systems is essential."--Gen. Lester Lyles, vice chairman of the Air Force

2002: "We still have an acquisition system that takes years, and years, and years, notwithstanding the fact that technology is changing in 18, 20, 24 months. We have a budgeting process that takes forever. We have any number of things that are too slow, too sluggish, not agile enough, not fast enough."--Secretary of Defense Donald Rumsfeld

We could go on (and on and on), but we're sure you get the picture. So given the amount of high-level focus on decreasing timelines for the past two decades, one might wonder how much progress we've actually made. Figure 1 on page 16--a 30-year snapshot of average development cycle times--answers that question.

We are having a hard time finding a 50 percent decrease ... or a 25 percent decrease ... or a noticeable reduction in time for any of the Services. We'd even settle for signs of the "fast-paced acquisition system" that Cohen asked for, but we just don't see it. All three Services seem to be rising to a common level of slowness, while the U.S. automobile industry cuts its time by almost 75 percent. Of course, it's not exactly an apples-to-apples comparison, but the point isn't to beat or even match Detroit. The point is to demonstrate some sort of decrease.

As you'll notice, the graph ends in 1998, which was eight years ago. Maybe things have greatly improved and nobody knows it, in which case we didn't need to write this article. Sadly, our research indicates that not to be the case--the timeline trend has not improved. More significantly, nobody seems to be tracking, analyzing, and publishing these metrics any more. That just might be the most disturbing thing.

Maybe There Was A Typo?

So we started thinking. Could it be someone accidentally added an extra "s" somewhere along the line and everyone started trying to reduce our timeliness instead of timelines? We're pretty sure that's not what happened, but the data do seem to support that hypothesis.

[ILLUSTRATION OMITTED]

All joking aside, this is a really interesting--and by "interesting," we mean "disturbing--set of trends. Dr. Marvin Sambur, former assistant secretary of the Air Force for acquisition, used Figure 1 in a briefing, with this commentary: "As depicted by the solid black line, the auto industry was faced with a crisis in the early seventies.... Japanese competition and consumer demand for new products drove down the [American] product cycle time."

So, if competition decreased the auto industry's cycle time, then perhaps the DoD doesn't have enough competition. Or more pointedly, perhaps we don't have sufficient competition in the right dimension.

When we develop an airplane, for example, we judge its airspeed but not its development speed. In a competitive acquisition, the DoD tends to put all competitors on the same timeline and does not usually give points for early delivery. Over 90 percent of DoD contracts contain no schedule incentives, according to the Schedule Incentives Reinvention Team report. That means if a proposal hits the milestone--super. If they plan to deliver early--no big deal.

So we suspect development cycle times have not gone down in large part because there is no competitive pressure to drive them down. Surely there are exceptions to this, but the Schedule Incentives Reinvention Team briefing indicates that "80% of projects specify an expected schedule to the contractors--and contractors who bid different schedules are seen as non-responsive."

Now there's a brilliant idea: discount any contractor who claims the government's expected timeline could be shortened. Is it possible these so-called "non-responsive" contractors are actually willing and able to deliver technology faster than the government expects? We'll never know unless we let them try.

By the way, the May 2003 update to the DoDD 5000.1 guidance states that "advanced technology shall be integrated into producible systems and deployed in the shortest time practicable." This is a step in the right direction, and we contend that dictating a schedule (as the DoD apparently does 80 percent of the time) violates this directive. That's a practice that simply has to stop.

Can It Be Done?

Okay, we hope everyone is convinced by now that development cycle times are w-a-y too long. It's painfully clear we need to move faster. The question is, are we asking too much? Can the work really be done any faster than it already is? Maybe this stuff has to take as long as it does.

Well, a few years back, there was a Lean Aerospace Initiative research project, sponsored by some school called MIT (never heard of it). Air Force Lt. Col. Ross McNutt, Ph.D., examined 320 defense projects (the results are to be found in his Massachusetts Institute of Technology doctoral dissertation "Reducing DoD Product Development Time: The Role of the Schedule Development Process"). The various project managers and program element monitors interviewed estimated the average project could be completed in 50 to 65 percent of the scheduled time--factors that were consistent across all size programs, all levels of technological advance, and all different types of systems.

Still not convinced? Recall Parkinson's Law, which states that work expands to fill the time allotted. It's the old "if you've got all day to do a project, it'll probably take all day" idea. The thing is, Parkinson's Law cuts both ways. It means work is also compressible, at least to a point. If you've only got an hour to finish that same project, you can probably pull it off, can't you? Or is that just us?

[FIGURE 1 OMITTED]

But why limit the discussion to defense programs and automobiles? Let's see what a few segments of the private sector are up to lately. Figure 2 shows what some industries have accomplished.

We didn't collect these particular data; they came from that MIT project we mentioned. And we feel compelled to point out that we can't quantify how long it took to get from "Old" to "Current." Of course, given the 30-year DoD trend we saw previously, it really doesn't matter how long it took the commercial world to do this. This trend is clearly not even starting in the DoD acquisition environment.

So let's check out a few specific data points that went into that chart. The Boeing Company stated they cannot afford a new aircraft unless they can develop it in two-and-a-half years. Modifications of their commercial aircraft have to take less than 18 months. Hughes Aircraft Company recently designed and launched an entirely new spacecraft bus and payload in less then 26 months. Really? Yes, really. Moving on ...

Secret Speed Sauce

What's the secret? How did the aircraft, automobile, spacecraft, and electronics industries do it? What do they know that we don't know? This may sound obvious and redundant, but apparently "companies that have focused on reducing their development times have dramatically reduced their development times." Does that surprise anyone? The MIT crew thought it was worth pointing out.

It gets better. Along with reducing development/acquisition time, these companies have also increased product quality, decreased development cost, and increased the number of products produced. Which brings us back to the Packard Commission's observation that an unreasonably long timeline is the central problem from which other problems stem. Maybe that Packard group was really on to something. It's too bad we didn't listen.

The Irrelevance Of Ease

Some of us might be tempted to believe that if it was easy for the DoD to cut cycle times, we would have done it already. That would be incorrect. If it was valued we would have done it already. If people thought it was important, and if we really wanted to cut cycle time, we would have done it already. The truth is, we're not even tracking cycle-time metrics.

We are not suggesting it would be easy to cut cycle times in half. We simply contend that ease or difficulty is entirely irrelevant. The DoD does difficult things all the time (and cutting development time is apparently not all that tough).

In reality, the DoD has not cut development time because we don't really want to, despite the earlier statements from various officials. How do we justify that assertion? Quite easily--just look at the data again. All the data. Specifically, take the part about "companies that focused on reducing timelines reduced their timelines" and put it next to that other bit about how "contractors who bid different schedules are deemed non-responsive," and "90% of contracts offer no schedule incentives." Then add in the fact that we stopped collecting cycle-time data in 1998. Looks like a lack of desire, focus, will, and values to us.

Fast & Slow

"Hurry! Hurry! Go, go, go!"

"Where to, sir?"

"It doesn't matter--they need me everywhere!"

Okay, time for a short note about what speed really means. The May 2003 Harvard Business Review tells a fable about a farmer pushing a cart full of apples. The farmer asks a passer-by how far away the market is. The reply: "The market is an hour away if you go slow. If you go fast, it'll take all day."

That strange answer makes sense because the road was bumpy and the cart was full. If the farmer tried to rush to market, he'd spend all day picking up the apples that would inevitably bounce out of his cart. Does that sound like a familiar condition for a DoD program manager--very bumpy roads and very full carts?

Clearly, the objective in the fable (and in the real world) is to get to the market soon, and sometimes the fastest way forward is to take your time. Remember the tortoise who beat the hare in that famous race? So, while speed is indeed a virtue, being fast is not simply about quick movement. Deliberate and efficient forward movement, even if it seems slow in the short term, might be the fastest way to the finish line. The point is, there's a world of difference between being fast and being hasty. And now that we've cleared that up, back to the show.

Time To Get Our Game On!

So far, we've seen that technology development needs to be done faster, probably on the order of half the time it currently takes. We've also seen it can be done faster, according to a significant number of smart people who know what's going on. Then we talked about what speed is and is not. The only remaining question, then, is "How?" What can be done to bring about this increased speed?

Submitted for your consideration are three concrete actions. Fail to proceed at your own risk.

The Goal: Set an aggressive goal (50 percent reduction sounds good to us) and mean it this time, doggone it! Yes, that's what we all thought the Packard Commission did in '86, and FASA did in '96, and everything else--but maybe we could try it again, just one more time. Action on the individual PM's level would be a nice first step. Or how about a DoD-wide initiative to reduce development time across the board? Yes, it's been tried before, but what if we launch a little psyops mission and tell the Air Force that the Navy is going much faster all of a sudden ... then tell the Army the Air Force is slashing schedules left and right ... and then tell the Navy the Army is kicking butt. It's amazing what inter-Service rivalry can do.

The Practice: Start generating, collecting, tracking, analyzing, and publishing cycle-time metrics. Then discontinue/disallow the practice of dictating schedules. At the very least, make it a rare exception to the soon-to-be-newly established standard practice of seeking fast-moving, rapid-delivery contractors who set aggressive delivery timetables. Introduce schedule incentives for some portion of the 90 percent of contracts that currently don't have any. Then make sure late deliveries and schedule slips are not tolerated, or at the very least, not ignored or rewarded.

[FIGURE 2 OMITTED]

The People: Remove, relocate, retrain, re-educate, or otherwise replace the people who are content with the status quo. That's an essential element of any significant organizational change, and it just might be the missing piece of the various timeline-reduction efforts of the past few decades. The DoD needs to stop tolerating people who assert the amount of time it currently takes to develop and deploy new systems is just fine or can't be shortened. Those who believe solving the timeline problem will introduce new problems are undoubtedly correct, but that doesn't mean we shouldn't solve the timeline problem anyway and then start fixing the new problems. It's time to find people who believe in speed and put them in charge. We've got a list of names, if anyone is interested.

Seriously, cutting the DoD's technology development cycle times may or may not be easy, but it is certainly possible. We can do it. We need to do it, even if it's hard. It will solve a whole host of problems. The alternative is to keep slow-dancing with the 800-pound status quo gorilla. And that's just not pretty.

The authors welcome comments and questions. They can be contacted at [e-mail] and [e-mail].

Maj. Dan Ward, USAF

Maj. Chris Quaid, USAF

Ward holds degrees in electrical engineering and engineering management. He is Level III certified in SPRDE, Level I in PM. T & E and IT. He is currently assigned to the Air Force Research Laboratory in Rome, N.Y. Quaid earned his master's degree in business and is a PM certified Level 2 contracting officer's technical representative. He has logged over 10,000 hours of space operations and presently serves on the Pentagon Air Staff for Space Radar.