Public Works Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope keep getting written around one division's work orders?

The requirements document is almost always written by the division with the loudest problem, which is usually streets. That produces a work order system shaped like street maintenance: pothole categories, a paving activity list, a crew calendar. Then sewer, fleet, parks and the sign crew are told to use it, discover it does not describe their work, and go back to the spreadsheet they were already keeping.

This happens in public works more than in most categories because the department is genuinely several businesses sharing a yard. A lift station, a sign, a fleet unit and a storm inlet are different data models with a shared crew pool, and a system built around one of them cannot absorb the others through custom fields.

The fix is to model the asset hierarchy before modelling the work. Assets carry effective dated attributes, sit in hierarchies, and belong to spatial relationships that resolve at write time, meaning a single inlet knows its basin, its ward, its snow route and the capital project that replaced it. Work then attaches to assets rather than to a category list. Get that right and adding a division is configuration. Get it wrong and every division after the first is a rewrite.

Scope the first release across at least two divisions with genuinely different asset shapes, even if only one goes live. It costs a little more in design and it is the difference between a platform and a streets tool.

What goes wrong when you migrate asset data and work order history?

The migration exposes a problem departments know about and have learned to live with: your geographic information system, or GIS, and your work order history do not agree on what things are called. Asset identifiers drift, get duplicated when a feature is re digitised, or were never stable in the first place because someone used a sequence that restarted after a schema change.

That matters because the entire value of the new system is asking what a specific asset has cost you over time. If the work order history cannot be joined to the current asset record, you have moved your data without gaining the one report your finance director has been asking for.

The other reliable surprise is the undocumented network. Every department has tie ins, valves, service laterals and abandoned segments that were never mapped, and the person who knows where they are has been there twenty years. That knowledge is not in either system, and no migration recovers it.

The approach that works is a reconciliation phase before any application code is written. Produce a match report between work order history and current features, classify the unmatched into duplicates, retired assets and genuine gaps, and decide deliberately per class. For the undocumented network, build a field discovery path from day one so what the crew learns during a repair enters the system. Departments that import wholesale end up with a faster way to query bad data.

Why do the Esri and finance integrations break after launch?

The Esri integration breaks because it is usually built one directional. The nightly job pushes attributes from GIS into the work order system, GIS is treated as authoritative, and the field is treated as a consumer. Then a crew exposes a pipe that is a different size and material from what the map says, and there is no path for that discovery to travel back except an email to an analyst with a backlog. The map stays wrong, engineering quietly re surveys before every project, and the integration is technically working the entire time.

Build it bidirectionally and treat field discovery as a first class record. Close out asks what the crew actually found, whether it matches the record, and for a photo. A mismatch creates a discrepancy record with the location fix and the note, which lands in a review queue as a proposed edit the analyst approves or rejects in bulk. Also expect a schema change mid project, because GIS teams keep working while you build, and ask any developer how they have handled one before.

The finance integration breaks on the chart of accounts. Activity codes and fund mappings change during a budget cycle, and a crew leader picking the first plausible code from an alphabetical dropdown will charge work to the wrong fund all year. Get the mapping committed in writing before development, constrain the picker to the codes valid for that asset and that project, and run a monthly reconciliation that compares what the work order system posted against what the ledger received.

What happens when storm events and records obligations are not covered?

Two gaps sit outside normal operations and both are expensive in a way that never appears as a line item.

Storm events are the first. Systems designed around a steady state queue collapse when hundreds of requests arrive in a few hours, so dispatchers abandon them and the event goes unrecorded. An event mode fixes it: one toggle changes intake, dispatch layout and close out requirements for a declared event, requests group by geographic cluster, crews receive a route rather than a ticket, and close out drops to a photo and a timestamp because during a storm you capture rather than classify. Every record silently carries the fields a claim will need. Build it before you need it, because the six days a year it matters are not days you can build on.

Records obligations are the second. Your work orders are public records, citizen contact details are inside them, and a records request will land. That shapes retention, redaction and export, and it is far cheaper as a design decision than as a scramble. The same applies to accessibility on the citizen facing portal, which is a requirement for a public body rather than a preference, and which touches every form and every status page rather than being a styling pass at the end.

Should you build custom or configure Cityworks or Cartegraph instead?

Plenty of departments should configure rather than build, and we would say so to a city manager. Cityworks and Cartegraph are genuinely good products if you are a median shaped department with one primary division, reasonably clean Esri data, and no structural oddity in how you operate. Both integrate with Esri properly and both encode a great deal of municipal maintenance workflow you would otherwise rediscover.

Stay bought in three specific situations. If your county or state has standardised on one of them, you will spend two years fighting procurement and information technology for an exception, and that fight costs more than the gap. If your asset data is genuinely bad, custom software will not clean it, it will render bad data faster and more expensively, so fix the data first and revisit. And if the real problem is that nobody uses the system you have, a new system does not solve an adoption problem, it resets the clock on it.

Build when your operation is structurally unusual: a combined utility, a shared services agreement with neighbouring townships, a snow operation that dominates your winter, or an internal fleet shop that bills other departments. Off the shelf products are built for the median department, and if you are not the median then every year of configuring around the gap is a year of paying software to make the job harder. The second signal is financial: when your licence plus the consultant you keep on retainer to maintain configurations passes roughly eighty thousand dollars a year, you are already funding a build and merely renting the result.

How do hidden costs get into a public works quote?

Offline first mobile is the single biggest multiplier and it is routinely priced as a feature. A truck in a river valley or a vault has no signal, and a sync engine that survives two crews editing the same asset offline for six hours is genuine engineering. A team that answers with last write wins will discover the problem in month five when it is expensive.

Esri integration cost scales with how clean your geodatabase is rather than with how many layers it has. No stable asset identifiers means a reconciliation phase before application work, and that phase is analyst time on your side as much as developer time on theirs.

Financial system integration is usually a knowable cost, but only once finance commits to a chart of accounts and activity mapping in writing, and that conversation takes longer than the code. Departments that start development before it is settled pay for the rework.

Then the ones nobody prices: records retention and redaction, accessibility on the citizen portal with testing rather than assertion, procurement documentation your purchasing agent can process, and training across divisions that work different hours.

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

The builds that work make recording the truth easier than not recording it. That is the whole discipline. When a crew leader on hour fourteen of a main break faces an eleven field close out form, the record does not get created and the asset stays wrong forever. A three question close out with a photo produces better data than a thorough form nobody completes, and it is the design decision that separates a system crews use from one they route around.

The second marker is that geography is captured automatically rather than asked for. Every work order stamps ward, council district, pavement section, sewer basin and snow route at creation by spatial join from your own layers. Nobody types it, so nobody omits it, and the council question about response times by ward becomes a saved view rather than a week of reconstruction.

Finally, get source code ownership in the contract with a repository handover clause, confirmed by your city attorney before signing rather than at go live. Many agencies sign language that quietly leaves the vendor holding the code, which means changing vendors means rebuilding. At Digital Heroes the client owns the repository and the infrastructure accounts from the first commit, and for a public body that is the baseline rather than a concession.