Learning from incidents: corrective actions and lessons learned

A root cause analysis that ends in a report has done half its job. The other half is making the changes that stop the incident happening again, checking that they worked and making sure the rest of the organization learns from them. Many facilities are good at the first half and weak at the second: the report is written, the actions are agreed, and a year later half of them are still open and the same kind of incident happens on another campus. This lesson is about closing the loop. It follows the corrective actions from the breaker incident of Lessons 7 and 9 and looks at how Stonebridge turns incidents, near misses and drills into lasting improvement.

Correction, corrective action and preventive action

Three words are often confused. A correction fixes the immediate problem: the crushed cord is replaced and the breaker's settings are corrected. A corrective action removes a cause so that the problem does not recur: the procedure is rewritten so that settings are always applied. A preventive action removes the cause of a problem that has not happened yet but could: checking every other trip unit on both campuses for the same mistake before any of them fails. Quality management systems often combine the last two under the name corrective and preventive action, or CAPA. The distinction matters because a list made only of corrections looks like progress and changes nothing.

Strong and weak actions

Not all actions are equally effective. Safety and quality professionals rank them by how much they depend on people remembering to do the right thing. The strongest actions change the design or the equipment so that the error cannot happen or cannot cause harm. Next come engineering controls and automation that catch the error. Then come changes to procedures, checklists and hold points. Weakest are training, warnings and reminders, which rely entirely on memory and attention. Weak actions have their place, but a corrective action list made only of them, such as remind staff to check settings, will not stop a determined recurrence.

In practice, the strongest actions are often expensive or slow, so a good list combines them: a moderate action that can be done this week, a stronger one planned for the next budget, and the briefing that helps people understand why the procedure changed.

Writing a corrective action

Each corrective action at Stonebridge is written so that anyone can tell when it is done. It names one specific change, one owner who is a named role, a due date, and the evidence that will show it is complete. It is linked to the cause it addresses. Remind the team to be careful is not a corrective action. Revise MOP template EL-07 to add a step to load and photograph the coordination settings, with a hold point signed by the shift lead, owner: operations engineer, due 30 April, evidence: revised template issued, is.

For the breaker incident, the RCA team agreed seven actions.

Extent of condition

Action 2 is one of the most important ideas in this lesson. When an incident reveals a weakness in one piece of equipment, the first question after the RCA is: where else does the same weakness exist? This is called the extent of condition. The trip unit on RPP-A2-08 was wrong because of how it was replaced. Every trip unit replaced the same way could be wrong too, and each one is a future incident waiting for its trigger.

Verifying effectiveness

An action is closed when it is done; it has worked only when the evidence shows the problem has stopped. Stonebridge separates the two. Each corrective action is closed when its evidence is provided, and the RCA as a whole is reviewed again after a set period, usually six months, to check that the actions have had the intended effect. For the breaker incident, the six-month review checks that the revised MOP has been used for every trip unit job since, that the settings records exist, that the annual test program now includes the check, and that no further mis-set units have been found. If an action has not worked, a new one is raised.

# Corrective action tracker: status, overdue items and effectiveness checks
from datetime import date
today = date(2027, 6, 15)
actions = [  # no, action, due, closed, effectiveness verified
    (1, "apply settings to RPP-A2-08", date(2027, 3, 1), date(2027, 2, 24), True),
    (2, "check all replaced trip units (both campuses)", date(2027, 3, 29), date(2027, 3, 22), True),
    (3, "revise trip unit MOP template", date(2027, 3, 22), date(2027, 3, 19), False),
    (4, "settings check in annual breaker tests", date(2027, 5, 31), None, False),
    (5, "monitor trip unit settings and alarm", date(2028, 3, 31), None, False),
    (6, "cord routing in install checklist", date(2027, 3, 15), date(2027, 3, 11), False),
    (7, "offer transfer switch to customer", date(2027, 3, 15), date(2027, 3, 9), True),
]
open_ = [a for a in actions if a[3] is None]
overdue = [a for a in open_ if a[2] < today]
on_time = sum(1 for a in actions if a[3] is not None and a[3] <= a[2])
print(f"{len(actions)} actions: {len(actions) - len(open_)} closed ({on_time} on time), {len(open_)} open, {len(overdue)} overdue")
for no, what, due, closed, eff in actions:
    state = ("closed " + closed.isoformat()) if closed else ("OVERDUE" if due < today else "open, due " + due.isoformat())
    check = "effective" if eff else ("check due" if closed else "")
    print(f" {no}. {what:46} {state:22} {check}")

7 actions: 5 closed (5 on time), 2 open, 1 overdue
 1. apply settings to RPP-A2-08                    closed 2027-02-24      effective
 2. check all replaced trip units (both campuses)  closed 2027-03-22      effective
 3. revise trip unit MOP template                  closed 2027-03-19      check due
 4. settings check in annual breaker tests         OVERDUE                
 5. monitor trip unit settings and alarm           open, due 2028-03-31   
 6. cord routing in install checklist              closed 2027-03-11      check due
 7. offer transfer switch to customer              closed 2027-03-09      effective

Action 4 is overdue: the program review it depended on was postponed, and Morgan has escalated it to Anjali. Action 5 is open but not overdue; it is a budget item for next year. Actions 3 and 6 are closed but their effectiveness has not yet been verified, which will happen at the six-month review. The tracker is reviewed every month at the operations meeting, and overdue actions are reported to the operations director.

Near misses

An incident is expensive to learn from. A near miss, an event that could have caused harm or an outage but did not, teaches the same lessons for free. The CRAH unit almost stopped in Lesson 3's vendor example, the out-of-date placard in Lesson 6's drill and the leftover maintenance mode in Lesson 4 are all near misses. Industry experience, going back to studies of workplace accidents decades ago, is that for every serious incident there are many minor ones and many more near misses with the same causes. A facility that collects and studies its near misses can fix the causes before they produce the serious event.

Stonebridge asks every employee and contractor to report near misses through a short form in the shift log, and reports them in the monthly operations review. The form asks four questions: what happened, what could have happened, why it did not, and what would stop it happening again. Reports are blameless in the same way as RCA: nobody is disciplined for reporting a near miss, even one they caused, unless they deliberately broke a safety rule. Anjali counts the number of near-miss reports as a good sign, not a bad one. A site with no near-miss reports does not have no near misses; it has people who do not report them.

Sharing and trending

Lessons learned on one campus are of little use if the other campus repeats the mistake. Stonebridge shares the summary of every severity 1 and 2 RCA, and of selected near misses, with both campuses and its other sites, in a monthly lessons-learned bulletin and at the quarterly operations meeting. The breaker incident's extent-of-condition check across both campuses was itself a product of this sharing. Some lessons go further: Stonebridge contributes anonymized summaries to an industry incident-sharing group, because the same weaknesses appear across many operators.

Trending looks for patterns across incidents. One incident caused by a maintenance procedure is a problem; five in a year is a pattern that says the procedure-writing process itself needs attention. Morgan and the operations engineer tag every incident and near miss with its causes using the fishbone categories of Lesson 9, and review the counts every quarter. Lesson 1's industry figures, with procedures behind most human-error outages, came from exactly this kind of trending across many organizations.

# Trend incidents and near misses by cause category over four quarters
records = [  # quarter, type, cause category
    ("Q1", "incident", "procedures"), ("Q1", "near miss", "people"), ("Q1", "near miss", "procedures"),
    ("Q2", "incident", "equipment"), ("Q2", "near miss", "procedures"), ("Q2", "near miss", "environment"),
    ("Q2", "near miss", "procedures"), ("Q3", "incident", "procedures"), ("Q3", "near miss", "management"),
    ("Q3", "near miss", "procedures"), ("Q4", "near miss", "equipment"), ("Q4", "near miss", "procedures"),
]
cats = sorted({c for _, _, c in records})
print("category     " + "  ".join(q for q in ("Q1", "Q2", "Q3", "Q4")) + "  total")
for c in cats:
    row = [sum(1 for q, _, cc in records if q == qq and cc == c) for qq in ("Q1", "Q2", "Q3", "Q4")]
    print(f"{c:12} " + "  ".join(f"{n:2}" for n in row) + f"   {sum(row):3}")
inc = sum(1 for _, t, _ in records if t == "incident")
print(f"incidents {inc}, near misses {len(records) - inc}")

category     Q1  Q2  Q3  Q4  total
environment   0   1   0   0     1
equipment     0   1   0   1     2
management    0   0   1   0     1
people        1   0   0   0     1
procedures    2   2   2   1     7
incidents 3, near misses 9

Procedures appear in seven of the twelve records across the year, more than every other category together. The trend leads to a decision that goes beyond any single RCA: a review of how Stonebridge writes and checks its procedure templates, with the operations engineers and the shift leads together, before the next maintenance season.

Learning culture

All of this depends on people being willing to talk about what went wrong. Roz has worked at sites where incidents were quietly fixed and never written up, because writing them up led to blame. Those sites, she says, had the same incidents over and over. At Stonebridge she has seen a technician stand up at the operations meeting and explain how he left a CRAH in maintenance mode, and the result was a change to the return-to-service checklist of Lesson 4 that every crew now uses. The habits of this lesson, blameless reporting, strong actions, checking everything like it, verifying that fixes work and sharing them, are what turn a group of skilled technicians into an organization that gets more reliable every year.