Bridge Inspection Software Problems: The 7 That Cost You a Compliance Finding, and How to Avoid Them

Why does the agency developed element set get underestimated?

Because element level inspection reads as one feature and it is not. National bridge elements and bridge management elements are a published starting point. Every agency then extends them to cover what it actually owns: specific joint types, particular coating systems, culvert configurations, historic truss details. Your set is yours, and each element in it carries a form definition, validation rules, condition state quantity logic and its own place in reporting.

The scope failure looks like a proposal that quotes element level inspection as a line item without ever having seen your list. Fifty agency elements and two hundred and fifty agency elements are the same sentence and different projects.

The consequence when this is missed is not a missing feature, it is a form that inspectors cannot complete correctly, so they record something approximate and your quantity data becomes unusable for trending. The fix is to send your element list and one full inspection report before anyone scopes anything, and to insist the estimate names a count. Phase by inspection type as well: routine inspections on your own structures first, with underwater and non-redundant steel tension member types in a later release, because those carry their own forms, their own intervals and their own qualified inspector rules.

What goes wrong when decades of legacy inventory are migrated?

This is the item most often underestimated on bridge projects, and the reason is that the data is not merely old, it was coded under earlier definitions. Values entered against the previous coding guide do not always mean what the current item expects, so a straight export produces a file that validates and is wrong. Sitting behind that are structures that were replaced, renumbered or transferred to another owner, duplicate records created when a county and a city both claimed a crossing, and element quantities that shift between cycles because two inspectors measured the same deck differently.

The last one is quietly the worst. A four percent measurement difference between inspectors reads as condition improvement in a deterioration model, and a network of those turns your prioritisation into noise wearing the clothes of analysis.

The fix has three parts. Migrate with provenance, keeping the original coded value alongside the mapped one so a questionable figure can be traced rather than argued about. Do not manufacture element data for cycles where it was never collected, because a gap is honest and an interpolation is not. Going forward, carry the previous cycle's quantities into the field form as the starting point and require an explicit reason when a total changes. That one control is what makes network level trending defensible when a ranking is challenged.

Why do GIS, maintenance systems and consultant submissions break after launch?

Because each of them is a different organisation's data on a different cadence. Your geodatabase is maintained by another department and structures get edited there without anyone telling corrosion, maintenance or bridge. Your work management system, whether Cityworks or Maximo, has its own asset identifiers that were never reconciled with the bridge register. Consultant firms submit inspections in their own house styles, and a firm that changes its reporting software mid contract changes your inputs without notice.

The failure mode is quiet divergence rather than an outage. Identifiers drift apart over a year, a handful of structures end up in one system and not the other, and nobody finds out until an annual reconciliation or an audit.

The fix is to make divergence visible on a schedule instead of at year end. Run an automated reconciliation between the structure register and the geodatabase weekly and put the exceptions in a named person's queue. Give consultants a submission route with validation applied at their end and a review and acceptance step at yours, with rejections returned carrying specific reasons rather than a phone call. That replaces the current pattern of PDF reports arriving by email and a technician re-keying condition ratings weeks later, and it removes the format inconsistency that appears the moment you have three firms.

What happens when interval determination is not documented as data?

Under the National Bridge Inspection Standards the routine interval is no longer one universal number. There is a default interval with extensions where criteria are met, a risk based method that can lengthen or shorten the interval for a specific structure, and separate rules for underwater inspections and for non-redundant steel tension members. Every due date is therefore the output of a decision.

When those decisions live in an engineer's memory, so does your compliance position. The failure is undramatic: a structure transfers from a county to a city, or a risk based interval is shortened after a finding and the schedule is never updated, or a culvert crosses the length threshold after a survey. One structure passes its interval, and the finding lands in a federal compliance review with your agency's name on it.

The fix is to make the determination a record rather than a habit. Each structure carries its interval method, the criteria that supported it, the approver and the date, and the due date is derived from that record. Escalate at ninety, thirty and seven days out to a named person rather than a shared inbox, and refuse to show a year as complete when any structure has passed its interval. A reviewer should be able to read why a given bridge is on the interval it is on without asking the engineer who decided it.

Should you build custom or configure what you already own?

Do not build if you are a county whose inspections are performed and submitted by the state. Ask for your data back annually, keep a good spreadsheet, and put the money into maintenance. That is genuinely the right answer for a great many owners and nobody should talk you out of it.

If you already run AASHTOWare Bridge Management successfully and your staff know it, configure before you replace. It is comprehensive on the management side, covering element data, deterioration modelling and programme optimisation, and most agencies that want to replace it are actually describing a field inspection problem. In that case the targeted build is an offline field application carrying your agency element set that feeds BrM, not a new system of record. Bentley InspectTech is similarly strong at inspection collection and report production, which is why so many consultant teams use it, and if collection is your only gap it may already be the answer.

Esri deserves a specific caution. Field Maps and Survey123 are excellent geospatial tools and agencies reach for them because they are already licensed. What you get is forms and points, with no structure domain model, no element quantity logic across condition states, no interval rules and no submittal validation. It works for a season and then becomes a data problem.

Build when you own several hundred structures or more, when multiple consultant firms submit in incompatible formats, when your interval determinations are not documented anywhere a reviewer could read, when the annual submittal is a manual reconciliation exercise, or when you cannot produce a condition trend per element to defend your programme.

How do hidden costs get into the quote?

These are the lines that move numbers on bridge projects, and they are rarely priced separately.

• The agency element set. Each element is a form definition plus validation plus reporting, so the count matters more than the bridge count does.
• Legacy migration. Decades of records coded under earlier definitions, with replaced, renumbered and transferred structures, is discovery work measured in weeks.
• Submittal validation depth. Item level checks before submission cost considerably more than a basic export, and the difference is whether you learn about a problem before or after rejection.
• Offline conflict resolution. Two inspectors editing the same structure while out of signal is a design problem, and skipping it means inspectors go back to paper.
• Photo storage and retention. Inspection photography accumulates permanently and has to remain retrievable and tied to specific elements and defects rather than dumped in folders.
• Capital programming integration. Feeding candidate projects into your programming process is a real project of its own, not a report.

What separates a bridge programme build that works from one that fails?

Ask a prospective developer to model a bridge that gets its superstructure replaced. If the answer creates a new structure record and abandons the history, they will lose your long term condition trends and your load rating chain, and you will discover it two cycles later.

Ask how the field application handles a tablet that has been offline for six hours under a bridge while another inspector edited the same structure. Offline conflict resolution separates people who have shipped field applications from people who have written one.

Ask what they know about element quantity consistency across cycles. If they do not immediately raise the problem of inspectors measuring totals differently, your deterioration models will be built on sand.

Then settle ownership in writing before kickoff, covering the repository, the database and the cloud accounts. Inspection records are permanent public safety records and can become discovery material after an incident, so they cannot sit inside a vendor account. The builds that work are also phased: routine inspections, your own structures, your own staff, in the field for a full cycle before consultant workflow and submittal generation are added.