Vision Project Risk Register
Vision projects fail in repetitive ways. Setting them out as a register and working through it at proposal and scheme review is far more useful than reconstructing what went wrong afterwards. Nothing in this list is unusual: each item is something most projects encounter to some degree. The difference between projects is whether the risk was identified in advance with an action attached, or met for the first time on the day it happened.
Key takeaways
- The value of a register is early identification, not exhaustiveness.
- Unfrozen criteria, insufficient samples and an overrun cycle are the three most common.
- Every entry needs a warning signal, an action and a named owner.
- Revisit the register during the project, not only at kick-off.
Risk management in practice often means a table of vague entries — "possible delay", "technical risk may exist" — which is then filed and never read. This register is deliberately different. Each entry describes a recognisable situation, a signal that can be observed while there is still time to act, and a specific action. They are drawn from what projects actually run into, not from what might conceivably happen.
The register
| Risk | Warning signal | Action |
|---|---|---|
| Criteria not frozen before development | Criteria still changing after kick-off; "we will tune it once it runs" | Make freezing the criteria a milestone; no detailed development before it |
| Insufficient acceptance samples | Fewer than a few dozen defect samples; only good parts available | State the shortfall as a contractual risk and agree a supplementary acceptance |
| Cycle time overrun | Single frame time close to or above the takt; no margin left | Build a cycle budget with margin at proposal stage, see [the budget](blog/takt-time-and-inspection-budget) |
| Real conditions worse than assumed | No images taken on the real line; only laboratory samples seen | Image the real line before development, including the worst conditions |
| Environment unchecked | Vibration, dust, temperature, humidity, ambient light not assessed | Assess each at the site survey and write them in as stated assumptions |
| Interfaces undefined | Data exchange with the line or MES described only verbally | Agree a written field list before development and have both sides sign it |
| Parameters drifting out of control | Parameters adjusted on the line with no record kept | Establish parameter control before go-live, see [change management](blog/visual-sop-change-management) |
| Loss of a key person | The project depends on one or two people's personal knowledge | Build documentation and the sample library during the project, not at the end |
| Supplier capability mismatch | Answers stay general; "yes we can do that" without specifics | Use the question list in [vendor evaluation](blog/visual-sop-vendor-evaluation) |
| Acceptance dispute | Criteria in the contract not measurable, or read differently by each side | Write targets as numbers and confirm them before kick-off |
The three that come up most
Criteria that are not frozen lead the list. The sign is a project already selecting cameras, writing algorithms and designing lighting while "what counts as acceptable" is still under discussion. Every technical decision made in that state rests on a moving foundation — change the criteria and the camera choice may no longer suit, the lighting may need redesigning, and half the labelled samples may need relabelling. Freezing the criteria does not mean they can never change again; it means there is a formal moment that moves them from "in discussion" to "confirmed, proceed", after which changes follow the change route.
Insufficient acceptance samples comes second. Acceptance depends on samples, particularly defect samples, and defect samples arise by chance — a defect that does not occur during trial production may appear months into volume production, by which time it emerges the system was never shown an example. The response is not to wait. At proposal stage, state plainly that if a defect class cannot be represented, the acceptance scope narrows accordingly, or the contract provides for a supplementary acceptance once samples exist. Leaving it vague means an uncomfortable conversation at the end.
Cycle time overrun comes third, and its distinguishing feature is that it is discovered late. During development the timings come from single images and look comfortable. Only at integration, with several cameras running together and communication and logging overhead included, does the end-to-end figure emerge. By then the remaining options are limited — reduce resolution or add compute — and both require re-validating accuracy. This is why the cycle budget belongs at proposal stage and should be checked against at every selection decision.
Common questions about project risk
Does a small project need all this?
The register can be shortened but two entries cannot be dropped: freezing the criteria, and fixing acceptance criteria in advance. Small projects have smaller budgets and therefore less room to absorb rework, so the proportional cost of changing criteria mid-flight is higher. A five line version, worked through once, is enough.
What happens when a risk materialises?
Establish which kind it is. If a stated assumption changed — the criteria were revised, the operating conditions differ — the scheme needs reassessing and the change goes through the change route, with schedule and cost renegotiated accordingly. If it is an execution failure, such as parameters drifting or the sample library not maintained, the fix is in the process rather than the scheme. Discussing the two together turns a technical review into a search for who to blame.
How do I decide whether a risk belongs in the register?
The test is whether its occurrence would change the scheme or the schedule. If it would, it belongs. If it would merely be inconvenient, it does not. For example, dust heavier than expected is a register entry if it means adding an enclosure or changing the camera; it is not one if it only means wiping the window more often, which is ordinary maintenance.
Which of these will bite you?
Tell us the project stage, the state of the criteria and the acceptance arrangements. We will identify the entries most likely to become problems.
Related articles
-
Alarm Fatigue: Why the Floor Turns the System Off
Many visual SOP systems are not beaten by technical problems — they are muted by…
Read more → -
Visual SOP Camera Selection and Mounting
Camera selection for visual SOP is not the same as for product inspection. The s…
Read more → -
Vision Monitoring at the Semiconductor Die Bonder
Semiconductor packaging stations are characterised by high precision, fast cycle…
Read more → -
Wrong-Assembly Alarms Without the False Alarms
The most common reason a visual SOP project fails is not poor recognition — it i…
Read more →
Need specific advice for your production line?
Our engineers can share practical approaches to process error prevention and SOP compliance inspection for your scenario.
Request a free trial plan