22-Mec-B5 Product Design and Development · May 2014
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
National Exams, May 2014 — 07-Mec-B5 Product Design and Development. Three hours. Open book; no calculator permitted. Question 1 must be completed and is worth 40 marks; four of the six remaining questions are chosen, each worth 15 marks, for 100 marks in total. Only the first five questions as they appear in the answer book are marked, and the paper states that most answers are expected in essay form or as tables, figures and charts, with clarity and organisation carrying weight.
The paper prints 40 + 6 × 15 = 130 marks and a candidate attempts 40 + 4 × 15 = 100 of them. All seven questions are answered below, because this set is a study resource rather than an examination script. The arithmetic that appears is deliberately light — no calculator is allowed.
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.
Challenge 1: asynchronous decision making. With sites eight to thirteen hours apart there is little or no overlapping working day, so most communication is a message rather than a conversation. The damaging consequence is not slow email; it is that decisions get taken while the people who would have challenged them are asleep. A question that would have been settled in ninety seconds at a desk instead costs a full day of round trip, and the pressure to keep moving means the site holding the model simply decides. Over a programme this produces a design that no one site would have chosen and that no one site feels accountable for.
Challenge 2: loss of tacit knowledge and context. Explicit knowledge — the model, the drawing, the test report — transfers perfectly. Tacit knowledge does not: the reason a wall thickness is 3.2 mm rather than 3.0, the supplier whose process cannot hold that tolerance, the warranty claim from two programmes ago that everyone at one site remembers and no one at another has heard of. Language and professional-culture differences compound it, because the same words carry different force — a reviewer who says a design is "interesting" may mean it is unacceptable, and directness norms differ enough between sites that a serious objection can be raised and not received.
Challenge 3: configuration and data integrity. Multiple sites working on one product across different tools, part-numbering conventions and network latencies produce the classic failures: two sites editing the same part from different baselines, an interface changed by one team and not communicated to the team on the other side of it, large assemblies that take hours to replicate, and a genuine legal layer — export control, customer confidentiality and differing intellectual-property regimes — that restricts what may be shared with whom.
Positively, distribution is not merely a cost strategy and should not be defended as one. Genuine round-the-clock progress is available on any task that decomposes cleanly, which shortens the critical path on detailing, analysis and drawing release. Access to deep specialist skill wherever it exists raises the technical ceiling. Design-in-region gives a product that suits its markets, catching duty cycles, regulations and user expectations that a single-site team would have got wrong, and proximity to the manufacturing site produces designs that are genuinely easier to make. The forced discipline of written communication is itself a benefit: a team that must write down its reasoning leaves a far better decision record than a co-located team that settles everything verbally.
Negatively, the same structure produces a design that reflects the organisation rather than the problem. Conway's observation applies directly: the product architecture drifts toward the communication structure, so interfaces between subsystems owned by different sites become over-specified, conservative and hard to change, while integration problems — tolerance stacks, thermal interactions, wiring routes — surface late because no one owns them. Duplicated and divergent work, slower iteration on anything genuinely coupled, and weaker shared ownership of the whole all follow, and they show up as changes late in the programme, which is where changes are most expensive.
Partition the work along the architecture, not the org chart. Give each site a whole subsystem with a clean, stable, documented interface, so that most of what a site does needs no cross-site conversation. This single decision removes more coordination load than every communication tool combined.
Freeze interfaces early and manage them formally. An interface control document per boundary, with a named owner on each side and a change process that cannot be bypassed, is what stops the late integration failures.
Run one master model under one PDM/PLM system, with check-in/check-out, a single part-numbering scheme, and a nightly build of the full assembly that everyone sees the next morning. Integrity problems become visible within a day instead of at first prototype.
Buy back some overlap and some face time. Fix a daily one-hour window in which every site is at work and rotate its inconvenience fairly rather than always imposing it on the same time zone; hold a short structured handoff at each site's end of day recording what changed, what is open and what the next site must not touch. Bring the team together physically at programme start and at each major integration milestone — this is where the tacit knowledge transfers, and it is the cheapest risk reduction on the programme.
Make the tacit explicit as a deliverable. Design rationale captured beside the model, not in someone's head; a lessons-learned database that is actually consulted; and model-based definition so that tolerances and process notes travel with the geometry rather than in a separate drawing a distant site may not have.
