Question 6 of 7: Development Phases, Gate Decisions and Concurrent Engineering

Question 6: Development Phases, Gate Decisions and Concurrent Engineering (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 phases

1. Planning and opportunity identification. Market and technology assessment, portfolio fit, the product vision or mission statement, target market, business goals, key assumptions and constraints. The output is a charter, not a design.

2. Concept development. Customer needs are identified and ranked, target specifications set, the problem decomposed into functions, multiple concepts generated for each function and combined into whole-product concepts, then screened and scored against a datum. The output is a selected concept with a preliminary economic analysis and an established specification.

3. System-level design. Product architecture: the assignment of functions to physical chunks, definition of the interfaces between them, the geometric layout, and the make-or-buy and platform decisions. The final assembly scheme is set here, which is where the assembly content of Question 1 was decided.

4. Detail design. Complete specification of geometry, materials and tolerances for every part; selection of purchased components; process design and tooling design; the control documentation. This phase consumes the largest share of engineering hours and commits the smallest share of the remaining cost, because architecture already did that.

5. Testing, refinement and production ramp-up. Alpha prototypes built from production-intent materials to answer "does it work"; beta prototypes from production-intent processes to answer "does it satisfy the customer and can it be built"; regulatory and reliability qualification; then pilot production, operator training, and the ramp to full rate with early units often sold to preferred customers.

Part B — The decision after each phase, and the role of iteration

Each phase ends at a gate, and a gate is a decision to invest the next increment of money, not a review of the last one. The available decisions are go, kill, hold and recycle, and a gate that cannot kill is a formality. After planning the question is whether the opportunity justifies development resource at all; after concept development, whether the selected concept can meet the specification at the target cost; after system-level design, whether the architecture, make-or-buy and supplier choices are committed, since this gate releases tooling money; after detail design, whether the design is releasable for tooling and long-lead purchase; and after test and refinement, whether the product is qualified for launch and the supply chain is ready.

The standard quantitative gate criterion makes the decision explicit rather than political.

1. Apply the expected commercial value criterion at the concept gate. $$ECV=\left[(PV\cdot P_{cs})-C\right]P_{ts}-D$$ where $PV$ is the present value of the commercialised product, $P_{cs}$ the probability of commercial success given technical success, $C$ the launch and commercialisation cost, $P_{ts}$ the probability of technical success and $D$ the remaining development cost. With $PV=\text{CAD }14{,}000{,}000$, $P_{cs}=0.65$, $C=\text{CAD }3{,}200{,}000$, $P_{ts}=0.80$ and $D=\text{CAD }1{,}450{,}000$, $$ECV=\left[(14{,}000{,}000\times 0.65)-3{,}200{,}000\right]\times 0.80-1{,}450{,}000 =\boxed{\text{CAD }3{,}270{,}000}$$ Ranking projects by the productivity index $PI=ECV/D=2.255$ rather than by $ECV$ alone is what allocates a constrained development budget correctly, because it prices the scarce resource.
2. Quantify why iteration must happen early. Each design pass closes a fraction of the remaining gap between the design and its specification, so the residual after $k$ passes is $g_k=\rho^{k}$ and the number of passes needed to reach a target residual is $$k=\frac{\ln g_{target}}{\ln\rho}$$ At a realistic $\rho=0.58$, reaching a 4 per cent residual takes $k=\ln 0.04/\ln 0.58=5.91$, i.e. six passes. Six passes will happen whether they are planned or not. The only decision available is where they happen, and since the cost of a change rises about an order of magnitude per stage, six passes on paper and in cheap prototypes cost a small fraction of the same six passes discovered after tooling. Iteration does not save money by being avoided; it saves money by being moved earlier.

Part C — The impact of concurrent engineering on cost and timeline

Concurrent engineering overlaps phases that a sequential process would run end to end, and brings downstream functions into upstream decisions. Its cost benefit is the one already quantified: producibility, serviceability and compliance problems are found while they are cheap. Its schedule benefit is real but bounded, and the bound is the part worth showing, because overlapping is routinely oversold.

1. Model the overlap. If stage 2 starts $x$ weeks before stage 1 finishes, it begins work on information that is still provisional, and some of that work must be redone. A standard model for the total duration is $$T(x)=S_1+S_2-x+\frac{A\,x^{2}}{S_1}$$ where $S_1$ and $S_2$ are the stage durations and $A$ measures how sensitive the downstream stage is to upstream change. With $S_1=30$ weeks of design, $S_2=24$ weeks of process and tooling development and $A=0.9$, the sequential duration is $T(0)=54.0$ weeks. Differentiating and setting $dT/dx=0$, $$x^{*}=\frac{S_1}{2A}=\frac{30}{1.8}=16.67\ \text{weeks} \quad\Rightarrow\quad \boxed{T(x^{*})=45.67\ \text{weeks}}$$ a saving of 8.33 weeks, or 15.4 per cent.
2. Show that more overlap is not better. The rework term grows quadratically while the calendar saving grows linearly, so the curve turns. Overlapping to the feasible limit $x=S_2=24$ weeks gives $T(24)=47.28$ weeks — 1.61 weeks worse than the optimum, and at a burn rate of CAD 46,000 per week that is CAD 74,213 spent to finish later. The team looks maximally concurrent and is not.

Two further consequences of concurrency are worth stating. It raises the peak resource requirement and the cost of a late change, because more work is in flight when the change lands — concurrency trades money-at-risk for calendar. And it only works if the upstream stage releases information progressively and honestly, with the maturity of each released item stated; a design group that releases nothing until it is certain gives the downstream group nothing to overlap with, and one that releases everything as though it were final drives the rework coefficient A up until the optimum overlap collapses toward zero. Managing A — through interface freezes, staged release with maturity levels, and early supplier involvement — is worth more than pushing x.