Concurrent Engineering
Concurrent engineering is simple in theory — run NPI tasks in parallel, save time, save money. In practice, most projects quietly fall apart. After years of watching it happen, only two things really matter.
The idea, and why it backfires
The idea is simple — run NPI tasks in parallel, save time, save money.
So what do most PMs do? Kick off everything as early as possible. It feels productive, right?
That's usually how projects quietly fall apart. After years of watching this happen, I've found only two things really matter.
1. Sync info, don't just start early
CE isn't "get everyone in the room on day one." It's getting the right info to the person who's actually waiting for it. Not any info. Not everyone.
Flood people with noise, and they'll learn to tune it all out. Those endless "alignment meetings"? Mostly an illusion of collaboration — and half the output turns into rework anyway.
A good PM's real KPI: how little of everyone's time the project burns.
2. Cut-off + release log
Picture this: drawings released → procurement starts RFQ → suppliers quote → IE does DFM → QA writes the test plan. Then the designer changes one thing. Everyone redoes everything.
Round one, everyone's helpful. A few rounds later? Quality drops, replies slow down, and eventually some teams just... ghost you.
1. A cut-off policy, so designs go out mature — changes after that follow a proper revision process.
2. A release log, so repeated revisions are visible to everyone (including whoever owns the budget), and feedback always points to a specific version.
That's it. No fancy framework. Just these two, done consistently — and the savings are real.