22-Mec-B5 Product Design and Development · May 2013
Nivaar worked solution (AI-drafted; not reviewed by a licensed engineer)
Paper format. National Exams, May 2013 — 07-Mec-B5, Product Design & Development. Three hours; open book; no calculator permitted. Question 1 is compulsory and carries 40 % of the paper; four of the remaining six questions are chosen, each worth 15 %, for 100 % 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 essay answer 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 each 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.
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, materials and process-selection material; Pahl & Beitz, Engineering Design: A Systematic Approach (Springer) for systematic concept generation and the function structure; Boothroyd, Dewhurst & Knight, Product Design for Manufacture and Assembly (CRC) for the design-for-assembly and design-for-manufacture rules; Ashby, Materials Selection in Mechanical Design (Butterworth-Heinemann) and Kalpakjian & Schmid, Manufacturing Engineering and Technology (Pearson) for the process-selection charts and cost models. Canadian context is taken from the Patent Act, Industrial Design Act, Trademarks Act and Copyright Act (Canadian Intellectual Property Office), from CSA standards (notably CSA B651 Accessible design for the built environment), from the Canada Consumer Product Safety Act, and from Engineers Canada / EGBC guidance on professional practice and on equity, diversity and inclusion in the profession.
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.
The two processes differ in what is given, what is decided, where the risk sits, and therefore in the shape of the gates.
What is given at the start. A new product begins with an opportunity and a mission statement: the market, the assumptions and the constraints are proposed, not known, and the first substantial deliverable is the specification itself, derived by the needs research described in question 1. A refinement begins with a product that already exists, so the specification, the architecture, the supply base, the tooling and the field-performance record are all inherited. The refinement's first deliverable is not a specification but a problem statement: which specific metric is to move, by how much, and what may not change while it moves.
What is actually decided. In new product development the product architecture — the mapping of functions onto physical elements and the definition of their interfaces — is the central decision, and it is made once, early, on the worst information the project will ever have. In refinement the architecture is a constraint rather than a decision: the work is confined inside existing interfaces, and the discipline is to establish exactly which interfaces the change touches. This is why a refinement's risk is almost never in the changed part itself but in an unintended interaction with a part nobody thought was affected.
The sequence of activity. A new product runs the full generic process: planning, concept development, system-level design, detail design, testing and refinement, production ramp-up, with a formal gate between each phase and with prototypes of decreasing crudeness supporting each gate. A refinement runs a much shorter loop, usually a formal engineering change process: change request, impact assessment across design, manufacturing, service and regulatory, a delta analysis of the failure modes rather than a fresh design failure mode and effects analysis, targeted validation of the change, regression testing of the functions that must not have moved, then release with a controlled cut-in point and disposition of the parts already in the pipeline. The last item has no equivalent in a new product and is often the most operationally difficult part of the job.
Where the uncertainty and the iteration live. New product development is dominated by front-end uncertainty: the number of unknowns is largest before anything is drawn, iteration is expected, and the correct response to a failed prototype is usually to learn from it. Refinement is dominated by back-end constraint: the unknowns are few and specific, iteration is expensive because it churns released documentation and tooling, and the correct response to a surprise is to stop and re-assess the change's scope. The economics run the same way — a new product commits capital in tooling and validation against an unproven forecast, while a refinement is judged on payback against a known volume, so its business case is arithmetic rather than argument.
Validation and evidence. A new product must demonstrate every requirement from first principles, including the ones no competitor has ever failed. A refinement must demonstrate two things instead: that the changed requirement is now met, and that nothing else has regressed — and the second of these is where refinements fail, because the regression set is defined by judgement about what the change could have touched. A written interface analysis is the mechanism that turns that judgement into something reviewable.
The new product team is a heavyweight, dedicated, cross-functional team. Its members are assigned to the project rather than lent to it, and its leader carries real authority over resources and content rather than a coordinating role, because the decisions being made cut across every function at once. The composition follows the work: a systems or architecture engineer who owns the interfaces; an industrial designer and a human-factors specialist, since the user interface is being invented; design engineers with analysis capability; a materials engineer; a manufacturing engineer brought in during concept development and not later, because design for manufacture is decided by architecture; a prototype and test engineer; a market researcher who runs the needs work; a cost engineer; and, at the points where they matter, regulatory and intellectual-property specialists. The skills that distinguish this team are tolerance of ambiguity, breadth over depth — the T-shaped engineer who can work across two or three disciplines — concept-generation and sketching ability, and the willingness to discard work, which is emotionally harder than it sounds. Co-location, or a deliberate substitute for it, matters more here than anywhere else because the interfaces between people mirror the interfaces between subsystems.
The refinement team is a lightweight, part-time, specialist team. It is normally led by a change owner or project coordinator who drives a defined scope through a functional organisation rather than commanding a dedicated group. Its centre of gravity is deep component and process expertise: the engineer who knows that part, a manufacturing or process engineer who owns the line and the tooling, a quality engineer fluent in statistical process control and in reading warranty and field-return data, a supplier engineer, a test engineer for regression, a service and field-support representative who knows what fails in practice, and — unglamorous but decisive — a configuration management and document control function that keeps drawing revisions, bills of material, service parts and effectivity dates consistent. The distinguishing skills are analytical rather than generative: structured root-cause analysis such as eight-discipline problem solving and fishbone analysis, design of experiments, tolerance stack-up analysis, value engineering and cost teardown, and the disciplined use of the change-control system.
Sizing, duration and decision rights differ accordingly. The new product team is larger, runs for a year or more, and needs authority to change the specification when the evidence demands it. The refinement team is small, runs for weeks to a few months, and needs authority to refuse scope growth — the classic failure mode of a refinement project is a change that quietly accumulates neighbouring improvements until it has all the risk of a new product and none of its validation budget.
