Question 3 of 7: Communicating Design Information

Question 3: Communicating Design Information (15 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part A — Three ways to communicate design information within a team (6 marks)

1. The controlled digital product definition — the 3D master model under configuration management. The single most important communication channel in a modern design team is not a conversation; it is the CAD assembly held in a PDM or PLM system, with released drawings or model-based definition carrying the GD&T, the bill of materials generated from it, and a formal change process (engineering change requests and notices) governing every revision. Its virtues are that it is unambiguous, that it is a single source of truth so that two engineers cannot unknowingly work to different geometry, that it carries revision and effectivity so that everyone knows which version is current and what changed, and that it is auditable years later. Its limitation is that it communicates what the design is and almost nothing about why, and it is slow: a change has to be modelled, checked and released before anyone can see it.

2. Synchronous, face-to-face working sessions around a shared artefact — design reviews, stage-gate reviews and the war room. This is the high-bandwidth channel: a physical prototype or a projected model on the table, the whole cross-functional group present, and the ability to ask a question and get an answer in seconds. It is where tacit knowledge moves — the reason a radius is what it is, the failure someone remembers from a previous programme — and where genuinely ambiguous or contested decisions get closed, because it supports negotiation and reads the body language that tells you a supplier is uncomfortable. The formal versions (design reviews with a checklist and an action list, gate reviews with defined deliverables) exist to make sure this channel is used deliberately rather than only when something has gone wrong. Its weakness is that it leaves no record unless someone is disciplined about capturing decisions and actions, and it does not scale beyond the people in the room.

3. Structured asynchronous documents and trackers — the specification, the DFMEA, the interface control document, the test report and the issue list. These are the channels that carry reasoning and status rather than geometry. The target specification says what the product must achieve and how it will be measured; the interface control document fixes what each subsystem may assume about its neighbours, which is what allows teams to work in parallel; the DFMEA and design records carry the risk reasoning and the rationale behind decisions; the issue tracker carries who owes what to whom by when. They are precise, searchable and durable, they scale to large teams, and they survive staff turnover. Their weakness is latency and the effort of writing, and they are only as good as the discipline that keeps them current — a stale specification is worse than none, because it is trusted.

A healthy team uses all three and matches the channel to the message: geometry and released requirements go in channel 1, contested or ambiguous decisions in channel 2, and rationale, status and interfaces in channel 3. The classic dysfunction is to attempt everything in one — either a team that decides everything verbally and records nothing, or one that tries to resolve a genuine disagreement by exchanging documents.

Part B — Co-located versus globally distributed teams (6 marks)

The channels above do not merely become harder over distance; their relative weight changes, and the change is not symmetric across the three.

What is lost. Co-location supplies a large amount of unplanned, zero-cost communication — overheard conversations, a two-minute question at a desk, a glance at the prototype on the bench — and this informal channel carries far more of a co-located team’s coordination than anyone realises until it is removed. Distributing the team destroys it, and the loss shows up as small misalignments discovered late rather than as an obvious communication failure. Time-zone separation compounds it: a team spread across Vancouver, Frankfurt and Shanghai may have no overlapping working hours at all, so every clarification costs a full day of latency and a chain of three clarifications costs a week. Trust, which co-located teams build incidentally, has to be built deliberately, and language and cultural differences in how disagreement and uncertainty are expressed can hide a problem for weeks — in some working cultures a direct “this will not work” is not an acceptable thing to say to a customer team.

What has to replace it. The distributed team must shift its weight from channel 2 to channels 1 and 3, and must raise the fidelity of both. In practice: a single PLM instance that everyone works in, with adequate bandwidth and a resolved question of who owns which file; written decisions rather than remembered ones, so that the rationale that used to be tacit is now recorded; explicit interface control documents, because the interfaces that a co-located team negotiates informally are exactly what will drift apart at a distance; and a partitioning of the work that follows the modularity of the product. That last point is the strongest lever: Conway’s observation that an organisation ships its communication structure means that if the team boundaries are placed at the product’s clean modular interfaces, the amount of cross-site communication required drops by an order of magnitude, whereas a team split across a tightly integrated subsystem will fail no matter how good its tools are. Overlap windows are scheduled and treated as expensive; asynchronous video walkthroughs of a model substitute for standing at the bench; and digital prototypes, simulation and shared measurement data substitute for the physical prototype that only one site can hold.

What stays the same, and the residual. The formal channels — released drawings, specifications, gate reviews — work essentially as well at a distance, which is why they dominate distributed practice. But some things genuinely require presence, and the mature answer is to buy that presence rather than pretend it is unnecessary: co-locate the whole team physically for the kickoff and for the concept phase, when the architecture and the interfaces are being set and ambiguity is highest, and again at major gates and at the first builds, when a physical part has to be looked at and argued over. The compensating advantages of distribution — follow-the-sun development, access to specialist skills and to local supply chains and markets, and proximity to the manufacturing site — are real, which is why the practice persists; but they are bought with coordination cost, and the design of the communication system is what determines the price.

Part C — Passing information from design to manufacturing (3 marks)

The design-to-manufacturing handoff is the highest-risk information transfer in the whole programme, because the receiving team must reproduce the design exactly without having been present when its intent was formed. Five challenges recur.

Incompleteness and ambiguity of the definition. A drawing that omits a datum scheme, applies a blanket tolerance to a feature that has a functional one, or leaves surface condition and edge condition unstated forces manufacturing to guess, and it will guess in the direction that is easiest to make. The deeper version of the problem is that the intent behind a tolerance is almost never on the drawing: manufacturing cannot tell which dimensions are critical to function and which are convenience, so it cannot tell where to spend its process capability. Model-based definition with properly applied GD&T and an identified set of critical-to-function characteristics is the standard response.

Tacit knowledge that does not travel. The reasons behind the design — the failure that drove a radius, the assembly sequence the designer had in mind, the supplier whose process the geometry was drawn around — live in people, not in files, and an over-the-wall handoff loses all of it. Manufacturing then optimises against constraints it does not know exist and unknowingly removes something load-bearing.

Manufacturability assumptions made without capability data. Designers routinely specify tolerances that the intended process cannot hold, because the process capability is not visible to them. The mismatch surfaces as scrap at the ramp rather than as a review comment, and by then the tooling exists. The quantitative form of this challenge is that design works in tolerance bands and manufacturing works in $C_p$ and $C_{pk}$, and unless someone converts between the two the two groups never discover they disagree.

Timing, change churn and organisational incentives. Information passed too late leaves no time to influence the design, and information that keeps changing after tooling release causes rework, scrap and a collapse of trust in the release process. Underneath this sits a genuine misalignment of incentives: the design team is measured on schedule and function, manufacturing on yield and cost, and the handoff is where those two measures collide.

Distance, supplier and language boundaries. When manufacturing is a contract manufacturer on another continent, every problem above is amplified by time zone, by commercial boundaries that restrict what can be shared, and by the fact that questions cost days. The mitigation for all five is the same in kind and is worth stating explicitly, because it is what the marks are for: concurrent engineering. Put a manufacturing engineer and a key supplier on the design team from concept, run formal DFM reviews at each gate, transfer the definition as a model-based package rather than a pile of drawings, prove the process with pilot builds and a first-article inspection before the design is frozen, and treat the handoff as a continuous overlap rather than an event.