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.

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

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.

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.

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?

Performance

• 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.

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).

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.

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.

Overview

Transportation agencies are facing increasing pressure to make more effective use of data and information systems to support their TAM programs. Addressing this need, NCHRP Project 08-115 produced NCHRP Report 956, a Guidebook for Data and Information Systems for Transportation Asset Management. AASHTO hosts web-based versions of the guidebook and tools, where subsequent implementation guidance and DOT implementation experiences have also been shared.

Built upon a data life-cycle framework which addresses five distinct stages in the use of data for TAM, the NCHRP Report 956 and associated AASHTO TAM Data Guide provide a structured approach for transportation agencies to:

• Assess current TAM data and information system practices and establish a desired state.
• Identify and evaluate data and information system-related improvements.
• Secure agency support for improvements and plan an implementation strategy.

Figure 7.4 Stages in the Use of Data for TAM

This guidance is supplemented with valuable support materials, including:

• Practical implementation tips to support the TAM data and information system assessment, improvement selection and evaluation, and action planning processes.
• Supporting materials and templates (such as assessment scoping guidance, stakeholder engagement and facilitation materials, and assessment summary and action planning templates).
• User guidance, quick reference materials, and tutorial videos to guide tool use and application.
• Research implementation examples based on four real-world implementations of the guidance at the New Hampshire, New Mexico, and Virginia DOTs.

Other Related Methodologies

For those exclusively focused on better understanding and improving how they manage their TAM data, NCHRP Project 20-44(12) was completed in 2022, providing improved tools, supplemental guidance, materials, and detailed case studies on implementation of the NCHRP Report 814 Data Self-Assessment Guidance. The outcomes of this project included detailed agency-specific assessment experiences, including several applications of the data management maturity and data value assessment frameworks in TAM-specific contexts.

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.

Table 7.2 Example Data Collection Strategies

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.

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.

Table 7.3 - Example Data Collection Approaches

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.

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.

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.

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

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

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?

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.