NivaarExam PrepOfficial exam papers ↗

23-Mechatronics-B8 Product Design and Development · December 2019

Question 7 of 7: Stages of a Product Development Process

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

Notes on this paper

National Exams, 16-Mex-B8, Product Design and Development — December 2019, 3 hours, open-book examination (Casio or Sharp approved calculator only). Question 1 (40 marks) is mandatory; candidates choose 4 of the remaining 6 questions (15 marks each, only the first five questions as they appear in the answer book are marked, for a total of 100%). This is an essay/design-methodology paper with no numerical calculations. All seven questions are answered below for completeness.

Reference texts: Ulrich, Eppinger & Yang, Product Design and Development, 7th ed. (generic product-development process, concept generation and selection, Design for Manufacturing and Assembly, intellectual-property strategy); Government of Canada, Canadian Intellectual Property Office (CIPO), A Guide to Patents (Patent Act novelty/ utility/non-obviousness requirements, first-to-file rule, maintenance fees); Transport Canada, Motor Vehicle Safety Act and Canada Motor Vehicle Safety Standards (CMVSS).

The wording of Question 1 parts A, D and E is assumed from the sub-part labels. Question 1 is an open-ended design-process question (the paper states that following a defined design process matters more than the actual design), so it is answered as: pick a team; state objectives; propose competing solutions; select the best; write specifications. Question 5 parts B and C are answered from their stems, which are clear. Question 7's sub-parts are taken to be the text printed under Question 6 part C; see the check note on Question 7 for the reasoning.

Question 7: Stages of a Product Development 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.

A. Five distinct stages of a product development process

A generic product development process (Ulrich & Eppinger) can be described in five stages. (1) Concept development: customer needs are identified, competing concepts are generated and one is selected and tested against those needs. (2) System-level design: the product is decomposed into subsystems and components, a geometric layout and interfaces between them are defined, and a preliminary process plan for final assembly is established. (3) Detail design: complete specification of every part's geometry, material and tolerances is produced, tooling is specified, and the full bill of materials is finalized. (4) Testing and refinement: multiple pre-production prototype builds are tested against the performance, reliability and regulatory requirements, and the design is corrected based on the results. (5) Production ramp-up: the product is manufactured using the intended production process and workforce, remaining process issues are resolved, and the line is handed off to ongoing production.

B. Deciding when to move between stages

Movement between stages is governed by formal stage-gate reviews: at each gate, the stage's required deliverables (e.g. a selected and validated concept at the end of stage 1, a complete interface layout at the end of stage 2) are checked against pre-agreed exit criteria by a cross-functional review board, and only a positive go decision authorizes the program to commit resources to the next stage. This makes each transition a deliberate, accountable decision rather than an informal drift from one activity to the next.

C. Issues with starting multiple stages at once

Running stages concurrently (a form of concurrent engineering) trades schedule for risk. If an upstream stage's output changes after a downstream stage has already started work against it (e.g. system-level interfaces change after detail design has begun), the downstream work must be reworked, which can cost more time than was saved by overlapping the stages in the first place. It also creates resource contention, since the same specialist engineers are often needed by more than one concurrent stage, and it increases coordination overhead and makes it harder to trace the root cause of a problem back to a single originating decision, since several stages' outputs are now interacting before any one of them was fully validated.

D. Managing an iterative approach within a staged process

The two are not mutually exclusive: a staged process can deliberately overlap adjacent stages (concurrent/spiral development) provided the overlap is managed rather than accidental. In practice this means capping concurrency to interfaces with genuinely low change risk, maintaining a single live requirements/interface baseline under change control so any change is immediately visible to every stage working against it, running short, frequent cross-functional review cycles (rather than waiting for the next full stage gate) so a downstream team is not surprised by an upstream change, and using rapid, low-cost prototyping to validate risky assumptions as early as possible — before the more expensive downstream stages have committed resources against them.

Back to the paper →