Introduction — A familiar product, a complex engineering enterprise

Why we will follow a car

A car is a useful place to begin because most readers can picture the product before learning how its engineering is organised. It has an engine, a structure, brakes, cooling, fuel, electrical controls and heating and ventilation. Its systems share space and resources. A decision in one discipline can change the work of another.

Our fictional organisation is developing four customised combustion-engine utility vehicles. It buys some equipment, designs other parts and asks suppliers to engineer assemblies to agreed requirements. Vehicle 01 is in build, Vehicle 02 has major components ordered, and Vehicles 03 and 04 are being planned. It begins selected manufacturing work while parts of the design are still developing. Customer requirements, captured in DOORS, can change after purchases have been committed and physical work has begun.

We will follow those decisions rather than describe each department in isolation. A higher payload requirement creates questions about the chassis, suspension, braking and powertrain. A hotter operating environment creates questions about cooling, cabin comfort, electrical demand and packaging. A supplier's revised connector raises a smaller but equally revealing question: which definitions, mating components, work instructions and test records are affected?

The engineering depth we are aiming for

The intended reference reaches beyond a four-vehicle workshop. We want to explain an operating model capable of supporting major defence and complex infrastructure programmes: products with millions of part occurrences, manufacturing programmes lasting years, and thousands of people working across organisational and supplier boundaries.

Those are the scale conditions we will examine, not claims about the size of our vehicle example. The engineering principles need to survive changes in scale, while their implementation must reflect the product, contract and assurance regime.

A familiar example lets us examine a single connection closely. Scaling passages will then ask what happens when the organisation has to identify, release, change, manufacture and inspect very large numbers of such connections. The answer cannot depend on everyone remembering a conversation or opening a complete model of the product whenever they need to act.

Part occurrences matter here. One standard fastener definition can be used at many positions. Those uses may belong to different assemblies, products, build stages and change dispositions. Managing the catalogue of part numbers is only one part of understanding what is intended and what has actually been installed.

What we mean by engineering

We will treat engineering as the creation and justification of the product definition throughout its lifecycle. Requirements, architectures, analyses, interfaces, CAD models, supplier specifications, manufacturing requirements, test plans and maintenance decisions all contribute. The following chapters explain their distinct purposes and how they connect.

The book will ask practical questions. What makes a set of components an assembly? Does the manufacturing assembly need to match the engineering assembly? Where does a bolted joint's definition belong? How are connector pin assignments related to harness manufacture and vehicle installation? How does the organisation know that the intended connection was made and checked on a particular vehicle?

We will also separate the technical decision from the business commitment. An acceptable design change may still require a supplier agreement, revised work packages, a different implementation date or re-verification. A changed customer requirement must be assessed against work already completed as well as design still in progress.

How the story develops

We begin with the purpose of engineering and the enterprise's delivery commitments. We then explain lifecycle reviews, systems models, product structures and information identity. With those foundations in place, we follow configuration, maturity, change, procurement, manufacturing, acceptance and support. Platform chapters show how the operating model can be represented using DOORS, NX, Capital, Teamcenter and SAP, identifying implementation choices rather than assuming integrations solve governance automatically.

Relevant chapters include a short scaling discussion: what remains the same, what becomes impractical, which responsibilities must be distributed, and what evidence must remain discoverable. We will cover work-package boundaries, delegated authority, supplier baselines, configuration queries, long-term records and the practical limits of working with a single large product structure.

The objective is a readable explanation and a usable reference for how an engineering organisation should run. Recognised standards and guidance inform the practices described. Applicable obligations depend on the contract, jurisdiction, product and assurance regime; the vehicle example establishes no universal defence or infrastructure compliance.

Start with what engineering means, or use the book map to find a specific topic.