NivaarExam PrepOfficial exam papers ↗

22-Mec-B5 Product Design and Development · December 2013

Question 5 of 7: Challenges that Limit the Design Process

Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)

Notes on this paper

Paper format. National Exams, December 2013 — 07-Mec-B5, Product Design and Development. Three hours; open book; no calculator is permitted. Question 1 is compulsory and carries 40 marks; four of the remaining six questions are chosen, each worth 15 marks, for 100 marks in total, and only the first five questions appearing in the answer book are marked. Note 5 of the paper states that most questions require an answer in essay format or the use of tables, figures and charts, and that clarity and organisation of the answer carry marks; Note 1 invites the candidate to state any assumption made where a question is open to interpretation, and that licence is used several times below with every use flagged. All seven printed questions are worked here — 130 marks of material against the 100 marks a candidate would actually attempt — so that the set serves as a complete study resource. Because no calculator is allowed, every figure quoted below is one a candidate could reach by hand or by slide-rule-grade estimation; the arithmetic is nonetheless.

Reference texts. Ulrich & Eppinger, Product Design and Development (McGraw-Hill) — the framework text for this exam code and the source of the generic development process, the needs-to-metrics translation, concept screening and concept scoring used throughout; Dieter & Schmidt, Engineering Design (McGraw-Hill) for the specification, problem-definition and materials/process-selection material; Pahl & Beitz, Engineering Design: A Systematic Approach (Springer) for the function structure and systematic concept generation; Boothroyd, Dewhurst & Knight, Product Design for Manufacture and Assembly (CRC) for the DFMA rules and the design-for-assembly index; Ashby, Materials Selection in Mechanical Design (Butterworth-Heinemann) and Kalpakjian & Schmid, Manufacturing Engineering and Technology (Pearson) for the process-selection charts and unit-cost models; Cross, Engineering Design Methods (Wiley) for the design-versus-art material. Canadian context is taken from CSA B651 Accessible design for the built environment and CSA/ISO 21542, the Accessible Canada Act (2019) and provincial accessibility statutes, the Canada Consumer Product Safety Act, the Canadian Environmental Protection Act and its prohibited-substances regulations, ISO 4210-8 (cycle pedal and drive-system testing) as adopted in Canada, and Engineers Canada / EGBC guidance on professional practice.

Question 5: Challenges that Limit the Design Process (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.

Note on the question as printed: part B refers to "each challenge listed in part B", which is evidently a typographical slip for part A. It is answered here as ways of overcoming the three challenges identified in part A, which is the only reading that makes the question coherent — exactly the situation Note 1 of the paper invites a candidate to flag.

Part A — Three challenges that limit the design process (6 marks)

(1) Ill-defined, incomplete and shifting requirements. Design almost never begins with a specification; it begins with a wish expressed by someone who is not an engineer, and the real requirements emerge only as the design develops and stakeholders react to what they see. Worse, the requirement set moves: marketing adds a feature, a regulation changes, a competitor launches. The practical effect is scope creep, rework, and a design frozen against a target that has since moved. This is the single most common cause of programme overrun, and it is structural rather than a failure of diligence — the problem genuinely is not fully knowable at the outset.

(2) The tension between constraints — cost, time, resources — and the escalating cost of late change. Design decisions commit cost long before they spend it: by the end of concept design the great majority of the lifecycle cost of a product has been determined, while only a small percentage has been disbursed. The corresponding cost of changing a decision rises by roughly an order of magnitude at each phase boundary — a change that costs one unit in concept costs ten in detail design, a hundred after tooling and a thousand after launch. Designers therefore face the worst possible information profile: the decisions with the greatest leverage must be made when the least is known. Add finite budgets, short schedules and scarce specialist skills, and the result is that alternatives go unexplored simply because there was no time.

(3) Cognitive and organisational limits: design fixation, bias, and communication across boundaries. Designers shown an example solution reliably reproduce its features, including its flaws, and are measurably less able to generate genuinely different concepts — the fixation effect. Alongside it sit anchoring on the first estimate, confirmation bias in interpreting test results, and sunk-cost commitment to a concept the team has already invested in. Organisationally, the same limits appear as siloed functions: design releases to manufacturing, manufacturing objects, and both discover that the requirement they were arguing about was never written down. Tacit knowledge stays in the heads of experienced staff and is lost on retirement.

Part B — Overcoming each challenge (6 marks)

Against ill-defined and shifting requirements: invest in the front end rather than resenting it. Conduct structured needs identification with real users in their own context; write the specification as measurable metrics with marginal and ideal values rather than as adjectives; weight the needs so that when a conflict arises there is a prior agreement about what yields; establish a requirements baseline under formal change control, so that requirements may change but only visibly and with their cost attached; and use rapid, low-fidelity prototypes deliberately as requirement-elicitation instruments, because stakeholders can criticise an artefact far more accurately than they can specify one. Where volatility is genuinely irreducible, choose a modular product architecture so that the volatile function is confined to one module and can be changed without disturbing the rest.

Against constraint pressure and the cost of late change: move the knowledge earlier rather than moving the decision later. Concurrent engineering puts manufacturing, procurement, service and regulatory expertise in the room during concept design; set-based design carries two or three alternatives further than feels comfortable and converges only as the evidence arrives, which is cheaper than committing early and reversing; stage-gate reviews with real exit criteria stop a weak concept before it consumes the tooling budget; targeted analysis and simulation buy information cheaply at the point where information is most valuable; and design-to-cost with a hard target, decomposed into per-subsystem cost budgets, keeps cost a design variable rather than an outcome. Reusing qualified platforms, modules and standard parts spends the scarce engineering time where the product is actually differentiated.

Against cognitive and organisational limits: use structured ideation that is designed to defeat fixation — generate concepts individually before the group meets so that nobody anchors the room, use a function structure to force decomposition into sub-functions and search for solutions to each, use morphological analysis and systematic combination, seek analogies from distant domains, and set an explicit quota of alternatives before any evaluation begins. Use the datum-based screening of Question 1 so that concepts are judged against a fixed reference and against pre-agreed weights rather than against each other in an argument. Bring in outsiders for design review. Against the organisational half, use cross-functional teams with co-location or its virtual equivalent, a single shared product data source, and disciplined capture of rationale — recording why a decision was made is what makes the decision revisable when circumstances change.

Part C — How technology has helped (3 marks)

Technology has attacked all three challenges, though unevenly. Against requirement volatility, requirements-management and product-lifecycle-management systems give traceability from a stated need through a specification to a verification test, so that the effect of a changed requirement can be found rather than guessed; and rapid prototyping, particularly additive manufacturing, has collapsed the cost of putting a physical artefact in front of a stakeholder from weeks and thousands of dollars to hours and tens of dollars, which turns requirement elicitation into something that can be done repeatedly instead of once. Against the cost of late change, simulation is the decisive development: finite element, computational fluid dynamics, mould-flow, tolerance and system simulation move information forward in the schedule, so that the decisions with the greatest leverage are made with far better knowledge than was once possible, and digital mock-up removes an entire class of interference and access problems before any hardware exists. Against cognitive and organisational limits, shared cloud-based model environments and version-controlled product data have largely eliminated the "which drawing is current" failure; visualisation, virtual reality review and digital twins let non-specialists participate meaningfully in review; and generative design and topology optimisation directly attack fixation by proposing geometries no human would have drawn.

Two qualifications are worth stating. Technology has not removed the underlying difficulty — requirements are still ill-defined, leverage still precedes knowledge, and people are still subject to bias; it has raised the level at which those problems are met. And each tool introduces its own failure mode, from unvalidated simulation to information overload to a false sense of completeness from a photorealistic render of a design that has never been tested. The engineering judgement that decides when to believe a tool is precisely what has not been automated.