Problem Solving & Quality · State

Closure Criteria First

Before any analysis, agree the measurable result and the observation period that will allow you to declare the problem closed.

Time20 min
FormatSmall group
StageState

Closure Criteria First: what it is and why it works

Closure Criteria First means agreeing, before any analysis starts, on the measurable result that will allow the problem to be declared solved. The team chooses the indicator that expresses the problem, records its baseline over a representative period, sets a target value and a minimum observation period, and names who will judge closure on which data source. These criteria are written at the top of the problem file, so every review is measured against the same finish line.

Setting the finish line early protects against two common failures: problems closed because the team has moved on, and actions declared effective simply because they were implemented. It also forces an honest look at the data before anyone has a favorite cause. The observation period is the subtle part. For rare events, a few quiet weeks prove little, so the period must be long enough that the problem would normally have occurred several times. The criteria feed the effectiveness check at the end and match the expectation in 8D and ISO 9001 that corrective actions are shown to work. A pilot run gives early evidence; the closure criteria decide when the case is really over.

What you need

A deviation statement naming the indicator and its units
Historical data long enough to establish a baseline
An estimate of how often the problem occurs, to size the observation period
Agreement from the person or customer who will judge closure

What you get

A named indicator with its baseline value and period
A target value that counts as solved
A minimum observation period or number of production campaigns
A named judge and data source
A criteria block at the top of the problem file

When to use it

When problems are closed because people are tired of them, then come back.

How to do it, step by step

Choose the indicator that expresses the problem: scrap rate, downtime hours, complaints, off-spec batches.
Record its baseline over a representative period.
Set the target value that counts as solved and the minimum observation period — for example eight weeks or three production campaigns.
Name who will judge closure and on which data source.
Write the criteria at the top of the problem file, where every review will see them.

Worked example: Recurring seal failures on slurry pumps

Illustrative scenario — figures are realistic but not from a real company.

A mineral-processing plant has replaced mechanical seals on its cyclone-feed slurry pumps 11 times in 26 weeks, roughly one failure every 2.4 weeks, at about $9,000 per event including lost throughput. A previous task force had 'closed' the problem twice after a quiet month.

Indicator: seal failures across the four cyclone-feed pumps, taken from CMMS work-order history.
Baseline: 11 failures in 26 weeks, confirmed by matching work orders to seal kits issued from the storeroom.
Target and period: no more than one failure in 20 weeks. At the baseline rate about eight failures would be expected in 20 weeks, so a quiet period of that length is meaningful; a quiet month is not.
Judge and source: the maintenance superintendent, using CMMS data reviewed with the reliability engineer.
The criteria were typed at the top of the A3 before the first cause-analysis session.

Result. Six weeks after the first fix, a change to gland-water flow control, the team wanted to close the case. The criteria kept it open. A failure in week 9 revealed a second cause: a worn impeller on one pump raising seal-chamber pressure. After both fixes, the plant recorded one failure in 20 weeks and closed the case on data rather than fatigue.

Open it in the FieldKit Problem Solving app → Get the Problem Solving template pack — join the waitlist

Common pitfalls and how to avoid them

Using completion of actions as the closure criterion.Judge closure on the problem indicator, not on the number of actions done.
An observation period too short for a rare event.Size the period so that several events would have been expected at the baseline rate; a simple Poisson estimate is enough.
Quietly moving the target halfway through.If new facts justify a change, record the reason and have the named judge approve it.
Starting without a baseline.Reconstruct the baseline from records before analysis; without it, improvement cannot be demonstrated.

Frequently asked questions

How long should you monitor after a corrective action?

Long enough that the problem would have shown up several times if it were still there. Start from the baseline frequency: if a failure used to occur about once every three weeks, about three would be expected in nine weeks, and seeing none by pure chance would happen roughly one time in twenty. For frequent defects, a few weeks of daily data may be enough; for rare events, plan months or several production campaigns.

What is the difference between verification and validation of a corrective action?

Verification checks that the action was implemented as planned: the new part is installed, the procedure is updated, people are trained. Validation, often called the effectiveness check, shows that the problem indicator actually improved and stayed improved over the agreed period. Closure criteria define what validation must show. Many problems return because only the first step was done.

Who should decide when a problem is closed?

Someone who owns the result and did not do the work, often the process owner, the plant quality manager or, for customer issues, the customer's quality contact. Naming the judge and the data source at the start avoids disputes later. The problem-solving team proposes closure with evidence, and the judge accepts or rejects it against the criteria written at the start.

Origin

SiliciumHex original, in line with the effectiveness-verification step of 8D and ISO 9001 corrective action.

Related methods

More in “State”

Describe the problem as a measurable gap — no cause, no culprit, no solution yet.