Water Utility Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does a utility build get scoped as an advanced metering dashboard?

Advanced metering infrastructure is the newest thing in the building and the easiest to demonstrate, so it dominates the brief. Somebody has seen a consumption graph and wants that, plus leak alerts, plus a map. What gets built is a second version of the vendor portal you already pay for, and the utility ends up with two places to look at the same interval reads.

The value is not in displaying meter data. It is in joining it to things the meter vendor will never hold: the pressure zone, the district metered area, the asset the meter is attached to, the account history and the work orders that touched that service. A leak alert on its own is noise. A leak alert correlated with a pressure dip in the same zone is a dispatch decision. The vendor cannot build the second one because they do not have your zone map, and they have no commercial reason to want it.

The fix is to scope phase one around the join rather than the display. Ingest the interval read stream into your own store, attach it to the service point, the asset record and the account, and deliver exactly one high value workflow on top, usually leak triage or compliance sampling. Nothing else in phase one. A utility that scopes six workflows in the first release gets none of them working well enough for staff to abandon the spreadsheet they currently trust.

What goes wrong reconciling service points, accounts and assets?

This is the failure that stops more utility projects than any technical problem. The billing system was built around an account. The geographic information system was built around a location. Nobody has ever been responsible for keeping the two in agreement, and after a decade of renumbering, subdivisions, demolitions, meter relocations and annexations, a meaningful share of them disagree.

The symptoms are recognisable. Accounts flagged wrong in billing because service point identifiers were renumbered years ago and never backfilled. Two accounts on one physical service. A service point with no account because the property was demolished and nobody removed the meter record. Meter serial numbers that appear in the metering vendor's system, in billing and in the asset record with three different formats. And the person who knows which route has which anomalies is one long tenured employee whose knowledge is not written down anywhere.

The fix is to do the reconciliation deliberately, before development on the real features starts, and to budget it honestly at four to six weeks on a mid sized system. Match automatically where you can, produce an exception list, and send crews to verify the exceptions in the field with a phone rather than guessing from a desk. Then hold the resolved key in your own database rather than in either vendor system, so it survives your next billing procurement. Utilities that skip this step do not avoid the work, they just do it in month four with the project already behind.

Why do metering, billing and control system integrations break after launch?

Each one fails in its own way and they need separate defences.

Metering vendor interfaces are rate limited, and a build that queries them live will work in testing with a hundred endpoints and fail in production with twelve thousand. The design that survives pulls interval data on a schedule into your own store and never depends on the vendor being available at the moment a user clicks something. When the vendor changes an interface version, you want that to break an overnight job you can see, not a screen a customer service representative is using on a call.

Billing integration depends heavily on the age of the system. A modern platform exposes an interface. An older system on a nightly flat file gives you latency, and everything you build has to live with the fact that today's payment is not visible until tomorrow. That is a design constraint to state out loud, because a customer portal that shows a stale balance generates calls rather than deflecting them.

Supervisory control and data acquisition is the one to be careful about. The correct architecture is read only, through a properly designed boundary between the business and operational networks, with no control path in the application, ever. Expect the security review to add three to five weeks. Treat that as evidence of a serious engagement rather than a delay, and treat any developer who is relaxed about the network boundary as somebody who has never worked on one.

What happens when sampling windows and service line inventory are missed?

Compliance is where an uncovered gap becomes a violation rather than an inconvenience. Sampling has windows, and a missed window is a violation regardless of whether the water was fine. A build that stores results but does not model the schedule gives you a nicer record of the violation you already committed.

Disinfection byproduct compliance runs on locational running averages, which means a site trending toward the maximum contaminant level in month two is visible long before it becomes an exceedance in month four, but only if the average is computed continuously rather than at quarter end. Sample sites themselves change, because houses are demolished and access is lost, and a site you cannot collect from is a problem you want flagged in advance rather than on the day.

The service line inventory required under the Lead and Copper Rule Revisions exposed how thin the underlying data is at most utilities. The honest starting point for many was a filing cabinet of old tap cards. A build that models a service line as a single material field has already failed, because the utility side and the customer side can differ and each needs its own basis of evidence.

The fix is to make the schedule a first class object with alerts that fire well before a deadline, compute running averages continuously, and model the service line with material on both sides plus a basis of evidence field and a photo. Then a crew potholing at a property can update the record from unknown to verified from the trench, and the state submission generates from data rather than from an intern with a spreadsheet.

Should you build custom or configure what you already own?

If you are under roughly three thousand connections with one pressure zone, a compliance load of a monthly operating report and quarterly bacteriological samples, and a crew of four, buy. Cityworks or a hosted package plus your metering vendor's portal is the right answer, and the overhead of owning software will consume the benefit. Anyone telling a utility that size to build is selling something.

Cityworks and Lucity are capable maintenance management products and they do that job well. The mistake we see most often is a utility deciding to replace a working maintenance system because the reporting is frustrating, when the actual gap is the join between work orders, meters, geographic data and compliance records. Replacing a working maintenance system is expensive and usually returns nothing. Building the layer that connects it to everything else returns a great deal.

The signals that justify building are concrete. Someone maintains a spreadsheet that joins two vendor systems and that spreadsheet is load bearing for a decision or a regulatory filing. You have asked two vendors for an integration and both quoted you a data export. Your non revenue water is high and you cannot separate real loss from apparent loss because no single tool holds meter data, production meters and the district map together. Or you are a regional authority or a utility that has acquired a neighbouring district, so you are operating as one entity across products priced and designed per system.

How do hidden costs get into the quote?

Connection count barely moves the price. These do.

• The key reconciliation. Four to six weeks of matching and field verification if service points and accounts do not align. Ask for a sample match rate before anyone quotes a timeline.
• The control system security review. Three to five weeks and a real dollar figure if operational network data is in scope. It is an architecture conversation before it is a code conversation.
• Each state report format. Every distinct submission is its own build with little reuse between them. List them all up front.
• Legacy billing latency. An older billing system on a nightly file changes what the rest of the system can honestly promise, and designing around that is work.
• Field verification. Crews confirming service line materials or exception records is operational time, not software time, and it belongs in the plan.
• Long term ownership. A public entity with a forty year asset horizon needs documented handover, a data export and infrastructure in accounts it controls.

A quote that prices by connection count rather than by integration count has not been scoped by anyone who has done this.

What separates a build that works from one that fails here?

Ask a prospective developer to describe the data model for a service line before you sign anything. If the answer does not immediately distinguish the utility side material from the customer side material, and does not include a basis of evidence field, they have not read the rule and they will learn on your budget. It is the sharpest domain test in this category because it is exactly where regulation, mapping and physical reality disagree.

Second, the alert design decides whether staff use the system. A leak list that fires on hundreds of accounts a month is a list your customer service team will ignore within a fortnight, and an ignored list is worse than none because it creates a false sense of coverage. The work that makes it usable is unglamorous: learn each account's own normal from its own history so a school with no summer usage and a laundromat with a three in the morning cycle both stop generating alerts. Aim for a number a person can actually work through in a shift.

Third, prove one workflow completely before adding a second. A utility that has leak triage working, with a measurable reduction in the alert list and a ranked meter change out list by lost revenue, has a business case for everything that follows. A utility with six half finished workflows has a shelf.

Fourth, get code ownership and a documented data exit in the contract at signing rather than negotiating later. You own the repository, you own the database, and there is a written export procedure. You are a public entity holding operational history that outlives every vendor in the market, and a supplier who folds should cost you a migration, not your record of what happened.