Question 7 of 7: Stages of a Product Development Process, Gate Decisions, Concurrency and Iteration

Question 7: Stages of a Product Development Process, Gate Decisions, Concurrency and Iteration (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 — Five distinct stages of a product development process. The five below follow the generic process of Ulrich and Eppinger. What makes them distinct is not that different people do them but that each ends with a different kind of commitment, and each retires a different kind of uncertainty.

1. Concept development. The needs of the target market are identified, alternative product concepts are generated and evaluated, and one or more are selected for further development. The output is a concept — a description of the form, function and features of the product, usually with a set of specifications, a competitive analysis and an economic justification. This stage retires market and functional uncertainty and is by far the cheapest place to change direction, because almost nothing has been committed.
2. System-level design. The product architecture is defined: the decomposition into subsystems and components, the assignment of function to physical chunks, and the definition of the interfaces between them. The output is a geometric layout, a functional specification of each subsystem, and a preliminary process flow diagram for final assembly. This stage retires architectural uncertainty and is where the great majority of lifetime cost is committed, which is why it deserves more time than it usually gets.
3. Detail design. The complete specification of geometry, materials and tolerances for every part, the identification of purchased parts, and the establishment of the process plan and tooling design. The output is the control documentation: drawings or CAD models, part specifications, and the process plans for fabrication and assembly. This stage retires producibility uncertainty.
4. Testing and refinement. Construction and evaluation of pre-production versions of the product — early alpha prototypes built from production-intent parts but not necessarily production processes, then beta prototypes built with production processes and tested by customers in their own environment. Regulatory certification and reliability demonstration happen here. This stage retires performance and reliability uncertainty.
5. Production ramp-up. The product is made using the intended production system, so that the workforce can be trained and remaining process problems resolved. Output transitions gradually to ongoing production and the product is launched. This stage retires process capability and supply uncertainty.

A planning phase precedes all five and is worth naming, because it is where the project is authorised, the technology is assessed and the platform strategy is set; and a post-launch review follows them, where the process itself is improved.

Part B — The decision process for moving between stages

The transition between stages is a gate, and a gate is a management decision to invest the next tranche of money, not an engineering milestone. It has three components: a set of deliverables the project must present, a set of criteria against which they are judged, and an output that is one of go, kill, hold or recycle. Two properties matter. The criteria must be defined in advance and be the same for every project, or the gate becomes a negotiation. And “kill” must be a live possibility — a gate that has never killed a project is a status meeting.

The criteria fall into two classes. Must-meet criteria are absolute and are checked first: strategic fit, technical feasibility, regulatory viability, and a positive business case. Failing any one ends the project regardless of the others. Should-meet criteria are scored and weighted: market attractiveness, competitive advantage, synergy with existing capability, and risk. A project can be weak on one and strong on another.

Making the gate decision quantitative. Given. At the gate between detail design and testing, a project with an expected present value of commercialised revenue of CAD 46 M; a probability of commercial success once launched of 0.80; a launch and commercialisation cost of CAD 12 M; a probability of technical success of 0.65; and CAD 5.5 M of development spend remaining. Find. The expected commercial value of continuing and the productivity index used to rank it against competing projects.

1. Roll the decision tree back to the gate. The expected commercial value discounts the payoff by both probabilities and subtracts the costs at the points they are incurred, $$\text{ECV}=\left[(PV\times P_{cs})-C\right]P_{ts}-D$$ $$\text{ECV}=\left[(46.0\times0.80)-12.0\right]\times0.65-5.5 =\left[36.8-12.0\right]\times0.65-5.5=\boxed{\text{CAD }10.62\ \text{M}}$$ The value is positive, so on this criterion the project passes.
2. Rank it against the other projects competing for the same engineers. Because development capacity, not money, is usually the binding constraint, projects are ranked by the productivity index — value created per unit of the constrained resource, $$\text{PI}=\frac{\text{ECV}}{D}=\frac{10.62}{5.5}=1.93$$ A project with a positive ECV can still fail its gate if its productivity index is below that of the projects it would displace, and stating the decision this way is what stops a portfolio filling up with individually-justifiable projects that collectively starve each other of people.

Part C — Issues with starting multiple development stages at once

Overlapping stages — concurrent or simultaneous engineering — is often presented as a free schedule saving. It is not free, and the cost has a definite shape.

Given. Stage 1 (system-level design) takes 20 weeks and stage 2 (detail design) 16 weeks, so sequential execution takes 36 weeks. Downstream work begun before the upstream information is final is invalidated in proportion to how much of the upstream stage remains, and reworking it costs an amplification factor of 1.5 times the work affected. Find. The overlap that minimises total duration, and the overlap beyond which concurrency is counter-productive.

1. Model the expected duration. With an overlap $x$, the probability that downstream work is invalidated is $x/S_1$, the downstream work at risk is $x$, and the rework costs $A$ times that, so $$T(x)=S_1+S_2-x+\frac{A\,x^{2}}{S_1} =36-x+\frac{1.5\,x^{2}}{20}=36-x+0.075\,x^{2}$$
2. Find the optimum. Setting $\mathrm{d}T/\mathrm{d}x=0$ gives $-1+0.15x=0$, so $$\begin{aligned} x^{*}&=\frac{S_1}{2A}=\frac{20}{2\times1.5}=6.7\ \text{weeks} \\ T(x^{*})&=\boxed{32.7\ \text{weeks}} \end{aligned}$$ a saving of 3.3 weeks, or 9 % — real, but far less than the 6.7 weeks of overlap naively promises, because rework has eaten half of it.
3. Find where concurrency starts costing time. $T(x)=36$ again at $$x=\frac{S_1}{A}=\frac{20}{1.5}=13.3\ \text{weeks},$$ and at a 16-week overlap $T(16)=39.2$ weeks — 3.2 weeks worse than running the two stages strictly in sequence. This is the result that matters and the one that intuition gets wrong: aggressive concurrency does not merely reduce the saving, it reverses it.

Beyond the duration arithmetic, five further issues attach to running stages in parallel, and each is a reason to overlap deliberately rather than by default. Rework and scrap — tooling cut to a geometry that then changes is scrapped, and tooling is the most expensive thing on the programme to redo. Resource contention — the same senior engineers are needed by both stages at once, so the nominal parallelism is not achieved and both stages slow. Premature commitment — starting detail design forces the architecture to be frozen before its alternatives have been properly evaluated, which is the most expensive kind of mistake because it is architectural. Coordination overhead — communication links grow as $n(n-1)/2$ in the number of interacting groups, so the meeting load grows quadratically while the work grows linearly. And quality erosion under compressed verification — when the schedule tightens it is testing, not design, that gets compressed, and defects escape to the customer.

The conditions under which overlap is justified follow directly from the model: overlap where the upstream information evolves quickly to a stable value (so the effective $x/S_1$ risk is small), where the downstream stage is insensitive to the remaining upstream uncertainty (small $A$), and where the upstream team can release preliminary information with an explicit confidence label rather than a single frozen answer. Overlapping a stable interface is nearly free; overlapping a volatile one is how programmes lose a year.

Part D — Managing an iterative approach within a stage-gate process

The apparent contradiction — stages imply a single forward pass, iteration implies going back — dissolves once the two are placed at different scales. Iterate rapidly and freely inside a stage; move forward only through gates. The stage boundary is where the organisation makes an irreversible commitment; everything before it is deliberately reversible and should be revised as often as learning permits.

Quantifying how much iteration is needed. Given. Each design iteration closes a fixed fraction of the remaining gap between the current design and its requirement, with a convergence ratio $\rho=0.50$ per pass; the design is acceptable when the residual gap falls below 3 % of the original. Find. The number of iterations to plan for.

1. Model the convergence and invert it. The residual gap after $k$ passes is $g_k=\rho^{k}$, so the required number of passes is $$k=\frac{\ln g_{\text{target}}}{\ln\rho}=\frac{\ln 0.03}{\ln 0.50}=5.06 \;\Longrightarrow\;\boxed{6\ \text{iterations}}$$ Six analysis-and-revise cycles must be planned and resourced inside the stage. A plan that allows one pass is not a plan for a design, it is a plan for a first attempt, and the six cycles will happen anyway — but as unplanned overruns rather than as budgeted work.
2. Iterate where iteration is cheap. Because the cost of a change rises by roughly an order of magnitude per stage, six iterations in the concept stage cost about what one iteration costs in detail design and about a thousandth of what one costs at production tooling. The management instruction that follows is unambiguous: front-load the iteration, using analysis, simulation and cheap physical models, and arrive at the gate with the convergence already achieved rather than promised.

The management practices that make this work. Six, in the order they should be put in place:

1. Plan the iterations explicitly in the schedule. Name the analysis-build-test-revise loops, resource them, and give each a convergence criterion. An iteration that is not in the plan is an overrun by definition.
2. Make gates conditional rather than binary where the risk is containable. A conditional pass — proceed, with named open items and agreed closure dates — keeps momentum without pretending the work is finished, provided the conditions are tracked and the next gate refuses to open until they are closed.
3. Use set-based rather than point-based design early. Carry several feasible alternatives through the early stages and narrow the set as information arrives, instead of choosing one candidate immediately and iterating on it. This converts iteration from rework into scheduled elimination, and it is the core of the Toyota-style development method.
4. Attack the loop time, not only the loop count. The cost of iteration is (number of loops) times (cost per loop); simulation, rapid prototyping and automated test harnesses cut the second factor by an order of magnitude and are usually the cheapest available improvement to a development process.
5. Freeze progressively rather than all at once. Freeze interfaces first, then architecture, then geometry, then tolerances. This lets downstream work start against a stable interface while the detail behind it is still iterating, which is precisely the low-risk overlap that part C's model rewards.
6. Define what closes an iteration loop. Every loop ends with a recorded decision, a measured convergence and an updated baseline. Loops that end without a decision do not converge; they simply reopen at the next meeting, and that is the failure mode that makes iteration look like indiscipline.