Pavement Management Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does a pavement project turn into an asset management project?

The request that gets funded is narrow: defend the paving list. The project that gets scoped six weeks later covers signs, signals, sidewalks, streetlights, work orders and a citizen request portal, because every division head who attends the requirements workshop has something they want in it. This is the most common way a pavement build fails, and it fails quietly. Eighteen months later the department has a competent asset inventory and still cannot answer why Maple Avenue is not on the list.

It happens in pavement specifically because pavement is the only asset class where the decision is contested in public. So pavement carries the political urgency that gets a project approved, and once approved it becomes the vehicle for every other unfunded need in public works.

The fix is a scoping rule written down before the first workshop. This release answers one question: what to pave, in what order, at what cost, under a funding level someone can change on screen. That means segmentation, condition history, deterioration and treatment modelling, a constrained multi year program and a map. Work orders, sign inventories and citizen requests are a later phase with their own budget. Departments that hold that line ship a first release in 12 to 16 weeks. Departments that do not are still in requirements at week 20 and the paving list is still defended from a spreadsheet.

What goes wrong when you load historic condition surveys?

Loading one survey is easy. Loading three surveys from two vendors across nine years and getting a usable history out of them is the real work, and it is routinely underestimated because everyone assumes a condition index is a condition index.

Three things break. Segmentation differs between vendors and sometimes between cycles from the same vendor, because one used your linear referencing scheme and another split at driveways or at surface type changes. Segment identifiers get reused when the GIS layer is rebuilt, so a 2018 segment 4412 and a 2024 segment 4412 are different pieces of road. And the network itself changes: streets are reconstructed, annexed, realigned or vacated, so a straight identifier match across cycles quietly drops the segments that changed most.

The fix is structural and it belongs in the first sprint rather than in a data cleanup phase. Hold a segment identity you own, tied to the GIS centerline and aligned to how you let contracts block to block between cross streets. Every incoming survey is reconciled to that identity through a documented mapping, with a report of what matched, what split, what merged and what could not be resolved. Unresolved segments go to a human, not to a default. Then condition becomes a time series on a stable object and the question of how fast your pavements actually decay becomes answerable, which is the whole point of owning the system.

Why do the GIS and finance integrations break after launch?

Both of these work perfectly in the demo and fail in month seven, for the same reason: they depend on data owned by a team that has no idea your system exists.

The GIS centerline is republished on the GIS division's own schedule. Somebody splits a street at a new intersection, corrects a geometry error, or renumbers a corridor after an annexation. Nothing in that process asks whether a pavement system is keyed to those identifiers, so your condition history fragments overnight and the first symptom is a map with holes in it. The financial system, whether Tyler Munis, BS and A or Springbrook, has the same pattern. A new fiscal year brings a chart of accounts change or a new project numbering convention, and the appropriation link that fed your budget scenarios stops resolving.

The fix has two halves. Technically, never depend on a foreign identifier as your own primary key. Store the external reference as an attribute with an effective date, keep your own identity stable, and run a scheduled reconciliation job that reports differences rather than silently accepting them. Organisationally, get the GIS division named in the project charter and give them a change notification obligation, because this is a coordination failure that engineering alone cannot fix. The same applies to your survey vendor: put the deliverable schema, the segmentation basis and the segment identifier convention in the procurement documents for the next survey, not in an email after the data arrives.

What happens when utility conflicts and ramp obligations are not modelled?

This is the failure that reaches the newspaper. A street is resurfaced in July, and in October the water department opens a trench down the centre of it for a main replacement that sat in their capital plan the entire time. Most cities have a pavement cut moratorium precisely to prevent this, and the moratorium only works if somebody checks it against the paving list before the list is finalised. In a lot of departments that check is a person remembering to ask.

The second uncovered obligation is accessibility. Where a resurfacing project counts as an alteration, curb ramps at the affected intersections have to be brought into compliance, and that cost belongs in the project estimate. When it is not modelled, it arrives as a change order after award, which does not just cost money, it changes which projects were actually affordable in the first place. A program built without ramp costs is a program that will not deliver the mileage it promised.

Both are cheap to build compared with the modelling work around them. Utility and moratorium checking is a spatial and temporal overlap query against capital plans that already exist as GIS layers or spreadsheets, plus a review workflow so a flagged conflict has an owner. Ramp costs attach as a rule on the project estimate, triggered by scope type and intersection count. Confirm the specific triggering criteria with your city attorney or accessibility coordinator, because the determination depends on the work being done and is not a software judgement.

Should you build custom or configure what you already own?

For a real share of readers, the honest answer is configure, and the product to configure is StreetSaver. If you manage under roughly 100 centerline miles, it costs a fraction of a build, produces a defensible network condition index that consultants and peer agencies understand, and leaves budget for crack sealing, which will do more for your network this year than any software. We would tell you that in the first call.

The same applies further up. If your question is condition reporting rather than contested prioritisation, OpenGov Cartegraph is a reasonable purchase and its asset inventory and work order management are genuinely strong. Just do not buy its pavement analysis expecting a multi year constrained optimiser, because that is not what it is. If you are a state agency or a very large network with a modelling specialist on staff, Deighton dTIMS does deterioration modelling and constrained optimisation properly and there is no reason to rebuild it. AgileAssets is sized for state agency asset breadth and behaves accordingly.

Building earns its place when three conditions hold together: the paving program is politically contested, the model has to reconcile with the capital budget and with utility plans rather than living beside them, and you need a public facing answer to why a specific street is not on the list. Those are integration and communication problems, not modelling problems, and they are exactly what a licensed tool leaves as manual work for your staff every single cycle.

How do hidden costs get into the quote?

Four of them, reliably, and none is dishonest. They are simply invisible until someone opens the data.

• Centerline remediation. If your centerline lacks stable identifiers, carries duplicate geometry from an old conversion or disagrees with the street name file, that has to be fixed first. It is a prerequisite project and should be priced separately rather than absorbed into a fixed bid.
• Historic survey reconciliation. Priced per cycle, not per project. Four cycles from three vendors with a network that changed in between is weeks of work producing no visible feature.
• The public map. A genuinely public map carries accessibility requirements, performance requirements under load and a content review process. An internal staff map carries none of those, and quoting them as one line is where fixed price projects go wrong.
• Ongoing ingestion. Every future survey cycle needs importing, reconciling and quality checking. Unbudgeted, the system is current for two years and then abandoned.

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

Three things, and none of them is the optimiser.

The first is a closed loop. Recommended treatments group into projects, projects carry a funding source and an appropriation, and award plus as built quantities post back to the segments that were actually treated. Without that, the model believes every recommendation was executed. Bids come in high, a preservation contract covers 31 of the 40 segments the model recommended, nothing records the shortfall, and within about three cycles the model's picture of the network and the real network have separated. The ranking then loses credibility at exactly the moment a council member challenges it.

The second is honesty about confidence. Deterioration curves shipped as defaults must be labelled as defaults on screen, so nobody presents a projection as a measurement. Calibration needs at least two survey cycles on the same segments, which is why most agencies never do it, and a system that hides which curves are fitted and which are assumed removes the only signal staff have about how much to trust a number.

The third is the two click council answer. Given any street, show the score, the recommended treatment, that treatment's cost and its rank under current funding, on a map a resident can read. That view is what makes the project defensible politically and it is the feature most likely to be cut for schedule. Protect it.

Then settle ownership in writing before kickoff: the repository, the cloud accounts and every condition, treatment and cost record, with the right to hire another firm. At Digital Heroes the client owns the code from the first commit. Condition history compounds in value across survey cycles, and it should never sit inside a supplier's platform.