Lesson 26: Reliability Engineering, Instructor Session Plan

Lesson 25 proved the system hits its rate. This lesson asks what happens when a piece of it breaks, and whether Riverside's one maintenance tech can put it back. The one outcome every student must leave with: reliability is designed, not specified. You build it by finding failure modes before the customer does, ranking them by what the failure costs, stocking spares by criticality, and matching the whole thing to the maintenance team the customer actually has. If a student sets an MTBF target off a datasheet, or stocks one of every part, or designs for a PM program Riverside doesn't run, the lesson hasn't landed. Don't lecture the methods off a slide. Draw the system and FMEA it live with the room.

Run of Show (60-minute baseline)

Segment	Min	What happens
Works at install, dies in a year	7	Read Michael's two failure stories aloud, verbatim: the pneumatic system that died when the compressor dropped air at peak, and the line where everything stopped when anything downstream slowed. Land the jolt: neither died on the math. Both died on maintenance. Don't resolve it yet, just open it.
FMEA the system live	13	Draw the Riverside system on the board. Walk it component by component, the carton exercise turned toward the breakdown. Start from the two real prior failures as observed modes, then add the O-ring drift and belt slippage from earlier lessons. Build the failure table with the room. Key teaching moment, below.
How often, how long, how much it matters	14	MTBF versus MTTR: fails-often is not the same as down-long. Then criticality on top of both. Use the sorter-and-merge-versus-spur example off the board: the sorter and merge stop the whole line, a spur slows one door. Stress that MTBF and MTTR are targets set with the customer, not inherited numbers.
Spares and the team you actually have	16	Rank criticality and decide spares out loud: stock by criticality and lead time, not by failure count. Then the maintenance-reality question. This is a team of one, reactive. Which of these components can he actually reach and replace alone? Run the maintenance-access question. Riverside facilitation, below.
Reliability plan and Forest close	10	Students assemble the reliability plan: FMEA, criticality ranking, spares list, MTBF and MTTR targets. It's the third piece of the validation package. Close on the driving question and the design principle: a system is only as reliable as the team that maintains it.
Total	60	Baseline session. Expand with the stretch option below if you have 90 minutes.

Stretch option (for a 90-minute block):

A second maintenance profile (add 30 min): give the room a different customer, a facility with a full proactive PM team and a maintenance shift, and have them show how the same Riverside system's reliability plan changes. The spares list shrinks, the tolerance for a delicate, higher-performing design grows, and some components that earned a shelf spare for Michael's team of one no longer do. Running the plan twice, against two maintenance realities, is what proves reliability is a design property set by the customer's capability, not a fixed spec.

KEY TEACHING MOMENT | FMEA IT LIVE, THEN ASK WHO FIXES IT

Move one: draw it and FMEA it. Put the Riverside system on the board and walk it component by component with the room. Start from the two observed failures Michael handed you, the compressor air-drop and the whole-line stop, then add the O-ring drift and belt slippage from earlier lessons. Fill the effect and the criticality for each out loud. Rank them, and decide spares in front of the class: the sorter and the merge stop the whole line and get a shelf spare; the spurs are local and get sourced when needed.

Move two: ask who actually fixes it. Now run the maintenance-reality question. This is a team of one, reactive. Which of these components can Michael reach and replace alone, without a second person and a ladder? The point lands when the room sees that reliability is a design property, not a spec-sheet number. A component that's optimal for the product but can't be serviced by the customer's team is a delayed failure, and the design has to answer for that before it's steel on the floor.

WATCH-FORS

The failures this lesson is built to prevent all come from designing for an ideal instead of the reality. Watch for them and send each one back to the customer's actual capability and the criticality ranking.

They design for an ideal PM team the customer doesn't have. Send them to Michael. One reactive tech can't carry a design that needs weekly proactive maintenance.
They want to stock one of everything. Ask what the failure of each part costs and how long the part takes to source. Spares are criticality times lead time, not a full shelf.
They treat failure frequency as the only reliability metric and miss MTTR and criticality. A rare, whole-line, long-down failure outranks a frequent, local, five-minute one. Make them carry all three.
They set an MTBF or MTTR target by pulling a generic number. Send them back to the operation. The target is tied to what this customer can tolerate, the way margin was tied to the environment.

RIVERSIDE FACILITATION | DESIGN FOR THE TEAM OF ONE

Use the two prior failures as the FMEA's starting failure modes. They're the most valuable teaching material in the lesson because they're real and they came out of this building. Make the room design the reliability plan for Michael's team of one specifically, not for a maintenance department that doesn't exist here. When a student defaults to the ideal team, don't correct them with the answer. Ask: who's on shift the night this fails, and can that one person reach it? Do not tell them. Ask.

Grade the reasoning about criticality and spares, not the length of the list. A short, well-reasoned spares list that names why the sorter and merge earn the shelf and the spurs don't beats a long list that stocks everything. The student who ties every call back to what Michael's team can actually keep running has understood the lesson. The one who produces a tidy analysis for an imaginary maintenance department has not.

CHECKPOINT ANSWER KEY | NOT IN THE STUDENT FILE

Spares by criticality, not frequency. Hold the spare for the rare, long-down, long-lead component, because criticality and lead time drive spares, not failure count. Its failure stops more, stays down longer, and the replacement is weeks out, so the shelf spare is what keeps a whole-line stop from becoming a whole-week stop. The frequent, five-minute, in-stock part needs no held spare; you'd try to design it out or reduce its failure rate because it's the nuisance, not the risk. The wrong instinct is sorting by "what fails most," which optimizes for the cheap failure and leaves the expensive one exposed. Look for the reasoning about criticality and lead time, not a memorized rule.
Design for the reactive team. The design has to change, because a one-tech reactive shop can't carry a design that needs weekly PM to hit its targets. Acceptable moves: simplify to fewer failure modes, specify longer-MTBF and more self-contained components where criticality is high, choose a more durable technology (an MDR system, for instance) even where a cheaper one fits the product. The trade is real and it usually costs more up front, and it may give up some peak performance the delicate design would have delivered. What you tell the customer before they sign: the honest maintenance load. This design assumes your actual team, one reactive tech, and here's what it will and won't take to keep it running, so nobody signs expecting a reliability number the maintenance reality can't support. A strong answer names the cost or the performance trade openly rather than hiding it. Note: the proposal section where that maintenance conversation gets written is a later lesson; naming it as deferred is correct.

INSTRUCTOR ONLY | DO NOT SHARE WITH STUDENTS

The reliability plan the disciplined student builds today, the FMEA, the criticality ranking, the spares list, and the MTBF and MTTR targets, is a project-folder artifact that carries into the capstone. It's the third piece of the validation package, and it feeds the proposal's maintenance section, the one that has to address Michael Collins by name. Students who keep a real Riverside note now have the plan ready when the capstone asks for a maintenance conversation that answers a man who's watched two systems fail. Frame today's plan as normal project work, not a graded exercise. Don't tell them where it leads. The payoff lands hardest on the ones who built it as if it were real.

One dry note on the name: Riverside's maintenance lead is Michael Collins, twenty years on site, a different person from the program's own Michael Collins whose field notes run through these lessons. If a student catches it, acknowledge it and move on. Don't make it a bit.