18 — Major contracts and supplier engineering

A major supplier package is both an engineering contribution and a commercial undertaking. The technical team needs a product that integrates and performs. The commercial team needs an agreement defining scope, price, obligations, rights and remedies. These views meet at the supplier boundary, but neither can replace the other. A technically acceptable design change may still require contractual authorisation; an agreed payment milestone may occur before the product is ready for installation.

The vehicle programme’s supplier-designed heating, ventilation and air conditioning (HVAC) package illustrates the distinction. The supplier may control internal equipment design while the vehicle business controls allocated requirements and vehicle interfaces. Successful delivery requires more than a box arriving at stores. It requires timely interface data, an understood configuration, evidence of suitability and agreed treatment of changes.

A technical baseline identifies the controlled requirements and definition used as a reference for engineering decisions. A contractual baseline identifies the agreed scope and obligations, including incorporated technical references and rules for changing them. Their content overlaps, but their authority and purpose differ. A newly released engineering document does not necessarily become part of an existing contract merely because it is available in the product lifecycle management system.

The agreement should establish how technical references are identified: by specific revision, by a defined baseline or through another explicit mechanism. Ambiguous references to “the latest drawing” can create uncertainty about which party bears the effect of later changes. The appropriate legal construction depends on the actual agreement and jurisdiction; the engineering requirement is to know which definition the supplier is authorised to use and how any transition is communicated.

Keep a controlled record linking contractual scope to the technical package actually issued. Record acknowledgement and discrepancies. If the supplier’s proposal qualifies a requirement, resolve that qualification rather than allowing the purchase order and engineering specification to tell different stories. The resulting reference should support a practical question: what must this supplier deliver, for which configurations, with what evidence?

Contract specialists own commercial drafting and interpretation within their authority. Engineering supplies precise scope, interfaces and acceptance needs. Programme management reconciles these with schedule and funding. The governing agreement and applicable obligations determine the legal effect of each decision; engineering records must preserve its technical scope and the authority under which it was issued.

Allocate design authority explicitly

The supplier’s design authority determines and controls its technical solution within the agreed scope. The vehicle design authority determines whether that solution integrates into the vehicle and satisfies the allocated needs. Define the boundary by information and decision, not merely by organisation name. A supplier may own the internal HVAC arrangement while the vehicle business owns mounting locations, electrical allocation and vehicle-level thermal performance.

At a cross-boundary connection, identify both endpoints and the authority coordinating compatibility. For the cooling module’s electrical interface, the module supplier controls its connector definition and the harness supplier controls the mating harness definition within their scopes. The vehicle integrator must ensure their agreement. Two independently approved supplier drawings do not prove that the pair works together.

Agree how internal supplier changes are classified. Some may have no effect on agreed interfaces or performance; others may affect installation, verification, maintenance or interchangeability. The contract and technical arrangements should define notification and consent expectations appropriate to these effects. Avoid demanding approval of every supplier working change while permitting an interface substitution to pass unnoticed.

NASA’s handbook appendix treats contractor integration as an explicit part of technical management, including agreements, interfaces, progress monitoring, changes and deliverable acceptance. That guidance supports the need to plan the boundary; its NASA-specific arrangements are not automatically vehicle contract requirements. NASA systems engineering handbook appendix.

Purchase information as well as hardware

Supplier data has a delivery schedule because other work depends upon it. Preliminary envelope information may support packaging. Controlled mounting and connection data supports detailed integration. Manufacturing and inspection information supports production readiness. Verification reports support acceptance. Service information supports use after delivery. Request these products at the maturity and date needed, rather than treating a final document bundle as an administrative accompaniment to hardware.

For each deliverable, establish purpose, content, format, revision identification, review route and acceptance criteria. Explain whether comments require correction before use, whether provisional use is permitted and who can grant it. A document received is not necessarily a document accepted. A document accepted for layout studies is not necessarily adequate for production release.

Data rights and access also influence engineering choices. The business may need sufficient information to maintain equipment, investigate faults or qualify an alternative supplier. The supplier may retain proprietary design information. Resolve the required use and access arrangements commercially before dependency grows. Where full internal definition will not be supplied, identify the interface and evidence package that allows responsible integration and support.

Do not equate access to a three-dimensional model with complete technical disclosure. The model may omit internal characteristics, operating limits, configuration status or acceptance evidence. Conversely, an unnecessarily large data demand can impose cost without improving a decision. Specify the information needed for the responsibilities the receiving organisation actually holds.

Reviews create decisions

A supplier review should test readiness against explicit criteria. Before a design review, agree the baseline, questions, evidence and expected decisions. During the review, distinguish accepted definition, observations, unresolved actions and conditions on further work. Afterwards, record who owns each action and which activities it prevents or permits.

A preliminary design review may examine whether the proposed architecture and interfaces can meet the allocated needs with credible development plans. A later review may examine detailed definition and verification readiness. The exact lifecycle and review names should follow the programme and contract. A meeting called “design review” does not establish maturity by its title.

Attendance is not a general acceptance of liability or product readiness. Record the specific meaning of concurrence and approval within the agreement. An engineer may accept an interface for vehicle integration while the supplier retains responsibility for its internal design. A commercial representative may authorise expenditure while a technical issue remains open under a controlled restriction.

For expensive packages, review the remaining uncertainty before major commitments such as tooling, material purchase or manufacture. The supplier needs an unambiguous instruction about what can proceed. Where early work is authorised, identify the scope, assumptions, exposure and later decision points. This allows concurrency without turning every unresolved detail into an uncontrolled contractual dispute.

Manage a change through both authorities

The customer raises the hot-climate requirement in DOORS after Vehicle 01 has entered build and Vehicle 02 equipment has been ordered. Engineering first establishes the changed requirement and assesses the existing solution. The HVAC supplier may need to analyse a different operating condition, the cooling supplier may offer alternatives and the harness supplier may need revised electrical information. Asking for this assessment is distinct from instructing production of a changed package.

A change proposal should identify the initiating cause, affected baseline, technical alternatives, vehicle applicability, evidence needed, cost and schedule consequences, and treatment of existing work. The supplier should distinguish design effort, non-recurring tooling or qualification, unit-price effects and consequences for already committed material where relevant. The business needs this separation to compare options and avoid paying twice for the same work.

Technical authority then determines which option is acceptable and under what conditions. Commercial authority agrees the variation within its delegated powers. Programme authority integrates funding and delivery effects. These decisions may proceed iteratively, but their status must remain visible. A design release should not disguise a missing commercial instruction, and a variation should not imply that technical verification is complete.

Vehicle 01 may require a retrofit assessment based on its actual build state. Vehicle 02 may require an order amendment before supplier manufacture reaches an expensive transition point. Vehicles 03 and 04 can incorporate a later configuration if the agreed scope supports it. Record whether each vehicle receives the changed package, retains an accepted earlier configuration or awaits a decision. A single fleet-wide change flag cannot express these outcomes adequately.

The supplier connector change is a separate initiating event. It may be unrelated to hot-climate performance yet affect the same module and harness orders. Preserve separate technical reasoning and commercial disposition, then coordinate implementation where appropriate. Combining the work can be efficient; merging the causes and authorities makes accountability obscure.

Accept delivery with the right evidence

Acceptance should distinguish data, hardware and demonstrated performance. A supplier can deliver complete hardware with incomplete records, or accepted design data before hardware exists. Contractual payment milestones can be related to these events, but their exact meaning must be explicit. Payment is not a substitute for a configuration and evidence assessment.

For a delivered cooling module, identify the supplied part and revision, the physical instance where traceability requires it, applicable inspection records and any approved departures. Confirm compatibility with the intended vehicle and mating harness. The supplier’s certificate or test report must refer to a recognisable configuration and scope. A report for a previous variant cannot silently demonstrate a changed installation.

Where a nonconformance exists, record its technical disposition and contractual treatment separately. A limited concession for a specific delivered instance does not automatically revise the design for future supply. Rework may require new inspection evidence. Replacement may affect schedule and stock allocation. The receiving organisation needs to know what can be installed while the commercial parties resolve responsibility.

Acceptance evidence also has a hierarchy. Supplier component tests can support an installation assessment without proving vehicle-level performance. The integrator must identify the remaining verification work and preserve the relationship between supplier evidence and vehicle acceptance. Otherwise, each party may believe another has demonstrated the overall outcome.

Close the loop across records

A change is not operationally complete when its commercial variation is signed. Update supplier definition, issued technical packages, affected orders, incoming controls, manufacturing instructions, service information and vehicle records as applicable. Confirm implementation and identify residual stock or work in progress. An old connector remaining in stores can defeat an otherwise well-controlled design transition.

The selected platform architecture needs a traceable relationship between Teamcenter technical baselines and SAP commercial and procurement records. DOORS holds customer requirement changes; NX and Capital support mechanical and electrical definition. The precise integration and supplier collaboration mechanisms remain implementation choices. Define the exchange content and responsible authorities before selecting workflow screens.

Access control must also follow responsibility. A supplier should receive the applicable package and authorised changes, while internal commercial or unrelated technical information is protected according to the actual agreement and security obligations. Avoid relying on unrestricted folder access as an informal change-notification system. Distribution, acknowledgement and disposition are different events and should remain distinguishable.

Scale without losing the accountable boundary

A major defence or infrastructure package may involve years of manufacture, thousands of contributors, lower-tier contracts and millions of occurrences in the finished product. The engineering business needs consistent boundary definitions, contract-to-technical references and evidence schedules across that scale. Local supplier teams can manage detailed actions, but cross-package interfaces require an integrating authority with visibility of both sides.

Changes to expensive packages should be evaluated before they propagate into tooling, fabrication and site work. Conversely, delay in deciding can itself create cost and schedule exposure. Set decision routes and escalation thresholds that reflect consequence rather than routing every issue to the highest committee. A useful contract and a useful engineering baseline make the same boundary understandable from different perspectives: what is required, who can decide, what is authorised and how delivery will be demonstrated.