It's a familiar pattern: a utility hires a consulting engineering firm for a design project, hands over the best available asset data, and eighteen months later has a finished project, a set of as-built drawings, and a firm's internal project files that contain a more accurate, more current version of the utility's own asset information than the utility's own records do. Nobody did anything wrong. It's just what happens when data flows one direction without a clear way to flow back.

Why this happens on almost every project

Engineering firms need working data to do their jobs; they pull what the utility can provide, refine it, correct errors they find along the way, and add detail specific to the project. That's normal and necessary. The problem isn't that the engineer's data becomes more accurate, it's that there's often no defined process for that improved data to flow back into the utility's own asset records once the project closes out. The firm's project files become the best version of the truth, sitting in a location the utility doesn't have routine access to.

Where the duplication actually shows up

  • Corrected asset locations or attributes the engineer identified during design or construction, never making it back into the utility's GIS.
  • As-built information that exists in the closeout package but never gets translated into an updated asset register entry.
  • Condition observations made during construction, adjacent assets the crew noticed were deteriorating, that were relevant to the project but outside its scope, and so never got recorded anywhere the utility would see them again.
  • Multiple engineering firms working on the same system over time, each starting from whatever data the utility could hand over at the time, none building on what the others found.

What tends to fix it

The utilities that avoid this pattern usually do three things differently, and none of them require new software or a major process overhaul:

  • They define what "data return" means before the project starts. As-built updates, corrected GIS attributes, and condition observations are named as deliverables in the scope of work, not assumed to happen automatically.
  • They give the engineer scoped access to current data instead of a one-time export. When a firm is working from a static file handed over at kickoff, corrections have nowhere obvious to go. When they have ongoing, appropriately limited access to the utility's actual records, updates are more likely to happen in the right place the first time.
  • Someone on staff is responsible for closing the loop. A defined point of contact who reviews closeout packages specifically for information that should update the asset register, rather than filing them away as a completed project, is often the difference between data coming back and data disappearing into a project folder.

This isn't about replacing the engineer's role

None of this is about second-guessing an engineering firm's design, modeling, or professional judgment, that expertise is exactly what utilities hire consulting engineers for. It's about making sure the information generated alongside that expertise, the corrected locations, the as-built details, the field observations, comes back to the utility that will own and operate the asset for the next fifty years, instead of staying in a project archive that outlives its usefulness the day the project closes out.