The Job Debrief That Makes the Next Bid Smarter

A lessons learned process is a short structured review at the end of a job that records what the estimate assumed, what actually happened, and what the next bid on similar scope should do differently. It works when the record lands where the next estimator will look, and fails when it becomes a signature on a closeout form. One project controls lead we interviewed put the standard plainly: this step should not be rubber stamped, it should be really thoughtful, and it should be stored so it can be reflected on should they have another job similar.

Why does the lessons learned process get pencil whipped?

Because it is the last line on a closeout checklist, it belongs to nobody, and it has no reader. Nothing breaks tomorrow morning if the form gets three vague sentences. In the mechanical contracting work we have mapped, it shows up as a standing failure mode: treated as a formality, never retrievable for the next similar job.

One project controls lead named the cost, and it is not one you see in a single month. Without a real debrief, he said, they will not evolve, they will not become smarter and more profitable.

The penalty arrives one bid at a time, in a business that priced the same mistake twice. Apply the 80/20 rule for process documentation and the debrief clears the bar on one test: its output is another department's input.

What belongs in a job debrief

Five things, and none of them is a rating out of ten. Each entry has to be usable by a person pricing similar work.

1. Name the scope that moved. Extra work executed before it is priced gets negotiated at closeout, and as one project controls lead put it, in that position they always take a hit.
2. Record the assumption that failed. Estimators routinely price a plan without knowing the client's sequencing priority, and that plan becomes the schedule everyone inherits. Name the assumption that was wrong, not just the overrun.
3. Date the long lead time decisions. On one electrical job, equipment lead times were about to run past the contract completion date. The estimator saw how it would surface: ten weeks out, when the units are not in, somebody asks when they were submitted.
4. Capture the handoff that never happened. On a high-profile job, that same estimator admitted there had been no official handoff meeting, and that they really should just sit down for twenty minutes.
5. Write the rule you would apply next time. One sentence, specific enough that someone else could follow it without asking what you meant.

Four of those five sit at the front end of the job, not in the field. A debrief that only reviews execution is reviewing the wrong half, which is why it belongs inside a documented estimating process rather than beside it.

Store it so the next similar job can find it

Retrieval is the whole game, and almost everyone gets it wrong. Debriefs get filed by job number, so finding the right one means already remembering which job it was.

If the next estimator cannot find the debrief while pricing a similar scope, it does not exist.

File it by what an estimator searches on: scope type, equipment class, delivery method, client, dollar band. Put it where bids are built, not in an archive that closes when the job does.

A debrief nobody can retrieve while pricing the next job is a diary.

Rate sheets change, material lists get revised, a client switches submittal portals, and a two-year-old debrief quietly becomes wrong. The same discipline applies here as when the rules change but nobody updates the SOP: give the record a review date, or it gets trusted long after it stopped being true.

---

Feed the estimate, not the file cabinet

The output of a good debrief is usually a change to how work flows, not one more checkbox.

One commercial electrical contractor traced an estimating miss of 500,000 to 600,000 dollars back to process discipline, workflow structure and training gaps rather than a missing checklist item. Nobody forgot to tick a box.

That is also the number that funds the fix. One traceable miss of that size argues better than any appeal to being more organized, which is what building the business case for a systems overhaul runs on.

Who runs the debrief, and when should you hold it?

Run it with somebody who did not price the job and does not own its outcome: project controls, operations, or whoever can ask an uncomfortable question without it becoming a performance review. The person who built the estimate is a participant, never the facilitator.

Hold it inside two weeks of closeout, and hold a short one mid-job wherever the schedule changed. The twenty minute handoff meeting that estimator wished for is the same meeting moved to the front of the job. Book both.

Keep it small enough to survive a busy quarter. One contractor was covering thirteen states with two schedulers, one of them junior at best, and any ritual assuming spare capacity was never going to happen there. That is the real constraint behind keeping improvement systems alive after the project ends: a debrief needing an hour and four senior people is cut first.

Separate what we would change from who we blame

A debrief that turns into a search for the responsible party gets attended once. After that, people show up with clean answers and nothing useful.

One industrial contractor's owner described a senior new hire who sent him a list of everything the company was doing wrong. He was completely insulted by it, and felt like the company was going backwards. The list may well have been correct, and it did not matter.

Nobody accepts a change proposal from somebody who does not yet understand the variables.

The sequence that works is to map the current state with the people who own it, get that map approved, then invite suggestions. Once everyone agrees on how the work runs today, a proposal reads as a conversation instead of a critique.

It also helps to de-risk candor out loud. In interviews we say a version of this early: the idea is not unproductive complaining, it is for everybody to open up about what we turn a blind eye to, and nobody is going to go tell a colleague you said this. Say it before the first criticism, not after.

The two numbers every debrief compares

What you bid, and what it cost. Everything else in the meeting is context for those two numbers.

The trap is comparing them at the job level. A project that lands on budget in total can hide two errors of similar size pointing opposite ways, and averaging them teaches the next estimator nothing. Compare bid to actual at the level you priced it, not at the level you invoiced it.

Contractors also underbid to keep the pipeline moving. One operator described the pull without flinching: they want the work, getting the work keeps the company flowing, so they underestimate. If the same scope line comes in light on three straight debriefs, that is not three estimating errors. That is a rate that is now fiction, and it deserves what any stale document gets in a process audit.

At The Systems Effect we build the debrief into the process map itself, with a named owner and a place for the output to land, because a step that runs on good intentions is not a step. Start smaller this week. Pick the last job that surprised you, sit down for twenty minutes with the two people who felt it, and write the one page the next estimator can find.

Frequently Asked Questions

What is a lessons learned process?

A lessons learned process is a structured review at the end of a job that records what the estimate assumed, what actually happened, and what should change next time. Its audience is whoever prices the next job of that shape, so the output is a short record tagged for retrieval by scope, not by job number. If it cannot be found later, it is a formality rather than a process.

When should you run a project debrief?

Run the main debrief within two weeks of closeout, while the details are still recoverable from the people who lived them. Add a short mid-job debrief wherever the schedule or scope changed, because that correction can still help the current job. Twenty minutes at a transition point beats an hour three months later.

How do you store lessons learned so people actually use them?

Store them where the next bid gets built, not in the project archive, and file them by what an estimator searches on: scope type, equipment class, delivery method, client, dollar band. Job number and project name are useless to anyone who was not on it. Keep each entry to about a page, give it a review date, and apply one test: could a new estimator pricing similar work find it without asking anyone?

Why do debrief meetings get skipped?

Because the step sits last on a closeout list, has no clear owner, and nothing visibly breaks when it is missed. The cost shows up later, as the same estimating assumption priced wrong a second time. Debriefs also get skipped once they turn into blame sessions, so give the step an owner, a facilitator who did not price the job, and a twenty minute ceiling.