Why quality, supply chain and product release cannot be separate workstreams

A product cannot be released independently of its supply chain

When people talk about product readiness, they tend to think about engineering completion.

Does the product meet the requirements?

Has validation been completed?

Does it work?

Those questions are essential.

They are not sufficient.

A product cannot be manufactured without material.

The material cannot simply be available.

It has to be the correct material, from appropriate sources, in the required quantities and under the appropriate controls.

That means product readiness also depends on questions such as:

Are the production components approved?

Are suppliers qualified?

Are long-lead items ordered?

Are component alternates controlled?

Is the BOM released?

Are supplier part numbers correct?

Are minimum order quantities understood?

Are lead times credible?

Are custom parts drawing-controlled?

Is sufficient material available for the planned ramp?

A product with a completed design but an unqualified supply chain is not ready for production.

It is an engineering design waiting for a manufacturing system.

Quality begins before material reaches the factory

Quality cannot simply inspect whatever purchasing delivers.

By then, many of the important decisions have already been made.

Supplier selection is a quality decision.

Component selection is a quality decision.

Specifications are quality decisions.

Approved substitutes are quality decisions.

Tooling is a quality decision.

Packaging can be a quality decision.

Transportation conditions can be a quality decision.

If quality becomes involved only when parts arrive at incoming inspection, it has joined the process far too late.

The same applies to supply chain.

Procurement cannot successfully source a production product if engineering has created a BOM without considering:

availability,

lifecycle,

lead time,

approved sources,

regional restrictions,

minimum order quantities,

or alternate parts.

The functions need to interact during product development rather than exchanging problems after design completion.

The BOM is where the workstreams meet

The Bill of Materials is one of the most important control points in a product business because it connects several disciplines at once.

Engineering sees the product definition.

Supply chain sees demand.

Manufacturing sees material requirements.

Quality sees controlled components and approved sources.

Finance sees product cost.

Service sees replacement parts.

Regulatory may see components forming part of the approved configuration.

A weak BOM control process therefore creates problems across the business.

Before release, the organisation needs to know:

Which BOM revision is production authorised?

Which manufacturer part numbers are approved?

Which supplier sources are approved?

What alternates exist?

What quantities are required?

Which components are long-lead?

Which components are obsolete or at lifecycle risk?

What material has already been purchased?

What becomes obsolete if the BOM changes?

This is why a spreadsheet passed informally between engineering and purchasing becomes increasingly dangerous as the company grows.

There has to be a controlled product definition.

Approved part does not automatically mean approved supplier

This distinction becomes increasingly important as volume grows.

Engineering may approve a specific component manufacturer and part number.

That does not mean every source from which that part can be purchased represents the same level of risk.

Material from:

an authorised distributor,

the original manufacturer,

an approved broker,

an unknown marketplace,

or surplus stock

does not necessarily provide equivalent traceability or assurance.

Supply-chain pressure can encourage companies to blur those distinctions.

A critical component becomes unavailable.

A broker has stock.

The programme needs to ship.

The purchase looks like a procurement decision.

It is actually a quality and product release decision as well.

Can authenticity be demonstrated?

Has storage been controlled?

Does the date code matter?

What inspection is required?

Does the material need additional testing?

Who has authority to accept that risk?

That decision should not be left to whichever buyer happens to be dealing with the shortage.

Supplier qualification should follow product risk

Not every supplier requires the same level of control.

A supplier providing office stationery obviously creates different risk from a supplier producing a safety-critical machined component.

Supplier qualification should therefore be proportionate.

Factors might include:

product criticality,

technical complexity,

manufacturing process,

regulatory significance,

single-source dependency,

financial exposure,

custom tooling,

quality history,

and difficulty of replacement.

Higher-risk suppliers may justify:

formal audits,

process validation,

quality agreements,

first-article approval,

capability studies,

greater incoming inspection,

and regular performance reviews.

Lower-risk suppliers may require much less.

The objective is not to create paperwork.

It is to direct quality effort towards the parts of the supply chain capable of materially affecting the product.

Product release needs objective evidence

One of the most dangerous phrases in a hardware programme is:

"We should be ready."

Production release should not depend on confidence.

It should depend on evidence.

The organisation should define what must be true before the product can move to the next stage.

Depending on the product, release evidence might include:

• Product requirements approved
• Design released
• Verification completed
• Validation completed
• Production BOM released
• Critical suppliers approved
• Long-lead material available or committed
• Manufacturing process defined
• Tooling available
• Work instructions released
• Production test validated
• Quality controls defined
• Packaging approved
• Regulatory requirements satisfied
• Software and firmware released
• Traceability defined
• Service documentation available
• Known deviations approved
• Pilot build completed
• Yield within acceptable limits

Not every business requires every item.

The principle is that the company decides in advance what evidence is required rather than negotiating readiness when the launch date is already under pressure.

The gate should expose problems, not hide them

Stage gates are sometimes treated as management theatre.

Slides are prepared.

Status indicators are made green.

The meeting takes place.

The programme passes because everybody knows that missing the date would be difficult.

That destroys the value of the gate.

A gate exists to answer a specific question.

Has enough uncertainty been removed to justify committing the company to the next stage?

For a production release, the next stage may involve substantial financial exposure.

Tooling.

Inventory.

Factory capacity.

Customer commitments.

Freight.

Regulatory liability.

Once those commitments are made, reversing the decision becomes expensive.

The gate should therefore make remaining uncertainty visible.

Passing with approved exceptions can be entirely reasonable.

Pretending the exceptions do not exist is not.

Supply-chain readiness should be part of the release decision

A product should not pass a production gate simply because engineering is complete.

Supply-chain readiness needs objective evidence of its own.

For example:

What percentage of the BOM has an approved source?

Which items are single source?

Which components exceed the required lead-time window?

Which purchase orders are outstanding?

What material is constrained?

What quantity can actually be built?

Where are alternates required?

How much material is at risk?

What inventory has been purchased against forecast?

What components have unresolved lifecycle concerns?

If the answers are unknown, the production plan is largely theoretical.

A red supplier issue can invalidate a green product plan

Programme dashboards often make each workstream separately green, amber or red.

That can create false confidence.

Suppose engineering is green.

Manufacturing is green.

Regulatory is green.

Quality is green.

Supply chain is red because a critical custom component will be six weeks late.

The product is not 80 percent green.

It is six weeks late.

Dependencies matter more than averages.

The same principle applies if one critical test is incomplete or one regulatory approval prevents legal sale.

Product readiness should therefore be assessed against critical-path conditions rather than an average of departmental status.

Engineering changes connect everything

Engineering change is where separate workstreams most visibly fail.

Consider a design change introduced shortly before launch.

Engineering may ask:

Does the new part meet the specification?

Operations has to ask substantially more.

Is the part available?

Has the supplier been approved?

Does the change affect tooling?

Does it change the manufacturing process?

Is the existing material now obsolete?

Does it change the test limits?

Does firmware need updating?

Does packaging change?

Does regulatory evidence remain valid?

Does the service organisation need new spare parts?

Which serial number introduces the change?

Which customer receives which configuration?

A properly designed Engineering Change Order process brings those decisions together.

Without it, every function can independently implement part of the change while the overall product configuration becomes unclear.

Late changes are particularly expensive

The cost of a product change generally increases as the product moves closer to production.

Early in development, changing a component may mean updating a schematic.

Later, the same change may affect:

existing inventory,

purchase orders,

tooling,

production documentation,

test equipment,

validation,

regulatory submissions,

packaging,

service stock,

and customer commitments.

That does not mean late changes should never happen.

Sometimes they are necessary.

But the decision should account for total impact.

The engineering value of the change must be compared with its operational consequences.

This is another reason quality and supply chain need to be involved before the decision is approved.

Deviations need controlled ownership

Production reality occasionally requires temporary departures from the released design or process.

A preferred component may be unavailable.

A drawing may contain an error.

A rework may be necessary.

A temporary manufacturing process may be required.

Companies often handle this informally.

"Use these parts for this batch."

"Engineering says it is fine."

"Build the next ten this way."

That approach becomes dangerous quickly.

A controlled deviation should establish:

what is changing,

why,

which units are affected,

what risk assessment has been performed,

who approved it,

how long the deviation applies,

what additional inspection or test is required,

and how the normal configuration will be restored.

Temporary changes have a habit of becoming permanent when nobody owns their closure.

Production quality needs to be designed, not added

Quality inspection should not be the mechanism by which a weak process becomes acceptable.

If the manufacturing process repeatedly creates defects, adding more inspectors treats the symptom.

The preferred hierarchy is normally:

prevent the defect,

detect it within the process,

detect it immediately afterwards,

and rely on final inspection only where appropriate.

That means quality needs to participate in process design.

Where can defects occur?

Which characteristics are critical?

Which processes require validation?

What should operators check?

What should be automated?

What should be measured?

What requires traceability?

Which failures can escape to the customer?

This is where tools such as process FMEAs and control plans become useful, provided they drive real manufacturing controls rather than becoming documents created purely for audits.

First-pass yield is a release metric, not just a factory metric

A product that can eventually be made correctly is not necessarily production ready.

Suppose the pilot build produces 100 units.

Ninety-five eventually pass.

That sounds reasonably good.

But if only 55 pass the first time and 40 require rework, there is a serious production problem.

The organisation needs to understand:

why units failed,

where they failed,

whether the failure is design or process related,

how much labour rework consumes,

whether rework creates additional risk,

and whether the failure mode will worsen at volume.

First-pass yield therefore provides information about design maturity, manufacturing process quality and production economics simultaneously.

It should be visible during release decisions.

Quality data should flow back to engineering and supply chain

One of the most valuable characteristics of a mature operating system is the feedback loop.

A defect occurs.

Manufacturing records it.

Quality analyses it.

The root cause identifies a supplier issue.

Supply chain works with the supplier.

Engineering changes a tolerance.

The control plan is updated.

Future production improves.

Without that loop, quality becomes a repair service.

It detects the same problems repeatedly.

Good quality systems turn manufacturing data into product and process improvement.

Supplier quality is not something procurement can delegate away

A contract manufacturer may manage hundreds of component suppliers.

That can provide major operational benefits.

It does not remove the product company's interest in supplier quality.

The company still needs to understand:

who supplies critical components,

where those components are manufactured,

which sources are approved,

where major quality risks exist,

how supplier changes are controlled,

and how significant failures are escalated.

The more important the component, the less comfortable the company should be with complete invisibility.

Outsourcing purchasing is not the same as outsourcing accountability for the product.

Regulatory compliance depends on configuration

For regulated products, the relationship becomes even tighter.

Approvals are normally associated with a defined product configuration.

Changing:

a power supply,

radio module,

safety component,

material,

firmware function,

enclosure,

or manufacturing process

may affect the evidence supporting compliance.

That means engineering and supply-chain changes can become regulatory decisions.

If procurement substitutes a component because it is cheaper or more available, the technical performance may remain acceptable while the approved product configuration no longer does.

Regulatory involvement therefore needs to be risk based and integrated into change control rather than operating as an isolated certification project.

Packaging belongs in release readiness too

Packaging is often left surprisingly late.

It should not be.

The product needs to survive the journey between the factory and customer.

That may involve:

vibration,

shock,

humidity,

temperature,

stacking,

handling,

air freight,

sea freight,

storage,

and repeated loading.

If packaging is not validated until after production begins, the company risks discovering that a perfectly manufactured product arrives damaged.

Packaging also affects:

shipping cost,

warehouse utilisation,

customer experience,

environmental obligations,

and sometimes regulatory labelling.

It is part of the production system and should therefore form part of release readiness.

Logistics can reveal design decisions

The same applies to logistics.

A product may be technically excellent but expensive or impractical to move.

Dimensions affect freight class.

Weight affects handling.

Lithium batteries affect transport requirements.

Dangerous goods classification affects carriers.

Wood packaging can create phytosanitary requirements.

Country of origin affects duty.

Product architecture can therefore have logistical consequences.

These questions should appear while the product is still being designed rather than after manufacturing has started.

Release quantity should reflect maturity

One of the strongest risk controls available to a hardware business is production quantity.

A company does not have to move directly from ten prototypes to 10,000 production units.

A sensible ramp may progress through controlled quantities.

For example:

10 units,

then 25,

then 100,

then 500,

with defined evidence required before each increase.

The exact quantities depend on product economics.

The principle is powerful.

Each build produces evidence.

Yield improves.

Processes stabilise.

Supplier performance becomes visible.

Field reliability emerges.

Documentation improves.

The company increases financial exposure as uncertainty decreases.

This is far safer than committing to large volume because the annual forecast says those units will eventually be required.

Early production should be treated as learning

Low-rate initial production is not simply inefficient full-rate production.

It serves a different purpose.

The organisation should deliberately use early builds to understand:

cycle time,

yield,

material shortages,

operator feedback,

test performance,

documentation gaps,

supplier issues,

failure modes,

and engineering support requirements.

Those observations should feed back into the product and manufacturing process before the next rate increase.

A production ramp is therefore a controlled learning process.

The company should not ask only:

"How many did we build?"

It should ask:

"What did this build prove?"

The release meeting needs real authority

A release process only works if the people making the decision have authority to stop or condition the release.

That can be uncomfortable.

Commercial teams may have promised a shipment.

Investors may expect a milestone.

Manufacturing may have allocated capacity.

Customers may be waiting.

But if every gate automatically passes because the date cannot move, the organisation does not have a release process.

It has a calendar.

A robust release meeting should allow several outcomes:

approved,

approved subject to defined conditions,

limited release,

pilot quantity only,

or not approved.

Exceptions should have:

an owner,

a deadline,

a risk assessment,

and clear closure evidence.

Ownership must be clear without creating silos

Integration does not mean everybody owns everything.

That creates confusion.

Responsibilities should remain clear.

Engineering owns the design.

Supply chain owns material availability and supplier management.

Quality owns assurance and the quality system.

Manufacturing owns the production process.

Regulatory owns compliance strategy.

Programme leadership owns integrated delivery.

Operations usually ensures the system joins together.

The important point is that none of those functions should be able to declare success independently when a dependency remains unresolved.

Functional ownership and integrated decision-making can coexist.

They have to.

One integrated readiness view is better than six status reports

Leadership does not need six departments telling it that their own work is progressing.

It needs to know whether the company can release the product.

A useful readiness review should therefore organise information around the decision rather than the departments.

For example:

Product

Is the design stable and validated?

Material

Can we build the required quantity using approved parts?

Manufacturing

Can the intended process repeatedly build it?

Quality

Are risks controlled and evidence available?

Compliance

Can the product legally be placed on the intended market?

Commercial

Are the economics and customer commitments understood?

Service

Can the company support the product after shipment?

Risk

What remains unresolved and what could prevent release?

This creates one view of reality.

The objective is controlled confidence

No product reaches production with zero risk.

Waiting for perfect certainty would prevent almost every launch.

The objective is different.

Management should know:

what has been proven,

what has not,

what risk remains,

who owns that risk,

and why the remaining uncertainty is acceptable.

That is controlled confidence.

It is very different from hoping that the remaining problems will be solved during production.

The seams are where hardware programmes fail

Most serious operational failures do not sit neatly inside one department.

They happen between departments.

Engineering and supply chain.

Supply chain and quality.

Quality and manufacturing.

Manufacturing and logistics.

Commercial and capacity.

Engineering and regulatory.

Those interfaces are where assumptions go unchallenged and responsibility becomes ambiguous.

A strong product business therefore pays disproportionate attention to the seams.

The company does not need more meetings or more paperwork.

It needs an integrated release process that forces the important dependencies to become visible before money, material and customer commitments make them expensive.

Because quality cannot guarantee a product whose supply chain it does not understand.

Supply chain cannot secure a product whose design is still moving without control.

And a programme manager cannot release a product simply because the planned date has arrived.

Product release is the point at which all three have to become true at the same time.