Hardware Engineering Change Checklist: What Else Does This Change Touch?

A resistor value changes. One line in the schematic, one line in the BOM, two minutes of work.

Six weeks later the test department is still using the old pass/fail window, the calibration procedure quotes a voltage that no board produces any more, and a distributor has shipped 500 of the superseded part against a purchase order nobody cancelled.

Nothing was done wrong, exactly. The change was correct. The problem is that a change to a design is never a change to one file, and the cost of a change is almost entirely in the things that quietly went stale around it.

This is an impact checklist: not how to approve a change, but how to find everything the change touched once you have decided to make it.

Work outwards, not alphabetically

The useful way to run an impact analysis is to start at the change and move outwards in rings:

1. The design itself — schematic, layout, BOM.
2. What is derived from the design — manufacturing outputs, drawings, test

data.

1. What references the design — procedures, labels, firmware, higher

assemblies.

1. What was committed before the change — orders, stock, boards already

built.

1. People — who is working from the version you just superseded.

Most missed impacts live in rings 3 and 4. Rings 1 and 2 are the part everyone remembers.

The propagation map

Sample mappings. Yours will differ — the point is to have a map at all, so impact analysis is a lookup and not an act of memory at five in the afternoon.

The checklist

Run this against any change that has left the engineer's own machine.

Design

• [ ] Schematic updated and re-checked
• [ ] Layout updated, DRC clean
• [ ] BOM updated: value, part number, quantity, reference designators
• [ ] Reference designators still match between schematic, layout and BOM
• [ ] Revision moved on everything that changed, and on nothing that did not

Derived outputs

• [ ] Gerbers and drill data regenerated from the changed layout
• [ ] Pick-and-place file regenerated
• [ ] Assembly drawing regenerated or annotated
• [ ] 3D model or STEP export regenerated if mechanical interfaces moved
• [ ] Old outputs archived or marked superseded, not left beside the new ones

Test and verification

• [ ] Test limits reviewed against the new design values
• [ ] Test fixture still makes contact where it used to
• [ ] Test coverage still reaches circuits whose parts changed
• [ ] Any qualification or compliance evidence reviewed for invalidation

Documents that quote the design

• [ ] Assembly and inspection procedures
• [ ] Calibration and setup procedures
• [ ] User-facing documentation, if a visible behaviour changed
• [ ] Interface control documents and anything a neighbouring team works from

Firmware and software

• [ ] Pin map, if anything moved
• [ ] Hard-coded constants that mirror a hardware value
• [ ] Compatibility: does old firmware run on the new board, and the reverse?

Commercial and inventory

• [ ] Open purchase orders for superseded parts
• [ ] Stock of the old part: use up, rework or scrap — pick one and record it
• [ ] Boards already built: usable, reworkable or not
• [ ] Supplier notified if they hold your files or your stock

Identification

• [ ] Silkscreen revision, if it changed
• [ ] Product label and any marking that encodes configuration
• [ ] Packaging, if it identifies the version

The questions that catch the expensive ones

Three questions find more missed impacts than any list:

What is already in flight? Boards in production, parts on order, units at a customer. A change that is cheap for future builds can be expensive for the batch currently on the line.

Is old hardware still out there? If yes, every document now has to say which version it applies to. This is the moment a procedure stops being "the procedure" and becomes "the procedure for Rev B and later", and if nobody makes that edit, the document silently becomes wrong for half the fleet.

Who else reads this? Test, purchasing, the firmware team, the mechanical engineer, the contract manufacturer, the certification body. Not all of them, every time — but the list of who you did and did not tell is worth writing down, because the one you forget is the one who finds out at the worst moment.

Scale the effort

Not every change deserves this treatment. A typo in a comment does not.

A workable split:

Minor — no fit, form or function change, nothing released depends on it: update the file, move the revision, done. Significant — affects manufacture, test or interchangeability: run the checklist, record what you checked. * Major — affects the interface, safety, compliance, or hardware already in the field: checklist plus an explicit decision about existing units.

The classification itself is the judgement call, and getting it wrong in the cautious direction costs an hour. Getting it wrong the other way costs a batch.

Record what you checked, not just what you changed

The most common failure is not skipping the analysis. It is running it, finding nothing, and writing nothing down — so six months later, when the problem surfaces, nobody can tell whether the impact was considered and dismissed or never considered at all.

A change record that says "test limits reviewed, unchanged; no open POs; 40 units in stock, use up" is worth more than one that only says what the new resistor value is.

Impact analysis is reading work. It is only as fast as your ability to answer "what else uses this part, this footprint, this document?" — and in most projects that answer is reconstructed by hand each time.

In XKEMA components are shared records rather than text in a spreadsheet, so a part is visible across the projects that use it, and each version of a BOM records what changed and when.

Hardware configuration management Hardware revision control: a practical guide * PCB release checklist