# Applying Concurrent Engineering to Machine Building Projects
Machine building projects fail on handoffs more often than on technology. The mechanical engineer finishes the layout and throws it over the wall to electrical, which discovers the panel has nowhere to live. The design “completes,” and the assembly floor finds out that the frame and the cover were never checked to fit together. Concurrent engineering is the management of the overlaps: running design efforts in parallel, crossing information at defined points, and resolving the conflicts early when they are cheap. This article covers the practical mechanics of running a machine project concurrently without losing control.
The Overlap That Saves the Schedule
The conventional sequential project budget wastes its own critical path. Mechanical finishes the structure, then electrical designs the routing, then software starts. Each phase waits for the previous one and each phase discovers the previous one’s oversights. Concurrent engineering overlaps these phases: mechanical freezes the envelope and the mounting surfaces early so electrical can route against a provisional model while mechanical is still refining details. The overlap is the schedule saving; the discipline is only sharing the decisions that can be frozen, and marking clearly what is provisional.
The overlap also reroutes information that used to arrive too late. The mechanical designer learns from the assembly team that access is tight before the frame spend is approved. The electrical engineer tells the mechanical designer where the connectors will land before the covers are drawn. Information flows sideways, not just forward, and the project makes decisions with more of the picture in front of it.
Freezing the Interface, Flowing the Details
The key management move in concurrent engineering is the interface freeze. Choose the few decisions that everything else hangs on — the machine envelope, the base frame datum, the panel position, the power and air service points, the communications architecture — and freeze them early with the people who own them. Once frozen, every discipline can proceed in parallel against a stable anchor, and the details that remain open are local to each discipline. The interface freeze is the contract that makes parallelism safe.
The discipline is choosing what not to freeze. Over-freezing shuts off the design freedom that produces the good ideas; under-freezing lets the project drift into conflicts that surface at integration. The interface freeze should be reviewed at a gate, with a written record of what was frozen at what date, so that when a late design breakthrough arrives, the project knows exactly what it will cost to reconsider the frozen decisions.
The Design Reviews That Catch Conflicts
Concurrent engineering raises the stakes of design reviews, because parallel design produces more conflicts to catch. The review should be a regular, short meeting where the disciplines show the current state at the interfaces: electrical shows the routing against the mechanical model, mechanical shows the cover envelopes against the frame, software shows the sensor list against the mounting plan. The meeting is not a status report; it is a conflict hunt. Every mismatch found here is one fewer change order on the assembly floor.
The review cadence should match the rhythm of the project: weekly at the working level, with the output being a short list of open conflicts and owners. The review record is the project memory. When two design choices conflict and the review resolves them, the resolution written down prevents the same conflict from resurfacing in a different form next month.
Ownership and the Design Owner
Every interface needs a named owner, not a committee. The owner of the mechanical-electrical interface decides how a connector location conflict is resolved, chairs the discussion, and holds the freeze record. Without an owner, an interface conflict bounces between two departments until the project manager forces a decision into a rushed compromise. The owner model keeps decisions at the level of the people who understand the trade-offs, with escalation reserved for the genuinely cross-cutting calls.
The owner also owns the documentation of the interface. When the panel position moves, the owner updates the shared model, the interface drawing, and the open-issue log. Other disciplines are then working against the current truth rather than their private assumptions. A project with well-owned interfaces runs on current information; a project without them runs on the most senior person’s memory.
Shared Models and Configuration Control
The shared model is the backbone of concurrent engineering, and configuration control is what keeps it honest. With multiple disciplines editing views of the same assembly, the risk of stale or divergent data grows. The workflow should be built around a single source model, with disciplines working in controlled references, and a change notification that reaches anyone relying on the changed feature. The alternative — each discipline keeping its own copy and reconciling by email — is concurrent engineering with the concurrency removed and all the conflict retained.
The change notification is the point most often skipped and the point that poisons everything else. A mechanical change to the base plate that electrical has routed against, with no notification, is a week of electrical rework discovered at integration. A formalized change notice (even a lightweight task-list entry) that names affected disciplines and asks for confirmation resolves the rework early. The notice is the coordination cost that makes parallel work safe.
Feeding Forward From Past Projects
Concurrent engineering compounds when it runs on lessons learned. The conflicts that killed the last project’s schedule — the panel that did not fit the frame, the software interface that mechanical did not provide — should be written into the standard checklist for the next project. The interface freeze list, the design review agenda, and the change-notification workflow all improve as each project teaches where the real conflicts live. The organisation that captures this feedback runs each new project with fewer surprises than the previous one.
The learning loop also reaches the team. A project retrospective that names the interfaces that hurt, the review that caught a costly conflict, and the notification that was missed, feeds the next project’s template. Concurrent engineering is not a fixed method; it is a method that iterates on its own failure modes.
What Does Not Concur
Some work cannot be overlapped honestly. A structural analysis that depends on loads not yet defined, a procurement order that depends on a supplier bid not yet received, and a safety review that must see the final configuration are sequential by nature. The art is identifying the genuinely sequential steps and scheduling them as the critical path, rather than pretending everything can be parallelised. The project schedule should show both: the parallel blocks where concurrency saves time, and the honest serial chain that defines the earliest possible finish.
The other non-negotiable sequence is around change. If a late change to a frozen interface is worth pursuing, it should go through the change decision process — with cost, schedule, and affected disciplines named — before anyone starts editing. Concurrency removes waiting, not governance; a project that removes the governance along with the waiting trades schedule for chaos.
A Working Concurrent Workflow
- Freeze the envelope, datums, and service points at kickoff
- Run mechanical, electrical, software, and controls in parallel against the frozen anchors
- Hold a weekly interface review that hunts conflicts, not status
- Own every interface by name
- Share one authoritative model with change notifications
- Capture the conflicts for the next project’s checklist
Conclusion
Concurrent engineering is how machine projects stop paying for the serial handoff. The overlap of the disciplines, anchored on frozen interfaces and steered by regular conflict-hunting reviews, compresses the schedule and moves the risk from the assembly floor to the design phase, where it is met with revisions instead of change orders. Run pragmatically, with owned interfaces and honest configuration control, concurrency turns a machine project from a relay race into a collaboration.
The Interface as a Contract Between Teams
The discipline that makes concurrency safe is to treat every interface as a signed contract. When mechanical owns the base plate pattern and electrical owns the terminal rail, the interface — the bolt circle, the clearance envelope, the routing space — is a contract they both sign before the parallel work begins. The contract names the geometry, the tolerances, and the freeze date, and it names who may change it. Work that runs in parallel against a signed contract stays consistent; work that runs against an assumption drifts until the integration day discovers it.
The signed contract also changes who fights the battles. When an interface conflict surfaces, it is no longer a negotiation between two engineers with overlapping drawings; it is a contract dispute with a named owner, a change process, and an escalation. That sounds bureaucratic, but it is precisely the governance that lets the engineering run fast. The interface contract converts the worst failure mode of concurrency — silent drift — into a visible, manageable change decision.
The Digital Thread Through the Process
Concurrent engineering needs a shared nervous system, and the machine project’s digital thread is the model, the data, and the change record that every discipline reads from and writes to. The mechanical model, the electrical schematic, and the software build should all reference the same configuration state, so a “latest” part in one domain is the “latest” part in every domain. The digital thread is what makes the parallel teams confident they are designing against the same reality, rather than against their own local copies of the truth.
The thread also carries the traceability that the audits and the customer want. When the site team asks why a panel moved, the change record in the thread answers with the date, the owner, and the affected interface — no archaeology required. The digital thread is the concurrency project’s memory: without it, the parallel teams are designing in parallel silos, and the project is paying for the silos’ reconciliation later.
Starting a New Project in the Concurrent Mode
The transition to concurrent working starts with the project’s kickoff artefacts. The envelope freeze, the datum scheme, and the service points — the anchors that everyone works against — are the first deliverables, not the first casualties of the schedule. A project that starts with the anchors defined spends its first meetings defining what is shared; a project that starts with detailed drawings is already serializing. Define the shared anchors first, name the interface owners, and only then fan the disciplines out to run in parallel.
The change culture must be established at the same kickoff. A stated rule — “no one edits a frozen interface without a named change decision” — costs a sentence at the start and saves the week of rework that a silent edit costs at integration. The teams that agree on the procedure before the pressure starts are the teams that keep the procedure when the pressure arrives.
Conclusion
Concurrent engineering is how machine projects stop paying for the serial handoff. The overlap of the disciplines, anchored on frozen interfaces and steered by regular conflict-hunting reviews, compresses the schedule and moves the risk from the assembly floor to the design phase, where it is met with revisions instead of change orders. Run pragmatically, with owned interfaces, signed interface contracts, and a digital thread that keeps every team honest, concurrency turns a machine project from a relay race into a collaboration.
The Co-Location Fallacy and the Distributed Team
Concurrency is sometimes mistaken for co-location: the assumption that parallel work requires the teams to sit in one room. Modern machine projects often run with mechanical in one city, controls in another, and the customer’s process engineer at the plant. What collides is not distance but information. A distributed team can run concurrency well when the shared artefacts — the frozen model, the interface contract, the change record — are the coordination surface, and the daily status ritual (a short stand-up or a shared board) replaces the corridor conversation. When the coordination lives in the shared artefacts rather than in memory, the distributed team is no slower than the co-located one, and often more disciplined because every handoff is written.
The distributed coordination also refuses the silent edit in a stronger way. In a co-located room, an engineer “mentions” a change in conversation; in a distributed project, the change must pass through the record to propagate at all. That friction, annoying at first, is exactly the governance concurrent working needs. The project that writes its coordination is the project whose coordination also survives.
Completing it well is about the checks between the teams as it is about any single drawing.
