How These Deployments Fail

Video analytics deployments fail in recognisable ways. The diagnosis matters more than any implementation guide.

Reusing unsuitable cameras

The symptom: performance far below the demonstration, and tuning does not help.

The cause: cameras installed for human review, wide and high, with too few pixels on target.

The correction: the survey, then camera work. Reduce scope rather than accepting cameras that cannot support the task.

Alert volume nobody computed

The symptom: operators ignore the channel within a month.

The correction: compute alerts per shift before purchase, set an alert budget, and treat exceeding it as a defect.

No ground truth

The symptom: nobody can say whether it works, and the discussion is about impressions.

The correction: an independent record of what actually happened, for a defined period, compared against output.

Deployed real-time first

The symptom: an alarm system with an unusable rate and no baseline.

The correction: run retrospectively first. It establishes the true event rate and tunes the threshold against real data.

Detection substituted for the physical control

The symptom: a detector in an aisle that should have a barrier, still there three years later.

The correction: record it as interim, with a date, on the risk register, and report interim measures past their date.

Scope creep through vendor features

The symptom: the system now estimates demographics because an upgrade enabled it.

The correction: re-check the feature set after every upgrade, against the inventory and the notice.

Purpose drift

The symptom: safety footage used in a performance conversation.

The consequence: the workarounds described elsewhere, and the safety data stops describing the hazard.

The correction: the limitation in writing, enforced in the first hard case, with the decision-maker named in advance.

No owner after commissioning

The symptom: performance unmeasured for two years, alerts ignored, retention at the vendor default.

The correction: an owner at commissioning, with the periodic evaluation as a scheduled task.

The average concealing the distribution

The symptom: a good accuracy figure and repeated complaints from the same people.

The correction: subgroup performance, override rates by area, and taking a cluster of complaints as data rather than as noise.

The common thread

Each of these is measuring the deployment rather than the outcome.

Cameras installed, detections generated, dashboards built — all rise while incidents, defects and the actual event rate stay where they were.

Reporting the outcome measure alongside the detection count from the first week is the single most effective preventive step, because it makes the gap visible while there is still time to correct it.

Diagnosing before buying more

A replacement product bought to fix a failing deployment usually fails the same way.

Work through the list and name which failure you have.

Cameras, alert volume, no ground truth, real-time first, substituted control, scope creep, purpose drift, no owner, hidden distribution.

Each has a specific correction and only one of them is a product problem.

Where the honest answer is that nobody owns it, say that rather than proposing a purchase, because the new system will not be owned either.

Reporting the outcome measure from week one

The single most effective preventive step, and it costs nothing.

Alongside the detection count, report the thing the system exists to affect: incidents, defects, the actual event rate.

From the first week, so the baseline exists.

On the same chart, so divergence is visible.

Detections falling with the outcome flat is degradation or avoidance, and it is otherwise invisible.

Most deployments report only detections, which is how a degraded system produces a reassuring chart for a year.