5 Whys / Issue Tree

Write the root as one measurable question

Do not start with "why did the MAX fail" — that inherits every ambiguity below it. Frame it as: why did a derivative aircraft certified as safe suffer two fatal loss-of-control events with the same activation signature within five months of entry into heavy service? Notice what the framing forces: "same signature, two operators, two continents" is already a data point, not a symptom. Also clarify the real objective with the client — the question is not "who was at fault on the flight deck" but "what inside Boeing's control has to change so this cannot recur," which is the difference between an inquiry and a recommendation.

Split Level 1 with a process split, not adjectives

There is no revenue equation here, so use the process split the guide recommends: any accident is caused in the design layer, in the safeguard layer, or in the operating layer. Design covers aerodynamics, control laws and sensor architecture. Safeguards cover the certification route, the hazard assessment, the flight manual and the training requirement — everything that is supposed to catch a design hazard before it flies. Operations covers airline maintenance and crew response. Three branches, mutually exclusive, and collectively they cover every path from drawing board to impact — no fourth box needed, and resisting the temptation to add a "culture" branch is what keeps the tree testable rather than rhetorical.

Test with data and kill a branch out loud

Take the operating branch first because it is the one the public had already convicted. Two different airlines, on two continents, with different maintenance organisations and different crew training regimes, produced the same failure sequence five months apart — a repeated common-mode failure across independent operators cannot have an operator-specific root cause. Maintenance of the angle-of-attack vane and crew response were contributing factors and belong in the recommendation, but they cannot be the root. Say it aloud: "I am setting the operator branch aside as a contributor, not a cause; the common factor sits in design or safeguards." That single sentence is worth more in an interview than ten more boxes.

Switch to 5 Whys on the surviving branch

Why did the nose repeatedly pitch down? Because MCAS commanded nose-down stabiliser trim, repeatedly. Why did MCAS command trim when the aircraft was not stalling? Because it took its input from a single angle-of-attack vane, that vane was giving an erroneous reading, and there was no cross-check against the second vane on the other side of the aircraft. Why was a single-sensor input acceptable for a function with that much control authority? Because the safety assessment had classified MCAS as a limited-authority handling augmentation, and when its authority was later increased for the low-speed case (reported as roughly 0.6 to 2.5 degrees of stabiliser travel) and made able to re-trigger repeatedly, the single-point-of-failure question was not re-opened.

Keep going past the first plausible stop

Most candidates stop at "single sensor, bad design" — that is the fuse, not the strainer. Why did the aircraft need MCAS at all? Because the LEAP-1B engine has a much larger fan and had to be mounted further forward and higher on the wing, which produces a pitch-up tendency at high angle of attack, and a software control law was the cheapest way to make the MAX feel like the previous NG. Why did it have to feel like the NG? To preserve a common type rating so airlines could convert crews with computer-based differences training instead of full-flight simulator sessions — a launch customer contract reportedly carried a penalty of about a million dollars per aircraft if simulator training became mandatory. Why was that constraint so binding? Because after a major US carrier's 2011 A320neo order, Boeing chose to re-engine a 1960s airframe on a compressed schedule rather than build clean-sheet, and schedule plus commonality became the programme's governing metrics.

Verify the chain backwards, and apply the stopping test

Read it upward with "therefore": competitive schedule pressure, therefore a derivative not a clean sheet, therefore a no-simulator commonality constraint, therefore an aerodynamic problem solved in software, therefore MCAS with expanded authority, therefore a single-sensor trigger, therefore uncommanded repeated trim. Every link is a cause of the one above, not a restatement — the chain holds. Now apply the guide's stopping test. "The crews should have run the runaway-stabiliser memory items" names people, so ask why the system allowed it: MCAS was not described in the flight manual and the AoA Disagree alert was tied to an optional feature package, so crews were being asked to diagnose a system they had never been told existed. That is systemic and inside Boeing's control, so it belongs in the chain, not outside it.

Prove the fix removes the symptom, then size it

Three root causes survive, and each is Boeing-controllable: a hazard-assessment process that let a function's authority grow without re-classification, a single-point-of-failure sensor architecture in a repeatedly-triggering function, and a governance model where schedule and training-cost commonality outranked design margin — reinforced by self-certification under delegated authority. The fixes map one-to-one: MCAS now compares both AoA vanes and disables itself on disagreement, activates once per event, is overridable by pilot trim, AoA Disagree became standard, the system is documented and trained, and the delegation process was reformed. Test top-down: with a two-sensor cross-check and a single activation, neither accident sequence can start. Then quantify the trade: the constraint being protected was worth on the order of a few hundred million dollars of simulator training across launch fleets, while the consequence has been reported above 20 billion dollars in charges plus about 20 months of lost production — roughly two orders of magnitude, before counting 346 lives.

Root question with a number, a direction and a clock

Why has batch rejection risen from 2.1% to 8.6% over nine months at the Hyderabad OSD plant, and is that the same cause as the OTIF fall from 96% to 82%? Size the problem before touching it: the plant runs roughly 1,200 batches a year with an average COGS of about 11 lakh per batch, so the extra 6.5 percentage points of rejection is about 78 batches, or roughly 8.6 crore of product scrapped annually — plus the capacity those batches consumed, which is what is actually breaking OTIF. State the objective back: the CEO's real question is whether to pay a supplier premium, so our test is whether the API branch can carry 8.6 crore of scrap. Anchoring on that number stops you from investigating something that could at best explain a fraction of it.

Level 1 split using the process, not a checklist

Rejections happen somewhere in the manufacturing sequence, so split by process stage: dispensing and inputs, granulation and drying, compression, coating, and packing. That is MECE by construction because a batch passes through each stage exactly once and can only fail in one of them. Layer the classic 4M cut underneath as the Level 2 lens — material, machine, method, man — so each stage can be interrogated the same way. Refuse the plant head's framing at this point: "API quality" is one leaf under material at the inputs stage, not the top of the tree, and treating it as the root before testing it is exactly the tunnelling the framework exists to prevent.

Test each branch with one number and kill branches aloud

Ask for the rejection log cut three ways — by product, by line, and by failure reason — rather than for a general quality report. It comes back extremely concentrated: 71 of the 78 excess rejections are one high-dose extended-release product, all on compression line C-3, and the failure reason on almost all of them is tablet weight variation and content uniformity out of specification. That single cut kills the API hypothesis outright: the same API lots from the same new supplier ran through line C-1 for the domestic pack with rejection at 2.3%, so material cannot be the discriminator. Say it out loud — "the supplier is not the variable, because the variable that changes is the line, not the lot" — and note the compression stage is where the defect appears, which is not necessarily where it is caused.

Switch to 5 Whys on the surviving branch

Why do tablets fail weight and content uniformity on C-3? Because granule flow into the die is inconsistent, and the loss-on-drying moisture of the granules coming to that press ranges from about 1.4% to 3.8% against a specification of 2.0–2.5%. Why is granule moisture that variable? Because the fluid bed dryer feeding C-3, FBD-2, is being run to a fixed 45-minute drying time instead of being stopped on an in-line moisture reading. Why is it being run on time? Because the near-infrared moisture probe on FBD-2 has been throwing an error since a monsoon-season power event about seven months ago, and the SOP permits a time-based fallback, which the operators dutifully switched to. Note the timing match — seven months of a broken probe against nine months of rising rejections, with the ramp starting once the affected product's volume grew.

Do not stop at the broken probe

A broken sensor is a symptom with a work order, not a root cause, so keep going. Why was it not repaired for seven months? Because the probe is classified as a non-critical instrument in the asset register, which puts it on annual-shutdown maintenance rather than the monthly preventive list, and its replacement sensor costs about 4.2 lakh with a roughly ten-week import lead time and needs three quotes plus a capex approval because it crosses the one-lakh threshold. Why did nobody escalate it as a quality risk? Because the rejection dashboard the plant reviews is monthly and reported at plant level, so a problem concentrated in one product on one line stayed buried inside an average until we cut the data. And why was the workaround allowed to run indefinitely? Because the fallback clause in the SOP has no expiry date and no deviation trigger — a temporary method silently became the standard method.

Stop at the systemic cause and check it is inside the client's control

Two root causes survive, and both name a policy rather than a person. First, asset criticality in the register is classified by equipment cost and downtime impact, not by product-quality impact, so an instrument whose failure directly moves a critical quality attribute sits outside preventive maintenance and outside the critical-spares list. Second, an SOP fallback with no time limit and no escalation, combined with a monthly plant-level rejection report, means the organisation had no mechanism to notice a seven-month degradation. Resist the tempting stop at "the maintenance engineer should have raised it" — that is the scapegoat answer; the correct question is why the system let a quality-critical instrument stay dead for seven months without anyone being required to act.

Prove the fix removes the symptom, then quantify it

Fixes map directly onto the two roots: re-classify assets by quality impact using a short FMEA so every instrument tied to a critical quality attribute moves onto monthly PM and a pre-approved critical-spares kanban with a standing capex waiver; put a 72-hour expiry and an automatic deviation trigger on every SOP fallback clause; and move the rejection dashboard to daily, cut by line, product and failure reason. Read it top-down to test: with moisture end-pointed on a working probe, granule LOD returns to the 2.0–2.5% band, tablet weight variation stops, and the C-3 rejections disappear — the original number moves. Sizing: this recovers roughly 7 crore of the 8.6 crore scrap, returns OTIF to around 95%, and protects a 120 crore contract, against a fix cost of roughly 25 lakh for the sensor plus spares. Compare that with the plant head's proposal, which would have paid an API premium of several crore a year to fix a branch the data had already killed.