Question 6 of 7: Communicating Design Information Within a Team

Question 6: Communicating Design Information Within a Team (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

Design information is not one kind of thing, and the three channels below are chosen because they carry different kinds and fail in different ways. A team that uses only one of them will reliably lose the kinds the other two carry.

1. The controlled technical data package — the formal, asynchronous, authoritative channel. Drawings, 3-D models, bills of material, specifications, interface control documents and test reports, all at a released revision under change control. This channel carries decided information. Its virtues are that it is unambiguous, auditable, legally significant and independent of who is available; a released drawing means the same thing to a supplier in Guangzhou at three in the morning as it does to the designer. Its limitation is that it carries only conclusions, never reasoning, and it is slow: a change must go through review and release before it can be communicated at all. Used alone, it produces teams in which everyone knows what was decided and nobody knows why, so the same rejected option is re-proposed every six months.

2. Structured synchronous review — the deliberative channel. Design reviews at defined gates, cross-functional working sessions, and the daily or weekly stand-up. This channel carries judgement under uncertainty: trade-offs, risks, the reasons an option was rejected, and disagreements that need resolving before they harden into rework. It works because it is interactive — a misunderstanding is detected and corrected in seconds rather than in a revision cycle — and because it forces a decision to be made in front of everyone affected by it. Its limitation is that it is expensive in the scarcest resource a programme has, senior attention, and that it evaporates unless the decisions and their rationale are written down; an undocumented design review is a meeting, not a channel.

3. Physical and visual artefacts — the shared-understanding channel. Sketches, renderings, exploded views, mock-ups, appearance models, functional prototypes and the project visual-management board. This channel carries tacit and spatial information that neither of the others can encode: how big the product actually feels, whether the grip is comfortable, whether an assembly sequence is physically awkward, whether two people mean the same thing by "compact". A five-dollar foam model settles arguments that a hundred pages of specification cannot, because it is interpreted identically by the industrial designer, the process engineer, the marketer and the user in the trial. Its limitation is that it is imprecise and uncontrolled — a prototype is never the design of record — so it must feed the formal channel rather than replace it.

Part B — What changes when the team is distributed around the world

Two of the three channels survive distribution almost unchanged, and the two that do not are the two that carry the most valuable information. The formal data package is unaffected: it was already asynchronous and it travels perfectly. Synchronous review and physical artefacts are both badly damaged, and the damage is quantifiable.

Given. A design team split across Vancouver (UTC−8), Munich (UTC+1) and Bangalore (UTC+5:30), each working 09:00 to 17:00 local time. Find. The synchronous overlap available to the team.

1. Map every working day onto one UTC axis. Vancouver 09:00–17:00 is 17:00–01:00 UTC, Munich is 08:00–16:00 UTC, and Bangalore is 03:30–11:30 UTC. Intersecting the pairs gives Munich with Bangalore $08{:}00$ to $11{:}30$ UTC, that is 3.5 h; Vancouver with Munich, zero; Vancouver with Bangalore, zero. The three-way intersection is therefore $\boxed{0\ \text{hours}}$ — there is no moment in the week when all three sites are at work.
2. Test whether extending the working day rescues it. Widening every site to 08:00–18:00 local buys Vancouver and Munich exactly 1 h of overlap and Munich and Bangalore 5.5 h, but the three-way intersection remains $\boxed{0\ \text{hours}}$. The conclusion is structural rather than a scheduling nuisance: a whole-team synchronous meeting is impossible without somebody working outside their day, permanently.

Three practical consequences follow, and they are what the marks are for. The default must invert from synchronous to asynchronous. If a decision needs three exchanges and each exchange costs a working day of latency, the decision takes three days instead of the thirty minutes it would take around one table — so distributed teams must write more, decide in writing, and record rationale in the artefact rather than in the meeting. The rotating burden must be shared explicitly. Where a synchronous meeting is genuinely necessary, the out-of-hours slot should rotate between sites rather than falling permanently on the smallest or most junior one, which is a professional fairness issue as much as an efficiency one. And work should be partitioned along interfaces rather than along tasks. Give each site a whole subsystem with a controlled interface, so most coordination happens inside a single time zone and only interface changes need to cross one — the organisational restatement of the modular-architecture principle.

The loss of physical artefacts is the harder problem, because a prototype cannot be emailed. The partial substitutes are shared 3-D models with markup and measurement, high-quality photogrammetry or scans of physical mock-ups, video of a prototype being handled by a real user rather than a static rendering, and duplicated hardware — deliberately building two of every prototype and shipping one. Duplicating prototypes looks wasteful on a budget line and is almost always cheaper than the design error it prevents.

Underlying all of this is why the problem grows so quickly with team size. The number of pairwise channels that must be kept consistent is $n(n-1)/2$, so a team of 6 has 15 links and a team of 12 has 66 — 4.4 times as many for twice the people. Distribution multiplies the cost of every one of those links, which is why the answer to a struggling distributed programme is almost never "more meetings" and almost always "fewer, better-defined interfaces".

Part C — Three tools that enable the communication process

1. Product data management or product lifecycle management (PDM/PLM). A single controlled repository holding the CAD models, drawings, bills of material, specifications and their revision history, with check-in and check-out, access control, workflow-driven release and engineering-change management. It is the enabling tool for the formal channel of Part A, and it is what makes a distributed team possible at all: it guarantees that every site is working from the same released revision, it records who approved what and when, and it propagates a change notice to everyone affected rather than to everyone the author remembered. Without it, the failure mode is not miscommunication but silent divergence — two sites detailing against different revisions of the same interface and discovering it at first assembly.

2. Model-based collaboration and design-review tools. Lightweight viewers and web-based model review that let a distributed team open the same 3-D model, section it, measure it, mark it up and attach comments to specific features, together with screen sharing and recorded sessions. These recover part of what the synchronous and visual channels lose to distribution: the discussion attaches to the geometry rather than to a meeting, so it survives the meeting and is available to the site that was asleep. Recording the session, and attaching the recording and the resulting decision to the model in the PLM system, is what converts a synchronous event into an asynchronous artefact — the single highest-value habit a distributed design team can adopt.

3. Structured requirement and issue tracking. A requirements-management or issue-tracking system in which every requirement and every open problem is a numbered item with an owner, a status, a due date, a verification method and a link to the evidence that closed it. This is the tool that carries accountability across time zones without a meeting. It also produces the coverage metric used in Question 5 — 61 of 68 requirements verified at design freeze — which is only meaningful because every requirement is a tracked item rather than a sentence in a document. Its complement on the shop floor is visual management: a physical or electronic board showing status, blockers and the day’s priorities, so that the same information reaches an operator who does not use the engineering tool chain.