I have sat through perhaps two hundred launch readiness reviews, and I can usually tell within five minutes whether a risk register is alive or dead. A dead one has forty to sixty entries written in the passive voice, each with a mitigation line reading "monitor" or "manage via project process", and an owner column populated with department names rather than people. Nobody in the room can name the last date any entry was reviewed against evidence. The register was written to be filed — a deliverable for the programme gate, not a working tool.
The uncomfortable truth is that the problems you actually get at launch are almost always visible in the register somewhere, buried and unprioritised, because the register was designed to pass an audit rather than to drive action. The weld spatter that contaminates fixture sensors, the supplier who has never run your part at full cavitation, the torque tool calibration that expires mid-ramp — these appear as vague one-liners or not at all, while the register fills with compliance-flavoured padding nobody intends to act on.
The difference between a useful register and a filing exercise is not the software or the scoring matrix. It is whether entries are written as testable predictions with named owners and dates, and whether the review cadence forces evidence against those predictions. Everything else — scoring, tiering, tooling — follows from that discipline.
What a Good Risk Entry Actually Looks Like
A risk entry that predicts must contain four things: a specific failure mode, a mechanism, a trigger condition, and something observable that tells you it is materialising. Compare "Risk: supplier capacity insufficient" with "Risk: injection moulder has validated tooling only at 60% of rate; gate seal quality unproven above 85% cycle speed; leading indicator is short-shot rate in the first full-rate trial, review weekly from tool try-out". The first is a category. The second is a falsifiable statement you can argue about, resource, and retire.
Write risks at the level of mechanism, not consequence. "Line stoppage" is a consequence; "poka fixture proximity sensor fouled by trimming debris within four hours at target cycle" is a mechanism you can engineer against. Mechanism-level entries let you assign mitigation to someone who can change the physics — a tooling change, a sensor relocation, a cycle-time adjustment — rather than to a project manager who can only escalate.
Test every entry with one question: could a competent engineer disagree with this entry's likelihood or severity, and would the register tell them what evidence to bring to that argument? If not, the entry is decoration. Apply a second test: name the date and the artifact that would close the risk. "Design review complete" closes nothing. "Full-rate tool trial report showing gate seal acceptable across 500 shots at 100% cycle speed, signed by the process engineer" closes something.
Across automotive and aerospace programmes I have run, this rewrite discipline alone cuts register length by half and doubles the proportion of entries that get actively worked. Shorter and sharper beats longer and dormant every time.
Hunting the Risks That Never Make the List
The highest-value entries are the ones nobody writes down, usually because they sit across organisational seams. Equipment proven only at the supplier's facility, running the part the supplier made, with their material lot. Maintenance schedules from the old programme carried forward to a line running harder cycles. The second shift, trained two weeks after the first, with no stable work instructions. De-rating gains that quietly vanish when launch pressure forces full speed. None of these fit neatly in a template, so they get omitted.
Go and look for them deliberately. Before writing a single entry, walk the pilot line or the supplier's floor with the operators and the maintenance technician, and ask what changed since the last programme. Read the early build deviation log — patterns of temporary containment are unborn risk entries. Interrogate the interface points: material release timing against the first full-rate trial, gauge availability against first submission builds, packaging proof against the logistics trial. Every seam between functions is where unregistered risks breed.
Another productive source is your own launch post-mortems. Pull the top problems from the last three launches and check whether the current register contains analogous entries. If the previous launch drowned in poor weld fixture repeatability and this register has no fixture-related risk, that is not confidence — that is amnesia. Institutional memory converted into register entries is the cheapest predictive power you will ever buy.
Finding the risks that never make the template
- 01Walk the floorPilot line or supplier plant with operators and maintenance; ask what changed since the last programme.
- 02Mine the deviation logRepeated temporary containments on early builds are unborn risk entries.
- 03Interrogate interfacesMaterial release vs first trial, gauges vs first submission, packaging vs logistics trial.
- 04Check past post-mortemsEvery major problem from the last three launches should have an analogous entry.
Ownership: One Name, One Consequence
Departmental ownership is where registers go to die. When the owner column reads "Purchasing", no individual feels the review coming, and nobody prepares evidence. Assign every entry to one named person who has the authority and the competence to execute the mitigation — not to escalate it, to execute it. If the mitigation genuinely spans functions, split the entry into separately owned pieces. A risk shared is a risk unmanaged.
Ownership must carry consequence in both directions. An owner who arrives at a review with no evidence but a plausible story should be treated more harshly than one who arrives with bad news and data. The moment review culture punishes honest red status, owners learn to amber-wash everything, and the register loses its predictive value within a fortnight. I have watched it happen: status hygiene is fragile, destroyed by a single director blowing up at a red flag in a gate review.
A review with no recorded consequence for any entry was a meeting, not a review.
Retiring risks should be an earned event. An owner who closes a risk with evidence — a trial report, a capability study on the new fixture, a signed maintenance plan for the critical asset — has done real work. A risk closed because the gate passed is still live, and it will resurface during ramp-up when you have the least capacity to deal with it. Keep a closed log and revisit it once before launch sign-off; the number of entries closed without evidence is itself a leading indicator of launch trouble.
Review Cadence That Matches the Clock Speed of the Risks
A monthly review of a launch register is almost always too slow, and a weekly review of every entry is too slow for a handful of critical ones. Tier the register. Top-tier risks — high severity with a short fuse, such as full-rate tool validation or long-lead gauge procurement — deserve a weekly fifteen-minute check against a specific indicator, done by the owner and one challenger, not a committee. Second-tier entries ride the fortnightly or monthly programme review. Everything else gets a hard look at defined gate points only.
Each entry needs its own clock. The trigger condition written at identification — first full-rate trial, first three-shift week, first PPAP submission build, tool transfer date — defines when the risk becomes testable and when review intensity must step up. A register with a uniform cadence is a register reviewed at the wrong speed for nearly everything. Insist that owners declare their trigger dates in the register itself, and set the cadence backwards from those dates.
Reviews must demand evidence, not narrative. The standing question is "show me": show me the try-out report, the sensor fault log from the pilot line, the delivery performance of the one supplier feeding your bottleneck station. Fifteen minutes of data beats an hour of confidence. And record the decision: what changed, who does what by when, whether the risk was raised, lowered, or had its mitigation redirected.
Scoring Without Self-Deception
Likelihood-and-severity matrices have their place, but they are routinely gamed. Teams under pressure score everything as low-likelihood because nobody wants to own a red entry going into a gate. Counter this by scoring likelihood against a defined evidence base: has this failure mode been observed on this process, on similar processes, or never? A three-anchor scale — "observed here", "observed elsewhere", "not observed" — is harder to fudge than a one-to-five guess, and it forces the conversation about analogues that produces better entries.
Severity should be scored against a concrete consequence, defined once for the programme: containment cost, line stop duration, customer exposure. Vague severity invites inflation and deflation for political reasons. Reserve the top severity band for things that stop the line or ship bad product to a customer, and hold that line even when the entry belongs to a friendly department. A register where every entry is medium is a register where prioritisation has already failed.
Re-score honestly over time. As evidence accumulates — successful trials, stable pilot runs — scores should fall and the register should visibly shrink. A register whose scores never move between gate three and launch is telling you the reviews are theatre. Equally, watch for score migration driven by schedule pressure: risks quietly downgraded in the run-up to a gate decision are among the most reliable predictors of launch fire-fighting I know.
Two registers, two outcomes
Written to be filed
- Passive-voice entries with vague consequences
- Mitigation: monitor via project process
- Owners are department names
- Uniform monthly review of everything
- Risks closed when the gate passes
Written to predict
- Mechanism-level, falsifiable statements
- Mitigation assigned to someone who can change the physics
- One named owner per entry
- Cadence set backwards from trigger dates
- Closure requires a signed artifact of evidence
Making the Register Survive Contact With Launch
The final test comes in the ramp-up weeks, when the organisation is saturated and nobody reads documents. By then the register should have mutated into something operational: a short list of open risks, each with an owner physically present at launch, a defined leading indicator, and a pre-agreed reaction plan. Hold a specific review two weeks before start of production whose sole agenda is converting the top open risks into a launch monitoring sheet — the indicators, who watches them, at what threshold the reaction triggers, and what the reaction is.
After launch, close the loop. Within a month of stable production, compare the actual problem list against the register. Every significant problem that occurred should map to either a registered risk that was under-managed or a gap in identification. Both findings go back into the method: entries that predicted get studied for why they worked; entries that missed get studied for what seam produced them. This is how the register improves programme after programme, and how a quality organisation builds genuine predictive capability rather than gate-compliance theatre.
The register written to be filed will always exist, because someone will always demand the artifact. Your job is to make sure the artifact and the working tool are the same document — specific entries, named owners, evidence-driven reviews, cadence matched to trigger dates. Do that, and the register stops being a launch formality and becomes the cheapest insurance you will ever underwrite.