7. Information and Systems

Chapter 7

Information and Systems

TAM is naturally a data-driven activity; well-managed data and integrated information systems are keys to success. Asset data collection processes, management systems and reporting platforms are costly to implement and maintain. It is important to plan and design them in a deliberate fashion to serve decision making and reporting needs – while making them both maintainable and adaptable.

This chapter builds on the discussion of TAM information and needs in Chapter 6. It covers processes and tools for TAM data collection, management, integration and reporting.

Section 7.1

TAM Information Integration

This section discusses the different information systems in a transportation agency and the need to connect data across these systems to provide an integrated view of information. It provides an overview of how to plan for system integration efforts – recognizing key integration points and data flows. It ends with a discussion of integrating data across the TAM life cycle.

Section 7.2

Collecting Asset Data

This section discusses approaches to collecting and maintaining asset inventory and condition data. It builds on the discussion of monitoring requirements included in Chapter 6.

Section 7.3

Asset Data Sharing, Reporting and Visualization

This section covers approaches to sharing, reporting and visualizing asset data to support agency decision making. It builds on the discussion of TAM Information Integration in section 7.1 and focuses on how to get value from the integrated data. This involves careful planning to define the needs of different users and design ways of delivering and sharing data to meet varying needs.

Section 7.4

Data Governance and Management

This section provides an overview of data governance and management practices that are essential for achieving data quality, consistency and integration. These practices are applicable to all kinds of agency data, and are best implemented at the agency-wide level. After introducing general concepts and principles, the section highlights specific governance and management applications for TAM. It concludes with a synthesis of available tools for assessing data governance and management maturity levels.

Section 7.1

TAM Information Integration

This section discusses the different information systems in a transportation agency and the need to connect data across these systems to provide an integrated view of information. It provides an overview of how to plan for system integration efforts – recognizing key integration points and data flows. It ends with a discussion of integrating data across the TAM life cycle.


TAM Data and Systems

Often organizations maintain data on inventory, condition and needs for individual asset classes in separate, self-contained systems. However, increasingly it is necessary to integrate asset and related data distributed across multiple systems to support decision-making.

As discussed in Chapter 6, there are several different types of information needed for TAM decision making. These include:

  • Asset inventory and design information including location, type, quantity, material, and design details. This also includes summary level information about the asset as a whole as well as information about individual asset components (e.g. different pavement layers or bridge elements). It may also include asset valuation information (calculated based on deteriorated replacement cost, historic cost, or fair market value).
  • Asset condition and performance information including results of visual inspections, measured condition (such as roughness or cracking for pavements), and computed measures of performance (such as remaining service life or “deficient” status designation). This also includes aggregated network level measures (such as the percentage of pavement in good condition).
  • Contextual information such as system or network characteristics, functional classification, highway geometric characteristics, traffic volumes, congestion and reliability, crash history, adjacent land uses, weather and features of the natural environment. This information is helpful for understanding factors that may impact the asset service requirements or goals, physical deterioration, funding eligibility, and/or project needs and constraints.
  • Work information including date, cost and scopes of work proposed, scheduled and completed on assets – including installation, replacement/reconstruction, rehabilitation, preservation and maintenance. When projects include multiple assets, it is valuable to itemize the work performed by asset.
  • Revenue and funding allocation information including historical and forecasted funds available for asset installation, replacement/reconstruction, rehabilitation, preservation and maintenance – by source; and historical allocations by asset category and work type.
  • Analysis information including forecasted condition and needs under varying funding or program scenarios, treatment life or life extension results, or project prioritization ratings or rankings.

Agencies store and manage TAM-related data within several different information systems:

  • Asset Management Systems (AMS) – this includes pavement management systems (PMS), bridge management systems (BMS), management systems for other specific asset classes (sign or signal management systems), and systems used to manage information for multiple asset classes. All of these systems are used to store inventory and inspection data, and track work performed on an inventory of assets. They also typically include contextual information needed for modeling and analysis, such as traffic, functional classification, number of lanes, and presence of a median. More advanced management systems may identify and forecast preservation and rehabilitation or replacement needs, and analyze funding scenarios. However, often agencies use multiple systems for this purpose, with separate systems for maintaining the asset inventory and predicting future conditions. Pavement and bridge management systems are typically used as the sources for federal Highway Performance Monitoring System (HPMS) and National Bridge Inventory (NBI) reporting.
  • Maintenance Management Systems (MMS) – used to plan and track routine maintenance activities. These systems typically store information about planned and completed maintenance activities and resources (labor, materials, equipment) consumed. MMS may include customer work requests, work orders, and maintenance level of service (LOS) information. Some MMS do not store any asset inventory data. In such cases, work is tracked by maintenance activity category and route section rather than specific asset. Note that there are many commercial Asset Management Systems that provide full functionality for asset inventory, inspection/condition assessment, work planning, and work tracking.
  • Program and Project Management Systems (PPMS) – used to manage information about capital and major maintenance projects from initial planning and programming through completion. There may be separate systems for managing programming/funding information, preconstruction/design information and construction phase information. Some agencies integrate data from these various systems to obtain a single source of project information. Project information typically includes a mix of tabular data as well as unstructured data (for example, documents and images). Unstructured data may be managed within an engineering content management system separately from other data.
  • Financial Management Systems (FMS) – used to manage and track revenues, expenditures, budgets, grants, payments, receipts, and other financial information. These systems are often supplemented with special purpose tools supporting budgeting, revenue forecasting and analysis.
  • Enterprise Resource Planning Systems (ERP) – incorporate features of financial systems as well as a wide variety of other modules for functions including human resources, payroll, purchasing, maintenance management, inventory management, equipment management, project programming, project financial management, and revenue forecasting.
  • Highway Inventory Systems (HIS) – used to store and report administrative and physical characteristics of the roads and highways. Federal Highway Performance Monitoring System (HPMS) requirements and the Model Minimum Inventory of Roadway Elements (MIRE) define standard road inventory elements; some DOTs maintain additional elements. HPMS elements include pavement type, pavement condition (roughness, cracking, rutting and faulting), and structure type. These systems may include Linear Referencing System (LRS) management capabilities or, may be integrated with a separate LRS management system. Per FHWA’s All Roads Network of Linear Referenced Data (ARNOLD) requirements, state DOTs must submit an LRS for all public roads to FHWA, linked to their HPMS data.
  • Crash Data Systems (CDS) – used to store and report data about collisions and resulting injuries and fatalities; which when combined with traffic data and road inventory data provides information for identifying traffic and safety asset needs.
  • Traffic Monitoring Systems (TMS) – used to store and report traffic data, required for federal reporting and used for a wide variety of purposes, including TAM processes for asset deterioration modeling, treatment selection and prioritization.
  • Engineering Design Systems (EDS) – used to create design drawings or models including design details for different assets. As agencies adopt 3D object-based design modeling practices, there are opportunities to share information about assets between design models and other asset data systems used across the life cycle.
  • Enterprise Geographic Information Systems (GIS) – used to manage spatial information, including asset location. Assets may be represented as point, linear or polygon features; location may be specified based on coordinates and/or based on a linear referencing system (LRS). Asset features maintained within GIS may be linked to asset information within other systems.
  • Imagery Databases (ID) – used to store highway video imagery and mobile LiDAR data that can be used for manual or semi-automated extraction of asset inventory.
  • Data Warehouses/Business Intelligence Systems (DW/BI) – used to integrate data from source systems for reporting and analysis. These may be tailored for TAM decision support.
  • Other – there may be other specialized decision support tools that produce analysis results – for example, tools for life cycle cost analysis, cross-asset optimization, or project prioritization.

Taking stock of what data and information systems supporting TAM is a critical first step to take before pursuing data integration and system development initiatives.

Table 7.1 provides an overview of different systems with the types of information they typically contain. Note that this may vary within each agency.

Table 7.1 - TAM Data and Systems Overview (example)

Asset Inventory, Condition, and PerformanceContextualAsset Work InformationRevenue and Funding AllocationsAnalysis Results
Asset Management Systems
Maintenance Management Systems
Program and Project Management Systems
Financial Management/ERP
Road Inventory Systems/HPMS
Crash Databases
Traffic Monitoring Systems
Engineering Design Systems
Enterprise GIS Databases
Imagery Databases
Data Warehouses/BI

Common components included in computer-based asset management information systems are shown in Figure 7.1. Network inventory, network definition (e.g., location), and asset condition information serve as the primary components in a database, which may or may not be external to the management system. Agency-configured models are used to predict changes in asset condition over time and to determine what treatments are appropriate as the assets age and deteriorate. These models may be developed and updated based on historical condition and cost data.

When developing a computer-based model, an objective (performance, condition, financial, risk) must be defined within the model for it to evaluate these criteria to develop and select optimal strategies. Metrics such as benefit-cost, risk, condition and treatment costs are often used.

A typical pavement management system performs some type of benefit/cost analysis that determines the performance benefits (typically in terms of improved condition) and the costs associated with each possible treatment timing application. By selecting the projects and treatments with the highest benefit/cost ratio, an agency can demonstrate that it is maximizing the return on its investment.

Bridge management systems more typically rely on optimization to perform a single-objective analysis, such as minimizing life cycle costs or maximizing condition, or a multi-objective optimization analysis that considers factors such as condition, life cycle cost, risk of failure, and mobility. Project- and/or network-level benefit/cost analyses are used in a bridge management system to explore all feasible treatment options over an analysis to determine the most cost-effective set of treatments with the highest benefits to the network.

Start by defining what questions the agency wants to answer and then make a plan for how data across systems could be integrated to answer these questions.

Figure 7.1 Typical Management System Components

Source: Applied Pavement Technology, Inc. 2018.

Figure 7.2 shows an example of how the different systems listed in Table 7.1 might be integrated, adapted from the approach used by a U.S. state DOT.

Figure 7.2 Data Integration Example

Source: Adapted from Applied Pavement Technology, Inc. 2018.


Why Integrate?

Integrated views of asset information enable insights that lead to better decisions. Information produced by one part of the agency can support decision making across the agency.

Linking information across different systems enables agencies to quickly answer important questions that might have taken hours of staff time without integrated data. Integrating data opens up access to previously siloed data sets across the organization. It allows an agency to reduce duplicative effort, achieve efficiencies and derive greater value from its data. Some questions that rely on integrated data are:

Investments and Accomplishments

  • What have we spent over the past ten years on route X in county Y (across all assets and including both maintenance and rehabilitation)?
  • What percentage of deficient pavements will be addressed by our current capital and major maintenance programs?

Work Costing and Scoping

  • What does it cost us to restripe a mile of pavement markings in each district?
  • What locations identified along the linear referencing system (LRS) are planned for next year?
  • Do the costs estimated by our pavement management system match what we are actually seeing in our projects?
  • If we upgrade our guardrails whenever we do a paving project, how long will it take, and what will it cost to eliminate the current backlog?
  • How can we best plan our projects to address multiple needs that may exist along a corridor?


  • How many years does our standard mill and fill pavement treatment last for roads in different traffic volume categories?

Tradeoffs and Prioritization

  • How should we prioritize our asset replacement/rehabilitation projects, considering not only life cycle management strategies but also stormwater management, safety, congestion, non-motorized, transit and ADA needs?
  • How should we allocate our available funds across multiple asset types?

Disaster Recovery

  • What assets were on route X in county Y prior to the storm? What will it cost to replace them?

An integrated approach to asset data collection, management and reporting not only makes it easier to answer these questions; it also can reduce costs. Opportunities for achieving efficiencies include:

  • Using a single application to manage information about multiple assets.
  • Using Data Warehouse/BI and GIS tools to provide reporting and mapping functions rather than investing effort to develop these capabilities within individual asset management systems.
  • Gathering data on multiple assets through the same approach – using mobile technology, video imagery and/or LiDAR (see section 7.2)
  • Sharing asset data across the life cycle – for example, automating methods for extracting asset data from design plans to update asset inventories (described further below).

Emerging technologies and new data sources are making an integrated approach to asset data management even more important. For instance, there are increasingly opportunities to use data collected from cell phones and connected vehicles that may cut across many asset categories. Also, there has been and will likely continue to be rapid advancement in machine learning techniques, such as for extracting asset data from video imagery or predicting optimal maintenance interventions given a wide array of data. Using these techniques typically requires establishing large, integrated data sets.

In addition, advances in computer-aided design and engineering software are making it possible to integrate asset data across the life cycle and achieve efficiencies and cost savings in maintaining asset inventories. See the discussion in section 7.1.4 further on.

Integrating information systems can be approached incrementally. Have a long term goal in mind and find opportunities to move towards this goal as systems are upgraded or replaced.

Ohio DOT

Ohio DOT has separate pavement and structures management systems, but integrates both asset and project information within its Transportation Information Management System (TIMS). A separate Transportation Asset Management Decision Support Tool (TAM-DST) allows for a user to combine data from TIMS with other state-maintained data sets to perform analysis and reporting. The application allows for one to consume large quantities of data in a timely manner to help make better choices in planning. See practice examples in Section 2.2.4 and Section 6.2.1 for more information on TIMS.


Planning for TAM Information Integration

There are different levels of integration. In the short term, agencies can integrate the information they already have. In the longer term, agencies can modify and consolidate their information systems. Integrating data for TAM should be approached systematically to ensure agencies achieve a solution that meets their needs and is ultimately sustainable.

Step 1: Establish Requirements

What is the purpose of the integration? To create a publicly available map showing asset conditions and projects for both internal and public use? To create a BI environment for answering a range of questions about asset performance and cost? To integrate asset data across different systems used for planning, design, construction, and maintenance?

Based on the identified needs, determine what data will be integrated and at what frequency. Consider whether this will require historical data, current data, future projections, or a combination.

Early collaboration between business units and information technology units is important to establish a shared understanding of both business needs as well as technical requirements and constraints. A strong business-IT partnership is essential for successful information integration initiatives.

Step 2: Identify and Evaluate Data Sources

Identify the available data sources to meet requirements. Determine where the data reside, and in what form – such as engineering design systems, relational databases, spreadsheets, document repositories, etc. Assess the current level of data quality to make sure that the source is ready for integration, based on discussions with the data steward or through examining the data. For design files/models a key quality consideration is whether established standards have been consistently applied. It is also important to determine the level of spatial and temporal granularity – or what does each record represent (such as a pavement condition observation for a 0.1 mile section for April 2019; a paving project on a 1.5 mile section due to open for traffic sometime in 2020).

Step 3: Analyze Linkages

Identify how different data sources will be linked. Spatial linkages are a good place to begin. If GPS coordinates are used, make sure that the Coordinate Reference System (CRS) used is documented, along with positional accuracy. If a Linear Reference was used, determine what method was used to establish the measure along the route, and what version of the agency’s LRS was used to establish route identifiers and reference points. Find out if the linear reference has been updated to reflect changes in the LRS since the data were last collected (if applicable).

Set standards for how assets and work activities will be linked to GIS/LRS locations. Then create processes and tools to make sure these standards are followed.

Identify other types of (non-spatial) linkages that may be needed to join different data sources – for example, project numbers, account codes, work order numbers, etc. Agencies may want to profile the data for these elements to understand variations in coding and formats.

Step 4: Design Data Flows and Select Technology Solutions

Based on the requirements, available data, the linkage analysis and the tools and resources available within the agency, design how the data will flow from sources to target systems, and select the technology solutions to be used for performing the integration itself. The target system might be a general purpose enterprise geodatabase, an enterprise asset management database, a BI tool reporting data source, data warehouse, or a data lake. Data Extract-Transform-Load tools are available from data warehouse vendors; simple integration tasks may be accomplished through scripting. There are also a variety of specialized tools available for transforming and combining spatial data, and for extracting data from CAD/3D models.

Step 5: Design and Implement Integration Methods

Develop the technical approach for transforming link fields so that they are consistent across databases and if applicable, joining the different data sets and combining common data elements from the different sources. This may involve spatial processing (such as dynamic segmentation), aggregation, coding conversions, and other transformations.

Short term integration strategies include:

  • Creating GIS data layers and making them accessible in available web and desktop-based GIS software. This strategy requires that each data source uses compatible spatial referencing, or can be converted to a common referencing system.
  • Creating a database or view combining data from various source systems, and using available BI/Reporting tools to create reports and data visualizations. This strategy requires identifying common “dimensions” across source systems and/or normalizing data so that it can be summarized. For example, if the agency wants to report asset quantities by district or county by year, it will be necessary to make sure that each source has these data elements and that the data can be converted to a consistent set of values.
  • Exposing data from authoritative sources as services via Application Programming Interfaces (APIs).

In the longer term, agencies can consider re-architecting or consolidating their systems so that they work better together. A logical way to approach this is to document the “as is” situation and then map out a “to be” architecture. This will allow the agency to chart a path from the current state to the desired future state. It will also provide a framework for capturing requirements for any new systems that are brought into the agency.

Integrated asset management systems are not a new concept and there are several commercial systems that support information management and work planning for multiple asset types. However, some agencies are challenged to integrate information about major assets (pavements and bridges) with information about various other ancillary assets – given that approaches to planning and budgeting for major assets are more sophisticated and require a greater level of detailed information and analysis. Also, it can be a challenge to integrate information about operations and maintenance with capital projects given differences in how work is categorized, performed, and tracked.

Find opportunities to save on data collection costs by capturing asset information during project design and construction.

Kansas DOT

KDOT’s architecture was based on a value chain model that represents the agency’s business components and relationships. It included a set of “context diagrams” showing information flow across systems and actors for major subject areas including highway asset systems, long range planning, pre-construction, construction and maintenance. While an architecture does require significant effort to create and maintain, it provides a more global and stable view of business processes and information needs than what would be produced through a piecemeal, incremental approach to system upgrades and replacements. This view can be used to plan the path from the existing set of systems to a more efficient and integrated set.

Kansas DOT Value Chain Framework

Source: Adapted from Kansas Department of Transportation. 2003. Enterprise IT Architecture


Integrating Asset Information Across the Life Cycle

As assets are designed, created, maintained, restored, and replaced, different systems are typically used to keep records of asset characteristics, conditions and work. Ideally, information created at one stage of the asset life cycle is made available for use at the next stage. Techniques, tools and processes are available to manage data for an asset over its entire life cycle from construction or acquisition to disposal.

Integrating information across the transportation infrastructure life cycle is an area of significant interest in the transportation industry. Several terms have been used to describe the collection of processes, standards and technologies for accomplishing such integration – including Civil Integrated Management (CIM) and Building Information Modeling (BIM) for Infrastructure. In 2019 ISO issued its first BIM standard, ISO Standard 19650. This builds on an earlier standard published by the British Standards Institute (BSI).

Traditionally, information created at one phase of the life cycle is archived and not made available to downstream processes. There are substantial opportunities for cost savings by using a shared, electronic model of the infrastructure, defining information needs at each life cycle phase, and establishing procedures for information handoffs across the life cycle. For example, information about assets included in a construction project can be compiled during design and linked to the model representations of the assets. This information can be confirmed and corrected during construction and made available to asset management systems when the project is completed and turned over to maintenance and operation.

Such integration can reduce duplicative data collection efforts, and speed the time required to make decisions and perform work. Implementing these techniques requires much more than adoption of technology supporting 2D and 3D models. A commitment to common standards and processes is needed. Recognizing that this scale of change takes time, maturity models and levels of implementation have been defined to guide agencies in developing roadmaps for enhancing life cycle information integration over time. See the references at the end of this chapter for further information.

Figure 7.3 Integrated Workflow Model for Sharing Information Across the Life Cycle Components

Transportation Research Board. 2016. Civil Integrated Management (CIM) for Departments of Transportation, Volume 1: Guidebook. https://www.nap.edu/read/23697/chapter/5#16


Crossrail is a major design-build project to construct a new railway line across central London (UK). It includes 42 km of track and 10 new underground stations. Project construction began in 2009. The project is being delivered by Crossrail Limited (CRL), currently a wholly owned subsidiary of Transport for London (TfL). Once the project is complete it will be operated by TfL as the Elizabeth Line. The Crossrail project provides a good example of the application of several BIM elements. Early on, CRL established the following objective:

To set a world-class standard in creating and managing data for constructing, operating and maintaining railways by:

  • Exploiting the use of BIM by Crossrail, contractors and suppliers
  • Adoption of Crossrail information into future infrastructure management (IM) and operator systems

CRL established a Common Data Environment (CDE) with integrated information about the project and the assets it includes. This environment included CAD models, separate linked databases containing asset details, GIS data, and specialized applications for scheduling, risk management and cost management. Data warehousing techniques were used to combine and display integrated information. Considerable work went into defining asset data requirements and setting up standard, well documented data structures and workflows to provide an orderly flow of information from design through construction, and on to maintenance and operation. It was essential to create a common information architecture given that work on each of Crossrail’s nine stations was conducted by different teams, each consisting of multiple contractors. Each station was comprised of over 15,000 individual assets.

Key elements of the approach included:

  • A common asset information database with standard templates for deliverables. This database serves as the “master data source from which playlists of information can be created.”
  • An asset breakdown structure (ABS) that relates facilities (e.g. stations) to functional units (e.g. retaining walls) to individual assets (e.g. steel piles).
  • Asset naming, identification and labeling standards that distinguish functional duty requirements (e.g. a pump is needed here) from specific equipment in place fulfilling these requirements.
  • Asset data dictionary definition documents (AD4s) that lay out the specific attributes to be associated with different types of assets, based on the ABS.
  • Sourcing of the asset data from design and as-built information.
  • A Project Information Handover Procedure specifying the methods of data and information handover for maintenance and operations once the construction has been completed.
  • Use of a common projected coordinate system for CAD and GIS data
  • Use of a federated data model in which information was maintained within separate special purpose systems, with a common master data model enabling sharing and interpretation of data from the different sources. The master model included elements such as time periods, budget and schedule versions, organizations, data owners, contractors, milestones and key events.




BIM Lifecycle Information Management

Source: Adapted from Crossrail. 2016. Building A Spatial Data Infrastructure For Crossrail. https://learninglegacy.crossrail.co.uk/documents/building-a-spatial-infrastructure-for-crossrail/

Section 7.2

Collecting Asset Data

This section discusses approaches to collecting and maintaining asset inventory and condition data. It builds on the discussion of monitoring requirements included in Chapter 6.


Deciding What Data to Collect

Many organizations have recognized that data should be viewed as an asset. Before acquiring new data, it is important to establish a clear statement of how the data will be used and what value it is expected to provide.

Deciding what data to collect involves identifying information needs, estimating the full costs of obtaining and managing new data and keeping it up to date, and then determining whether the cost is justified. Just as agencies don’t have unlimited resources to repair and replace their assets, there are also limitations on resources for data collection and management.

A 2007 World Bank Study summarized three guiding principles for deciding what data to collect:

  • Collect only the data you need;
  • Collect data to the lowest level of detail sufficient to make appropriate decisions; and
  • Collect data only when they are needed.

Chapter 6 can be used to help identify the information needed to track the state of the assets and investments to maintain and improve them. The basic questions one needs to answer to identify needed data are:

  • What decisions do we need to make and what questions do we need to answer that require asset data? Typically, an organization needs to be able to answer questions including but not limited to its asset inventory, the conditions and performance of the inventory, and how resources are being spent on its assets. Also, an organization needs to determine what work is needed and how much that work will cost.
  • What specific data items are required or desired? Next, one must identify the data required to meet the established information needs. There may be other data items that are not strictly required, but that may be useful if collected in conjunction with the required data. For instance, answering questions and making decisions regarding pavement an organization would typically want to have an inventory of existing pavement, details on paving materials used, and details on current conditions. Additional information on treatment history or substructure conditions might not be strictly required, but if available could enhance the decision-making process.

It is also important to incorporate standard data elements for location and asset identification into requirements, ensuring consistency with other asset data in the agency.

  • What value will each data item provide? It is important to distinguish “nice to have” items from those that will clearly add significant value. The cost of collecting and maintaining a data element should be compared with the potential cost savings from improved decisions to be made based on the element. Cost savings may be due to asset life extension, improved safety, reduced travel time, or internal agency efficiencies. In addition, proxy measures for information value can be considered such as the number and type of anticipated users, and the number and type of agency business processes to be impacted.
  • What level of detail is required in the data? Level of detail is an issue for all assets, but is particularly an issue for linear assets such as pavement, where one may decide to capture data at any level of detail. For instance, to comply with Federal reporting requirements for pavement condition a state must collect distress data at 1/10 mile intervals for one lane of a road (typically the outside line in the predominant direction). For other applications it may be necessary to collect data for additional lanes, or at some other interval.
  • TIP
    Look for ways to "collect once, use multiple times" by leveraging existing data and planning data collection efforts to capture information about multiple assets.

  • What level of accuracy is needed? The degree of accuracy in the data may have a significant impact on the data collection cost and required update frequency. Ultimately the degree of accuracy required in the data is a function of how the data are used. For instance, for estimating the clearances under the bridge for the purpose of performing a bridge inspection it may be sufficient to estimate the clearance at lowest point to the nearest inch using video imagery. However, more accurate data may be required when routing an oversize vehicle or planning work for a bridge or a roadway underneath it. If a high degree of accuracy is not required it may be feasible to use sampling strategies to estimate overall conditions from data collected on a subset of assets.
  • How often should data be updated? Is the data collection a one-time effort, or will the data need to be updated over time? If data will need to be updated should the updates occur annually, over a period of multiple years, or as work is performed on an asset?

Table 7.2 below illustrates examples of data collection strategies that might address different information needs.

7.2 Example Data Collection Strategies

Example Asset(s)Type of InformationExample DecisionsExample Data Collection Strategies
Pavement MarkingsTotal asset quantity by type, district, and corridor or subnetworkBudgeting for assets maintained cyclicallyEstimation based on sampling

Full inventory every 3-5 years with interim updates based on new asset installation
Roadside SignsInventory of individual assets – location and typeWork planning and scheduling for assets maintained cyclically

Project scoping
Full inventory every 3-5 years with interim updates based on new asset installation
GuardrailInventory + General Condition (e.g. pass/fail or good-fair-poor)Work planning and scheduling for assets maintained based on conditionInventory and condition assessment every 2-3 years

Inventory and continuous monitoring (e.g. from maintenance crews or automated detection)
BridgesInventory + Detailed ConditionTreatment optimization for major, long life cycle assetsInventory and condition assessment every 1-2 years + continuous monitoring (e.g. strain gages on bridges)

Once a general approach has been established, more detailed planning for what data elements to collect is needed. Prior to selecting data elements, identify the intended users and uses for the data, keeping in mind that there may be several different uses for a given data set. Identify some specific scenarios describing people who will use the information, and then validate these scenarios by involving internal stakeholders.

One common pitfall in identifying information needs is failing to distinguish requirements for network level and project level data. While advances in data collection technology make it feasible to collect highly detailed and accurate information, it is not generally cost-effective to gather and maintain the level of information required for project design for an entire network of assets.

A second pitfall is failing to consider the ongoing costs of updating data. The data update cycle can have a dramatic impact on data maintenance costs. Update cycles should be based both on business needs for data currency and how frequently information is likely to change. For example, asset inventory data is relatively static, but condition data may change on a year-to-year basis.

A third common pitfall is taking an asset-by-asset approach rather than a systems approach in planning for both asset data collection as well as downstream management of asset information.

Even when there is a strong business case for data collection, it is sometimes necessary to prioritize what data are collected given budget and staffing constraints. Some agencies do this by establishing different “tiers” of assets. For example:

  • Tier 1: Assets with high replacement values and substantial potential cost savings from life cycle management (such as pavements and bridges)
  • Tier 2: Assets that must be inventoried and assessed to meet legal obligations (such as ADA ramps, stormwater management features)
  • Tier 3: Assets with high to moderate likelihood and consequences of failure (such as traffic signals, unstable slopes, high mast lighting and sign structures)
  • Tier 4: Other assets that would benefit from a managed approach to budgeting and work planning (such as roadside signs, pipes and drains)

While updating data can be expensive, various strategies are available for combining data collection activities to reduce the incremental cost of collecting additional data. For instance, one approach to collecting data on traffic signal systems is to update the data when personnel perform routine maintenance work. Also, in some cases data can be extracted from a video log captured as part of the pavement data collection process.

Given limited resources for data collection, it may be helpful to formally assess the return on investment from data collection or prioritize competing data collection initiatives. A formal assessment may be of particular value when considering whether the additional benefits from collecting additional data using a new approach justify the data collection cost. NCHRP Report 866 details the steps for calculating the return on investment (ROI) from asset management system and process improvements, including asset data collection initiatives.

Oregon DOT

  • Tier 1: Assets with high replacement values and substantial potential cost savings from life cycle management (e.g. pavements and bridges)
  • Tier 2: Assets that must be inventoried and assessed to meet legal obligations (e.g. ADA ramps, stormwater management features)
  • Tier 3: Assets with high to moderate likelihood and consequences of failure (e.g. traffic signals, unstable slopes, high mast lighting, sign structures)
  • Tier 4: Other assets that would benefit from a managed approach to budgeting and work planning (e.g roadside signs, pipes and drains)


How to Collect Data

As technology continues to advance there are more methods available for collecting data related to assets. It is important for agencies to understand the technology and options available for data collection. Depending on the asset-type or data needed, a different data collection approach may be preferable. This section provides information on making that decision.

There are many different approaches to collecting asset and related data. Often a mix of approaches is used, including visual inspection, semi-automated and automated approaches. The technologies for data collection are advancing rapidly, allowing for increased use of semi-automated and automated approaches for collecting more accurate data at a lower cost. Examples of recent innovations include:

  • Improvements in machine vision that allow extracting some forms of asset inventory data from video or LiDAR.
  • Use of unmanned aerial vehicles (UAV, also called drones) for allowing bridge inspectors to obtain video of hard-to-reach areas of a bridge.
  • Improvements in non-destructive evaluation (NDE), allowing for greater use of techniques such as ground penetrating radar (GPR) for pavement and bridge decks and instrumenting bridges to monitor performance over time.
  • Improvements in hand-held devices allowing for increased field use, reducing cost and time of manual data collection.

Several of these technologies provide opportunities to save money by collecting data for multiple assets within a single collection effort. Table 7.3 provides a summary of potential data collection approaches for common roadway asset classes.

Before collecting new data, make sure you are leveraging data that already exists or is already collected, and coordinate with other agency groups that may have a need for the same data.

Table 7.3 - Example Data Collection Approaches

Asset ClassData Collection MethodData CollectedNotes
PavementVisual InspectionPresent Serviceability Index (PSI)Often used in urban environments or for small networks where data collection using automated collection approaches is impractical – can be supplemented by UAVs
PavementAutomated data collection vehicle with laser scanning systemroughness, cracking, nuttingIncludes a range of 2D video and 3D laser-based systems. Many systems store video images and can capture additional measures, such as cross slope, gradient and curvature
PavementLight Detections and Ranging (LiDAR)/ Terrestrial Laser Scanning (TLS)roughness, cracking, nuttingProvides a high resolution continuous pavement survey. Often inventory data for other assets can be extracted from the data set
PavementFalling weight deflectometerstrength/deflection
PavementLocked wheel tester/spin up testerskid resistance
PavementGround Penetrating Radar (GPR)layer thicknesses, detection of voids and crack depth
PavementCoringlayer thicknesses, detection of voids and crack depth
PavementSmart phonespotholes, roughnessIncludes systems for reporting of potholes and measuring roughness through crowdsourcing
Structures and BridgeSensorsinventory, condition ratingsStrain and displacement gauges; wired or wireless,
Structures and BridgeUnmanned Aerial Vehicles (UAVs)condition of non-bridge struc- tures (e.g. retaining walls)
Structures and BridgeLiDARVertical Clearance
Structures and BridgeVisualinventory, condition ratingsCan be supplemented using UAV and other technologies
Structures and BridgeAcoustical (e.g., impact echo)delamination, corrosion
Structures and BridgeInfrared/ Thermal Imagingdelamination, corrosion
Structures and BridgeGPRconcrete deck condition
Structures and BridgeHalf Cell Potential Testconcrete deck condition
Traffic SignsVideologinventory, condition ratingsautomated or semi-automated techniques available for classification
Traffic SignsMobile LiDARinventory, condition ratings
Traffic SignsField Inspection – mobile applicationinventory, condition ratings
Traffic SignsRetroreflectometerretroreflectivity

Once data are collected, it is essential to put in place regular processes for updating the data. This can be accomplished through periodic data collection cycles, or through updating as part of asset project development and maintenance management processes.

Michigan DOT

Unmanned Aerial Vehicles (UAVs) offer several advantages for asset data collection. They can fly into confined spaces such as entrances to sewers and culverts to collect data and images. They can collect high resolution images, thermal images and LiDAR. LiDAR can be used to produce three dimensional images that allow for accurate measurements. Thermal images can be used to detect subsurface concrete deterioration.

Michigan DOT analyzed the benefits of using UAVs for bridge inspection, and concluded that using a UAV for a deck inspection of a highway bridge reduces personnel costs from $4600 to $250. A traditional inspection would take a full day and require two inspectors, and two traffic control staff to close two lanes of traffic. The same inspection using a UAV takes 2 hours and would require only a pilot and a spotter. An additional savings of $14,600 in user delay cost was estimated based on delays associated with shutting down one lane of a four lane, two way highway bridge in a metropolitan area for a bridge inspection.

Tennessee DOT

The Tennessee DOT uses an automated data collection van to collect pavement condition surveys each year in support of its pavement management system. In addition to the pavement sensors, the van also has high definition cameras and LIDAR sensors which scan the roadway and create a 3D model of the environment. As the surveys are conducted, inventory information for approximately 20 highway assets is extracted from photolog and LiDAR information. The inventory from the past data collection cycle is compared to the data collected during the current data collection cycle to determine any changes to asset inventory to keep the data up to date. Tennessee DOT summarizes this inventory data at the county level for planning and budgeting; however, they are currently working toward having the ability to report maintenance work at the asset level in the future.

Source: Federal Highway Administration (FHWA). Pending publication 2019. Handbook for Including Ancillary Assets in Transportation Asset Management Programs. FHWA-HIF-19-068. Federal Highway Administration, Washington D.C


Preparing for Data Collection

In order to get the most out of the data collection process, it is important for agencies to be thoughtful in the steps leading up to the actual collection of data. Three important steps to prepare for data collection include: coordinating with stakeholders, specifying exactly what data will be collected, and training staff to collect the data.

Once an organization has determined what data to collect and how to best to collect it, the next step is to prepare for data collection.

Step 1. Coordinate

An important step prior to collecting data is to coordinate with other stakeholders in the organization concerning the data collection effort. It may be possible, through such coordination, to identify opportunities for coordinating data collection activities to reduce costs. Alternatively, other stakeholders may identify needs for collecting related data to address other needs. Another possibility is that a different business unit in the organization has already collected data that may impact the data collection plan.

Step 2. Specify

In this step one must identify exactly what data will be collected, the means used to collect the data, and who will collect the data. If data collection is being outsourced, at this point it is necessary to establish contract specifications for data collection.

Also as part of this step one should establish the approach for quality assurance (QA)/quality control (QC). A QA/QC plan specifies the desired accuracy of the data to be collected, and describes the measures used to assure data are of the specific level of accuracy, review data quality as data are acquired, and address any data quality issues that arise. If data are collected using automated means, the plan should specify the approach for calibrating any measurement devices used for data collection. If data are collected through visual inspection the plan should detail training requirements.

Note that given data QA/QC is an area of particular concern for pavement condition data collection, given the expense involved in collecting this data and increased reliance on automated data collection techniques. The Federal performance management requirements described previously include a requirement for State DOTs to establish a QA/QC plan for pavement data collection.

Step 3. Contract

This step involves determining whether to outsource data collection and to contract for services if applicable. Decisions to outsource are typically made to tap into a vendor with specialized equipment and experience with a particular data collection technique, and to enable accomplishing a major collection effort within a compressed timeframe, which would not be possible using internal staff resources. Some agencies may implement a hybrid approach, hiring a contractor while using internal staff (or a separate independent contractor) for supervisory or QA functions.

Understand your audiences and the questions they are trying to answer.

Step 4. Train

The last step prior to collecting data is to train the staff involved in data collection and review in how data collection should be performed, as well as in their specific roles and responsibilities. Training is important for any data collection effort, but is particularly important in cases where the collection effort relies on visual inspection (for inspecting bridges). In these cases, the training requirements for inspectors should be carefully established and implemented. Even where there are no formal requirements for inspectors, it can be highly valuable to assemble inspectors prior to the start of data collection to review the data to be collected, walk through the data collection process, and perform inspections in a test scenario to ensure consistent interpretation of condition assessment language and other areas where differences in human judgement may impact how data are collected.

Once these steps have been performed the next step is to collect data, following the approach established in Step 2 for data collection and QA/QC.

Utah DOT

Utah DOT started capturing LiDAR data for multiple assets in 2011. Several different business units within the agency provided funding for the effort, which has included collection of inventory data for bridges, walls, signs, signals, barriers, power poles, striping, curb cuts, drainage, shoulders and ATMS devices – as well as pavement condition and roadway geometrics. UDOT has leveraged this integrated pool of asset data for several different applications, including one which creates a draft cost estimate for asset installation for project scoping, based on existing inventory.

Section 7.3

Asset Data Sharing, Reporting and Visualization

This section covers approaches to sharing, reporting and visualizing asset data to support agency decision making. It builds on the discussion of TAM Information Integration in section 7.1 and focuses on how to get value from the integrated data. This involves careful planning to define the needs of different users and design ways of delivering and sharing data to meet varying needs.


Designing Effective Reports and Visualizations

A wide variety of reports, maps, charts and infographics can be produced to convert raw data into actionable information. Designing effective reports and visualizations begins with a good understanding of who will be consuming the information, what their questions are, and what key messages the agency wants to communicate.

Different types of information users for asset data and sample questions they may have are shown in Table 7.4. This can be used as a starting point for identifying what types of reports and visualizations should be created. Keep in mind that increasingly, reports and visualizations are not static – they include multiple options for filtering, sorting and navigating information.

Some reports/visualizations are primarily for analysis, exploration and insight; others are primarily for communication. Some may be designed for both purposes. Those designed for analysis should emphasize flexibility – with multiple options for viewing, filtering, sorting, and exporting to various formats. Those designed for communication should emphasize simplicity and clarity of message; and clean, aesthetically pleasing design. They should reflect what the agency wants people to learn or know.

All reports/visualizations should include information that helps the user to understand:

  • the sources of the data being presented and the effective date for the data (e.g. what calendar year is represented)
  • the assumptions used for any calculated items
  • definitions of any acronyms or potentially unfamiliar terms
  • who to contact for further information

A wide array of tools and techniques are available for reporting and visualization – tabular reports, maps, charts, dashboards, infographics, and combinations. GIS is an essential visualization tool with many applications and can be integral to information presentation. While some visualizations can be produced using standard office applications, many agencies use desktop publishing and business intelligence offerings. There are several general resources available on design of effective visualizations – see the reference list at the end of this chapter. Chapter 6 contains additional examples of data visualizations.

Table 7.4 Information Needs of Different Users (continues)

User TypeSample QuestionsTypes of Reports/Visualizations
AnalystAre the asset locations in this new inventory valid?Map showing asset locations

Report listing asset locations outside of the ranges of valid route-milepoint/mileposts.
AnalystAre the observed changes in asset condition from the last inspection reasonable?Time series plot/grid of asset condition + intervening project/maintenance activities
AnalystWhat is the expected service life for asset X? What are the key factors impacting service life?Minimum, maximum, mean, median life for selected asset type – with breakdowns by subtype (e.g. concrete versus asphalt pavement), last treatment, geographic region, road class.
Map of assets with low (e.g. 25th percentile) lives with available information on contributing factors (e.g. reported drainage issues, soil quality, materials, contractor, use of road salt, etc.)
Asset/Maintenance ManagerWhat is the state of my asset(s)?Fact sheet showing inventory, condition distribu- tion, age distribution, value, performance projec- tions and targets (if applicable)
Asset/Maintenance ManagerWhich assets should be considered for treatment?Map and listing of assets showing condition information and (if available) assigned treatment need – overlaid with programmed work. Drill down to condition and work detail.
Asset/Maintenance ManagerWhat should I budget for preventive maintenance?Report showing asset quantities, unit cost for preventive maintenance, planned maintenance interval, and average annual cost over 5 year period.

Separate report to inform selection of a unit cost – historical cost per unit of work or historical labor/ equipment/materials utilization per unit of work.
Project EngineerWhat assets are within the footprint of a project I am scoping?Listing of assets and associated quantities for a defined location (route/from MP, to MP)
Project EngineerAre there opportunities to coordinate work?Map showing identified needs, proposed projects, programmed projects.
ExecutiveWhat have we been spending to maintain our assets?Time series chart showing expenditures with breakdown by asset type, work type (maintenance versus capital), district/region.

Display asset quantities and conditions on same time scale to compare expenditures against results.
ExecutiveWhat is our backlog of needs?Chart showing current needs backlog for selected assets – with available breakdowns by district/ region, road class, asset type.

Accompanying chart showing 5-10 year changes in backlog and projected backlog given revenue and funding allocation assumptions.
ExecutiveHow do asset conditions compare across districts/regions?Infographic showing asset condition (Good-Fair-Poor) bar charts superimposed on map of districts/regions.
ExecutiveHow should we allocate our available funding across different assets/ projects?Charts showing results of investment versus performance analysis

Charts showing allocation and performance results of a prioritization exercise with drill down to prioritized project lists.
Funding/Oversight Agency (State/Federal)How does the current and projected asset condition compare to the established target?Trend line showing current and projected conditions under different funding scenarios with separate line for target.
Funding/Oversight Agency (State/Federal)How do the actual pavement and bridge program accomplishments compare to those that were planned?Chart showing planned, actual, percent difference and explanation.
General PublicWhen will my street be paved?

When will the bridge replacement project be completed?

How is the DOT using its funding?
Map showing programmed projects with status/ schedule/funding information

Connecticut DOT

To complement the Connecticut TAMP, Connecticut DOT (CTDOT) developed a series of asset Fact Sheets providing at-a-glance summaries of asset inventory and condition, State of Good Repair definitions, performance projections, targets and asset valuation for bridges, pavements, and five additional assets included in the TAMP. The asset Fact Sheets pair simplified graphs and other information displays with supporting contextual detail; a format that helps communicate CTDOT’s TAM approach to policy makers, executives, and other non-technical stakeholders.

Source: Connecticut DOT. 2018. Asset Fact Sheet.


Data Sharing

There are many different ways to share information about assets, condition, performance, needs, and work. Agencies can select multiple distribution channels to serve both internal and external users.

As with the design of reports and visualizations, designing a data sharing strategy should begin with an understanding of the different audiences for data and their needs. A variety of options for data sharing are available that can be employed. Table 7.5 outlines some of these options and suggests some questions to consider in selecting an appropriate option.

It is helpful to establish guiding principles for data sharing in order to achieve a consistent agency approach that provides maximum benefits in a cost-effective manner. Possible principles include:

  • By default, data should be shared unless it is sensitive, protected by law or if sharing it would pose unacceptable risks or cost burdens
  • Self-service methods of data sharing should be used when there is a relatively large pool of data users and data limitations can be readily communicated via standard metadata
  • Avoid proliferation of single purpose data sharing applications by adopting standard platforms where multiple data sets can be shared
  • When it is necessary to share the same data set through multiple channels, the source data should be stored in a single location or a single data refresh process should be used to reflect updates
  • The process of preparing data for sharing, reporting and visualization should be governed to ensure quality, ensure adequate documentation, and avoid inconsistency

Table 7.5 Data Sharing Options

Data Sharing OptionMost appropriate for...Considerations
On requestInternal or external data usersUse for uncommon, specialized requests requiring moderate to extensive effort to fulfill or where there is high potential for information misinterpretation or mis-use

For common information needs, use other methods to reduce staff time spent on fulfilling information requests.
Direct access to specialized asset management system (e.g. for pavement, bridges, culverts, etc.)Asset and maintenance specialists in the central office and field officesHelpful features include: ability to provide view-only privileges and ability to provide filtered views of information (e.g. restrict to a single district)
Direct access to enterprise asset management system (with information about multiple assets)Agency staff

Partner agency staff (e.g. MPOs, localities)
For partner agency access, ability to provide access outside of the agency firewall is needed.
Enterprise GIS with spatial open data portalInternal or external data usersIt is best to design separate maps geared to specific user types
May want to separate internal and external portals or restrict some specialized maps for internal use.
General open data portalInternal or external data usersConsider using available federal and state-level open data portals
May want to separate internal and external portals or restrict some specialized maps for internal use.
Data feeds/data services/Automated Programming Interfaces (APIs)Internal or external data usersMost suitable for real time data sets, data sets that are frequently updated, and complex data sets where flexible querying options are needed.
Data warehouse/data martAgency staffUse to create a cleansed and standardized data source for reporting/business intelligence.

Particularly helpful when historical/time series data is required, and direct access to data from source systems is problematic due to data quality, consistency or performance concerns.

Tabular data within the Data Warehouse can be joined with spatial data, as needed, within the Enterprise GIS.
Data lakeAgency data analysts/data scientistsUse to provide access to a heterogeneous collection of data including “big data” and unstructured data for research, modeling and analysis.
Content management systemAgency staff and partners (e.g. contractors)Use to provide access to a curated collection of content including engineering design drawings, asset maintenance manuals, contracts, etc.
Common data environment (CDE)Agency staff and partners (e.g. contractors)Use to provide a shared information repository for a construction project. CDEs typically include document management, collaboration and workflow features. CDE is one of the key elements of BIM practice defined by the UK’s Construction Industry Council.


Washington, DC has established four levels of data. By default, data is considered to be open and shareable.

  • Level 0. Open (the default classification)
  • Level 1. Public, Not Proactively Released (due to potential litigation risk or administrative burden)
  • Level 2. For District Government Use (exempt from the Freedom of Information Act but not confidential and of value within the agency)
  • Level 3. Confidential (sensitive or restricted from disclosure)
  • Level 4. Restricted Confidential (unauthorized disclosure can result in major damage or injury)

Source: https://octo.dc.gov/page/district-columbia-data-policy

Vermont Agency of Transportation (VTrans)

VTrans shares their data with the public through the VTransparency Public Information Portal. The goal of the portal is to “turn data into useful information for our customers” and to “create tools for getting answers to some of the questions we get most often”. The VTransparency Portal features different tools for viewing specific data. These tools include:

  • Projects Map
  • Road Conditions
  • Plow Finder
  • Weather Cams
  • Maintenance Districts
  • Crash Fatality Report
  • Crash Query Tool
  • Find a Project
  • Daily Traffic
  • Highway Closures
  • Bridge Inspections
  • Pavement Conditions
  • Pavement Performance
  • Maintenance Work
  • Rail Asset Inventory
  • Rail Bridge Inspections
  • Rail Clearance
  • Rail X-ing Inspections

The VTransparency Portal also links to the Vermont Open GeoData Portal. This provides GIS map layers related to the various tools for people interested in doing their own analysis of VTrans data. VTrans holds to the principle of making data available by default unless it is sensitive. The agency values transparency with the public and welcomes feedback on the tools they’ve developed. The VTransparency Portal can be accessed at https://vtrans.vermont.gov/vtransparency


Preparing Data for Sharing, Reporting and Visualization

Establishing a standard process to prepare data for sharing, reporting and visualization can make sure that data is publication-ready: quality checked, tested and documented.

A standard data preparation process should be used before moving data to any official reporting source – whether it is a data warehouse, a geodatabase, or a file uploaded to an open data portal.

A data preparation process might use the following checklist:

  • Is the data derived from a designated authoritative source system?
  • Have data quality checks been applied?
  • Has metadata for the data set been prepared, including explanation of the data source, date of last update?
  • Is an individual or business unit identified for data users to contact for further information?
  • Is an individual or business unit identified for reporting database or system managers to contact regarding any issues that arise?
  • Has metadata for the data elements included been prepared (data dictionary)?
  • Has the metadata been reviewed for completeness and quality?
  • Has a data owner or steward signed off on the data publication?

Ohio DOT

“Data-driven decision making is an approach to business governance or operations which values decisions supported with verifiable data. The success of the data-driven approach is reliant upon the quality of the data gathered and the effectiveness of its analysis and interpretation”

Section 7.4

Data Governance and Management

This section provides an overview of data governance and management practices that are essential for achieving data quality, consistency and integration. These practices are applicable to all kinds of agency data, and are best implemented at the agency-wide level. After introducing general concepts and principles, the section highlights specific governance and management applications for TAM. It concludes with a synthesis of available tools for assessing data governance and management maturity levels.


Fundamental Concepts and Principles

Data governance and management practices are essential for achieving reliable, consistent, integrated and accessible data that is of value for decision-making. Several definitions, concepts and principles are important to understand before embarking on a data governance initiative.

Data governance and data management are interrelated but distinct practices.

Data management includes activities such as data quality management, data documentation, metadata management, security and access controls, data integration, and data archiving.

Data governance is a policy making and oversight function for data management. Implementing data governance involves forming and chartering decision making bodies, defining roles and responsibilities, establishing policies that set expectations for behavior, and setting up standard processes for things like approving data standards, resolving data issues, and acquiring new types of data. Data governance is generally implemented in a hierarchical fashion, with an executive body at the top, a data council or board in the middle, and several more focused groups oriented around specific systems, business processes, organizational units or functions.

Data stewardship is closely related to data management and governance. It refers to established responsibilities and accountabilities for managing data. In general parlance, a steward is someone who is entrusted with the responsibility for taking care of someone else’s property. Similarly, a data steward is someone who takes care of data on behalf of their agency. Different types of stewardship roles can be defined and formalized within an agency data governance policy. Data stewardship can be viewed as the way to operationalize data governance policies, processes and standards.

Data governance can be implemented to:

  • Improve quality and consistency of data
  • Ensure coordination across different business units
  • Maximize efficiency in data collection and management processes
  • Enable data integration and shared solutions to make the most of available IT resources
  • Ensure there is a solid business case for new data collection
  • Ensure that data will be maintained once it is collected

Agencies may be motivated to establish a formal data governance function as they try to move from a siloed approach to collecting and managing data to one that is more coordinated and centralized.

For example, implementing a reporting system that takes data from multiple sources within the agency creates the need for standardization, documentation, and agreed-upon update cycles. It is important to get agreement on standard data definitions, formats and code lists from different business units to achieve consistency. It is also important to clarify who is responsible for fixing errors and the process for error correction in the event that errors occur.

Data governance is a means to an end. It is important to clearly define and communicate why an agency needs to strengthen data governance: what is happening now that the agency may want to avoid (such as data duplication)? What is not happening now that the agency may want to achieve (such as standardized data)? The effort involved in putting data governance in place should not be underestimated, since it involves changes in how decisions are made and changes in behavior. A full scale agency data governance model can take years to mature. However, data governance can be rolled out incrementally to focus on short term objectives. It is a good idea to adopt a set of principles to provide the foundation for data governance policies and practices. The AASHTO Data Principles (see callout box) can be used as a model.

Data itself should be viewed as an asset to be managed.

Florida DOT

Florida Department of Transportation (FDOT) launched a statewide initiative to better manage and integrate agency data. This effort combines the resources, goals, and objectives of Florida’s Technology and Operation Divisions into the initiative known as ROADS, which stands for:

R—Reliable, accurate, authoritative, accessible data

O—Organized data that produces actionable information

A—Accurate governance-produced data

D—Data and technology integration

S—Shared agency data to perform cross-functional analysis

The agency has created processes, procedures, and guidelines so that all data (financial, safety, project, program, assets, etc.) are organized and accessible. Florida’s steering committee, known as RET (ROADS Executive Team), is led by the agency’s Chief of Transportation Technology and Civil Integrated Management Officer. The committee, which includes district secretaries, financial and planning executives, and operational directors, is charged with governance leadership and instituting processes that will change the culture of the agency by converting data to knowledge.

ROADS is being implemented incrementally, through a series of 6-month initiatives. One initiative related to asset management is to standardize inventory attributes for 120 different classes of infrastructure assets and the agency’s approximately 170 enterprise software applications. Part of this effort is to determine specific authoritative source data to include in a new data warehouse. The data warehouse will provide a single authoritative site for sharing the accurate data.

Through the ROADS initiatives, Florida DOT has created a strategic direction for data integration covering data stewards, division responsibilities, asset inventory, business system integration, and an implementation roadmap. By coordinating its efforts, the agency is able to maximize the value of its data while streamlining processes for data collection, management, and dissemination.

Florida DOT Enterprise Information Management

Source: Florida DOT. 2019


Data Governance Practices Supporting TAM

Data governance practices can be implemented to support development of a valuable, reliable base of integrated information for TAM decision making.

A first step in data governance is to identify key decision points to be governed. These may include:

  • Adopting common data definitions or standard code lists
  • Adopting location referencing standards
  • Adopting standard tools for field data collection
  • Collecting new asset data to be included within an integrated asset management system
  • Archiving or deleting existing data
  • Modifying data elements for an existing TAM data source
  • Adding new data layers to an enterprise GIS repository
  • Adding new data marts to a data warehouse
  • Adding new reports or controls to a BI environment
  • Responding to an external request for data

It is best to take an incremental approach to setting up governance processes, starting with a few high impact areas that are aligned with what the agency is trying to achieve. For each of the selected decisions to be governed, think both about the criteria or guidelines to be followed as well as all the people who should be consulted or involved in making the decision.

Data governance practices should involve stakeholders responsible for collecting and analyzing the data, as well as those who will be using the data in decision making.

  • Criteria and Guidelines: Developing guidelines for key decisions is a good way to institutionalize practices that reflect the agency’s goals for data. For example, some agencies have established “readiness checklists” that need to be completed before data can be added to an enterprise repository. These ensure (among other things) that a data owner or point of contact has been identified, that necessary metadata is provided, that a refresh cycle has been specified, and that the authoritative source system of record has been identified.
  • Decision Making Process: Consider who should be involved in each of these decisions – who is responsible for making technical recommendations, who should be consulted, who has approval authority, and who needs to be informed about the decision. Define a process for resolving issues and conflicts; and a process for granting exceptions to established standards.

Agency data governance bodies can be responsible for adopting both guidelines and process flows impacting decisions that impact multiple business functions. If there are no existing governance bodies or if decisions to be governed are specific to TAM, a separate TAM data governance group can be established.

Keep in mind that the function of governance bodies is to make decisions. Use technical advisory groups, working groups or communities of interest to do the collaborative work required to develop standards or make recommendations about changes to data and systems.

Ohio DOT

Ohio DOT has established a standard process for adding a new asset to their inventory. As illustrated in the flowchart below, the process has three stages – (1) Asset Overview, where the request is submitted, evaluated, and approved, (2) Requirements, in which business and technical requirements for collecting and managing the new data are documented, and (3) Application Development, where the technology solution is developed either in-house (using standard tools), via contract (for custom development) or through acquisition of a commercial off-the-shelf (COTS) package.

As part of the TAM Audit Group workflow shown in the figure, ODOT has introduced over 693,000 active ancillary assets into their inventory.

Ohio DOT TAM Audit Group Workflow Diagram

Source: Ohio DOT. 2019


Assessing Data Management and Governance Maturity

Data management and governance implementation can be viewed as a long term process of maturation. Several models and assessment tools are available to help agencies identify their current state, set goals for where they want to be, and create plans for moving up the maturity scale.

There are several different assessment tools tailored to DOT data programs that can be used or adapted as needed. In addition, several DOTs have created their own tools. Most of these tools are based on a maturity model.

A typical maturity model could include the following levels:

  • Level 1-Initial
  • Level 2-Repeatable processes
  • Level 3-Defined and documented processes
  • Level 4-Measured and managed processes
  • Level 5-Optimizing processes (continuous improvement)

Use a maturity model to identify gaps, prioritize initiatives and track progress over time.

For TAM information and systems, maturity levels can be assigned to different aspects of data management and governance. Assessments can also be conducted at different levels of the organization – from the agency-wide level, to the level of individual information systems (or even data elements).

Figure 7.4 Example Maturity Model

Table 7.6 shows the data management and information system-related assessment elements from the TAM Gap Analysis Tool, developed under NCHRP Project 08-90. Figure 7.5 illustrates the data assessment guidance created under NCHRP 08-92. This process is suitable for application either at the agency-wide level, for an individual data program, or for a business process. It goes into greater depth than the TAM Gap Analysis Tool.

Figure 7.5 Folio Describing the Transportation Agency Data Self-Assessment Process

Table 7.6 - TAM Analysis Tool Assessment Elements

ElementSub-elementSample Assessment Criteria
Data ManagementAsset Inventory
  • Complete, accurate, current inventory data
  • Critical asset components identified
  • Asset tiers identified to facilitate prioritization
  • Location-based data collection practices (e.g. GPS)
  • Appropriate mix of data collection technology
  • Inventory level of detail considers maintenance costs, accuracy, and asset criticality
Asset Condition and Performance
  • Periodic/regular collection of condition and performance data
  • Adequate level of coverage to ensure objectivity, consistency and repeatability
  • Assessments by knowledgeable personnel
  • Ability to monitor operational status of assets
  • Monitoring of public perceptions
Data Governance
  • Oversight and approval authority for all data elements
  • Single authoritative sources for shared data entities
  • Data stewardship roles and responsibilities
  • Data standards
  • Central metadata repository
  • Business rules for add/update/delete
  • Efforts to reduce redundancy
  • Quality assessment and improvement
Information SystemsSystem Technology and Integration
  • Updated asset management systems
  • Integrated to provide consistent information across assets
  • Serving multiple users and uses
  • Established requirements and standards to guide future development
  • Common geographic referencing
  • Procedure to manage changes in referencing
  • Common map-based interface
Decision-Support Tools
  • Pavement management system
  • Bridge management system
  • Assessments by knowledgeable personnel
  • Maintenance management system
  • Capital-maintenance tradeoff capabilities
System Features
  • Life cycle analysis
  • Cost data
  • Performance data – impacts of maintenance and preservation
  • Cost and performance prediction
  • Future demand prediction
  • Regular review of treatment intervention strategies
  • Benefit/cost or optimization analysis

Iowa DOT

Iowa DOT conducted a detailed data maturity assessment for over 180 data systems. Assessments were based on a standardized questionnaire administered to data stewards and custodians. The questions covered data quality, availability of metadata, whether a data retention plan was in place, the degree to which data collection was automated, and several other factors. Charts were produced showing maturity scores for each system, with roll-ups at the division level. This tool helps the agency track their progress over time and identify specific data improvements to pursue.

Sample Data Assessment Summary Radar Chart

Source: Iowa DOT. 2019

Chapter 7: Key Practices

Key practices in Information and Systems are defined at three levels of maturity: emerging, strengthening, and advanced. The accompanying maturity examples are meant to provide some context for the concepts discussed within the chapter, and the degree to which an agency adopts them in its TAM program.

Information and Systems

  • Agency information systems are unintegrated, however the current portfolio of systems are well mapped, and an improvement plan is in progress to improve integration toward a clearly defined future state that is suited to agency requirements.
  • Agency information systems are partially integrated, interconnected and a plan is being implemented to create a system that is suited to agency requirements.
  • Agency information systems are fully integrated. Systems supporting inventory management, data warehouses and statistics, inspections and condition assessments, maintenance management, performance modeling, analytics, forecasting and financial systems are interconnected and are suited to agency requirements.

Asset Data Sharing, Reporting and Visualization

  • Information is available to most stakeholders and allow for improving decisions over time.
  • Data and analysis presentation is improving with a plan for consistency across the agency.
  • Information is available to most stakeholders and allow for informed, supported decisions
  • Data and analysis presentation is improving and is targeted to key decision-makers, and consistent across the agency.
  • Information is available to all stakeholders and allow for informed, supported decisions
  • Data and analysis presentation is well crafted, easy to understand for the targeted audience, and consistent across the agency.

Data Governance and Management

  • Data governance and management practices are being established with a gap assessment identifying an improvement strategy over time.
  • Data governance and management practices well established and support continuous improvement in data systems.
  • Data governance and management practices well established and support reliable, consistent, integrated and accessible data systems
  • Governance frameworks are reviewed periodically to ensure it evolves with agency requirements.

Asset Management Data Collection Guide
June 6, 2006 | AASHTO

This guide contains information on several highway right-of-way assets including pavements, bridges, culverts, guardrails, and drainage structures.

External Link: https://store.transportation.org/Item/PublicationDetail?ID=390

Data Collection Technologies for Road Management
February 1, 2007 | East Asia Pacific Transport Unit, The World Bank

This report compiles and evaluates a selection of data collection technologies that assist with the comprehensive implementation of road management.

External Link: http://siteresources.worldbank.org/INTTRANSPORT/Resources/07-02-12DataCollectionTechnologiesReport-v20.pdf

FHWA Recommended Framework for a Bridge QA/QC Program
August 9, 2017 | FHWA

This framework succinctly outlines steps to standardize and clarify quality control (QC) and quality assurance (QA) procedures used in the bridge inspection process.

External Link: https://www.fhwa.dot.gov/bridge/nbis/nbisframework.cfm

Guidelines for Collecting, Processing, and Managing Roadway Asset Inventory Data
June 1, 2015 | AASHTO

This report catalogues and recommends technologies for collecting, storing, processing, and managing data for roadway asset inventories.

External Link: http://sp.maintenance.transportation.org/Documents/NCHRP%2020-07_task%20357%20A%20Guide%20to%20Collecting,%20Processing,%20and%20Managing%20Roadway%20Asset%20Inventory%20Data.pdf

PIARC Asset Management Guide
| Chapter 6, PIARC

External Link:

Data Visualization Methods for Transportation Agencies
September 1, 2017 | NCHRP Project 08-36/Task 128, TRB

External Link: http://vizguide.camsys.com/index.htm#home

Successful Practices in GIS-Based Asset Management
September 1, 2016 | NCHRP Report 800, TRB

External Link:

The Visual Display of Quantitative Information
September 1, 2001 | Edward Tufte

External Link: