Webcast: Resolving the Municipal and Utility As-built Backlog

Last month, I had the privilege of delivering a webcast entitled “Resolving the Municipal and Utility As-Built Backlog”. The webcast was hosted by IMAGINiT Technologies and was aimed at local, state/provincial and federal governments; utilities; public works and infrastructure management professionals; as well as, engineering, CAD and GIS professionals.

Note that I have blogged about the as-built problem previously and this webcast served to expand on the topic. However, the webcast also confirmed that as-built backlogs remain an issue for many organizations. In fact, 69% of webcast participants indicated that they continue to have an as-built problem.

Furthermore, over 50% of participants indicated that the as-built backlog was a reason for concern and more than 10% indicated that their as-built backlog was unmanageable.

The webcast continued with a description of a typical as-built workflow and a discussion of the three main causes of the as-built backlog. A strategy for resolving the as-built backlog and improving data currency was presented and demonstrations were used to highlight resulting benefits.

If your as-built drawings are months or years out-of-date and you’re looking for ways of improving the currency of your infrastructure databases, please check out the archived webcast here.

GIS Databases Negatively Impacted by As-Built Problem

I just returned from Dallas, Texas this week where I delivered a seminar discussing data to design workflows and CAD/GIS integration. During the seminar, which was hosted by Expert Computing Solutions, an interesting discussion on the topic of the as-built backlog arose. Recall from one of my previous posts that the as-built backlog refers to the delay between when infrastructure has been constructed and when information about this construction is entered into GIS and records databases. According to seminar participants, that delay ranges anywhere from a few months to several years. Some participants revealed an indefinite delay; in other words, their databases were never up-to-date!

So, what are the problems of such a delay? What are the consequences of not having an up-to-date GIS database? Well, the impacts are many; listed below are just a few…

Poor decision making: Out-of-date information about the type, location and other related attributes about the above and below ground infrastructure can lead to inaccuracies in predicating future repair and maintenance requirements which can lead to decreased infrastructure life expectancy and premature replacement.

Decreased efficiency: When work orders are based on out-of-date databases, field activities are impacted; for example, when crews are dispatched in response to a repair or routine maintenance request only to find that upon arriving at the field location that they have the wrong equipment, crews must make a trip back to the warehouse to retrieve the correct piece of equipment. The result is an inefficient use of resources with time, dollars and fuel all wasted.

Re-work: Re-work occurs when the information in the GIS database must continually be verified against paper as-built drawings simply because this as-built information had not been loaded into the database yet.

Data confidence: When users know that the corporate database is not current, confidence in the data can be eroded to the point where users stop relying on the corporate database in favor of their own records. The result is data redundancy and all its corresponding problems.

Insufficient budgets: When infrastructure budgets are derived from out-of-date databases, a budget shortfall becomes a real possibility, especially in areas of rapid growth.

Environment and public safety issues: Worse yet, when users trust out-of-date information, bad decisions can be made – decisions which can harm the environment, impact public safety and create liability exposure. For example, according to the National Post, trusting old design drawings proved to be a costly mistake, when a contractor ruptured a crude oil pipeline in Burnaby, BC almost two years ago. The result was a toxic geyser that spewed almost a quarter of a million litres of crude oil onto residences, streets and into the Pacific Ocean.

Inaccurate regulatory reports: The accuracy of reports on capital assets in response to regulatory requirements such as PSAB 3150 and GASB 34 becomes suspect when based on GIS databases that are suppose to have a current inventory of above and below ground infrastructure but instead are potentially years out-of-date.

I’m sure the as-built problem generates additional consequences. However, given the above, can corporate GIS databases that are months or years out-of-date really be trusted? Caution is prudent.

If you know of other as-built related issues or have related comments, I would enjoy hearing from you…

As-built Backlogs Impact Accuracy of PSAB 3150 Reports

As of January 2009, Section 3150 of the Public Sector Accounting Board (PSAB 3150) requires Canadian municipalities to report on their tangible capital assets including roads, bridges, utilities, water systems, sewer networks and land. The accuracy of such a report is based, in part, on the currency of a municipality’s infrastructure inventory databases. However, these databases are often out-of-date due to the as-built backlog.

The as-built backlog refers to the delay experienced between when infrastructure has been constructed and when information about this construction is entered into the records database. These delays often span months and sometimes years and make it difficult to provide reliable information about the infrastructure for field, management and regulatory requirements such as PSAB 3150.

The as-built workflow can be explained with an example. A new subdivision project typically starts by assembling a collection of cadastral maps, existing infrastructure data and other information from a variety of sources to create a base map. Subdivision design is next; new infrastructure is drafted, existing infrastructure is updated and detailed design drawings for construction are created. Then construction takes place and upon completion, information about the construction is collected and compared to the design documents to create an as-built drawing. This as-built information is then used to update the infrastructure inventory database.

The as-built problem arises for several reasons:

• Accelerated development during booming economies often means that engineering and construction firms have all-hands-on-deck to keep up with construction demand. Consequently, creating as-built drawings is sometimes just not a priority.
• As-built drawings are often created from paper design documents that contain redline markups describing the as-constructed information. These paper documents are then re-drafted to create an electronic version that is added to the infrastructure inventory database. The re-drafting effort is error prone and time consuming.
• As-built drawings and the infrastructure inventory database are often maintained via different systems (typically CAD and GIS) and by different departments. Loading CAD data into a records database may require translation, editing for topology and other inefficient workflows.

As you can see, workflow contributes to the as-built backlog which impacts the currency of the infrastructure database and inadequate currency impacts the accuracy of PSAB 3150 reporting. If your infrastructure database is months or years out-of-date then how can you be sure that your PSAB 3150 reports on tangible capital assets are accurate?

The solution requires a new way of thinking. Stay tuned as I discuss proposed solutions to the as-built problem in future posts.

Until next time…