Assembly Lessons Learned Review

A lessons learned review is the cheapest engineering tool available and the one most often skipped. It costs a meeting and some preparation, and it prevents a design flaw or a process assumption from being rediscovered on the next programme. The reviews that fail do so for predictable reasons: they are held too late, they collect opinions rather than data, and they produce a list of observations that nobody converts into a change. A useful review is short, specific and ends with assigned actions that change a document somebody will actually read again, rather than a report that is filed and forgotten.

Why Reviews Repeat Themselves

Most organisations hold reviews and still repeat the same mistakes, because the output never reaches the people who would avoid them. Findings are written into a report that lives on a shared drive, the checklist that guided the design is not updated, and the next project begins with the same assumptions. The lesson was learned by individuals, who then moved to other teams, and the organisation retained nothing it could use the next time.

The remedy is to attach each lesson to something that will be used again: a checklist item, a design rule, a process window, a fixture requirement or a test step. A lesson that exists only as a paragraph in a report has a very short life. A lesson that exists as an item in a review checklist is applied automatically on the next programme, whether or not anyone remembers why it is there.

Collecting the Material

The material for the review should be gathered before the meeting, and it should be factual. Defect records by code and stage, the rework hours, the escapes and their root causes, the engineering changes made after the design freeze, the supplier issues and the test steps that were added during the ramp. Together these tell the story of where the programme actually spent its effort, which is often different from where it planned to.

It also helps to include the predictions made at the start. Comparing the fault spectrum that was forecast with the one that occurred shows whether the team understood the product, and the gap between them is frequently the most valuable single item on the agenda. Where the escape rate was higher than expected, that comparison goes a long way towards explaining why. Quality checklist data is the usual source for the forecast.

Structuring the Session

Structure keeps the meeting from becoming a discussion of personalities. A workable format takes each phase in turn, design, fabrication, assembly, test and field, and asks three questions: what went well, what went badly, and what would we change. The facilitator should keep the group on the third question, because the first two are easy to talk about and the third is the only one that produces anything.

Attendance matters. The session should include the design engineer, the process engineer, the test engineer, the people who built the product and somebody from quality. Where a supplier or a contract manufacturer contributed to the outcome, their input is often decisive, and inviting them to a focused part of the session is better than reconstructing their issues second hand from the records, which is both slower and less accurate.

Turning Findings into Changes

Every finding should end with one of four outcomes: a document change, a design rule, a checklist item or an explicit decision to accept the risk. Anything else is an observation, and observations do not change outcomes. Assigning an owner and a date to each item at the meeting, rather than afterwards by email, is what makes the difference between a productive session and a pleasant one.

The design rule route is the most durable for engineering findings. If a review concludes that a particular connector needs a wider keep-out, that conclusion belongs in the layout rules rather than in a report, where it will be applied by the next designer automatically. Findings that relate to the process belong in the work instructions, and findings that relate to the test strategy belong in the test plan and its justification.

Updating the Checklist

The checklist used before the design freeze is the single best place to store a lesson. Adding an item costs almost nothing and guarantees that the question is asked on the next programme. Over several years this produces a checklist that encodes the organisation’s experience, and a new engineer inherits it on their first day rather than accumulating it over a decade.

The checklist should be reviewed at the same time as the lessons, because items accumulate and some become obsolete when the process or the component technology changes. An item that no longer applies still consumes attention, and a long checklist that is answered carelessly is worse than a short one that is answered properly. Retiring items is part of maintaining it.

Following Through

Actions from a lessons learned review should be tracked in the same system as any other engineering action, with the same visibility and the same consequences for slipping past a due date. A separate list that nobody reviews is where good intentions go to die, and it teaches the team that the review was a formality rather than a working session.

A short follow-up meeting, four to six weeks later, checking that each action closed and re-testing the ones that did not, keeps the loop honest. Chasing closure is what separates a review that changed something from one that merely recorded it. Where an action was abandoned, the reason should be recorded, because an abandoned action usually means the finding was wrong or the fix was impractical, and both are worth knowing. Handover routine is a good model for this kind of short, disciplined follow-up.

Making It a Habit

For the review to become a habit it has to be scheduled as part of the programme rather than added at the end when everyone is tired. Placing it at the end of the ramp, with the data fresh and the participants still available, produces better material than a session held months later when the people who did the work have moved to another project.

It also helps to keep the output short. A one-page summary of the three or four changes that will be made, with owners and dates, is more likely to be read and applied than a comprehensive report. The value is in the change, not in the document, and the document exists only so that the change survives the departure of the people who thought of it in the first place, which is the test of whether the review produced anything lasting.

FAQ

When should a lessons learned review be held? At the end of the ramp or the first production build, while the data is fresh and the people who did the work are still on the same programme.

What is the minimum useful output? Three or four changes with owners and dates, recorded in the documents that will be used again, such as the design review checklist and the assembly work instructions.

How do we keep the review from becoming a blame session? Focus on the process rather than the person, use data rather than recollection, and make the third question, what we would change, the only agenda item that matters.