WRYGTENGINEERING · MANUFACTURING · PRODUCTS

Insights

Working notes from the methods we actually use.

Short, practical reference notes on the tools that come up on almost every hardware program we touch: risk analysis, design transfer, process qualification, and the statistics behind "is this process actually in control."

Obsolescence

BOM scrub: finding EOL risk before it finds you

A BOM scrub is a systematic pass through every line of a bill of materials, checking each component's real lifecycle status against manufacturer PCNs and distributor data, rather than waiting for a discontinuation notice to land in an inbox. The point isn't reacting to what a supplier decides to announce, it's finding the parts showing early warning signs before anyone's issued a formal notice at all.

This is core, hands-on work for us, not a generic add-on: scoring real risk by criticality and sourcing, not just lifecycle status, and qualifying real alternates against footprint, electrical, and mechanical fit, not just a datasheet comparison.

Read the full guide →

Design

DFM: designing for the line, not just the bench

Design for Manufacturability means making component, layout, and tolerance decisions with the actual build process in view, before those decisions get locked in. A schematic that works perfectly on a bench prototype can still be a nightmare to place, solder, test, or source at volume if manufacturability wasn't part of the original design conversation.

In practice this means favoring standard footprints and package sizes over exotic ones, checking part availability and lead time before it becomes a BOM line item, keeping tolerances as loose as the design honestly allows, and involving whoever will actually build the board while the layout is still editable, not after it's frozen. The earlier DFM review happens, the cheaper every fix is; the same change that's a five-minute layout edit in week two can be a re-spin in week twelve.

Read the full guide →

Risk Analysis

DFMEA: finding failure modes on paper, before they show up in the field

Design Failure Mode and Effects Analysis is a structured way of asking "what could go wrong with this design, and how bad would it be" before the design is finished. For each function or feature, the team lists the ways it could fail, what would cause that failure, and what the downstream effect would be, then scores each one for severity, likelihood of occurrence, and how likely it is to be caught before it reaches a customer.

The output isn't the spreadsheet itself, it's the short list of highest-risk items that actually change the design: an added interlock, a different connector keying scheme, a tighter tolerance on one critical dimension. Done well, a DFMEA is a working document that gets revisited as the design matures, not a one-time exercise completed for an audit trail and then filed away.

Read the full guide →

Risk Analysis

PFMEA: the same discipline, applied to how it's actually built

Process Failure Mode and Effects Analysis asks the same questions as DFMEA, but about the manufacturing process rather than the design itself: at each process step, what could go wrong, why, and what happens downstream if it does. A reflow profile that's slightly off, a fixture that allows a part to be seated backward, an operator step that's easy to skip under time pressure, these are the kinds of failure modes a PFMEA is built to surface.

The two documents should talk to each other. A design characteristic the DFMEA flags as high-severity should show up in the PFMEA as a process step that gets tighter controls, not just an inspection step added after the fact. Prevention, fixturing, error-proofing, parameter interlocks, catches more than a final visual check ever will; if every action item on a PFMEA is "add an inspection," that's usually a sign the root causes weren't addressed.

Read the full guide →

Manufacturing

Design transfer: where good documentation earns its keep

Design transfer is the handoff from "we have a validated design" to "someone else can build it correctly, repeatably, without the original design team in the room." That covers the BOM, schematics, layout files, assembly drawings, and test procedures, but the part that actually determines whether the transfer succeeds is usually the information that never made it into a formal document: why a tolerance is tighter than it looks like it needs to be, why a specific supplier was chosen for one component, what almost went wrong during bring-up.

This is exactly the moment obsolescence issues and undocumented tribal knowledge tend to surface, often during a supplier change or a contract manufacturer switch. A design transfer that's treated as a real engineering activity, with the receiving team asking questions and the sending team available to answer them, catches these gaps before they become a production stoppage instead of after.

Read the full guide →

Manufacturing

Process qualification: IQ, OQ, and PQ in plain terms

Qualifying a manufacturing process before it goes live usually happens in three stages. Installation Qualification confirms the equipment itself is installed correctly and calibrated: right machine, right settings, documented as-built. Operational Qualification confirms the process performs as intended across its expected operating range, not just at one ideal setpoint. Performance Qualification confirms the process holds up under real production conditions, typically across multiple lots, operators, and shifts, not just in a controlled trial run.

Skipping straight to PQ without a real IQ and OQ behind it is a common shortcut, and it's usually where "it worked in the qualification run but not in production" problems come from. Each stage is answering a genuinely different question, and problems caught at IQ are far cheaper to fix than the same problem discovered three lots into production.

Read the full guide →

Statistics

Process capability: what Cp and Cpk are actually telling you

Process capability indices answer a simple question with real statistical weight behind it: given the natural variation in a process, how comfortably does its output fit inside the specification limits? Cp compares the spread of the process to the width of the tolerance band, assuming the process is perfectly centered. In the real world, processes drift off-center, which is exactly what Cpk accounts for: it takes the same spread but measures it against whichever spec limit the process is actually closest to.

A high Cp with a low Cpk is a specific, useful signal: the process is consistent enough to meet spec, it just isn't centered where it needs to be, which is usually a setpoint or fixturing fix rather than a fundamental process redesign. As a rule of thumb, a Cpk around 1.33 is a common baseline for a stable process; medical and other high-reliability applications often expect more. The number only means something if the underlying data is genuinely representative of normal production, not a hand-picked best run.

Read the full guide →

Statistics

DOE: changing more than one variable on purpose

Design of Experiments is a structured way to figure out how multiple variables affect an outcome at the same time, instead of testing them one at a time. Changing one factor per test run feels intuitive, but it's slow, and worse, it misses interactions between variables that only show up when two or more of them move together. A well-designed experiment changes several factors in a planned pattern across a small number of runs, then uses the results to show which factors actually matter, how much, and whether any of them interact.

For a manufacturing process, that might mean testing reflow temperature, dwell time, and stencil thickness together across a fraction of the combinations a full one-at-a-time approach would need, and coming out the other side with an actual model of the process instead of a handful of disconnected data points. It's most valuable exactly where intuition is weakest: processes with several interacting variables and a real cost to getting a production run wrong.

Read the full guide →

Design

GD&T: tolerancing that describes function, not just size

Geometric Dimensioning and Tolerancing is a drawing language for specifying not just how big a feature is, but how it's allowed to vary in position, orientation, form, and how it relates to other features, in a way that maps to how the part actually needs to function. A plus-or-minus tolerance on a linear dimension can be technically satisfied while the part still doesn't fit or align correctly; GD&T callouts like true position, flatness, and datum references are built specifically to prevent that gap.

Used well, GD&T gives manufacturing and inspection an unambiguous, function-based standard to build and measure against, which tends to open up tolerances that don't actually matter while tightening the ones that do, rather than applying one tight number everywhere out of caution. That combination, looser where it's safe and tighter where it counts, is usually what makes a design both manufacturable and reliably correct.

Read the full guide →

Working through one of these on a real program?

These notes are a starting point, not a substitute for looking at your actual design or process. Tell us what you're working on.

Start a Project