Closing the loop — warranty callbacks become next year's contingency

PMI calls it lessons learned. The lessons-learned process is the only project management discipline with documented ROI across decades of studies (PMI Pulse of the Profession reports it cuts repeat-defect cost by 20–30% when consistently applied). It's also the discipline that fails most often, for one reason: the data lives somewhere else by the time you need it.

For a specialty trade, the highest-value lessons come from warranty callbacks — the work you go back and do for free, six months to a year after closeout. Every callback is the project literally telling you "you got this part wrong." The signal is unambiguous. The cost is captured (you're paying labor + material to fix it). The only question is whether you act on it the next time around.

The loop:

Warranty callback opens for a project closed N months ago.
        ↓
Service tech logs hours, replaced parts, root cause.
        ↓
Callback gets categorized: install defect, material failure,
operator error, design issue, scope ambiguity.
        ↓
Pattern detection across callbacks: which assemblies fail, which
GCs / project types / regions correlate, which subcontracted scopes
keep biting.
        ↓
Three places the pattern lands:
  - Assembly library: increased install cost, tighter QA spec
  - Estimating contingency: per-assembly or per-project-type uplift
  - Closeout checklist: new line items to catch the failure pre-callback
        ↓
[loop, next bid]

The loop is short. Twelve months from callback close to next bid affected. Run it for three years and you have something like institutional learning.

Why most subs lose the data

The pre-STrOp setup is structurally hostile to this loop:

Warranty callbacks come in by phone, get scheduled in the dispatcher's calendar, work gets logged in QuickBooks Time or a paper ticket, the callback closes. The callback never touches the original project record.
The estimator who priced the next-year version of the same assembly never sees the callback data. They're working from the assembly library that says "1.2 hours/EA install" — but they don't know that 14% of the installs from last year came back as callbacks for a loose connection.
The closeout PM who could add a torque-check step to the punch list doesn't see the callback either.

By month six the data trail is broken and the loop never closes.

What changes when warranty lives in the same system

Three pivots, all of which require the warranty record to be the same data structure as the original FWO that installed the thing:

1. Every callback links to the original FWO and the original install crew. When the loose-connection pattern emerges, you can trace it back to the crew that installed it (training opportunity) and the FWO it came from (was the install rushed? What was the daily report context?).

2. Callbacks roll up by assembly, not by project. "Project 2024-117 had 3 callbacks" tells you nothing. "Across all projects, the EMT-fitting-to-junction-box assembly has 14% callback rate vs library average of 3%" tells you exactly what to fix.

3. Closeout punch list pulls from prior callback patterns. When a job hits substantial completion, STrOp surfaces the top 5 callback patterns from the last 18 months on similar projects. The PM adds them to the punch list. The defect that took a callback last year becomes a punch item this year — caught before closeout.

What STrOp routes back to estimating

Signal	Lands in
Callback frequency per assembly	Assembly library — base productivity + contingency multiplier
Average rework cost per callback type	Per-assembly contingency by failure mode
Per-GC callback correlation	GC profile in CRM — bid uplift if the GC pattern is sustained
Per-region or per-project-type pattern	Project-type contingency in the estimating template
Material brand correlation	Product catalog — flag products with elevated failure rate

The estimator doesn't have to remember any of this. The next bid that uses the assembly shows: "this assembly has 8% callback rate over 142 installs. Default contingency: +6% on install hours, +3% on material."

The estimator can ignore the suggestion, of course. But they're ignoring it knowingly — not because the data never reached them.

The PMI lessons-learned discipline, applied honestly

The PMI framework for lessons learned is a four-step process: identify, document, analyze, store. Most subs do a version of step 1 and 2 informally ("we had problems on the Riverside job"), skip step 3 entirely, and step 4 becomes "we'll remember." Six months later they don't, and the next Riverside-style job repeats.

The single-pipeline version makes steps 3 and 4 nearly automatic:

Identify — warranty callbacks are identified by the customer who calls. STrOp logs the call against the project.
Document — the service tech logs the work. The data structure forces categorization.
Analyze — STrOp's pattern detection runs across the corpus. The estimator sees the result.
Store — it's already in the assembly library. There's no separate place to file it.

The only step that requires discipline is forcing the service tech to categorize the root cause at callback close. That's a 30-second decision per callback that compounds into years of decision-improving data.

The 18-month rule

Patterns aren't real until you have observations across multiple projects. The rule we use:

Single-project observation — note it. Maybe coincidence.
Two-project pattern — flag for review. Possibly a system issue.
Three+ project pattern in 18 months — act on it. Update the assembly, the contingency, or the closeout checklist.

18 months is roughly the time between "first install" and "callback statute of limitations" on typical workmanship warranties. Patterns that show up over that window are real.

Common failure modes

Warranty work in a separate system. Callback data doesn't reach estimating. Loop broken at step 1.
No root-cause categorization at callback close. "Customer issue" or "fixed it" tells you nothing six months later. Force one of: install defect, material failure, operator error, design issue, scope ambiguity.
Patterns acted on without sufficient n. One callback is a coincidence; updating an assembly's cost based on n=1 is overfitting. Wait for the pattern.
Estimator doesn't see the signal at bid time. The library surfaces the data but the estimator doesn't look. Build the suggestion into the workflow, not a separate report.
Lessons learned written for the file, not for the bid. "We learned that detail X is hard" stored in a Word doc helps nobody. The lesson has to land in the assembly library or the closeout checklist where it'll get used.