There’s a lot of criticism these days of a practice called concurrency, an engineering approach the DoD implemented a reform or two ago. Concurrency was supposed to help move things to the field faster. Unfortunately, like many reform ideas, it didn’t quite pan out.
The basic idea behind concurrency was that the DoD could do some development activities in parallel, instead of one after the other, thus shortening the timeline for fielding a new piece of equipment.
The principle behind concurrency is sound. Some activities can and should be done at the same time. Unfortunately, concurrency was widely misapplied and DoD ended up with situations where manufacturing and design happened simultaneously – hardly an ideal approach. Halfway through trying to build an undesigned piece of gear, the futility of this method became painfully clear (at least to some of us).
Other projects twisted concurrency to mean developmental activities could be done in any order at all, so they tried to field a new system first, then test it later, and maybe eventually design it…someday. That would be silly if there wasn’t so much money involved.
The ineffective version of concurrency creates a short-term, superficial appearance of speed but ends up requiring a lot more time between project start and project delivery than doing things in a logical order. It is very different than genuinely moving faster by building to a restrained requirement set and using a block / incremental / spiral approach, in which an initial, simple design based on fully mature tech is tested prior to fielding, followed by an updated version which is also fully matured and tested before it’s shipped…you get the picture.
Here’s the thing – concurrency is actually a great way to speed things up, but only if it’s done well. Drs. Alexander Laufer and Edward Hoffman explained this concept in a paper titled 99 Rules For Managing Faster, Better, Cheaper Projects. Rule #65 states:
Overlapping project phases is vital in order to accelerate speed. This step can be applied easily when phases are independent of one another. Very often, however, phases are highly dependent on each other, and overlapping without maintaining essential conditions can be very costly. Since completing tasks too early may bring about a need to redo them, overlapping without maintaining essential conditions may even add time to the project.
As Laufer and Hoffman explain, it’s desirable to do some overlapping (i.e. concurrent) activities, but not every set of tasks can be overlapped. Some things need to be done sequentially.
I believe the phrase you’re looking for is “no duh.”
It shouldn’t take a rocket scientist to understand and apply that concept, but unfortunately even actual rocket scientists have been known to get it wrong.
So, concurrency is a terrible idea if it’s done wrong, and a great idea if it’s done right. That pretty much puts it in the same category as any other good idea in the history of the world. Let’s keep in mind that just because some people do a thing badly doesn’t mean nobody can do it well.
Another thing to understand about concurrency is that it does not mean we’ve accepted more risk, although that’s how it is often justified. From a risk perspective, careless concurrency guarantees a significant amount of rework. Ultimately, it delays the system’s actual delivery and reduces its effectiveness. That’s not a risk. It’s a locked-in, pre-planned bad outcome. There’s a difference.
As a general rule of thumb, we can’t solve a program’s problems by rushing it to the field with under-designed, untested technology. We also can’t solve a program’s problems by indefinitely delaying delivery. That latter strategy only increases the program’s exposure to change and boosts the overall cost while increasing the risk of irrelevance and obsolescence. Fortunately, those are not the only two options.
The approach that works best is to perform independent tasks simultaneously and dependent tasks in series – that’s how concurrency was supposed to work. The result is quickly and continuously fielding a series of fully-baked, mature, tested systems that are a little bit better than what we had before. And isn’t that what it’s really all about?
Lieut. Colonel Dan Ward is an active duty acquisitions officer in the U.S. Air Force, currently deployed to Kabul, Afghanistan. The views expressed in this article are solely those of the author and do not reflect the official policy or position of the U.S. Air Force or Department of Defense.