I get called in after the fact. Somebody has bought a system, it has been installed, it has been signed off, and now there is a question about whether it does what it was supposed to do. I sell no hardware, no software and no installation, which is the only reason anyone believes my answer either way.
That vantage point has an odd side effect. You start seeing the same handful of things over and over, across different integrators, different platforms and different provinces. Very few of them are workmanship problems. Most are decisions made early, by somebody who was not in the room when the consequence turned up.
Here are the five I find most often, and what actually stops them.
01. Retention sized at a bitrate that will never happen
The storage calculation gets done with a manufacturer’s tool, at a default bitrate that assumes a quiet scene. Then the system goes into a loading dock, a parking lot in February, or a corridor with a failing fluorescent tube, and the encoder produces far more data than the calculator assumed. Snow alone will do it.
The result is storage short by a meaningful margin from day one. Nobody notices, because the system does not announce it. Retention quietly stops meeting the policy it was sized for, and it gets found the day somebody asks for footage from five weeks ago.
What stops it: Size against a measured bitrate from a comparable scene that is already running, not against a default. Then write the retention figure into the acceptance criteria so it is verified at handover instead of assumed.
02. PoE budget, not port count
Switches get selected by counting cameras. Forty-eight devices, forty-eight ports, done. Then the PTZs arrive, and the multi-sensor units, and the illuminators, and the housings with heaters in them, and the power budget is exhausted at sixty percent of the ports.
The part that gets missed even by people who do check the budget is where the budget comes from. Available PoE is not a property of the switch model. It is a property of the power supplies installed in it, and of how those supplies are configured. The same chassis ships with very different wattage depending on which supply is in it, and a second supply does not automatically double what you can draw.
That second supply is a decision, and it is usually made by whoever chose the part number rather than by whoever sized the cameras. In a redundant configuration two supplies give you the budget of one, with failover. In a combined configuration they give you the sum, with no failover. Both are legitimate. Picking one by accident is not, and a design that quietly assumed the combined number while the switch was built for redundancy is short before a single camera is mounted.
So a switch listed as supporting a given PoE class across every port may well do that, with the largest supply, in combined mode. It arrives with the base supply instead, and the quote was technically accurate the whole time.
This one is also seasonal. That is what makes it nasty. It passes commissioning in September and fails in January, because that is when the heaters draw and the switch starts shedding whatever sits at the end of its priority list.
What stops it: A per-device power table at design stage with heater and illuminator draw included. Then specify the power supply, the quantity, and the redundancy mode explicitly, rather than the switch model alone. Budget the winter number, not the bench number.
03. Multicast configured by hoping
On a flat network with a dozen cameras it works, which is the problem. It builds confidence that does not survive a second site. Add a router, add a VLAN, and without an IGMP querier and snooping configured deliberately, multicast video either floods everywhere it should not go or fails to arrive where it should.
Then it gets diagnosed as a camera fault. Or a recorder fault. Or an intermittent nobody can reproduce, for weeks. I have watched two competent companies argue about a camera model for a month over a querier that was never configured.
What stops it: Decide unicast or multicast at design rather than at install, and if it is multicast, name where the querier lives and put it in the documentation.
04. No acceptance criteria, so acceptance is an argument
This is the one that costs installers more than it costs owners, and it is the reason I put it in an article aimed at people who install things.
When a specification does not define the tests that constitute completion, “finished” becomes a matter of opinion. The disagreement then happens at exactly the point where the final payment sits. A good contractor with a well built system has nothing to prove it with. A weak one has room to argue. Neither is fair to whoever did the work properly.
Defined acceptance tests protect the installer at least as much as the owner. They are the only thing that turns “it works” from a claim into a demonstration.
What stops it: Written commissioning criteria in the specification, before tender. Not after award, when they read as a change in scope.
05. Version drift across the estate
Camera firmware, device packs, controller firmware, client versions. After three years and four service visits by three different technicians, no two sites are alike and nobody wrote down what changed.
The system then behaves inconsistently. That is the worst failure mode there is, because it cannot be reproduced and therefore cannot be closed. It also makes every support call after it more expensive, for everybody.
What stops it: A version baseline captured at handover and a standing decision about who owns updates afterwards. The decision matters more than the answer.
The uncomfortable part
Four of those five are settled before an integrator is even selected. They are specification and design decisions. By the time anyone is pulling cable the outcome is largely fixed, and the company on site inherits a problem it did not create.
Worth saying plainly in a trade publication, because this industry has a habit of calling them installation failures. They are not. They are procurement failures that surface during installation, and the person holding the ladder is the one asked to explain them.
There is a practical version of this for both sides of a tender. If you are writing the specification, put the measured bitrate assumption, the power budget, the multicast decision and the acceptance criteria in it. If you are bidding against one that does not contain them, raise it during the question period rather than absorbing it at closeout. It is a reasonable question, it marks you as the serious bidder, and it puts the risk back where it belongs.
None of this is exotic. It is a checklist, and it is consistent enough across systems that it stops being bad luck and starts being something you can design out.