I remember one of the launch meetings from back when I was working as an SQE for the customer. We were reviewing the Reliability Plan.

On paper, it looked like a pretty standard document. A table, some data, references to FMEA and DVP&R, a few actions, a few comments. Nothing special at first glance.

And yet, documents like this often tell you more about the real condition of a project than another status presentation full of green indicators.

If the document is well prepared, it usually means the team has connected lessons from previous projects, field data, risk analysis, design actions, and validation testing.

If it is poorly prepared, it becomes just another box to tick during a meeting. That is what makes this topic interesting.

The document itself does not protect anything. What matters is what comes out of it for the project, the tests, and the team’s decisions.

In that sense, it is a bit like a procedure nobody follows. The document alone does not reduce risk. Only the actions behind it do.

What is a Reliability Plan?

In simple terms, a Reliability Plan is a document used to organize the team’s thinking about product risk before mass production starts.

It is not just about listing durability tests, functional checks, or a few validation points. It should help the team build a common view of:

• what may go wrong,
• which components are affected,
• why this risk is considered relevant,
• what needs to be verified,
• what needs to be changed,
• and who is responsible.

This is where I often see the first problem.

A lot of people in the organization, especially in manufacturing plants, do not really know this document. And when they do, they often see it as something owned by the lab. But this is not a document only for test engineers.

It should be useful for the whole project team: quality, R&D, suppliers, validation, and sometimes even the people handling claims, especially warranty returns.

In practice, it sits somewhere between APQP, FMEA, and DVP&R. Its role is to connect risk with action and help the project move toward a safer start of production.

It is not just a test list

When the Reliability Plan turns into nothing more than a test list, it loses most of its value.

That is when you see entries like:

• run a test,
• check durability,
• confirm in DVP&R,
• topic to be verified.

Technically, something is written down. But in reality, those entries do not say much. A good document should show a simple logic:

• What problem do we see?
• What does it affect?
• Why do we believe the risk is real?
• What action is supposed to reduce it?

That is a very different level of thinking.

What this document should show in practice

In most cases, the finished product is broken down into components and specific failure symptoms.

For example, when I was working with complete seats, typical topics included wear of headrest components, excessive play in interacting mechanisms, the effect of temperature on adjustment, interference between neighboring parts, incorrect PUR foam density in the cushion, backrest, or headrest, and issues caused by incorrect tightening torque.

There should also be links to DVP&R, DFMEA, PFMEA, CAD analysis, and design actions. That is how it should look. Not: “the seat may have an issue”. But rather:

• which component,
• what symptom,
• what failure mode or mechanism,
• what action is planned,
• what evidence will confirm closure.

It sounds simple, but this is exactly the level of detail that separates a useful document from one that only exists for review meetings.

Where do the entries come from?

A better question is not, “What did we put into the plan?”

A better question is, “Why is this topic in the plan at all?”

A solid Reliability Plan should not come from random brainstorming during a meeting. This is not an Ishikawa exercise.

It should be built from several real sources. The first one is previous field issues.

If a similar component had a problem in the past with looseness, wear, noise, cracking, adjustment, or appearance, that is not just an old story. It is a warning sign for the new project. It should also be treated as part of a proper Lessons Learned approach.

The second source is FMEA. And I do not mean saying during a presentation, “It’s covered in the FMEA.” I mean DFMEA or PFMEA should actually help identify where the product or process is vulnerable.

The third source is DVP&R and other validation agreements. If the team already knows which tests are supposed to confirm the robustness of the solution, the Reliability Plan should reflect that.

The fourth source is experience.

Sometimes somebody from quality, product development, or the supplier remembers a similar issue from a previous launch. That experience matters too, as long as it leads to something specific and not just a vague story with no action behind it.

What should a quality professional look for?

From a quality point of view, this document should help you ask difficult questions before the customer does. I would start with five things.

1. Is the problem clearly described?

If you see an entry like “possible issue” or “to be checked,” you still do not know much. It is far better when the document says exactly what the concern is:

• excessive freeplay,
• noise,
• component wear,
• foreign body in a mechanism,
• poor adjustment under changing temperature conditions,
• contact between two neighboring parts.

Then at least everyone is talking about the same thing.

2. Is the source of the risk clear?

This is a big one. If the topic comes from DFMEA, PFMEA, DVP&R, a previous program, CAD analysis, or field issues, then the entry has a real foundation.

If nobody knows where the topic came from, there are usually two possibilities. Either it was added just in case. Or it is so general that no one can really defend it. Neither option helps the plan.

3. Does the action actually address the problem?

This is where weak plans start to show.

You have a risk related to a foreign body in the adjustment mechanism, but the action is written so broadly that it could apply to five other issues.

You have a problem with excessive play, but the action ends with a generic “verify in testing.”

You have a temperature-related risk, but no one has defined under what conditions it will be assessed.

These are all signs that the document is not yet driving real decisions.

4. Is there an owner and a deadline?

Without an owner and a due date, the plan quickly becomes a wish list.

Everybody sees the issue. Everybody agrees it matters. But nobody feels responsible for closing it.

Then the next review comes, and the topic is still open, just described a bit more nicely.

Or worse, it is already marked green and quietly pushed toward the plant to deal with later.

5. Is the evidence of closure defined?

A green status is not evidence. It is worth repeating, because this comes back again and again: a green status is not evidence. Evidence can be:

• a test result,
• a design change,
• validation confirmation,
• an updated DVP&R,
• an updated FMEA,
• supplier confirmation,
• analysis results after the change has been implemented.

If that is missing, then the topic may look closed only in the spreadsheet.

How to spot a living document

You can usually tell very quickly whether the plan is alive or whether it was created mainly for meetings.

A living Reliability Plan has specific entries. You can see the logic behind them. You can see updates, reactions to new information, and closures based on real evidence.

A dead document looks different.

It is full of generic wording. The status column looks nice. Some entries say “to be confirmed.” Owners are vague, sometimes listed only as a function instead of a name. Test results do not lead to a clear decision.

That is when the illusion starts. The team believes the project is covered because the document exists. Not really. Documentation can exist and still do very little to protect the project.

What this says about project maturity

To me, this is one of the most interesting things about a Reliability Plan. It does not only show product risk.  It also shows the quality of the team’s thinking.

If the team can take previous issues, transfer them into a new project, connect them with FMEA, validation, and design decisions, that shows maturity.

If every new program starts as if the company were building that component for the first time, that also shows.

And it usually ends the way you would expect. The automotive industry is not short of tools for learning from past mistakes. We have 8D, Lessons Learned, Read Across, FMEA, claim reviews, and usually warranty data as well. The problem is rarely the lack of tools.

The real problem is that many organizations still struggle to turn those tools into specific actions during a new launch.

What should come out of this document?

A good Reliability Plan should lead to decisions.

Sometimes those decisions are:

• add another test,
• modify the part,
• improve the geometry,
• change the material,
• add a safeguard,
• go back to the supplier,
• update the FMEA,
• add the topic to Lessons Learned.

That is when the document starts to matter. If nothing changes after the review apart from the status in the table, then it does not really matter how many lines the document contains.

Dariusz Kowalczyk