How can lab and line work better together?

A pilot lot of a new controller board stops at the pick and place machine on a Thursday evening. Two parts in the centroid file are rotated. A tall electrolytic capacitor sits over the programming header, so the jig cannot reach it. By Friday the lab says the line should have spotted it at kitting. The line says nobody told them revision B had changed. Both are partly right, and the customer's date has not moved.

This is the design-to-production gap that our overview of people issues in electronics warns about. The short answer: before any new board or revision reaches the floor, both sides sit down and close a written list of open points, each with one owner. After that, the floor's yield and rework figures travel back to the lab every week. Below is how to run both halves, then the questions owners usually ask next.

It is a meeting of about an hour. It happens once layout is frozen and before kitting starts for the pilot lot. It is not a design review, because the schematic is settled by then. The question is narrower. Can this board, with this firmware image and this bill of materials, be built and tested on our line next week without anyone guessing?

Who attends matters more than the agenda. The hardware designer and the firmware lead come from the lab. The line lead, the SMT setter, a test technician and someone from stores come from the floor. Quality chairs it. Where there is no quality engineer, the plant head does. Keep the room to people who will act on an item.

Board name, revision letter and customer part number.
Bill of materials revision, with every alternate part marked and approved.
Footprints checked against parts actually in stores, including polarity marks and pin one.
Centroid file and rotations proved on the setter's machine, not only in the layout tool.
Stencil aperture changes for fine-pitch or bottom-terminated parts.
Firmware image name, version and checksum, with who flashes it and on which jig.
Test fixture or flying-probe program ready, and who proved it on a known-good board.
Work instruction with photographs for every manual step, such as a hand-fitted terminal block.
Open point, owner, date due, closed by.

The last line changes behaviour. An open point with no owner is an argument postponed. Give it a name and a due day and it becomes a job. End the meeting by reading out every open point and its owner. Send the sheet to everyone who attended that afternoon.

• A land pattern drawn for one supplier's part while stores holds the alternate, with a longer body.
• A thermal pad under a QFN with no windowed paste, so the part floats and solder balls form.
• Via-in-pad left unplugged, wicking solder away from a BGA ball.
• A test point hidden under a connector, out of reach of the bed-of-nails fixture.
• Silkscreen printed over pads, or a polarity mark that vanishes under the placed part.
• Breakaway tabs and fiducials placed where the depanelling router or the conveyor rails cannot work.
• A firmware image that locks the debug port before production test has written serial numbers.

Every item on that list is cheap to fix on screen and expensive to fix across a rack of populated panels. The release review is where they get caught.

The second half of the answer runs the other way. Designers rarely see their board after the pilot. Rework tickets, AOI false calls, tombstoned resistors, bridging on a fine-pitch QFP and functional test failures all sit in the production office. A weekly page closes that loop without adding a meeting.

• First-pass yield at functional test for each active board, this week against last.
• The three most frequent faults per board, with one photograph of each.
• Rework minutes per board, taken from the rework bench log.
• Any fault the line suspects is a design cause, written as a question and not a verdict.
• Engineering change notes raised that week and where each one stands.

Address it to the designers by name. Ask one of them to reply with what changes on the next spin. The reply matters most. If the page goes out for a month with no answer, the floor stops filling it in.

The plant head, or whoever signs off the customer's delivery date. Not the designer, who is defending the board. Not the line lead, who is defending the floor. In a forty-person firm this is often the founder for the opening few boards. Hand it on once the sheet runs itself.

Then the review decides which open points can travel with the pilot lot. A missing work instruction can be covered by a supervisor standing at the station. A wrong footprint cannot. Write down each risk the team accepted and who accepted it. That note heads off the post-pilot blame session, since the call was made in writing beforehand.

Put people in the other room. The designer stands on the line for the first shift of every pilot build, beside the setter and the rework station. The line lead joins the layout review, where a remark about a connector that hand solderers cannot reach costs nothing to fix. Line leads asked to speak up in a room of engineers may need coaching first; line leader development in EMS units covers that.

1. 1

   Week one: pick one board

   Choose a board due for pilot build soon and treat it as the trial. Do not write a rule for every product yet.

2. 2

   Week two: agree the sheet

   Adapt the template with the designer and the line lead together, so neither side sees it as the other's form.

3. 3

   Week three: hold the review

   Chair it firmly, record owners and dates, and circulate the sheet the same day.

4. 4

   Week four: compare with the pilot

   Set what went wrong on the line against what was on the sheet. Anything missed becomes a new line for the next board.

Usually neither. It needs the duty written into roles. The designer's description should say they own manufacturability findings until the pilot lot passes. The line lead's should say they raise build risks at layout review. Count a clean pilot lot in the designer's goals and an early warning in the line lead's. Our role design work is where those duties get written, and the embedded systems role pages show how remits split between hardware, firmware and test.

The pattern behind this question is set out in lab and line as different worlds. If you want help writing the roles, goals and review sheet for your own boards, tell us about your boards and teams through our requirements page.