Pavement Management Software: Defending the Paving List When Every Street Is Someone's Street

The meeting where the paving list gets defended

It is a Tuesday evening. The proposed street resurfacing program is on the agenda. A council member has a printout of the list and one question: why is Maple Avenue not on it when Maple Avenue is visibly worse than three streets that are.

The honest engineering answer is that Maple Avenue is already past the point where a cheap treatment saves it, so fixing it consumes a disproportionate share of the program while three streets that are still savable get another year of decay and drop into the same expensive category. That is correct, it is standard pavement preservation practice, and it is almost impossible to say out loud without a system behind it. What you need on the screen is Maple Avenue's condition score, the treatment it now requires, what that treatment costs, what the alternative program buys instead, and where Maple Avenue sits in the queue under the current funding level.

Most public works departments cannot produce that in the room. The list came out of a consultant's model run eighteen months ago, adjusted since by staff judgement and by which streets the utility already tore up. The score behind each ranking is in a spreadsheet nobody brought. So the answer becomes a promise to look into it, and next year three more streets fall off the savable list while the program buys reconstruction for one.

Problem 1: the condition survey arrives as a deliverable, not as a system

You pay a vendor to drive the network with an imaging van and laser profiling. Months later a deliverable arrives: distress data, a condition index per segment computed to a standard such as ASTM D6433, perhaps roughness and rutting, in whatever segmentation the vendor used. It gets loaded once, a program is produced, and the file goes on a shared drive.

Three problems follow. The vendor's segmentation rarely matches how you let contracts, because you pave block to block between cross streets and their segments may be defined by a linear referencing scheme that splits differently. Reconciling the two by hand is where staff time disappears. Second, condition data ages the moment it lands, and nothing updates it when you actually treat a street, so the model still thinks last summer's overlay is a 42. Third, you have no way to compare survey cycles at the segment level, which is exactly what you need to calibrate how fast your pavements actually decay.

The fix is that condition is a time series on a stable segment identity that you own, not a snapshot in a consultant's schema. Every survey cycle appends. Every completed treatment posts a condition reset with an as built record. That one structural decision is what makes everything after it possible.

Problem 2: default deterioration curves describe somebody else's streets

Deterioration modelling is what separates a pavement management system from a condition spreadsheet. The curve says how a segment's score falls over time given its surface type, functional class, traffic and environment, and it is what lets you say a street will be savable for two more years or will not.

Every tool ships with default curves. Those defaults come from research networks and regional averages, and they will be wrong for you in ways that matter, because your subgrade, your freeze thaw exposure, your truck routes and your construction specifications are yours. A city that runs preventive treatments off default curves will systematically mistime them, which is the most expensive kind of error in this field because a mistimed preventive treatment is money spent with no life extension.

Calibration requires at least two survey cycles on the same segments, which is the honest reason most agencies never do it: they have one survey and a consultant's defaults. So build for it from the start. Hold curves as configurable families by surface type and class, fit them against your repeat survey data as cycles accumulate, and show staff the difference between the modelled and observed decay. In the meantime use defaults and label them as defaults, so nobody presents a projection as measurement.

Problem 3: the optimizer and the capital budget disagree

A pavement model produces a recommended program. The capital improvement program produces a funded project list. In a lot of cities those two documents do not reconcile, because the model works in treatment types and square yards and the budget works in projects and appropriations, and the translation happens in someone's head.

The consequences are practical. The model recommends slurry seal on 40 segments; the budget has one line item for a preservation contract; the actual contract covers 31 of them because bids came in high. Nothing feeds that back, so next year's model still believes 40 were treated. Within three cycles the model's picture of the network and the actual network have separated, and the ranking loses credibility exactly when a council member challenges it.

Build the loop closed. Recommended treatments group into projects. Projects carry a funding source and an appropriation. Award and as built quantities post back to segments. Your unit costs update from your own bid tabs rather than a national average, which also means the next program is priced from what contractors actually charged you last spring.

Problem 4: the water department is about to trench the street you just paved

This is the failure that makes the front page. A street is resurfaced in July. In October a utility opens a trench down the middle of it for a main replacement that was in their capital plan the whole 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.

A pavement system that does not ingest the water, sewer, gas and telecommunications capital plans and flag conflicts is missing the highest value coordination check available to a public works director. It is also cheap to build compared to everything else in the project, because it is a spatial and temporal overlap query against plans that already exist as GIS layers or spreadsheets.

While you are there, attach the accessibility obligation. When 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 rather than appearing as a change order. Modelling it up front changes which projects are actually affordable.

What Cartegraph, dTIMS, AgileAssets and StreetSaver actually do

Be fair about the incumbents. Deighton dTIMS is the real thing for deterioration modelling and constrained optimisation, and state DOTs use it because it does that job properly. The practical constraint is that it wants a modelling specialist to operate, and it is not built to explain a ranking to a council member or a resident. AgileAssets is enterprise transportation asset management sized for state agencies and their asset breadth.

OpenGov Cartegraph is strong at asset inventory and work order management, and if your problem is tracking maintenance activity it is a reasonable purchase. Its pavement analysis is not a multi year constrained optimiser and should not be sold to you as one. StreetSaver is inexpensive, widely used, and produces a defensible network condition index, which for a small agency is exactly the right trade. Its treatment catalogue and unit costs are regionally calibrated defaults, and reconciling its outputs against your own GIS centerline and your capital budget is manual work.

Our position: buy if your network is small or your question is condition reporting. Build when the paving program is politically contested, when you need the model to reconcile with the budget and with utility plans, and when you want a public facing answer to why is my street not on the list.

What a custom pavement system must include

• Segment identity you own, aligned to the GIS centerline and to how you let contracts block by block, with survey cycles appended as a time series
• Condition import from your survey vendor with quality control rules and a documented reconciliation to your segmentation
• Configurable deterioration curve families by surface type, functional class and traffic, fitted to your repeat surveys as data accumulates and clearly labelled when defaults are in use
• A treatment catalogue with unit costs sourced from your own bid tabulations and updated annually
• Multi year constrained optimisation with named scenarios, including hold the network at a target score, flat funding, and worst first for comparison
• Project grouping with funding source, appropriation and as built feedback that resets segment condition
• Utility and moratorium conflict checking against water, sewer, gas and telecommunications capital plans
• Accessibility cost attachment where resurfacing triggers curb ramp obligations
• A public and council facing map that shows, for any street, its score, its recommended treatment, that treatment's cost and its rank under current funding

What this costs and how long it takes

From Digital Heroes delivery experience on municipal data and decision support systems, a first release covering segmentation, condition import, deterioration and treatment modelling and a defensible multi year program runs $60,000 to $130,000 across 12 to 16 weeks. Adding public and council mapping, utility conflict checks, budget reconciliation and as built feedback runs $150,000 to $350,000 over 6 to 12 months.

What moves the number: network size, since a few hundred centerline miles and a few thousand are different performance problems. The state of your GIS centerline, which is the quiet cost driver, because if the centerline is inconsistent or lacks stable identifiers then fixing it is a prerequisite project. The number of historical survey cycles you want loaded and reconciled. Integration with your financial system, whether that is Tyler Munis, BS&A, Springbrook or something else. And whether the public map is genuinely public, which changes accessibility, performance and content review requirements.

When you should buy instead

Under about 100 centerline miles, buy StreetSaver or an equivalent and put the savings into crack sealing. If you have never done a condition survey, do the survey first: software cannot model data you do not have, and a consultant run program off one survey is a perfectly respectable starting point. And if your council is not asking questions about the list, you have a reporting need rather than a decision support need, and that is a much smaller engagement.

How to choose a developer for pavement and asset systems

Ask how they will keep segment identity stable across survey cycles and across street reconstruction that changes the network. If they do not have an answer, your condition history will fragment and calibration becomes impossible.

Ask what happens when a project is awarded for 31 of the 40 segments the model recommended. The system should record what was actually treated and leave the rest in the queue. If as built feedback is an afterthought, the model diverges from reality within three years.

Ask them to demonstrate the council question. Given any street, show the score, the treatment, the cost and the rank, in two clicks, on a map a resident can read. That is the deliverable that makes this project worth funding.

Ask who owns the code, the cloud accounts and the condition data, in writing before kickoff. At Digital Heroes the client owns the code from the first commit. A good next step: pull your last two condition surveys and last three years of bid tabs, and ask whoever you are evaluating to show what curve calibration on your own data would look like. If they can do that, they can do the rest.