Concurrent Product Development. For those of you that remember, does it bring you back? I, for one, haven’t heard that phrase in quite some time. And that fact alone perplexes me. So I’m sure you can see where I’m going with this.

This post reviews the value proposition of Concurrent Product Development, originally powered by CAD, as well as revisits why it is no longer a central topic in the industry. I have a few hypotheses, but I’m looking forward to hearing to the comments section and reader’s perspectives. Here we go.

Serial Product Development

In the past, engineering and other deliverables had to be changed manually to match design changes. Because designs changed drastically during the design phase, most deliverable creators would wait until close to design release, when the rate of change slowed dramatically, before they would start their work. The driver in all this was the avoidance of recreating their deliverables, which could represent a significant amount of rework.

From a process perspective, this forced the execution of steps in a sequential or serial fashion. Close to design release, the creation of engineering drawings started. At design release, the creation of NC toolpaths started. The same was true of any other deliverable based on design geometry.

Concurrent Product Development

What changed? Well, a technology disruption happened.

When feature-based parametric CAD was first introduced, the power to make changes to 3D solid geometry was the ‘wow’ factor. But that wasn’t what got the attention of executives. That wasn’t the justification behind the purchase of all that CAD back in the ’90s. Nope. To be honest, any mechanism could have been used to initiate geometry change. The real value lied in associativity.

The idea behind associativity was, and still is, simple. If the geometry of the 3D model changes, then that change shows up everywhere else the 3D model exists. That, of course, includes an assembly model. But it also includes drawings, manufacturing models that output NC tool paths and much more.

The business implication here was powerful. Instead of waiting to create drawings until near design release, you would start them almost simultaneously as the 3D model was created. The same holds true of the manufacturing model. Essentially, anything referencing the 3D model could be started very early. In all, this represented a switch from serial product development to concurrent product development.

Where Has It Gone?

That’s my point in all this. In all the conferences I attend and all the briefings I conduct, I literally haven’t heard a single software provider mention this concept in, well, I don’t know how long. And actually, the same holds true of manufacturers and engineering organizations as well. It’s like it has been forgotten. Given the time constraints for today’s development schedules, it offers a terribly powerful concept.

Now, I have a few ideas. And here’s where I’d like your help. Which of these hold most true? Which ones are simple false?

Concurrent Product Development is a Commodity

Practically ever CAD software application out there today offers the kind of associativity that is described above. Is this concept no longer discussed by software providers because it offers no differentiation? Perhaps that is true. But that’s just the software provider side of things. Even if this is a commodity, that doesn’t mean that is in practice on a widespread basis.

Concurrent Product Development is Widespread

Is every manufacturing company employing this kind of practice? Are drawings and manufacturing being started far ahead of design release? Maybe this is a central component of every CAD installation and PLM deployment.

Somehow, I have a tough time believing that is the case. I’m not seeing a lot of use cases along these lines. Maybe I’m wrong here, and I’d love to heard that if it is true. But again, I have a tough time believing it.

Deliverable Creation is Far Faster, Simpler and Easier

From a manufacturer perspective, this could be the case. Today’s CAD software applications can enable the creation of drawings, manufacturing models and more more quickly than in the past. So, maybe, creating these deliverables are simply far easier and faster than they were in the past. As a result, it doesn’t take as much time as it did in the past, undermining the need to execute these kinds of tasks concurrent instead of serially.

Again, with this one, I have my doubts. But you tell me. Again, I’m all ears.

Concurrent Product Development is Stale

The original concept of Concurrent Product Development was introduced almost some twenty years ago. Maybe for software providers, its simply old hat. It might simply be that it is no longer an interesting story. Maybe, with acquisitions and new products, it simply isn’t as compelling.

My Take

Personally, I think some combination of these factors are in play, except for the widespread adoption of concurrent product development. I have a hard time believing this problem has essentially been solved.

So let’s discuss. What say you? Really interested in getting your perspective.