14 — Concurrent engineering and early manufacture
Waiting for every vehicle detail before beginning manufacture avoids some early commitments but postpones learning and delivery. Beginning everything immediately creates another problem: teams commit material, interfaces and supplier capacity against assumptions that nobody owns. Concurrent engineering works between these extremes. It coordinates interdependent work so that each commitment uses sufficient information while the remaining uncertainty stays bounded and visible.
In the four-vehicle programme, Vehicle 01 is already in build while Vehicle 02 has major components ordered and Vehicles 03–04 remain in planning. Design discovery therefore encounters several kinds of commitment at once. A revised cooling module may be easy to adopt in a planned vehicle and expensive to install in a partly assembled one. The useful question is which work can proceed, under which conditions, and who will respond if those conditions change.
Release a dependency-bounded work package
A work package defines an executable scope with inputs, outputs, ownership and completion evidence. It may cover bracket fabrication, module assembly or installation into a particular vehicle. It should not be defined merely by a convenient folder of drawings. Its boundary must support a real commitment and expose the dependencies crossing it.
For a cooling-module mounting package, inputs include applicable loads, mounting geometry, module envelope, material definition, interface characteristics and relevant manufacturing constraints. Outputs include fabricated items, inspection results and identification linking them to the intended configuration. Open fan-performance analysis need not block every mounting operation, but it does block a commitment whose validity depends on an unbounded fan mass, load or envelope.
The package owner assembles a dependency account: which inputs are fixed for this use, which are provisional, which can vary within assessed bounds and which remain unavailable. Each provisional input needs a supplying owner and a required decision point. A schedule date alone cannot turn an unavailable interface into usable information. If a necessary input cannot be bounded, split the package or delay that commitment.
A practical split might permit material purchase and rough fabrication while withholding final mounting-hole operations. This creates useful progress only if the unfinished operation is technically and operationally credible. The team must check access, available machining or assembly methods, identification and inspection. Calling a package provisional cannot make an impossible later operation possible.
Stable interfaces make local progress possible
An interface is stable enough for a commitment when its controlled characteristics can be relied upon within stated bounds. Stability does not mean that nobody will ever request a change. It means that a change has an owner and must be assessed before dependent work is disturbed. NASA’s interface guidance connects interface definition, compatibility and controlled management throughout development and realisation; it is useful guidance rather than an imposed vehicle standard. NASA interface management.
The cooling module crosses mechanical, fluid and electrical boundaries. The module supplier owns its agreed endpoint definition; chassis and harness authorities own theirs. Integration owns the compatibility decision across those boundaries. The controlled interface account needs the relevant endpoint identities and occurrences, geometry or connection characteristics, applicable revisions, uncertainty and verification method. Matching connector names alone does not establish cavity assignment, electrical suitability or installed accessibility.
Assembly boundaries must serve the work. A supplier cooling module may arrive as one purchased item while vehicle manufacture installs hoses and harness connections separately. The installation package therefore includes cross-boundary operations that are absent from the supplier’s internal assembly tree. The functional cooling system also includes engine-side behaviour and air paths outside the module. Work-package completeness depends on these relationships, not on whether one assembly model opens without missing parts.
Own exposure explicitly
Exposure is the potential consequence of making a commitment before all relevant uncertainty has been removed. It includes stranded material, supplier claims, rework, lost access, delayed tests and acceptance risk. An exposure owner is the person accountable for accepting that consequence within delegated authority and arranging a response if the assumption fails.
The technical authority establishes whether the uncertainty is bounded and whether the proposed work remains technically defensible. The programme authority accepts delivery and resource consequences within its limits. Procurement authorises supplier commitments. Manufacturing confirms that the proposed sequence and recovery are executable. These decisions can be coordinated, but none substitutes for the others.
An early-commitment record identifies the action, evidence, assumptions, affected vehicles, alternatives, recovery options and decision trigger. It should explain why proceeding now is beneficial compared with waiting. An assumed future redesign is not a recovery plan unless the team has assessed how it can be performed. Reversible preparation deserves a different treatment from welding a structure that will become inaccessible.
The person who benefits from an early start should not be able to hide its consequences in another function’s budget or schedule. If procurement obtains a shorter lead time by ordering before interface agreement, the resulting exposure belongs in the programme decision. Likewise, engineering cannot call a change harmless while manufacturing carries unreported rework. Shared visibility makes the choice economically intelligible.
Discovery, stop and rework triggers
Concurrent work produces discoveries. A supplier prototype may reveal insufficient connector access, a test may challenge thermal assumptions, or manufacturing may find that the intended installation sequence traps a hose. Discovery should trigger assessment against the commitment conditions rather than an argument about which team was meant to finish first.
Before release, establish stop triggers. Examples include a new interface revision outside agreed bounds, evidence invalidating the load case, unidentified material or an unavailable required inspection. State who can place work on hold, who assesses the affected scope and who authorises restart. A local hold should target the affected operation and product context where the evidence permits; stopping all work indiscriminately can create avoidable disruption.
Restart requires evidence that the hold cause has been resolved or bounded by an authorised disposition, that affected instructions and material are compatible, and that the receiving team has acknowledged the permitted scope. Technical authority clears the technical condition; manufacturing confirms executable instructions and resources; the delegated commitment authority accepts any remaining exposure. Record the restart against the affected operation and vehicles.
Rework requires its own controlled instructions and evidence. A verbal instruction to enlarge a hole or adapt a connector can create a physical configuration that no released definition describes. The resulting record must identify the actual intervention, applicable technical disposition, inspection and vehicle. Where the existing definition remains valid and only workmanship is defective, use the nonconformance process rather than silently revising the design.
Hot-climate discovery during build
Suppose the customer changes the required hot-climate conditions in DOORS while Vehicle 01’s cooling installation is under way. The requirement proposal enters change assessment. Thermal engineering examines cooling performance; electrical engineering considers fan demand; integration examines airflow, packaging and interfaces. Manufacturing reports completed operations and remaining access, and procurement establishes supplier progress for Vehicle 02.
Vehicle 01 should not automatically stop every activity. The package owner identifies which remaining work depends on the challenged assumptions. Unaffected interior work may continue while cooling installation is held. A bracket fabricated within previously agreed bounds may remain usable, subject to an explicit assessment. If the revised solution exceeds those bounds, the exposure owner decides among controlled rework, replacement, revised sequencing or another technically justified option.
For Vehicle 02, an order amendment may be possible before supplier manufacture, but the supplier must acknowledge the revised technical and commercial package. Vehicles 03–04 can incorporate the accepted solution in their planning baseline. The team must still assess differences between these vehicles: a later serial position does not prove identical requirements or compatibility.
A concurrent supplier connector change complicates the picture. The new fan may require a different mating harness and installation instruction. The implementation plan therefore coordinates module and harness availability, stores identification, order applicability and verification. An early module delivery is not useful progress if it cannot be installed or tested with the available vehicle configuration.
Unit states change the decision
Physical and commercial state are inputs to concurrency decisions. Planned, ordered, fabricated, installed, inspected and accepted describe different commitments. These states should be recorded at the granularity needed for the decision, rather than assigning a single coarse state to the whole vehicle. Vehicle 01 may have an installed radiator, an uninstalled harness and a bracket awaiting inspection.
A state report needs a time and source. A supplier report received yesterday may become stale before a change decision today. For high-consequence commitments, obtain confirmation of the relevant physical state and establish a hold or notification arrangement while disposition is decided. Otherwise, the change plan may chase work that continues to move underneath it.
The plan must distinguish authorised future configuration from actual completed configuration. A released new module does not erase an earlier installation. Execution records and acceptance evidence eventually reconcile the difference. Chapter 12 explains use-specific readiness; chapter 13 follows the change through closure.
Systems and scale
NX and Capital can provide relevant mechanical and electrical definition; Teamcenter can coordinate controlled product information and manufacturing-planning relationships, while SAP supplies purchasing, material and order context. The operating requirement is a queryable link from each work package to its applicable inputs, decisions, conditions and completion evidence. This is a logical architecture, not a claim about default objects or automatic integration.
The release exchange should identify exact revisions and applicability, not send an instruction to use whatever is latest. Changed assumptions should generate accountable reassessment tasks. Failed notifications and unacknowledged supplier instructions remain visible work. An execution system or controlled record process must report actual operations; lifecycle status in a design repository cannot establish physical progress by itself.
On a major defence or infrastructure programme, millions of occurrences and multi-year manufacture create many simultaneous configuration states. Thousands of people cannot attend a daily meeting about every dependency. Stable interfaces, delegated release boundaries, exception queues and durable decisions allow local work to proceed while integration watches cross-boundary consequences. These are scaling requirements rather than platform throughput guarantees.
Smaller tasks need proportionate control. A reversible layout study may require a short agreement between neighbouring designers. Irreversible fabrication across several supplier boundaries needs stronger evidence and acknowledgement. Concurrency succeeds when the business can identify the commitment, justify its dependencies and respond promptly to discovery, rather than treating all unfinished design as equally dangerous or equally harmless.