Building a Business Case for 

Shared Geospatial Data and Services: 

A Practitioner’s Guide to Financial and 

Strategic Analysis for a Multi-participant 

Program 

A Research Publication of the 

 Geospatial Information & Technology Association’s 

Research Division in Conjunction with the 

U.S. Federal Geographic Data Committee 

The content and methodology of this document 

are based on the Building a Business Case for 

Geospatial Information Technology 

workbook published by GITA 

March 2007
DISCLAIMER 

This project was jointly funded by the Federal Geospatial Data Committee (FGDC) and the 

Geospatial Information Technology Association (GITA). These organizations assume no 

responsibility for the content of the research study reported in this publication or for the opinions or 

statements of fact expressed in the report. The mention of trade names for commercial products does 

not represent or imply the approval or endorsement of these organizations. This report is presented 

solely for informational purposes. 

Copyright © 2007 

by 

Geospatial Information & Technology Association 

All rights reserved. 

Printed in the U.S.A. 
CONTENTS 

 

FIGURES iv 

FOREWORD v 

ACKNOWLEDGMENTS vi 

ABOUT THE AUTHORS vii 

EXECUTIVE SUMMARY viii 

CHAPTER 1: INTRODUCTION 1 

WHY READ THIS WORKBOOK? 1 

WHY READ ABOUT GOVERNMENT AGENCIES OUTSIDE MY OWN SECTOR? 1 

WHO SHOULD USE THIS WORKBOOK? 1 

HOW TO USE THIS WORKBOOK AND THE ACCOMPANYING CD 1 

WHY BUILD A SHARED DATA AND SERVICES GIT BUSINESS CASE? 2 

STRUCTURE OF THIS WORKBOOK 2 

CHAPTER 2: OVERVIEW OF SHARED DATA AND SERVICES GIT AND BUSINESS CASE 

STRUCTURE 4 

KEY CHAPTER OBJECTIVES 4 

SHARED DATA AND SERVICES OVERVIEW 4 

GIT OVERVIEW 5 

GIT AS A CORE ENABLING TECHNOLOGY 6 

BUSINESS USES OF GIT 7 

TAKING A SHARED DATA AND SERVICES APPROACH TO IMPLEMENTING A GIT PROGRAM 

ACROSS MULTIPLE AGENCIES 8 

ROLE AND STRUCTURE OF A GIT BUSINESS CASE 8 

PROJECT DEFINITION 9 
FINANCIAL ANALYSIS 11 

STRATEGIC ANALYSIS 11 

BUSINESS USE APPLICATION EXAMPLES 11 

CHAPTER 3: GIT BENEFITS 17 

KEY CHAPTER OBJECTIVES 17 

TANGIBLE AND INTANGIBLE BENEFITS 17 

CAPTURING PRODUCTIVITY BENEFITS 17 

CALCULATING OTHER TANGIBLE BENEFITS 22 

INTERNAL AND EXTERNAL BENEFITS 23 

ESTIMATING BENEFITS ARISING FROM SHARED DATA AND SERVICES 23 

DEALING WITH UNCERTAINTY 24 

EXAMPLES OF TANGIBLE BENEFITS FOR GIT BUSINESS USES 24 

CHAPTER 4: GIT COSTS 30 

KEY CHAPTER OBJECTIVES 30 

START-UP AND OPERATING COSTS 30 

SUNK COSTS 31 

SHARED COSTS 31 

INTERNAL LABOR COSTS 31 

EXAMPLES OF TYPICAL GIT COSTS 34 

CHAPTER 5: FINANCIAL ANALYSIS 37 

KEY CHAPTER OBJECTIVES 37 

PROJECT LIFE AND CASH FLOW SCHEDULE 37 

TIME VALUE OF MONEY (OPPORTUNITY COSTS) 39 

DEALING WITH INFLATION 41 

COMMON FINANCIAL METRICS 42 

ii
IMPACT OF RECASTING INTERNAL LABOR COSTS 47 

SENSITIVITY ANALYSIS 48 

CHAPTER 6: STRATEGIC ANALYSIS AND THE BUSINESS CASE 50 

KEY CHAPTER OBJECTIVES 50 

INTERPRETING A BUSINESS CASE 50 

WHAT IS STRATEGIC ANALYSIS? 50 

STRATEGIC BENEFITS AS INTANGIBLES 51 

EXTERNAL BENEFITS 51 

COOPERATIVE SHARED DATA AND SERVICE GIT PROJECTS 52 

COMPLETING THE BUSINESS CASE 52 

CHAPTER 7: RESEARCH FINDINGS AND RECOMMENDATIONS 54 

KEY CHAPTER OBJECTIVES 54 

LITERATURE REVIEW PROCESS 54 

CASE STUDY FINDINGS 54 

APPENDIX A: BUSINESS CASE TEMPLATE INSTRUCTIONS A-1 

APPENDIX B: LITERATURE REVIEW B-1 

APPENDIX C: WASHINGTON STATE TRANSPORTATION FRAMEWORK FOR GIS C-1

iii
FIGURES 

Figure 3.1 — Sample spreadsheet to calculate productivity benefit 21 

Figure 3.2 — Timing of productivity benefit for cutting five positions contingent upon attrition 22 

Figure 4.1 — Example of GIT project cost estimate 33 

Figure 4.2 — Internal labor costs recast as reduced annual productivity benefit 33 

Figure 5.1 — High level timeline for costs and benefits 38 

Figure 5.2 — Cash flow schedule 38 

Figure 5.3 — Using a spreadsheet to convert a cash flow schedule to present values 40 

Figure 5.4 — Using a spreadsheet to calculate present values for a cash flow schedule that reflects 

 inflation 42 

Figure 5.5 — Subjective decisions about treatment of costs and benefits yield different ROI projections for the 

 same investment, yet NPV remains unaffected 45 

Figure 5.6 — Estimating IRR by plotting cumulative present values at different discount rates 46 

Figure 5.7 — The Breakeven Point occurs when cumulative benefits begin to exceed cumulative costs. The 

 Payback Period is the span between the outset of the project and the Breakeven Point 47 

Figure 5.8 — Calculation of NPV and ROI with training delayed until year 4 49 

iv
FOREWORD 

The Geospatial Information & Technology Association (GITA) is a nonprofit educational association 

serving the global geospatial community. GITA provides industry leadership by offering excellent 

geospatial educational and information exchange opportunities and promoting the use and 

development of geospatial information and technology to meet our members' evolving needs. This 

leadership is increasingly being delivered and recognized through our various research initiatives, 

demonstration projects, and relationships with other nonprofit organizations and state and federal 

agencies. 

In order to effectively manage these efforts, GITA has established a Research Division. The Research 

Division is responsible for sponsoring applied research and demonstration projects to enable federal, 

state, and local government agencies, along with electric, energy, gas, pipeline, telecommunications, 

and water and wastewater organizations and other professionals, to meet their business needs through 

the use of geospatial information and technology. It seeks to work together with member 

organizations that voluntarily participate in order to support and benefit from the geospatially related 

research that the association sponsors. Close to 150 user organizations are members of GITA, and 

more than 130 geospatially-related consulting firms, solution providers and vendor companies are 

corporate members. The majority of our members are in the United States and Canada. However, 

members from our international affiliates are welcome to participate in research and demonstration 

projects. 

This publication, “Building a Business Case for Shared Geospatial Data and Services: A 

Practitioners Guide to Financial and Strategic Analysis for a Multi-participant Program,” is a result 

of a project of the GITA Research Division in partnership with FGDC. It is hoped that its findings 

will be applied in United States’ Federal agencies as well as in communities throughout North 

American and around the world. We intend that this report not only serves as a means of 

communicating the results of this important applied research, but also becomes a tool to enlist the 

further support of utilities, government agencies, and other types of organizations and individuals for 

additional needed work.

 Robert M. Samborski 

 Executive Director, GITA 

 March 2007 

v
ACKNOWLEDGMENTS 

About the Geospatial Information and Technology Association 

The Geospatial Information and Technology Association (GITA) is a non-profit association focused on 

providing education, information exchange, and applied research on the use and benefits of geospatial 

information and technology worldwide. Its membership includes federal, state, and local government 

agencies, utilities, infrastructure management organizations, and private sector companies. 

About the Federal Geographic Data Committee 

The Federal Geographic Data Committee (FGDC) is a 19 member interagency committee with 

representatives from the Executive Office of the President, Cabinet-level and independent agencies. 

The FGDC is developing the National Spatial Data Infrastructure (NSDI) in cooperation with 

organizations from both the public and private sectors. The NSDI encompasses policies, standards, 

and procedures for organizations to cooperatively produce and share geographic data.

Special Thanks

The project team of Nancy Lerner, Susan Ancel, Mary Ann Stewart and Dave DiSera deserve special 

thanks for their vision and tireless work which brought this workbook to fruition. We are indebted 

to the project advisory committee of Milo Robinson (Federal Geographic Data Committee), Tammy 

Griffin (Washington State Department of Transportation), Dave Dennis (City of Cleveland) and Pete 

Gomez (Xcel Energy), and Paula Rojas (GeoConnections Canada) for their input and guidance 

during the review of the workbook business case and return on investment workbook and template 

material. 

vi
ABOUT THE AUTHORS 

Nancy Lerner 

Ms. Lerner is a Vice President with EMA, Inc., located in Houston, Texas. She leads organizational, 

business process, and technology optimization efforts for a variety of municipal, regional, and utility 

organizations. This includes planning, design, and implementation of enterprise reengineering and 

system integration programs as well as projects targeting performance management, asset and work 

management, customer service, data access, records management, financial management and billing, 

and workforce development/compensation. 

Susan Ancel 

Ms. Ancel is the General Manager of the Network Services and Operations department for EPCOR 

Water Services, Inc., in Edmonton, Alberta. Her group is responsible for water distribution system 

planning, design, construction management and the development of operations maintenance 

programs for the water distribution systems operated by EPCOR. This also includes the responsibility 

for the development and deployment of the GIS and the hydraulic network analysis models for the 

Edmonton system. 

Mary Ann Stewart 

Ms. Stewart is principal of Mary Ann Stewart Engineering LLC, a Lawrence, Kansas-based 

consulting firm providing engineering research and analysis and business development services for 

the geospatial and energy industries. She is the former manager of GIS data acquisition for Aquila’s 

gas and electric distribution systems, where she managed data conversion, field data acquisition, staff 

training, and data quality improvement. She was a member of Aquila’s IT project management 

group, developing standard practices for return on investment and cost/benefit analysis.

Dave DiSera 

Mr. DiSera is Chief Information Officer and Vice President with First Insurance Company of Hawaii, 

located in Honolulu. He has over 20 years experience in the Geospatial Information Technology 

industry. He has provided technical and management consulting involving Geospatial and 

Information Technology solutions for the government, utility, and financial sectors. For the last 

fifteen years, he has developed information technology strategic plans and business cases; defined 

users, data, applications, technology, and integration requirements; developed enterprise 

architectures, effective work practices, and organizational structures; and managed project 

implementations for organizations across North America. Mr. DiSera currently serves the Chairman 

of the Research Committee for the Geospatial Information and Technology Association.

vii
EXECUTIVE SUMMARY 

Public sector organizations can improve efficiency and data quality by sharing their data, technology, 

and applications. Shared data and services make sophisticated technology affordable for a broad 

range of agencies. Multi-agency partnerships reduce redundant data maintenance activities. This 

increases productivity and improves information quality and consistency. For these reasons, data and 

technology partnerships have become very attractive to government agencies, especially in the area 

of land- and property-based services supported by Geospatial Information Technology (GIT). 

GIT is a complicated investment. The initial costs can be high, and the tangible benefits can take 

several years to materialize. Elected and appointed officials do not have time to delve into the finer 

points of the technology before being asked to make an investment decision. They must weigh a GIT 

project against countless other opportunities and choose where and how their organization will spend 

its money. Their best tools for making these decisions are the net present value (financial bottom 

line) and strategic business case. 

The financial bottom line of a GIT project depends on the presence and quality of the existing GIT 

infrastructure. GIT infrastructure includes base maps, technical support personnel, and base map 

maintenance applications as well as user access tools and data communications channels. These 

infrastructure elements are expensive and may be difficult for a single agency to cost-justify. If 

multiple agencies share the cost of this infrastructure, each of the participants is in a better position 

to develop business cases for new applications. When multiple government agencies serve the same 

geographic area, it is logical for these agencies to share their geographic information and to 

standardize and integrate their spatial data management processes. When these agencies use the 

same GIT software, the opportunities for cooperative application development multiply, and the 

business case for sharing GIS resources becomes even more persuasive. 

When developing a business case for a GIT project that relies on shared data and services, it is 

important to understand exactly where each agency should draw the line in terms of the allocation of 

costs and benefits. The costs of a proposed system can be researched and allocated among partners, 

but the potential benefits are much harder to document. Many of the benefits of GIT partnerships 

accrue to the community as a whole and can be difficult to quantify on an agency-by-agency basis. 

Therefore, it is important for GIT partners to collaborate in the development of business cases related 

to their cooperative projects. 

This workbook is the culmination of several years of ongoing research by the Geospatial Information 

& Technology Association (GITA). It presents a straightforward methodology for developing GIT 

benefit estimates, conducting financial analysis, and preparing a credible business case for a multiparticipant GIT investment. 

viii
RESEARCH OBJECTIVES 

The Geospatial Information Technology Association (GITA) and the Federal Geospatial Data 

Committee (FGDC) funded this study to develop and document a formal methodology for the 

preparation of business cases for shared data and services for GIT within and across multiple 

agencies. The research includes a literature search and the development of a workbook and digital 

templates to assist other organizations in building multi-agency business cases for shared data and 

services GIT projects. The workbook includes a case study from a project with multi-participant 

organizations. The case study provides a real-life example applying the workbook's methodology and 

templates. 

This workbook builds on the seminars held at the GITA annual conference beginning in 2003, and 

the document “Building a Business Case for Geospatial Information Technology” published by 

GITA. 

The key objectives of the study include the following: 

1. Evaluate current related literature collected by the FGDC and GITA. 

2. Further develop return on investment methodology as presented in the GITA seminars, 

enhancing and refining the techniques and documentation. 

3. Develop a set of spreadsheet templates, examples, and directions that government agencies 

can use for financial analysis of their own projects. 

4. Conduct site visits to perform individual case studies of the financial performance and 

strategic impact of a multi-participant geospatial project. Perform investment analysis on this 

project and thoroughly document the case study as an example for the workbook, including 

detailed spreadsheet analysis available for study. Describe the approach to allocating the 

costs and benefits of shared data and services among the GIT partners. 

CONCLUSIONS

Large shared data and services geospatial projects, such as multi-agency efforts throughout a 

metropolitan area, have large costs and accompanying large benefits. In many cases, productivity 

benefits are dominant. 

Mature geospatial implementations enable the return of substantial benefits from the development of 

new applications based on the existing technology at a low marginal cost. 

Complex projects involving multiple agencies can provide substantial quantifiable and strategic 

benefits, but it may be difficult to collect thorough and consistent benefit data from all affected 

agencies. 

ix
RECOMMENDATIONS 

GIT partners should jointly develop their business cases. Joint workshops will provide all participants 

with a common understanding of costs and benefits and a consistent approach to project definition and 

underlying assumptions. This research project demonstrated that collaborative business case workshops 

are more effective than independent development of financial assumptions and analysis. 

It is essential for participants in GIT business case workshops to understand cost and benefit data 

requirements and the analysis process. Training sessions should be scheduled well in advance of the 

business case workshop so that participants know what types of information to bring to the group 

discussion. 

Organizations can benefit from a clear understanding of the uses of financial analysis at all stages of a 

project. The case study demonstrates financial analysis through a wide range of project lifecycles: from 

making the business case in order to obtain project funding, to setting the stage for analysis of project 

performance, to full historical analysis once benefits have been realized. Further work in this area 

should address the appropriate use of financial analysis at the various stages of a project’s life. 

x
CHAPTER 1 

INTRODUCTION 

WHY READ THIS WORKBOOK? 

This workbook will teach you how to develop a financial and strategic analysis of a shared data and 

services geospatial information technology (GIT) project. It explains each step in the process and 

provides detailed examples and a case study to illustrate the concepts. The accompanying CD provides 

templates that will help you build your own business case. The CD also includes a detailed instruction 

guide on how to use the templates and the completed versions of the templates for the case study for 

additional reference. 

This workbook will also provide you with insights into how various government organizations are using 

GIT, and it will point you to additional reading material on this and related subjects. 

WHY READ ABOUT GOVERNMENT AGENCIES OUTSIDE MY OWN SECTOR? 

Multiple government organizations share and serve a particular geographic area, so GIT projects are 

fertile grounds for interagency collaboration. GIT collaboration within a community can improve all 

agencies’ service levels while reducing the cost of data collection, data maintenance, and supporting 

technology. For this reason, it is valuable to become familiar with the full range of government GIT 

applications. 

This workbook will help you identify potential partners, recognize cost distribution opportunities, and 

incorporate the benefits of collaboration and data sharing into your project design and business case. 

WHO SHOULD USE THIS WORKBOOK? 

This workbook is designed expressly for GIT practitioners and managers who are responsible for defining 

and prioritizing projects and for obtaining project funding. 

Whether you are running a GIT program for a local government, state office, or federal agency, this 

workbook will provide you with the tools you need to make sound decisions and communicate effectively 

with others involved in the investment decision. 

HOW TO USE THIS WORKBOOK AND THE ACCOMPANYING CD 

To get the most out of this workbook, the authors recommend that you open the accompanying Case 

Study Financial Analysis files on the CD as you read through the case study. You can also refer to these 

files for examples as you read through the workbook sections on benefit and cost estimation and financial 

analysis. 

After reading the workbook and reviewing the case study, you will be ready to build your own business 

case. Follow the instructions on the CD (also in the appendix of this workbook) to select the appropriate 

1
template file from the Business Case Templates and Instructions folder. The instructions will take you 

step-by-step through the preparation of the business case following the same process that is described in 

the workbook. Refer to the application examples in the workbook if you need help defining your project. 

Refer to the literature review if you want to read more about GIT investment analysis and related topics. 

WHY BUILD A SHARED DATA AND SERVICES GIT BUSINESS CASE? 

A multi-participant Geospatial Information Technology (GIT) project is a complicated investment. The 

initial costs can be high, and the tangible benefits can take several years to materialize. The technical 

intricacies can be overwhelming. Often elected and appointed officials do not have time to delve into the 

finer points of the technology before being asked to make an investment decision. Armed with only a 

basic understanding of GIT, they must weigh the project against countless other opportunities and choose 

where and how their organization will spend its money. Their best tools for making these decisions are 

bottom line cumulative costs and cumulative benefits for determining payback period, break-even point, 

and return on their investment. 

For GIT project managers across all government sectors, this poses a tricky problem. The costs of a 

proposed multi-participant GIT program are not terribly difficult to research, but the potential benefits are 

much harder to document. Somehow, multiple organizations working together must identify these 

benefits and then predict their financial impact. This task is usually left to the GIT project managers or 

other staff members among these organizations who are promoting the investment. Because the early 

costs of the program are typically high, officials are understandably sensitive to the benefit estimates. 

They want to be sure the financial analysis is sound. 

This workbook is a culmination of several years of ongoing research by GITA and the FGDC. It presents 

a rational methodology that is focused on ways for developing benefit estimates that should instill a 

sufficient level of management confidence for ultimately determining a credible business case and return 

on investment. 

STRUCTURE OF THIS WORKBOOK 

Each section of this workbook starts with a short paragraph describing the key concepts to be covered in 

that section. The focus of this workbook is to lead the practitioner through the process of building a 

successful business case to obtain project funding. 

Multiple examples are provided throughout the workbook to help identify additional benefits to consider 

when implementing a shared data and services GIT project. These examples have been organized by 

business use areas that are referenced throughout the text. The definitions of each business use can be 

found at the end of Chapter 2. 

The literature review is an additional valuable source of ideas to consider when developing your project 

scope and business case. It was developed by FGDC to specifically address issues with multi-agency 

financial analysis. 

2
The case study represents a range of agencies within one state that could typically be found as participants 

in a multi-agency GIT project. This case study illustrates how the concepts presented in this workbook 

can be utilized when planning any multi-agency program. 

3
CHAPTER 2 

OVERVIEW OF SHARED DATA AND SERVICES GIT 

 AND BUSINESS CASE STRUCTURE 

KEY CHAPTER OBJECTIVES 

This chapter presents an overview of shared GIT data and services, including its uses and benefits, 

followed by a discussion of the basic structure of a business case, including project definition, 

financial analysis, and strategic analysis. 

Business uses of GIT are also defined in this chapter. These will be referenced throughout the 

workbook to provide further examples of tangible and intangible benefits that can be obtained in each 

of these areas. It is important to note that many GIT programs address multiple business uses. 

SHARED DATA AND SERVICES OVERVIEW 

Many government agencies have already entered into GIT partnerships, and many others are actively 

exploring opportunities to share data and services. GIT partnerships reduce the costs to all 

participants while improving the quality and consistency of spatial information. Cooperative 

arrangements are not new to local government - many agencies already share services and resources, 

thus benefiting from lower costs and economies of scale in the procurement of products and services. 

Traditionally, government agencies have opted for shared services in administrative business areas, 

such as payroll or telephone systems. More recently, however, there has been a shift towards sharing 

of advanced technology solutions, mostly in the area of web-based services, such as county-wide 

portals. 

Shared services make the most economic sense where the cost of running essential services by a 

single entity verges on the unaffordable. This often applies to service areas that rely on complex 

computer applications for service delivery. This includes land- and property-based services supported 

by Geospatial Information Technology. 

Shared data typically includes base maps (aerial photography, physical maps, parcels, and street 

centerlines). Shared applications typically include data maintenance (base map maintenance) tools 

and basic user access/viewing tools. Shared services may include application development, 

outsourced data maintenance, application administration, hardware, and user support. When multiple 

government agencies serve the same geographic area, it is logical for these agencies to share their 

geographic information and to standardize and integrate their spatial data management processes. 

When these agencies use the same GIT software, the opportunities for cooperative application 

development multiply, and the business case for sharing GIS resources becomes even more 

persuasive. 

4
The first step towards a shared vision among multiple agencies, once the business case is developed 

and proven, could be consolidation and centralization of GIT support resources for basic 

administrative tasks. The next step could be a reduction in duplication of effort through sharing of 

maintenance processes such as managing the GIT program and base maps. Hardware could be 

centralized as the next step, with all GIT systems moved to a shared platform, thereby reducing 

maintenance effort and costs, and freeing up computer room and office space for some of the 

participating agencies. The final step could be the sharing of the actual GIT software and databases, 

achieved through consolidation of software licenses. 

The program to deliver such a shared vision would need to be carefully planned and rolled out in 

stages, ensuring convergence of working procedures, policies, and software versions, and a major 

cleanup of data sets. However long and complicated the program, it needs to deliver real benefits at 

the end of each stage. Planning for these stages of benefits is part of the business case development 

process. 

GIT OVERVIEW 

The simplest definition of GIT is “an automated system for managing and analyzing information with a 

geographic, i.e. spatial, reference.” More specifically, GIT is a collection of hardware, software, data and 

procedures functioning together to capture, manage, analyze, maintain, and display information that has a 

spatial reference to the real world. Information has a spatial reference if it can be tied to a map. 

Typically, over 80 percent of information necessary to support an agency’s daily operations has a spatial 

reference. 

GIT is not simply a computer system for making maps, although it can create maps as required. GIT is a 

sophisticated management, query, and analysis tool that allows users to identify and display the geospatial 

relationships among related features. There are many generic questions that a well-designed GIT and 

integrated database environment can answer, including: 

• Location — What is at a given location? Data management is simplified when the user can 

quickly discover what exists at a particular location. The location can be described in many 

ways, including place name, Zip code, billing and street address, geographic coordinates, or by 

pointing to the feature on a computer screen. For example, by pointing to a street on the 

computer screen or entering an address, the location and characteristic of all assets, planned 

construction activities, property sales, main breaks, demographic data, etc., can be 

immediately identified. 

• Condition — Where is it? This question is the reverse of the location question. Instead of 

identifying what exists at a given location, the user finds locations where certain conditions 

are satisfied. For example, state highway roadways that were constructed before 1960 that 

have had specific categories of road repair performed on them can be identified. 

• Trends — What has changed over time? This question can involve either location or condition 

and seeks to find the difference over time. For example, a GIT analysis can show ground water 

5
contamination within an environmentally sensitive area where levels of contaminant and extent of 

intrusion have continued to increase over a certain percentage during a specified period of time. 

• Patterns — What spatial patterns exist? These types of questions can be very sophisticated. 

For example, a GIT analysis can show the spatial distribution of new home building permits and 

correlate this information with locations of existing community services, including such things as 

schools, police and fire stations, and medical clinics. This information can help determine if 

additional services are required to support growing areas within the community. 

• Modeling — What if ...? These types of questions are posed to predict the consequences of 

proposed changes. For example, the user can model a variety of emergency situations ranging 

from a contaminant spill to a terrorist attack and determine how the survivors can be safely 

moved out of harm’s way. 

GIT AS A CORE ENABLING TECHNOLOGY 

Organizations that have implemented GIT programs are finding that it is a core technology that 

increasingly defines their information management strategy and practices. The primary reason is that, as 

previously noted, a majority of all data and information used by organizations is geographically 

referenced. Consequently, any technology that provides the capability to capture, organize, and make 

available the majority of an organization’s data will be, by definition, a core technology. 

As GIT capabilities increase, the applications that access the data expand and increase in complexity. As 

more geographically referenced information is made available to the participating organizations, the skills 

of the staff, the organizational structures, and the work practices across the organizations will evolve to 

reflect the necessary shared data and services. 

Therefore, it is important that as government agencies work together to deploy a shared data and services 

GIT program, participants have a clear understanding of: 

• What the technology will allow the organization to achieve (e.g., business value) 

• What changes the technology will drive within each organization, and across organizations 

• The most cost-effective way to implement and integrate this technology 

• The time and resources necessary for implementation and operation of the program 

Ultimately, the implementation of a shared data and services GIT program will assist an organization’s 

ability to reduce operational costs and data redundancy, improve analysis processes, and increase the 

ability to access and integrate information. The result will offer better decision support and increased 

data-sharing and services within a technical framework that integrates data from the various systems 

across the various organizations. 

6
BUSINESS USES OF GIT 

Successful shared data and services GIT applications are designed to support specific business needs for a 

combination of participating organizations. It is the applications and organizational practices that enable 

shared data and services, rather than the mere presence of the technology, that provide the true benefits 

through the use of GIT. 

The following is a list of common shared data and services of GIT: 

• Data Access and Mapping (Accessing Data, Automated Mapping, and Data Maintenance) 

• Emergency Management and Security (Emergency Preparedness and Response/Critical 

Infrastructure Protection 

• Government Administration (Property Appraisal/Legislative (Voting) Districting/Tax 

Assessment) 

• Quality of Life (Public Health and Safety/Community Services/Code Enforcement) 

• Field Infrastructure Management (Management of Roads and Utilities/Capital 

Improvements/Maintenance) 

• Facility Management (Management of Buildings and Property/Capital 

Improvements/Maintenance) 

• Service Delivery (Citizen and Customer Service/Call Management/Outage 

Management/Dispatch) 

• Customer Relationship Management (Usage or Consumption Analysis/New Service 

Planning/Customer Compliance) 

• Engineering (Planning/Design/Construction/System Analysis/Network Modeling) 

• Land Management (Development Review/Zoning/Permitting/Land Use Analysis) 

• Regulatory Compliance (Permit Application/Monitoring Programs/Compliance Management) 

• Environmental Management (Natural Resource Preservation/Watershed Protection/Weather 

Monitoring) 

Specific examples are cited for each business use at the end of this chapter. These examples are typical 

GIT applications that agencies develop to support a shared data and services program. In this workbook, 

the term application refers to a business process supported by people, data, software, and hardware. In 

the Information Technology (IT) world, the term application is sometimes used to refer to a software 

product or a piece of custom code. However, software alone is typically too narrow an item to constitute 

7
a true GIT project or investment. The full costs of any shared data and services GIT program will include 

human and business process costs as well as technology costs, and the benefits of the investment can be 

realized only in the context of the business processes that the technology supports across multiple 

organizations. 

It is important to note that unless the business requirements of the participating organizations are well 

understood, there is a risk of implementing a system that does not address all participants’ needs, and this 

could jeopardize the GIT partnership. It is essential for all project participants to agree on the functional 

and technical requirements of all shared data and applications. The applications that are defined to 

support the various business needs of one or more organizations will need to be prioritized for funding 

and implementation purposes. Once prioritized, the specific multi-agency data, hardware and software, 

organizational, and training elements required to support that application can be further defined, and then 

developed or acquired. 

TAKING A SHARED DATA AND SERVICES APPROACH TO IMPLEMENTING A 

GIT PROGRAM ACROSS MULTIPLE AGENCIES 

The implementation of GIT can be a long-term undertaking. Working together, agencies can greatly 

improve the value of their GIT implementations by taking a shared data and services approach. This 

approach has proven very successful as a means to minimize program costs. It is not uncommon for a 

shared data and services GIT program to take three to five years to show payback. A shared data and 

services approach also enables multiple agencies to more effectively leverage existing datasets and 

operational capabilities. As a result, it can bring about major efficiencies and savings through increased 

operational performance. 

In the absence of GIT partnerships, organizations often duplicate data that are already available and in use 

by other departments or agencies. Planning for enterprise architecture across multiple agencies will reveal 

these areas of redundancy and provide an opportunity to make business decisions regarding crossorganizational data acquisition and management. A shared data and services GIT program can enable an 

organization to keep pace with new mandates even when it faces a shrinking budget. In addition, sharing 

common data can build stronger inter-organizational cooperation and expanded use of common 

information across these groups. 

It is important to emphasize that one of the most useful features of a GIT system is its ability to overlay 

different views of a location. Combinations are limited only by the kinds of questions asked and the kinds 

of geospatial data available to provide answers. This powerful ability to integrate different kinds of 

information about a location can lead to better-informed decisions about investments in services. GIT is 

an effective analytical and decision-making tool that enables its users to organize, compare, and analyze 

disparate types of information. 

ROLE AND STRUCTURE OF A GIT BUSINESS CASE 

Elected and appointed officials typically do not have time to delve into the finer points of technology 

before being asked to make GIT investment decisions. Armed with only a basic understanding of 

8
GIT, they must weigh these projects against countless other opportunities and choose where and how 

their organizations will spend money. They are looking not for the technical merits of their 

investment options but rather for the business cases for each alternative. Ideally, the projects that 

have the most persuasive business cases are the ones that receive funding. 

A business case consists of a project definition, financial analysis, and strategic analysis. It answers 

these essential questions: 

• What is the nature and purpose of this investment? 

• What is the financial impact of the investment? In other words: 

- What are the benefits, and when will we realize them? 

- What are the costs, and when will we incur them? 

- Do benefits exceed costs? By how much? 

- Will this project pay for itself? How quickly? 

- How confident are we in the assumptions behind our financial analysis? What happens if 

our assumptions are wrong? 

• Does this investment further our business mission and goals? How? 

PROJECT DEFINITION 

The project definition explains the nature and purpose of the GIT investment. It summarizes the 

scope of activities around the application(s) to be developed. Often, it is as important to clarify what 

lies outside the scope as it is to explain what the scope includes. Following is an example of a 

project definition: 

Project Name: SWOMP – State-wide Open Mapping Program 

Project Purpose: Support the Governor’s Efficient Government Reform Initiative through 

the development of a single statewide street centerline map and associated addressing 

standard for all parcels across the state. Discourage duplicate data management by cities and 

counties. Improve the quality and consistency of street address data used for emergency 

response and preparedness. Minimize emergency response teams’ travel time through more 

efficient and effective dispatch. 

9
Project Scope Summary: 

• Implement a statewide Street Centerline and Addressing System to: 

- Map and maintain a standard street centerline for each road segment in the state, 

in coordination with local and county agencies. 

- Obtain and verify addresses on any parcel in the state, view the selection on-line, 

and print/plot the results. Use this data to improve local, state, and federal 

coordination. 

The definition above is sufficiently concise for a busy decision-maker. It gives the project a name 

(SWOMP). It suggests a link to recognized goals and policies (the Governor’s Efficient Government 

Reform Initiative). It also summarizes expected outcomes and clarifies the extent of the project 

(statewide street centerlines and parcels with associated addresses). The scope emphasizes the 

business use of the technology and avoids technical jargon. 

Because shared data and services GIT projects involve multiple organizations, it is important to 

maintain clear project definitions within and across each participating organization. It is also 

important to identify project interrelationships with other programs. 

For example, another state agency may be considering the installation of a new data communications 

line that would support several different GIT projects as well as a proposed program to provide office 

automation to a remote site. If the installation of the data communications line is lumped into the 

definition of one of the GIT projects, then that project’s financial analysis will bear the full burden of 

the line’s costs. This may be strategically advantageous if the GIT project has significant benefits 

and can independently justify the line. On the other hand, it may cause decision-makers to reject the 

GIT project as too costly. Either way, it is important to note the interrelationships in the business 

cases for all projects that benefit from the new data line. 

In some cases, activities that support multiple projects are best treated as separate strategic 

initiatives. This type of project might be presented as a “cost of doing business” as opposed to a 

truly discretionary investment. Following is an example of this type of approach in an abbreviated 

business case: 

The new fiber-optic line along State Highway 46 will support four of the IT projects under 

consideration for the coming budget year. The combined financial benefit of these supported 

projects is $6.6 million, which far outweighs the $4.7 million price tag for the 

communication line. Even if we choose not to pursue any of the other proposed IT projects, 

the new data line will provide an important communications link for the State Highway 46 

project. This high-speed line is essential for day-to-day business because the dial-up 

connection that we currently use is too slow even for basic Email and access to the Land 

Information System. The fiber line we are proposing has the lowest life cycle cost of all the 

technical alternatives considered. 

10
FINANCIAL ANALYSIS 

Financial analysis looks at cash flows related to an investment. Positive cash flows are benefits that 

may be realized as revenues or cost avoidance. Negative cash flows are costs and include one-time or 

capital costs to start the project as well as ongoing costs the project would introduce to the operating 

budget. There are six steps in preparing the financial analysis section of a business case: 

1. Estimate tangible benefits (positive cash flows). 

2. Estimate tangible costs (negative cash flows). 

3. Schedule the cash flows. 

4. Account for opportunity cost and inflation. 

5. Calculate financial metrics such as net present value (NPV)and return on investment 

(ROI). 

6. Consider the sensitivity of the financial analysis to the timeline and other assumptions 

underlying the cash flow estimates. 

Chapters 3 and 4 provide detailed guidelines on estimating benefits and costs. Chapter 5 addresses 

the scheduling of cash flows, the time value of money (opportunity cost and inflation), the 

calculation of financial metrics, and financial sensitivity analysis. 

STRATEGIC ANALYSIS 

The strategic analysis addresses the relationship of the project to the mission and goals of the 

participating organizations. It presents costs and benefits that cannot be quantified and are therefore 

ignored by the financial analysis. Sometimes, a shared data and services project has such significant 

strategic value that it is worthwhile even if the financial analysis is not persuasive. For example, a 

city and county may choose to implement a common Internet-based GIT application that allows 

developers to obtain permits by completing applications on-line. The city and county may choose to 

make this investment even if the cost of the technology outweighs the financial benefit of a 

streamlined permit application process. Officials may place such a high strategic value on developer 

goodwill that they deem the program to be worth the expense. 

Chapter 6 provides guidelines for preparing a strategic analysis. 

BUSINESS USE APPLICATION EXAMPLES 

The following table lists shared data and service related application examples for each of the 12 

business use applications discussed in this workbook. 

11
DATA ACCESS AND MAPPING 

Automated Map Production, Data Maintenance, and Data Access 

 Data access and viewing tools (e.g., web portals to spatial data) 

 Automated tools to create the graphical representation of digital spatial data (maps and atlases, 

which may be distributed electronically or as hard plots or books) 

 Automated tools to facilitate a timely and standardized update process for digital maps and the 

nonspatial records associated with the map features 

 Automated tools to capture field data and updates 

EMERGENCY MANAGEMENT AND SECURITY 

Emergency Preparedness and Response/Critical Infrastructure Protection 

 Applications that identify and quantify risks to public safety and/or critical infrastructure 

 Applications that safeguard the public and/or assets that are essential to a community 

 Applications that support community collaboration related to emergency preparedness and 

response 

GOVERNMENT ADMINISTRATION 

Property Appraisal/Legislative (Voting) Districting/Tax Assessment 

 Applications that support cadastral mapping and property appraisal 

 Applications that support property tax assessment and revenue projections 

 Applications that support sales tax assessment and revenue projections 

 Applications that support the delineation of special districts related to public improvements that 

benefit particular properties and affect tax rates for those properties 

 Applications that support the delineation of legislative (voting) districts and analyze demographic 

information related to these districts 

 Applications that support the planning and management of public election activities 

12
QUALITY OF LIFE 

Public Health and Safety/Community Services/Code Enforcement 

 Applications that support crime pattern analysis and other public safety planning and 

management activities 

 Applications that support epidemiological analysis and other public health planning and 

management activities 

 Applications that support land use planning, public open space (park) acquisition and planning, 

and economic development and redevelopment 

 Applications that support vector control (e.g., mosquito control) and animal control (e.g., 

vaccination programs and licensing, loose and dangerous animal programs) 

FIELD INFRASTRUCTURE MANAGEMENT 

Management of Roads and Utilities/Capital Improvements/Maintenance 

 Applications that support maintenance planning, scheduling, and work assignment (for 

preventive and predictive maintenance programs, planned repairs, and construction) 

 Applications that support route development and optimization (for maintenance programs, meter 

reading, etc.) 

 Applications that support field infrastructure performance and condition analysis and 

repair/replace decision making (capital project planning) 

 Applications that support isolation of networked field infrastructure 

 Applications that provide map-based access to detailed infrastructure drawings 

 Field system analysis applications that predict the location and/or impact of point sources of 

pollution/contamination/illegal use 

 Applications that support monitoring programs for tanks and other potential contamination 

sources 

 Applications that support field infrastructure project coordination and/or joint planning of 

complex (multi-agency) work 

 Applications that support code enforcement, including inspections and investigations of 

building code violations and other municipal, state, or federal code violations 

13
FACILITY MANAGEMENT 

Management of Buildings and Property/Capital Improvements/Maintenance 

 Applications that support maintenance planning and scheduling (preventive and predictive 

maintenance programs, repairs, and construction on facilities) 

 Applications that support facility asset performance and condition analysis and property 

valuation 

 Applications that provide map-based access to shop drawings, schematics, operations manuals, 

and/or training videos 

 Field system analysis applications that predict point sources of pollution/contamination/illegal 

use that have affected or may affect production/treatment facilities 

SERVICE DELIVERY 

Citizen and Customer Service/Call Management/Outage Management/Dispatch 

 Applications that support call emergency management and dispatch functions 

 Applications that support analysis of citizen complaints and trends 

 Applications that support outage response coordination in order to minimize incident impact and 

expedite service restoration 

 Applications that support Automatic Vehicle Location and route optimization 

CITIZEN AND CUSTOMER RELATIONSHIP MANAGEMENT 

New Service Planning/Compliance 

 Applications that identify and protect citizens and customers with special needs 

 Applications that support citizen collaboration and communications 

 Applications that track utility customer locations (service premises) and associated 

consumption/usage and work/complaint histories 

 Applications that track monitored/regulated organizations and support associated monitoring 

programs (e.g., significant industrial users, storm water discharge monitoring) 

14
ENGINEERING 

Planning/Design/Construction/System Analysis/Network Modeling 

 Applications that project demographic trends, forecast future demand, and analyze capacity 

relative to demand projections (e.g., load/volume capacity analysis) 

 Applications that support site/corridor analysis (evaluation of soil types, property values, natural 

and cultural resource protection, and other factors that affect infrastructure reliability and 

development costs) 

 Applications that support site selection and right-of-way/easement acquisition 

 Applications that support surface and subsurface models, including three-dimensional models 

and hydrological models 

 Applications that support construction project management, including inspections and 

acceptance/commissioning 

 Applications that support the development of engineering drawings, including design 

optimization and modeling (selection of design alternatives based on predefined criteria) 

LAND MANAGEMENT 

Development Review/Zoning/Permitting/Land Use Analysis 

 Applications that support regional (multi-agency) development coordination activities, including 

cooperative land use planning and zoning coordination 

 Applications that track zoning and support zoning case management for development and 

redevelopment 

 Applications that support the process of issuing building permits, business licenses, certificates 

of occupancy, and other regulatory instruments affecting development and redevelopment 

 Applications that support the development review process, including plat and construction plan 

approval, redlining, and street name and address management 

REGULATORY COMPLIANCE 

Permit Application/Monitoring Programs/Compliance Management 

 Applications that support permit application processes (for construction or operations) 

 Applications that support regulatory reporting 

15
 Applications that support monitoring and work activities related to permit compliance (e.g., 

utility rights of way management, water sampling, leak detection, PCB management) 

 Applications that display and/or analyze monitoring results and/or permit violations (e.g., 

overflow/incident mapping, noise modeling, pipeline pressure mapping) 

ENVIRONMENTAL MANAGEMENT 

Natural Resource Preservation/Watershed Protection/Weather Monitoring 

 Applications that identify and quantify risks to the environment/watershed and/or support 

associated operations planning, including time-lapse analysis 

 Applications that monitor environmental/weather conditions and/or support associated 

operational decisions 

 Applications that support environmental monitoring programs 

16
CHAPTER 3 

GIT BENEFITS 

KEY CHAPTER OBJECTIVES 

This chapter will provide an overview of the types of benefits that organizations can expect when 

implementing a shared data and services GIT program. It will define methodologies for quantifying 

the tangible benefits to help build a positive business case and includes discussion about dealing with 

the uncertainty of benefit assumptions. The chapter ends with a list of tangible benefits typical of the 

12 business use areas presented in Chapter 2. 

TANGIBLE AND INTANGIBLE BENEFITS 

A tangible benefit can be quantified as a dollar value. This dollar value is associated with future 

revenue or cost savings. A cost savings (or avoided cost) is a cost that will occur if a proposed 

investment is not pursued). Revenue benefits may arise from a growth in demand (more customers 

or more per capita consumption for an existing product or service), introduction of a new service, or 

an increase in percentage of receivables recognized and collected (e.g., more accurate permit 

tracking, more effective data collection and maintenance). Avoided costs include all types of 

reductions in operating costs such as payroll costs, material and equipment costs, and data and 

technology license fees. Avoided costs may also include one-time items such as fines or judgments. 

Not all benefits are quantifiable. Sometimes, it is impossible to estimate the dollar value of a 

particular project outcome. These intangible benefits belong in the strategic analysis section of a 

business case (see Chapter 6). Intangible benefits associated with GIT projects include 

customer/citizen goodwill, employee morale, quality of life, environmental health, and community 

growth. Although intangible benefits do not affect the financial analysis, they can be equally 

important or even more important than the tangible benefits. For example, the ability to stay in 

business is a strategic benefit that can make a business case compelling in the absence of any 

tangible benefits. 

Both tangible and intangible benefits are a direct result of the GIT applications under consideration. 

For this reason, it is essential to clearly define the GIT business applications in the project definition 

(see Chapters 1 and 2). 

CAPTURING PRODUCTIVITY BENEFITS 

Productivity increases are an important GIT benefit. Higher productivity means that people 

can accomplish more work in a given amount of time. An organization can realize the 

benefits of higher productivity three different ways: 

17
• Revenue Increase: Higher productivity enables an organization to increase the 

output of a product or service. If there is a market (demand) for these additional 

products or services, then the organization can anticipate an increase in revenue. 

This type of productivity benefit is typical for physical improvements but is not 

common for GIT projects, so it will not be explored further in this workbook. 

• Labor Cost Avoidance: Higher productivity will enable an organization to maintain 

current output or service levels while cutting staff positions. The result is elimination 

(or avoidance) of the associated labor costs, including salaries, fringe, and the costs 

of related office space, equipment, and support services. The potential is 

significantly increased within a shared data and services GIT program. Labor cost 

avoidance is a common GIT benefit and is always appropriate to include in a 

financial analysis. 

• Value of New Services or Service Levels: If one or more organizations do not 

intend to cut staff positions, then higher productivity translates into new services or a 

higher level of service. These services have value; if they did not, the organization 

would direct staff to do something else. Some organizations are willing to quantify 

the value of these new services. In other words, without taking any money out of 

their budgets, they recognize tangible benefits because they are doing more 

worthwhile things (or are providing a higher level or quality of service). However, 

not all governmental agencies are comfortable quantifying productivity gains that are 

realized as new services. They prefer to quantify only those benefits that appear as 

budget reductions. This is particularly true of organizations that are over-staffed or 

are experiencing a decline in their responsibilities. In these situations, the new 

services or higher service levels should be addressed in the strategic analysis (see 

Chapter 6). 

Set the Parameters 

Before calculating productivity gains, it is essential to set the parameters for quantifying 

productivity. These parameters include: 

• Whether the organization is willing to quantify new services or higher service levels 

for purposes of financial analysis. 

• A salary multiplier that reflects fringe costs such as payroll taxes and insurance 

premiums. Fringe multipliers are usually in the range of 15% to 80% of actual salary. 

A burdened hourly rate is an hourly wage augmented by the fringe multiplier. For 

example, the burdened hourly rate for a wage of $20/hour and a 30% fringe multiplier 

is ($20/hour X 1.3) = $26/hour. 

18
• Average attrition rates (the number of positions employees vacate each year). 

Employees vacate positions when they move to different positions, retire, or 

otherwise leave the organization. 

Finance and human relations departments typically provide these parameters. They may differ across 

agencies. The fringe multiplier and attrition rate may differ across job classifications. 

Identify Affected Staff Positions 

Accurate benefit estimation requires a detailed accounting of the staff positions affected by the 

proposed applications. If a relatively small number of positions (e.g., fewer than a dozen) are 

affected, the cost of each specific position can be calculated. Otherwise, positions should be grouped 

into categories with similar job titles, roles, and salaries. 

Estimate Annual Labor Hour Savings 

Labor hour savings are a function of the proposed GIT application(s). Each savings estimate should 

be tied to a specific cause and should be stated as an annual figure. For example: 

• Eliminate annual map book binding process (three clerks @ 40 hours per clerk each 

year) for a total labor savings of 120 hours per year for Records Clerks 

• Reduce time needed to retrieve record drawings by 15 minutes per retrieval. Field 

crews retrieve record drawings approximately 10,000 times per year. Total savings in 

Years 1 through 3: 10,000 X 0.25 = 2,500 field crews hours per year. After 

acquisition that is slated for Year 4, retrievals are expected to grow to 12,000 times 

per year. Savings for Year 4 and beyond: 12,000 X 0.25 = 3,000 field crew hours per 

year. 

As a quality control measure, it is a good idea to compare the estimated labor hour savings 

for a job category to the total number of labor hours available from that category. For 

example, if only one individual holds a particular position, it is impossible for that position’s 

total hourly savings to exceed the total number of hours one person can work in a single year 

(unless more positions are to be added to the category, in which case the anticipated staffing 

growth should be clearly noted in the financial analysis). 

By documenting the specific causes for each type of labor savings, project managers can 

quickly respond to inquiries about benefit predictions. In essence, they can demonstrate what 

the GIT project will do, how it will affect people, and, ultimately, what that means in terms 

of dollars saved. 

Translate Labor Hour Savings into Dollar Amounts 

Labor hour savings are translated into dollars by multiplying the total saved hours by the burdened 

hourly rate (i.e., salary plus fringe benefits) for the affected staff position or category. 

19
If the agency intends to eliminate positions, then the hourly savings should be truncated down to the 

nearest whole number of positions eliminated (or new positions avoided). The hours that reflect a 

full time position will depend on the nature of the position. Although most full-time staff positions 

provide roughly 2,000 labor hours per year, care should be taken to understand the true (productive) 

annual work hours of a particular staff position or category before determining how many hours must 

be saved before a position can be eliminated or avoided. In all likelihood, somewhere between 10% 

and 25% of an employee’s time is spent on overhead activities such as vacation, sick leave, end-ofshift clean-up, and administrative meetings. This means that a reduction of between 1,500 and 1,900 

hours of core workload should be sufficient to eliminate a budgeted full time position. On the other 

hand, if employees in a particular job category are working a lot of overtime, a reduction in hours of 

workload may not be enough to justify the elimination of a budgeted position; rather, this may 

provide a benefit in the form of overtime cost avoidance. 

If an organization intends to account for productivity recognized as new services or higher service 

levels, then any number of labor hours can be used in the calculation of the benefit dollars. 

The annual productivity benefit of a particular GIT project is the sum of the annual dollar benefits for 

each affected staff position. This can be expressed as follows: 

ANNUAL PRODUCTIVITY BENEFIT = (C1 × S1) + (C2 × S2) + ... + (Cp × Sp) 

Where: 

P = a particular staff position or category 

C = the burdened hourly cost of the staff position (salary plus fringe benefits) 

S = the annual impact of the application on the staff position in terms of 

 hours saved for positions in the category 

Figure 3.1 illustrates how this productivity benefit equation can be organized in a spreadsheet. The 

first table in the spreadsheet should show each job category (label P) along with its average hourly 

rate and the burdened rate (label C). The second table should list each application associated with 

the proposed GIT project and the labor hours saved in each job category (label S). The annual 

productivity benefit equation can then be entered into a productivity value column (label B) and 

totaled for all applications. 

20
Field Division

Job Title/Class Work Coord. Dispatcher Field Tech

Avg. Hourly Rate: $25 $10 $15

+ 20% Fringe $30 $12 $18

Applications: Total Annual Labor Hours Saved: Productivity Value:

PWM 100 200 1000 $23,400

OWM 200 0 2000 $42,000

$65,400

C B

P

S

Field Division

Job Title/Class Work Coord. Dispatcher Field Tech

Avg. Hourly Rate: $25 $10 $15

+ 20% Fringe $30 $12 $18

Applications: Total Annual Labor Hours Saved: Productivity Value:

PWM 100 200 1000 $23,400

OWM 200 0 2000 $42,000

$65,400

C B

P

S

Figure 3.1 Sample spreadsheet to calculate productivity benefit 

Productivity Benefits and Job Security Fears 

Any time a GIT business case cites a reduction in staff positions, there is a risk that 

employees will react negatively, particularly if they feel that their own jobs are in jeopardy. 

If an organization is badly overstaffed, this situation may be acceptable. However, a loss of 

job security (even if it is only a perception on the part of employees) can become a 

significant morale problem with undesirable consequences for the GIT project, from one or 

more of the participating agencies. One way to alleviate this problem is to focus only on 

future positions that can be avoided. This may be sufficient to address this issue. 

Another option is to tie position cuts to attrition by stating specifically that positions cuts will 

be limited to vacant positions. Under this approach, the number of positions saved per year 

must be compared to the total number of vacancies in each category. If there are not enough 

vacancies to “cover” the savings, then the attrition rate should be used to adjust the timing of 

the labor cost avoidance benefit. For example, if a project’s productivity estimate is 11,000 

hours of labor savings for desk clerks, and if the organization assumes that each clerk works 

2,000 hours per year, then: 

11,000 hours saved / 2000 hours per position = 5.5 positions 

This truncates down to five full-time positions. 

Now, assume that only two clerk positions are vacant at the time the business case is 

prepared and that the attrition rate for this category is two positions per year. If the 

productivity benefit is assumed to begin at the start of Year 2, the organization can plan to 

eliminate four positions in Year 2 by freezing the two current vacancies and also freezing the 

21
two positions that are expected to be vacated for Year 2. It can then plan to eliminate the 

fifth position at the start of Year 3 (when attrition is expected to create two additional 

vacancies). Figure 3.2 illustrates this approach. 

Figure 3.2 Timing of productivity benefit for cutting five positions contingent upon attrition 

CALCULATING OTHER TANGIBLE BENEFITS 

Shared data and services GIT projects may provide other tangible benefits such as preventing 

regulatory fines and penalties, increasing fee collection, or reducing legal liability or 

workers’ compensation costs. As with productivity gains, it is important to describe and 

quantify each of these benefits individually. This provides a complete record of its benefit 

estimation process. 

Like productivity gains, some of these miscellaneous benefits are permanent. In other words, 

once an organization begins realizing the benefit, it continues to realize it every year 

thereafter. However, certain miscellaneous benefits are periodic or one-time events. For 

example, a local government may be able to avoid the consulting costs associated with a 

comprehensive plan that is prepared every three years. A State Department of Transportation 

may be able to conduct its own preliminary environmental study for a new roadway program. 

For these types of benefits, it is important to identify the years in which they will occur and 

Year 

1

Year 

2

Year 

3

Year 

4

Year 

5

Job Positio f time uiv lents

11

10

9

8

7

6

5

4

3

2

1

0

Cumulative Attrition

(Positions Vacated)

ns ( ull eq

a )

Productivity Benefit 

(Vacant Positions 

Cut from Budget)

Year 

1

Year 

2

Year 

3

Year 

4

Year 

5

itio f time uiv lents

11

10

9

8

7

6

5

4

3

2

1

0

Cumulative Attrition

(Positions Vacated)

) a eq ull ns (

Productivity Benefit 

(Vacant Positions 

Cut from Budget)

Job Pos

22
the dollar values that will be realized in each of those years. This is done as part of the cash 

flow scheduling for the financial analysis (see Chapter 5). 

INTERNAL AND EXTERNAL BENEFITS 

The only benefits that should be quantified for the financial analysis section of a business case are 

those that accrue directly to the organization funding the investment. External benefits may be 

readily quantifiable, but they do not factor into the funding agency’s return on investment. If the 

external benefits are of strategic value to the funding agency, they belong in the strategic analysis 

section of the business case (see Chapter 6). 

For example, consider a regional base map development project funded by a council of governments. 

If the project will raise the productivity of Council personnel, the value of the labor hours saved 

should be part of the financial analysis of the project. However, the financial analysis should not 

include productivity or data quality benefits that may accrue to the Census Bureau, state agencies, 

local governments, or private businesses that take advantage of the data. 

When a single agency funds a project, the distinction between internal and external benefits is very 

clear. When agencies share data and services developed through cooperative projects, the distinction 

between internal and external benefits depends on the granularity of the business case. If the 

business case is prepared from the perspective of a single agency that is participating in the 

cooperative project, it should include only those tangible benefits (and costs) that will be realized by 

the subject participant. If the business case is prepared from the perspective of the cooperative, it 

should include the benefits (and costs) realized by all participants. Multi-participant initiatives often 

require both types of business cases. The broader business case helps the cooperative decide whether 

a joint investment is worthwhile. The individual business cases help participants decide whether the 

cost allocation is equitable and whether continued participation in the cooperative is warranted. 

ESTIMATING BENEFITS ARISING FROM SHARED DATA AND SERVICES 

When preparing business cases for investments in multi-participant GIT projects, it is essential to 

identify which agency will realize each benefit. It is also essential to clarify whether the business 

case reflects the perspective of the entire partnership or the perspective of a single participant. This 

information allows analysts to organize the benefit data into the financial and strategic sections of the 

business case as needed. Ordinarily, there is no need to quantify the benefits described in the 

strategic analysis. 

Occasionally, however, the external benefits of a GIT project are significant enough that they warrant 

quantification within the strategic analysis section. Consider again the example of the regional base 

map developed by a Council of Governments. If this regional base map allows dozens of local 

agencies to reduce the number of GIT specialists on their payrolls, the dollar value of these external 

benefits may outweigh all the other benefits captured in the use case. In this instance, the strategic 

analysis should include quantified benefit projections. If all the external agencies are supported by 

23
the same taxpayers that support the Council of Governments, then the strategic analysis may include 

financial projections from the perspective of the taxpayer. 

When estimating benefits (or costs) for a multi-participant project, care should be taken to ensure that 

all participants use the same assumptions about project schedule, application scope, and participant 

responsibilities. The most effective way to coordinate the project business cases is for all partner 

agencies to collaborate on standard project definitions, schedules, and estimated cash flows. 

DEALING WITH UNCERTAINTY 

Benefits estimates are almost never certainties. They are based on assumptions which may or 

may not prove true. One way to deal with uncertainty is to examine the sensitivity of the 

financial analysis to different variables, including the value and timing of specific benefits 

(see Chapter 5). Sensitivity analysis is a good approach for dealing with uncertainties in 

productivity benefit estimates. 

Another method of dealing with uncertainty is to reduce benefit estimates by the probability 

of their occurrence. This approach is appropriate for miscellaneous, event-driven estimates 

such as cost savings from avoiding fines or fees. If the event that would trigger the fine or fee 

is only 70% likely to occur, then the dollar value of the benefit can be reduced to 70% of the 

anticipated fee or fine amount: 

Adjusted Benefit = B × P 

Where: 

 B = the dollar amount of the benefit 

 P = probability that the benefit will be realized 

EXAMPLES OF TANGIBLE BENEFITS FOR GIT BUSINESS USES 

Following are some examples of tangible benefits associated with different shared data and services 

GIT business uses. (See Chapter 6 for examples of intangible benefits.) These examples are not 

comprehensive and are intended only as a starting point for developing a GIT business case. 

24
DATA ACCESS AND MAPPING 

Data Access, Automated Map Production, and Data Maintenance 

 Reduce map production and distribution costs 

 Reduce map editing costs (internal productivity) 

 Avoid cost of liability for failure to provide information to multiple agencies 

 Eliminate costs of research/reconciliation of inconsistent data 

 Reduce the cost of research and decision-making by expediting/facilitating access to 

critical information 

EMERGENCY MANAGEMENT AND SECURITY 

Emergency Preparedness and Response/Critical Infrastructure Protection 

 Reduce repair and service interruption costs associated with emergencies 

 Reduce the cost of preparing insurance claims 

 Maximize and expedite claim recovery 

 Reduce cost of maintaining/staffing emergency operations centers and avoid/reduce 

other emergency preparedness costs through consolidation of roles/activities in the 

region 

GOVERNMENT ADMINISTRATION 

Property Appraisal / Legislative (Voting) Districting/Tax Assessment 

 Increase tax revenues by identifying properties that are not on the tax rolls 

 Increase rate-based revenues by identifying undocumented users 

 Increase productivity of appraisal staff 

 Increase productivity of election planning/management staff 

QUALITY OF LIFE 

Public Health and Safety/Community Services/Code Enforcement 

25
 Raise property values by improving community livability 

 Secure/retain grant funding for community services programs 

 Increase tax revenues by attracting new business 

 Improve staff productivity by reducing travel time and numbers of trips 

 Reduce field infrastructure repair costs through more effective management of wild 

animal populations (e.g., armadillos, moles) that damage infrastructure 

 Reduce insurance rates 

FIELD INFRASTRUCTURE MANAGEMENT 

Management of Roads and Utilities/Capital Improvements/Maintenance 

 Improve field crew productivity by reducing travel time 

 Reduce operations and maintenance costs by avoiding breakdowns and optimizing 

programmed activities (better planning and scheduling of proactive work, equipment 

take-downs, and routine repairs) 

 Reduce cost of repair by expediting access to asset and maintenance information (faster 

repairs) 

 Reduce cost of inventory by streamlining requirements for on-hand stock (supporting 

more just-in-time procurement) 

 Reduce capital costs by extending asset life 

 Reduce cost of capital project planning (better asset performance and condition 

information) 

 Reduce cost of line locate program by eliminating trips to locations that do not have 

assets 

 Reduce cost of special projects/repairs by sharing common costs with other agencies 

working in the area 

26
FACILITY MANAGEMENT 

Management of Plants, Buildings, and Property/Capital 

Improvements/Maintenance 

 Reduce operations and maintenance costs by avoiding breakdowns and optimizing 

programmed activities (better planning and scheduling of proactive work, equipment 

take-downs, and routine repairs) 

 Reduce cost of repair by expediting access to asset and maintenance information (faster 

repairs) 

 Reduce cost of inventory by streamlining requirements for on-hand stock (supporting 

more just-in-time procurement) 

 Reduce capital costs by extending asset life 

 Reduce operating costs by improving source quality (e.g., influent, power) 

SERVICE DELIVERY 

Citizen and Customer Service/Call Management/Outage Management/Dispatch 

 Reduce fees, fines, or damage mitigation costs associated with inadequate response 

times 

 Improve productivity of field crews through reduced travel time and 

reduction/elimination of duplicate work orders 

 Increase rate-based revenues by minimizing the length of service interruptions 

 Reduce cost of call management by reducing transfers and expediting call processing 

(internal productivity benefit and/or avoidance of new call-taker positions) 

27
CITIZEN AND CUSTOMER RELATIONSHIP MANAGEMENT 

New Service Planning/Customer Compliance 

 Reduce fees, fines, or damage mitigation costs associated with interrupting service to 

special needs customers 

 Reduce operating costs through more effective use of interruptible programs 

 Reduce wastewater treatment costs by improving influent quality and/or reducing illegal 

discharge to the sewer system 

 Reduce storm water system maintenance costs by reducing illegal discharges/dumping 

 Increase revenues by expanding opportunities to sell/provide additional services and 

better targeting the new service offerings and marketing 

ENGINEERING 

Planning/Design/Construction/System Analysis/Network Modeling 

 Reduce the cost of preliminary design by reducing/eliminating the need for ad hoc aerial 

photography and mapping across multiple agencies 

 Reduce the cost of preliminary design by expediting/automating the production of 

alternative designs 

 Reduce the cost of design by expediting access to relevant data 

 Reduce the cost of construction and/or land acquisition through design optimization and 

better site/corridor selection 

 Reduce the cost of construction through more efficient inspections and construction 

management/coordination 

 Reduce the cost of construction through community project coordination 

 Reduce cost of debt through more accurate long term revenue forecasts 

 Reduce or delay capital costs through more thorough examination of alternatives (better 

models) 

28
LAND MANAGEMENT 

Development Review/Zoning/Permitting/Land Use Analysis 

 Reduce the cost of internal development review, permitting and/or inspections 

 Reduce the cost of joint development review (better regional communication – reduce 

lag time and additional reviews; productivity) 

 Avoid costs associated with duplicate or otherwise undesirable street names or addresses 

(e.g., avoid dispatch to wrong location and/or confusion of field personnel – affects 

productivity and also costs associated with liability for incorrect/delayed dispatch) 

 Increase business license revenues (more accurate permit and license data) 

 Increase tax revenues by expediting activities that raise property values 

REGULATORY COMPLIANCE 

Permit Application/Monitoring Programs/Compliance Management

 Reduce the cost of assembling permit application/renewal documentation 

 Avoid or minimize fines by preventing violations 

 Reduce report development and submittal costs (productivity benefits of automated 

reporting) 

 Reduce cost of sampling/monitoring by optimizing routes and sample point selection 

ENVIRONMENTAL MANAGEMENT 

Natural Resource Preservation/Watershed Protection/Weather Monitoring 

 Avoid or minimize fines or restoration costs associated with environmental damage 

 Reduce production/treatment costs by anticipating uncontrollable conditions (e.g., 

weather) that affect operations 

 Reduce production/treatment costs by controlling land use and management (e.g., 

agricultural techniques, waste disposal methods, pesticide/herbicide use) that affect 

operations 

 Reduce reactive maintenance costs by assembling resources in advance of 

uncontrollable conditions (e.g., weather) that affect demand and/or operations 

29
CHAPTER 4 

GIT COSTS 

KEY CHAPTER OBJECTIVES 

This chapter will review the typical costs that should be considered when building the business case 

for a shared data and services GIT investment. The types of costs that one or more agencies will face 

include the one-time start up costs and the ongoing costs once the project has been completed. Both 

of these types of costs should be included to provide a complete picture of the value of the 

investment. The chapter also includes sections on dealing with shared costs and sunk costs. 

Examples of typical GIT costs are presented at the end of the chapter. 

START-UP AND OPERATING COSTS 

Investment costs fall into two categories: 

• One-time (start-up) costs. These costs may be capitalized (i.e., recorded as assets and then 

depreciated to spread the expense over the life of the investment). However, capitalization is 

an accounting convention and does not factor into the financial analysis. Whether a cost is 

capitalized or expensed immediately, it should still be considered as a negative cash flow in 

the year it is incurred. Sometimes, the ability to capitalize costs or fund projects out of 

capital budgets is deemed desirable and can serve to differentiate project alternatives. In 

these cases, the ability to capitalize should be addressed in the strategic analysis. Examples 

of one-time GIT project costs include: 

- New hardware 

- New software 

- Data acquisition or conversion 

- Start-up services 

• Ongoing costs. These are typically funded out of operating budgets (i.e., expensed in the 

year incurred). Examples of GIT operating costs include: 

- New hires 

- Salary adjustments 

- Hardware maintenance fees 

- Software maintenance fees 

- Training 

- Support services 

30
- Data license fees 

SUNK COSTS 

Financial analyses of proposed projects deal strictly with future cash flows. Costs that have already 

been incurred are considered sunk costs and should never be included in the financial analysis of a 

future investment. It may seem counter-intuitive to ignore a significant previous expense such as a 

large data conversion investment for GIT. However, historical costs are facts that cannot be changed 

by future project decisions. No matter how much money has been spent in the past, the value of a 

future investment depends only on future benefits and costs. When a large sunk cost is an issue with 

decision makers, this issue can be addressed in the strategic analysis. For example, a section of the 

strategic analysis might state: 

Over the past ten years, we have invested $9.5 Million in the development of a land base and 

digital county-based street centerline maps and the acquisition of GIT hardware and software. 

The SWOMP project will leverage this important investment and provide real, demonstrable 

benefits for the organization and the state or community as a whole. 

This $8 million historical investment is not included in the SWOMP project cost estimates because 

the money has already been spent. 

SHARED COSTS 

Costs, like benefits, may be internal or external to the funding agency. For example, if a federal 

agency upgrades its GIT software, the agency should include the entire cost of new software and 

upgrade services in its financial analysis. However, if the upgrade will require a group of state 

agencies to modify their existing GIT applications and interfaces, these state agency costs are 

external to the federal agency’s financial analysis. In the latter example, the strategic analysis might 

include a discussion of the external costs. 

When multiple agencies share data or services, the costs of the associated GIT projects are divided 

among the participants, often in accordance with the requirements of the interlocal agreement or 

memorandum of understanding that established the GIT partnership. When developing business 

cases for multi-participant GIT projects, it is important to itemize each cost and note which 

participant will bear that cost. The business analyst can then determine which cash flows to include 

in the financial analysis and which to address in the strategic analysis. 

INTERNAL LABOR COSTS 

Internal staff time can be a significant GIT project cost. Internal labor costs can include: 

• New positions created as part of the project. This may include system or database 

administrators and technical support personnel. 

31
• Salary increases related to the project. This may include raises needed to retain drafting 

technicians who become proficient in GIT. 

• Cost of time for existing positions diverted to build, support, or use the proposed 

application(s). These costs can be politically sensitive in organizations that utilize program 

budgets, particularly if the diverted time reflects a large percentage of existing employees’ 

hours. If a project’s business case indicates that an existing GIT Technician position will be 

diverted full time for two years for project development, this may raise two concerns: (1) the 

position may not be justifiable in the budget if the GIT investment is rejected or delayed, and 

(2) even if the project is funded, the position is not justified after Year two. For 

organizations that rely on program-based budgets, the internal labor cost estimation process 

may be fraught with the same types of job security issues as the process for estimating 

productivity-related position cuts. One option for dealing with this issue is to recast the 

internal labor cost as a reduced productivity benefit. In other words, instead of listing the 

internal labor costs with the other negative cash flows, the dollar amount can be subtracted 

from the benefit associated with work force productivity gains. This generalizes the project’s 

impact on labor spending. It may mitigate job security fears associated with productivity 

benefit estimates and internal development cost estimates, and it has no net effect on the 

determination of a project’s financial viability (see Chapter 5). 

The hourly cost of internal labor should be the burdened rate (hourly wage plus fringe benefits). 

Figure 4.1 is a GIT project cost estimate that includes internal labor costs. 

One-time Costs: 

• GIT programming contract — $125,000 

• Five satellite imagery software licenses — 

$25,000 

• Satellite imagery system support contract 

— $50,000 

• Project manager time — 

 Hourly wage: $30 

 Burdened rate = $30 *1.2 = $36 

 Estimate labor @ 100 hours 

 100 hrs. @ $36/hr. = $3,600 

Ongoing Costs: 

• Additional annual software 

maintenance — $5,000 

SWOMP user support by GIT help desk — 

 Average help desk employee hourly wage: 

$25 

 Burdened rate = $25 *1.2 = $30 

 Estimate support needs @ 200 hours per 

year 

 200 hrs/yr @ $30/hr = $6,000

Figure 4.1 Example of GIT project cost estimate 

32
In Figure 4.1, there are two internal labor costs: a one-time cost of $3,600 associated with the project 

manager’s time, and an ongoing cost of $6,000 per year in GIT help desk staff time. These costs can 

be recast as reduced productivity benefits using the following equation: 

REDUCED ANNUAL PRODUCTIVITY BENEFIT =SAP-[AIL+(OIL÷PP)] 

Where: 

 SAP = sum of all applications’ annual productivity benefits

 AIL = annual internal labor cost (to be recast) 

 OIL = one-time internal labor cost (to be annualized over project life and recast) 

 PP = planning period (project life) (See Chapter 5 for details) 

Figure 4.2 shows how this equation is applied to the internal labor costs from Figure 4.1. First, the 

applications’ annual productivity benefits are added together (SAP label). Then, the ongoing internal 

labor cost for the help desk is subtracted from the annual benefit (AIL label). The one-time project 

management cost (OIL label) is divided over the project life (PP label) for an annual benefit of 

reduction of $3,600 / 10 years = $360 per year. The end result is an annual productivity benefit 

estimate of $59,040 instead of the original estimate of $65,400. 

SAP

Applications: Total Annual Labor Hours Saved: Productivity Value:

PWM 100 200 1000 $23,400

OWM 200 0 2000 $42,000

$65,400

Recast ongoing cost of help desk support: (6,000)

RAP

AIL $59,400

City Project Manager One Time Cost ($3600) over 10 Year Project Life: (360)

OIL PP

$59,040

SAP

Applications: Total Annual Labor Hours Saved: Productivity Value:

PWM 100 200 1000 $23,400

OWM 200 0 2000 $42,000

$65,400

Recast ongoing cost of help desk support: (6,000)

RAP

AIL $59,400

City Project Manager One Time Cost ($3600) over 10 Year Project Life: (360)

OIL PP

$59,040

Applications: Total Annual Labor Hours Saved: Productivity Value:

PWM 100 200 1000 $23,400

OWM 200 0 2000 $42,000

$65,400

Recast ongoing cost of help desk support: (6,000)

RAP

AIL $59,400

City Project Manager One Time Cost ($3600) over 10 Year Project Life: (360)

OIL PP

$59,040

Figure 4.2 Internal labor costs recast as reduced annual productivity benefit 

33
EXAMPLES OF TYPICAL GIT COSTS 

Following are some examples of one-time and ongoing costs typical for GIT investments. These 

examples are not comprehensive and are intended only as a starting point for developing a shared 

data and services GIT business case. 

Capital/One Time Costs 

 Project planning and business analysis/systems analysis 

 Legal and financial review 

 Technical staff development and training 

 Application and interface design 

 Data acquisition 

 Data conversion and reconciliation 

 Network enhancements 

 Office space, furnishings, phones, and other general equipment for new staff positions 

 New hardware to support the application 

 New software to support the application 

 Application development (programming) 

 Interface development (programming) 

 User training 

 Introductory publicity and communication 

34
Operating/On-going Costs – Personnel Costs 

 Salaries and fringe benefits for new staff (for execution of the supported business 

processes, technical support, ongoing workflow or systems analysis, and/or data 

maintenance) 

 Ongoing training and conference attendance for new staff positions 

 Allocations related to new staff positions (e.g., telephone services, office automation 

software maintenance fees, personal computer upgrades, administrative overhead 

allocations) 

 Increases to salary and fringe for existing staff (to reflect new duties and associated 

salary adjustments) 

 Additional ongoing training and conference attendance for existing staff positions 

Operating/On-going Costs – Technology Costs 

 Hardware maintenance contracts and/or periodic upgrades 

 Software license maintenance fees and/or periodic upgrades 

 Hardware and software lease costs 

 Application service provider (ASP) fees (if applicable) 

 Internet service provider fees 

 Shared resource cost allocations 

 Additional communication fees (e.g., wireless charges, leased lines) 

 Contracts for application support and enhancements, including periodic workflow and 

performance analysis 

Operating / On-going Costs – Data Costs 

 Data license fees 

 Contracts for offsite data storage 

 Contracts for data maintenance/updates 

35
Operating / On-going Costs – Technology Costs 

 Office supplies to support a shared data and services GIT program 

 Building maintenance (or maintenance/overhead allocations) for new office space 

36
CHAPTER 5 

FINANCIAL ANALYSIS 

KEY CHAPTER OBJECTIVES 

This Chapter explains the different financial analysis metrics, such as return on investment, internal 

rate of return, breakeven point and payback period, and addresses when it is appropriate to use each 

metric to compare investments. Techniques for defining cash flows and the opportunity cost impacts 

as part of the analysis will be explained, as well as how to account for inflation in your analysis. 

Finally, the chapter will close with a discussion on sensitivity analysis and how to include this in 

your overall shared data and service GIT project justification. 

WHAT IS FINANCIAL ANALYSIS? 

Financial analysis looks at cash flows related to an investment. Positive cash flows are benefits that 

may be realized as revenues or cost avoidance. Chapter 3 provides guidelines and examples for 

estimating GIT project benefits. Negative cash flows are costs and include one-time or capital costs 

to start the project as well as ongoing costs the project would introduce to the operating budget. 

Chapter 4 provides guidelines and examples for estimating GIT project costs. 

The CD that accompanies this workbook contains financial analysis templates and examples of 

completed templates for the case study. Readers may find it useful to review the case study financial 

analysis files as they work through this chapter. These are Microsoft® Excel files. Basic familiarity 

with Microsoft® Excel workbook navigation is all that is required to follow along in the case study 

files. 

PROJECT LIFE AND CASH FLOW SCHEDULE 

A cash flow schedule shows costs and benefits for every year of a project’s life. For purposes of 

financial analysis, a finite life (or planning period) is needed. A project life may be anywhere from 

several years to several decades in length. Determining factors include: 

• Business nature of the applications (i.e., How long will the processes be relevant, and how 

many agencies will benefit from it?) 

• Speed of technology change (i.e., When will newer technology replace these applications?) 

• Significance of future cash flows (i.e., At what point do future cash flows cease to have a 

significant impact on the financial analysis?) The planning period should be long enough to 

include all one-time costs and benefits and at least one instance of each periodic cost and 

benefit. 

37
• Magnitude of data acquisition. Data sets, if properly maintained, are long-lived assets, so it is 

appropriate to use 10-year or longer planning periods for projects with substantial data 

acquisition components. On the other hand, hardware and software are relatively short-lived 

assets. A five-year planning period is appropriate for projects that are predominantly 

technology development efforts. 

The finance departments of the representative agencies may provide guidelines for planning periods 

for different types of projects. The cash flow schedule should reflect the years in which specific 

costs and benefits occur (regardless of accounting methods used to book these flows as revenues and 

expenses). 

Figure 5.1 shows how activities related to costs and benefits can be mapped to a project timeline. 

Accurate scheduling of costs and benefits requires a solid understanding of the project 

implementation schedule. Benefits typically do not occur until after the implementation is 

completed. Costs may occur at various stages of the implementation, and some costs may continue 

annually after the implementation is complete. 

Task Name

Figure 5.1 High level timeline for costs and benefits 

Figure 5.2 shows how a spreadsheet can be used to translate a high level project timeline into a 

detailed schedule of cash flows. Costs are shown as negative flows while benefits are shown as 

positive flows. Spreadsheet equations are used to total the costs and benefits for each year of the 

project life. Spreadsheet equations can also calculate cumulative values by adding the total cost or 

benefit for the current year to the cumulative value for the previous year. 

Figure 5.2 Cash flow schedule 

Modify GIS

Procure SW Licenses

Modify WMS

Productivity Benefits

Faster Meter Repair

Y1 Y2 Y3 Y4 Y5 Y6 Y7 Y8 Y9 Y10

Year 1 2 3 4 5 6 7 8 9 10

GIS Contract ($100,000) ($25,000)

Software ($25,000)

WMS Contract ($25,000) ($25,000)

Annual Costs ($150,000) ($50,000) $0 $0 $0 $0 $0 $0 $0 $0

Cumulative Costs ($150,000) ($200,000) ($200,000) ($200,000) ($200,000) ($200,000) ($200,000) ($200,000) ($200,000) ($200,000)

roductivity $29,520 $59,040 $59,040 $59,040 $59,040 $59,040 $59,040 $59,040 $59,040

Faster Repair $10,000 $20,000 $20,000 $20,000 $20,000 $20,000 $20,000 $20,000 $20,000

Annual Benefits $0 $39,520 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040

umulative Benefits $0 $39,520 $118,560 $197,600 $276,640 $355,680 $434,720 $513,760 $592,800 $671,840

P

C

38
TIME VALUE OF MONEY (OPPORTUNITY COSTS) 

The timing of benefits and costs has an impact on their current value. A $100 bill in hand today is 

more valuable than a $100 bill that will not be in hand until next year. This is because money in hand 

today can be invested during the year to return a greater amount at year’s end. If an organization has 

to wait a full year realize a benefit of $100, there is an opportunity cost associated with this delay. 

The opportunity cost can be quantified as the return that might have been earned if the $100 had been 

in hand and invested at the start of the year. (In the same way, if an organization can delay a $100 

cost for a year, the negative value of that cash flow is mitigated by the fact that the money can be 

invested for a year prior to being spent.) 

Opportunity Costs for Future Investments 

The essential concepts in addressing the time value of money for future investments are: future 

values, present values, and the discount rate. 

• A future value is the actual cash flow that will be realized at the time shown. GIT cost and 

benefit estimates are typically expressed as future values. 

• The present value of a future cost or benefit is the value today of experiencing that cost or 

benefit at the projected time in the future. Present values allow a realistic comparison of cash 

flows that occur in different periods. The future values of GIT costs and benefits should be 

converted into present values prior to calculating the financial metrics (return on investment, 

net present value, etc.). 

• The discount rate is a multiplier that converts future values to present values. This multiplier 

reflects the annual rate of return available from an alternative investment. This may be a 

secure alternative such as government bonds, or it may be an average or published rate of 

return for investments of a similar nature or risk level. Most finance departments provide 

guidelines for discount rates to be used within their organizations. The discount rate is 

sometimes called a cutoff rate, hurdle rate, required rate of return, or opportunity cost of 

capital. 

The following equation shows how a simple (or nominal) discount rate converts a future cash flow to 

its present value. 

PV = FVn ÷ ( 1 + DR )n-1

Where: 

PV = Present value of the cash flow 

FVn = Future value estimated for year n 

DR = Discount Rate 

n = The year of the future cash flow (e.g., n = 1 for current period cash flows, n = 2

 for next year’s cash flows)

39
Figure 5.3 shows how a spreadsheet can be used to convert a cash flow schedule into present values. 

The spreadsheet first expresses annual costs and benefits as future values. It then applies the above 

equation to convert these cash flows to present values. As with the undiscounted schedule, the 

cumulative values are calculated by adding the present value of the current year’s cash flow to the 

previous year’s cumulative value. 

C

Discount Rate = 5%

Year 1 2 3 4 5 6 7 8 9 10

Annual Costs ($150,000) ($50,000) $0 $0 $0 $0 $0 $0 $0 $0

PV Annual Costs ($150,000) ($47,619) $0 $0 $0 $0 $0 $0 $0 $0

Cumulative Costs ($150,000) ($197,619) ($197,619) ($197,619) ($197,619) ($197,619) ($197,619) ($197,619) ($197,619) ($197,619)

Annual Benefits $0 $39,520 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040

PV Annual Benefits $0 $37,638 $71,692 $68,278 $65,026 $61,930 $58,981 $56,172 $53,497 $50,950

umulative Benefits $0 $37,638 $109,330 $177,607 $242,634 $304,564 $363,545 $419,717 $473,214 $524,164

Present Value of Annual Benefit in Year 3:

= FV ÷ (1 + DR) n - 1

= 79,040 ÷ (1 + 0.05) 3 - 1

= 71,692

Present Value of Cumulative Benefits in Year 3:

= PV Year 3 Benefits + PV Year 2 Cumulative Benefits

= 71,692 + 37,638

= 109,330

Figure 5.3 Using a spreadsheet to convert a cash flow schedule to present values 

Opportunity Costs and Historical Analyses 

The time value of money is also relevant in historical analyses (reviews of past investments). 

Discount rates are used to convert actual historical cash flows into adjusted values for a single year in 

the same way that they are used to convert a future investment’s cash flows into present values The 

essential concepts in addressing the time value of money in past investments are: actual historical 

cash flows, adjusted values, and basis for stating adjusted values. 

• An actual historical cash flow is a cost or benefit expressed in the dollars actually spent 

(or realized) in the year the cost or benefit occurred. 

• The adjusted value of a historical cash flow translates the dollars into the value they held 

in a particular year, typically the year of project inception. These values are expressed 

with a reference to the subject year. For example: $2.3 Million (in 2001 dollars). 

40
Adjusted values allow a realistic comparison of cash flows that occur in different periods. 

Actual historical cash flows should be adjusted into values for a single year prior to 

calculating the financial metrics (return on investment, net present value, etc.). 

• The adjusted values in a historical analysis are stated as dollars for a particular year. The 

selected year is the basis for stating the adjusted values, and any year can be used as long 

as all cash flows are converted to the values they hold in that year. Although any year can 

serve as the basis for the adjusted values, it is valuable to use the year of project inception. 

This enables analysts to compare actual financial performance to the business case 

(projections) prepared at the beginning of the project. In other words, if analysts prepared 

a business case prior to launching a project, they would have discounted all projected cash 

flows to present values (i.e., values at the year of project inception). By using this same 

year as the basis for stating adjusted values in a historical analysis, an analyst can safely 

compare the cash flows (and resulting financial metrics) from both business cases. 

DEALING WITH INFLATION 

Inflation occurs when money loses purchasing power over time. Purchasing power is the amount of 

real goods or services that can be acquired for a given sum of money. When the inflation rate is high 

or the investment life span is longer than a couple of years, inflation can have a significant impact on 

the purchasing power of future cash flows. 

When estimating the future values of costs and benefits for long projects, it is important to consider 

inflation and to document whether or not it is included in the estimates. Inflation should be treated 

consistently throughout the analysis. In other words, it should be included in all cash flow estimates 

or in none of them. If internal labor estimates reflect cost of living increases each year, then 

estimates of new or avoided data license fees should likewise reflect annual price increases 

anticipated from the vendor. If future values of cost and benefit estimates do not include an inflation 

factor, then this fact should be stated in the analysis. 

However, if the future values reflect inflation, then the nominal discount rate must be adjusted to 

reflect the reduction in purchasing power over time. This reduces the impact of the discount rate on 

the future cash flows because it reduces the true value (purchasing power) of the return that could be 

earned if the cash were otherwise invested. A real discount rate (as opposed to a simple or nominal 

discount rate) is a multiplier that is adjusted to reflect inflation. The assumed inflation rate should be 

clearly documented. Most Finance Departments will provide guidelines for inflation assumptions 

and real discount rates. 

The following equation shows how to use a real discount rate (the nominal discount rate reduced by 

the inflation rate) to convert future cash flows that reflect inflation. 

41
PV = FVn [ (1 + IR ) ÷ ( 1 + DR ) ]n-1

Where: 

PV = Present value of the cash flow

FVn = Future value estimated for year n

IR = Assumed annual inflation rate

DR = Annual nominal discount rate

n = The year of the future cash flow (e.g., n = 1 for current period cash flows, n = 2 

for next year’s cash flows) 

Figure 5.4 shows how a spreadsheet can convert future cash flows that reflect inflation. Compare 

Figure 5.4 to Figure 5.3. The present values in Figure 5.4 (with the inflation accounting) are higher 

than those in Figure 5.3 because inflation has reduced the opportunity cost of money. 

Discount Rate = 5%

Inflation Rate = 2%

Year 1 2 3 4 5 6 7 8 9 10

Annual Costs ($150,000) ($50,000) $0 $0 $0 $0 $0 $0 $0 $0

PV Annual Costs ($150,000) ($48,571) $0 $0 $0 $0 $0 $0 $0 $0

Cumulative Costs ($150,000) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571)

Annual Benefits $0 $39,520 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040

PV Annual Benefits $0 $38,391 $74,588 $72,457 $70,387 $68,376 $66,422 $64,524 $62,681 $60,890

Cumulative Benefits $0 $38,391 $112,979 $185,436 $255,822 $324,198 $390,620 $455,144 $517,825 $578,715

Present Value of Annual Benefit in Year 3:

= FV * [(1 + IR) ÷ (1 + DR)] n - 1

= 79,040 * [(1 + 0.02) ÷ (1 + 0.05)] 3 - 1

= 74,588

Figure 5.4 Using a spreadsheet to calculate present values for a cash flow schedule that reflects 

inflation 

Note: The example in Figure 5.3 shows future cash flows that “level off” to constant values toward 

the end of the project. Often, this is an indication that the future values ignore inflation, in which 

case a simple or nominal discount rate should be used rather than the real discount rate illustrated in 

Figure 5.4. Before factoring inflation into a present value conversion process, it is important to 

verify that the future cash flows actually reflect inflation. 

COMMON FINANCIAL METRICS 

Once the cash flow schedule is converted to reflect present values, standard metrics can be used to 

express the financial value of the project. Five common financial metrics are net present value, 

return on investment, internal rate of return, breakeven point, and payback period. 

42
Net Present Value (NPV) 

NPV is the sum of the present values of all cash flows (i.e., benefits net of costs). The equation for 

calculating NPV is as follows: 

NPV = ∑PV 

Where: 

∑PV = sum of present values of future cash flows 

This is the best overall measure of financial value because a higher NPV always indicates a better 

financial investment. A positive NPV indicates that a project is financially viable. When deciding 

between mutually exclusive projects or rationing project funding, NPV will indicate which projects 

have the greatest financial value. 

Refer to Figure 5.4 (the cash flow schedule converted to present values with the real discount rate). 

The present value of cumulative costs in this example is ($198,571), and the present value of 

cumulative benefits is $578,715. Adding these cumulative costs and benefits produces an NPV of 

($198,571) + $578,715 = $380,143. This indicates the project is financially viable and is a better 

investment that alternative projects with NPVs less than $380,143 (assuming the strategic values of 

the projects are equivalent). 

Return on Investment (ROI) 

ROI is the ratio of NPV to the absolute present value of all costs. (Note: The absolute value of the 

costs is expressed as a positive rather than a negative number). A positive ROI indicates that a 

project is financially viable. 

Refer to Figure 5.4 and the discussion of NPV above. The present value of cumulative costs in this 

example is ($198,571), and the NPV is $380,143. ROI is figured as NPV divided by the absolute 

value of the cumulative costs: $380,143 ÷ $198,571 = 190%. This indicates the project is financially 

viable. ROI may be annualized (expressed as an annual rate of return). Financial calculators and 

spreadsheets have functions that provide this value. It can also be approximated by dividing the ROI 

by the number of years in the project life (in this example, the 10 year planning period). The 

annualized rate of return for this is example is approximated as 190% ÷ 10 years = 19% per year. 

ROI is not the same thing as a benefit/cost ratio. ROI is a ratio of net benefits (NPV) to costs. 

Benefit/cost ratios divide cumulative benefits by cumulative costs. These ratios should use present 

values. They can be calculated for each year of a project’s life and are useful for calculating 

breakeven point. 

Despite its popularity, ROI is an inappropriate metric for comparing mutually exclusive investments. 

There are two reasons for this: 

43
• First, projects with a high NPV can have a relatively low ROI while projects with a low NPV 

can have a deceptively high ROI. For example, assume there are two mutually exclusive 

investments. One is worth $100,000 (NPV) with an ROI of 12% and the other is worth 

$80,000 (NPV) with an ROI of 14%. If only one investment can be pursued and the projects 

have equivalent risk and strategic value, then the best option is to pursue the first one. The 

$100,000 NPV is worth more than the $80,000 NPV regardless of the ROI percentages. 

• Second, ROI is sensitive to subjective assumptions about the nature of costs and benefits. A 

particular GIT project may create some new costs or workload while simultaneously 

streamlining other tasks and reducing other costs. It is up to an analyst’s subjective judgment 

whether to consolidate or itemize workload and cost impacts. Analysts who consolidate 

impacts will typically produce higher ROI figures than analysts who itemize. This is because 

ROI depends on a denominator that is a reflection of total investment costs. As discussed in 

Chapter 4, it may be appropriate to treat certain types of costs as reductions in benefits. This 

reduces the “cost denominator” of the ROI ratio and thus increases the resulting ROI. 

Figure 5.5 shows three different analysts’ interpretations of a proposed investment in an engineering 

research tool. Each analyst uses the same underlying assumptions, but they make different decisions 

about the itemization and presentation of costs and benefits. Each interpretation is valid and 

defensible. The decisions have no impact on NPV, which is the same in each analysis. However, the 

subjective differences in presentation yield very different ROI projections. The third analysis has an 

ROI that is more than 50% higher than that produced in the first analysis. These examples illustrate 

the significant weakness of ROI as a tool for comparing investment alternatives. They also 

demonstrate the power of NPV, which is a much better comparative tool because it is immune to 

analysts’ subjective decisions about the presentation of costs and benefits. 

Analysis 1: 

Itemize Everything 

Analysis 2: 

Consolidate Engineering 

Impact 

Analysis 3: 

Consolidate Engineering 

and Service Contract 

Impacts 

Assumptions

 Project Life – 5 Years 

 Inflation Rate – 2.5% 

 Cost of Capital – 5% 

 Fringe Rate – 50% 

Labor costs reflect inflation 

rate 

Assumptions

 Project Life – 5 Years 

 Inflation Rate – 2.5% 

 Cost of Capital – 5% 

 Fringe Rate – 50% 

Labor costs reflect inflation 

rate 

Assumptions

 Project Life – 5 Years 

 Inflation Rate – 2.5% 

 Cost of Capital – 5% 

 Fringe Rate – 50% 

Labor costs reflect inflation 

rate 

Current (and Burdened) 

Rates

 Programmers – $30 ($45) 

 Administrator – $40 ($60) 

 Analysts – $35 ($52.50) 

Current (and Burdened) 

Rates

 Programmers – $30 ($45) 

 Administrator – $40 ($60) 

 Analysts – $35 ($52.50) 

Current (and Burdened) 

Rates

 Programmers – $30 ($45) 

 Administrator – $40 ($60) 

 Analysts – $35 ($52.50) 

44
Analysis 1: 

Itemize Everything 

Analysis 2: 

Consolidate Engineering 

Impact 

Analysis 3: 

Consolidate Engineering 

and Service Contract 

Impacts 

One-time Costs (all Year 1)

New Software: $50,000 

Programmer Time: 500 hours 

Administrator Time: 40 

hours 

Analysts Time: 80 hours 

One-time Costs (all Year 1)

New Software: $50,000 

Programmer Time: 500 hours 

Administrator Time: 40 

hours 

One-time Costs (all Year 1)

New Software: $50,000 

Programmer Time: 500 hours 

Administrator Time: 40 

hours 

Annual Costs

Administrator Labor: 8 hours 

Software Maintenance: 

$10,000 

Annual Costs

Administrator Labor: 8 hours 

Software Maintenance: 

$10,000 

Annual Costs

Administrator Labor: 8 hours 

Annual Benefits

Faster Research for Analysts: 

 Year 1 – 200 hours 

 Year 2 – 400 hours 

 Year 3 – 400 hours 

 Year 4 – 400 hours 

 Year 5 – 400 hours 

Avoid Research Contract: 

 Year 2 – $15,000 

 Year 3 – $15,500 

 Year 4 – $16,000 

 Year 5 – $16,500 

Annual Benefits

Faster Research for Analysts:

 Year 1 – 120 hours 

 Year 2 – 400 hours 

 Year 3 – 400 hours 

 Year 4 – 400 hours 

 Year 5 – 400 hours 

Avoid Research Contract: 

 Year 2 – $15,000 

 Year 3 – $15,500 

 Year 4 – $16,000 

 Year 5 – $16,500 

Annual Benefits

Faster Research for Analysts:

 Year 1 – 120 hours 

 Year 2 – 400 hours 

 Year 3 – 400 hours 

 Year 4 – 400 hours 

 Year 5 – 400 hours 

Reduce Contract Fees: 

 Year 2 – $5,000 

 Year 3 – $5,500 

 Year 4 – $6,000 

 Year 5 – $6,500 

Cumulative Cash Flows 

(Present Values)

Costs – $118,698 

Benefits – $153,907 

Cumulative Cash Flows 

(Present Values)

Costs – $114,498 

Benefits – $149,707 

Cumulative Cash Flows 

(Present Values)

Costs – $76,823 

Benefits – $112,032 

NPV: $35,209 

ROI: 5.93% (Annualized) 

NPV: $35,209 

ROI: 6.15% (Annualized) 

NPV: $35,209 

ROI: 9.17% (Annualized) 

Figure 5.5 Subjective decisions about treatment of costs and benefits yield different ROI 

projections for the same investment, yet NPV remains unaffected 

45
Internal Rate of Return (IRR) 

The internal rate of return (IRR) is the discount rate that would produce an NPV of zero (i.e., the 

discount rate at which the cumulative present value of benefits equals the cumulative present value of 

costs). If the IRR exceeds the minimum rate of return that an organization requires for a project, it 

can be deemed a good investment. However, IRR is an inappropriate metric for comparing 

investment options because a high NPV project can have an IRR that is lower than an alternative 

project with a smaller NPV. 

Spreadsheet software and financial calculators are typically used to calculate IRR for a stream of 

cash flows. Without these tools, solving for IRR requires trial and error estimates of NPV at 

different discount rates (similar to solving for square roots). If the first discount rate produces a 

positive NPV, try again and again with higher rates until NPV is negative. A graph of NPVs (or 

present values of costs and benefits) at different discount rates can help zero in on the IRR. See 

Figure 5.6. 

Total Benefits Total Benefits

Present 

Value 

($)

IRR IRR

Discount Rate

Total Costs Total Costs

Total Benefits Total Benefits

Present 

Value 

($)

IRR IRR

Discount Rate

Total Costs Total Costs

Figure 5.6 Estimating IRR by plotting cumulative present values at different discount rates 

Breakeven Point 

Breakeven point is the year in which cumulative benefits equal cumulative costs. Financially viable 

projects will break even at some point in the future. Although this metric is politically relevant, it is 

not a meaningful financial differentiator and should not be used to compare the financial impact of 

alternative projects. For example, assume there are two mutually exclusive investments. One is 

worth $100,000 (NPV) and will break even in Year 4, and the other is worth $80,000 (NPV) and will 

break even in Year 3. If only one investment can be pursued and both projects have the same risk 

and strategic value, then the best option is to pursue the first one. Expressed as a present value, 

$100,000 is always worth more than $80,000 regardless of the timing of the cash flows. 

To calculate the breakeven point, look for the year in which cumulative benefits exceed cumulative 

costs. This can be achieved in a spreadsheet by setting up a “benefit/cost ratio” row that divides 

cumulative benefits by cumulative costs. Breakeven occurs in the year where the ratio exceeds 1. 

(The same thing can be accomplished with a “Net Benefits” row that subtracts cumulative costs from 

cumulative benefits. In this case, look for the year in which the net benefits exceed 0.) Present 

values should be used in the calculation of the benefit ratios or net benefits. 

46
Payback Period 

The payback period is the length of time between the initial investment (project start) and the 

breakeven point, typically expressed in months or years. Like the breakeven point, this metric is 

politically relevant, but it is not a meaningful financial differentiator and should not be used to 

compare the financial impact of alternative projects. 

Figure 5.7 illustrates the calculation of the breakeven point and payback period. Breakeven occurs at 

the point where the cost and benefit lines intersect. If these lines intersect more than once (due to 

periodic cost spikes such as those associated with hardware and software replacement), the breakeven 

point is the final intersection. 

Cumulative 

Costs

Cumulative 

Costs

Cumulative 

Benefits

Cumulative 

Benefits

Payback 

Period

Payback 

Period

Present

Value

($)

Time

Break-Even

Point

Break-Even

Point

Figure 5.7 The breakeven point occurs when cumulative benefits begin to exceed cumulative 

costs. The payback period is the span between the outset of the project and the breakeven 

point. 

IMPACT OF RECASTING INTERNAL LABOR COSTS 

It may be politically expedient to recast internal labor costs as a reduced productivity benefit (see 

Chapter 3). This process has no impact on NPV because it trades a negative cash flow for a 

proportionately reduced positive cash flow, and the sum of all cash flows is unchanged. The process 

will also not effect the determination of project viability using ROI or breakeven point because this 

47
determination is really a reflection of NPV (i.e., ROI will always be greater than zero and a project 

will eventually break even if NPV is positive). However, the recasting process has the effect of 

reducing stated project costs, which leads to a higher ROI. As illustrated in Figure 5.5, the 

distinction between a cost and a negative benefit is open to interpretation. As a result, the 

denominator in an ROI ratio is subjective. This is the reason NPV is the preferred tool for comparing 

investment options. 

SENSITIVITY ANALYSIS 

Financial analysis relies on estimates and assumptions. If actual costs and benefits differ from the 

estimates, the results of the investment will differ from those predicted by the analysis. If NPV is 

extremely sensitive to an uncertain cash flow estimate with a wide range of possible actual values, 

then the investment may be riskier than an alternative for which there is a narrower range of possible 

values or less sensitivity to any particular estimate. When two investment alternatives have the same 

NPV, the option with the lower risk is typically viewed as the better investment (although some 

organizations may prefer riskier options that have a strong possibility of achieving a higher NPV). 

Sensitivity analysis illustrates the risk inherent in a financial analysis and allows officials to factor 

their risk tolerance into the decision-making process. 

Sensitivity analysis begins with thorough documentation of all benefit and cost estimates and the 

assumptions underlying these estimates (see Chapters 3 and 4). Each of these estimates and 

assumptions are variables in the investment decision. In addition to the cash flow estimates, 

important investment variables include the cash flow schedule, the events that affect that cash flow 

schedule, and the opportunity cost of capital (discount rate). Sensitivity analysis looks at how these 

variables affect NPV. This is accomplished by calculating several “versions” of NPV using different 

values for one or more selected variables while holding all other variables at their original levels. 

For numeric variables (cash flow estimates, discount rates), the sensitivity analysis typically includes 

the “minimum” and “maximum” NPV (the NPV for the minimum and maximum values of the 

variable under consideration). The sensitivity analysis also may indicate the value of the variable that 

produces an NPV of zero. If this “breakeven” level of the variable is significantly higher than the 

potential minimum value of the variable or is otherwise likely to occur, the investment may be 

deemed a risky one. Alternatively, if the worst-case scenarios for the significant variables still 

produce a positive NPV, then the investment may be deemed a low-risk option. 

For nonnumeric variables (such as events that influence cash flows or timing), the sensitivity analysis 

shows NPV for alternative assumptions and then states the confidence level in the original 

assumption. If confidence in the original assumption is low and alternative assumptions produce a 

negative NPV, the investment may be deemed a risky one. Low risk investments are characterized 

by high confidence levels in all variables and positive NPVs even for worst-case scenarios of 

alternative assumptions. Following is an example of sensitivity analysis for a nonnumeric variable. 

Refer to the previous figures and examples for background. 

48
This financial analysis assumes training will happen in Year 2. It is possible that emergency 

management training might be delayed as long as Year 4 (the termination of the current union 

contract). If this happens, benefits will not begin until Year 5, and the NPV will drop 

roughly 50% to $194,708. Annualized ROI will drop from 19% to 10%. It is highly unlikely 

that training will be delayed beyond the end of Year 2 because influential union officials 

have expressed their support. Even under the worst case scenario for this variable, the 

investment is still cost-justifiable. 

Figure 5.8 shows how to use a spreadsheet to calculate alternative financial metrics for the different 

assumptions in the sensitivity analysis example above. This can be compared to the original analysis 

shown in Figure 5.3, where the benefits are shown to occur partially through Year 2 of the project. 

Year 1 2 3 4 5 6 7 8 9 10

Annual Costs ($150,000) ($50,000) $0 $0 $0 $0 $0 $0 $0 $0

PV Annual Costs ($150,000) ($48,571) $0 $0 $0 $0 $0 $0 $0 $0

Cumulative Costs ($150,000) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571) ($198,571)

Annual Benefits $0 $0 $0 $0 $79,040 $79,040 $79,040 $79,040 $79,040 $79,040

PV Annual Benefits $0 $0 $0 $0 $70,387 $68,376 $66,422 $64,524 $62,681 $60,890

Cumulative Benefits $0 $0 $0 $0 $70,387 $138,762 $205,184 $269,709 $332,389 $393,279

NPV ($393,279-$198,571): $194,708

ROI ($194/708 / $198,571): 98%

Annualized (98% / 10 years): 10%

Figure 5.8 Calculation of NPV and ROI with training delayed until Year 4 

49
CHAPTER 6 

STRATEGIC ANALYSIS AND THE BUSINESS CASE 

KEY CHAPTER OBJECTIVES 

This chapter discusses how to present the strategic value and make the business case for the proposed 

shared data and services GIT program. This includes how best to present the intangible benefits that 

are not captured in the financial analyses and how to present any project interrelationships, and 

benefits that extend beyond organization. A recommended format for an Executive Summary of the 

project is also provided. Examples of strategic (intangible) benefits for each of the 12 business use 

areas are also provided at the end of the chapter. 

INTERPRETING A BUSINESS CASE 

Rigorous financial analysis of proposed GIT investments is rare and analysis of actual financial 

performance is rarer still. This is even more unusual for shared data and services GIT projects. 

Given the importance and size of these investments, the lack of rigorous business case analysis is 

unfortunate, and it provides the impetus for this workbook. 

The purpose of a rigorous business case is to prepare decision-makers across multiple agencies to 

evaluate a proposed shared data and services GIT investment. While cost projections are relatively 

easy to assemble and must be accurate enough to support budgeting, the benefit estimates in a 

business case are often much harder to quantify and much more sensitive to the business case’s 

underlying assumptions. When reviewing a business case for a proposed future investment, it is 

important to keep in mind the uncertainties associated with the benefit estimates. The point of a 

business case is not to guarantee a particular stream of benefits but rather to provide a reasonable 

indication of the prudence and relative value of a potential investment. 

It is also useful to evaluate actual historical cash flows for a project. These analyses teach analysts to 

fine-tune their estimating skills, and this improves the reliability of future business cases. The 

purpose of preparing a historical business case is to learn lessons that can be applied to the evaluation 

of related future projects. Some organizations regularly conduct post implementation reviews of 

their capital projects and the use of the concepts and templates presented in this workbook will 

provide the necessary backup to allow an effective review. 

It is important that the business case include a discussion of the strategic value of the investment in 

addition to the financial metrics discussed in previous chapters. 

WHAT IS STRATEGIC ANALYSIS? 

The strategic analysis section of a business case provides the context for interpreting the financial 

analysis. It explains how an investment furthers an organization’s mission and goals, and it presents 

intangible (non-quantifiable) benefits. The strategic analysis also addresses project 

50
interrelationships. This is particularly important for GIT projects that involve data capture since the 

data may support a wide range of future endeavors. 

Strategic analysis is an essential part of the business case for an investment, and is typically 

presented in a narrative form prior to presenting the financial metrics calculated through the 

templates. 

STRATEGIC BENEFITS AS INTANGIBLES 

The strategic analysis section of a business case is the place to define intangible benefits. These are 

the benefits that are not readily quantifiable. General examples of strategic benefits include higher 

employee morale and/or safety, more public goodwill, or an increased certainty of business 

continuity among agencies. These can also be presented as consequences to the organization should 

the project not proceed. 

PROJECT INTERRELATIONSHIPS 

If the project under consideration will lay the groundwork for future projects, the strategic analysis 

describes these project relationships and the types of benefits that can be expected once the 

groundwork is in place. 

For example, if a “foundation-type” GIT project provides a spatial inventory of linear infrastructure 

such as a transportation network, this will lay the groundwork for future linear asset management and 

security planning projects. The direct, tangible benefits of the first project may be limited to shared 

data access and data maintenance. However, the strategic benefits of the project include the ability to 

launch a linear asset management program that will likely reduce asset life cycle costs. It will 

provide a foundation for a linear asset security assessment and critical infrastructure protection plan 

among multiple agencies, which will improve public safety and increase the likelihood of business 

continuity in the event of a natural or man-made disaster. 

Project interrelationships are particularly important for GIT investments among multiple agencies 

that are not justifiable from a purely financial perspective. If these projects are worthwhile, it is 

typically because they support future projects that will have a beneficial financial impact. It is 

important to communicate this potential clearly in the business case. 

EXTERNAL BENEFITS 

The benefits of a shared data and services GIT project must extend beyond the boundaries of the 

agencies that are funding it. If the funding agencies will be sharing data with other organizations or 

the general public, each of the data users will benefit. These benefits may even be quantifiable, but 

they will not find their way into the financial analysis if they do not accrue to the funding agency. 

The strategic analysis is the place to describe these external benefits. 

For example, if a county agency is building a GIT capital project coordination application and 

making it available to other city and county agencies and utilities so that the community can identify 

51
project coordination opportunities, there will be many external benefits. Each of the participating 

agencies can anticipate a reduction in capital project costs. The agencies that maintain the streets and 

highways can anticipate an increase in useful pavement life through a reduction in excavations. 

Community businesses will benefit from a reduction in business interruption through better project 

coordination. All community residents can anticipate an improved quality of life due to a reduction 

in the number of disruptive excavations. Some of these benefits are quantifiable for the benefiting 

agencies. Others are purely intangible. All of them belong in the discussion of the strategic value of 

the proposed GIT project. 

COOPERATIVE SHARED DATA AND SERVICE GIT PROJECTS 

When the external benefits of a GIT project are significant, there is often an opportunity for 

collaboration with outside agencies beyond those participating. For example, a regional planning 

agency interested in building a capital project coordination application may find willing partners in 

area local governments, other utilities, and large landholders such as universities, hospital districts, 

or military bases. 

Shared data and service projects present an interesting challenge to business case development. Each 

participant must persuade its governing board or council that the project itself is beneficial and that 

the allocation of costs is equitable. This requires an analysis of the project as a whole followed by an 

analysis of each participant’s costs and benefits. 

The financial analysis for an organization’s contribution to a shared data and services GIT project 

should include only those costs and benefits that accrue directly to the participant. The strategic 

analysis is the place to describe the entire project, all costs and the method for distributing them 

among participants, and all benefits, including the benefits that accrue to external agencies and the 

community as a whole. 

COMPLETING THE BUSINESS CASE 

The complete shared data and services GIT business case includes the following elements: 

• Project Definition (see Chapter 2). 

• Financial Analysis. This is usually a summary of key financial metrics and highlights of the 

sensitivity analysis. Detailed assumptions, calculations, and the complete sensitivity analysis 

are typically placed in an appendix. (See Chapter 5.) 

• Strategic Analysis. This includes the discussion of strategic benefits, external benefits, and 

project interrelationships. In the case of collaborative projects, this is the place to describe 

the full project, the cost-sharing methodology, and the benefits to other participants and the 

community as a whole. 

52
• Recommended Course of Action. If a business case is persuasive, it should conclude with a 

recommendation to make the investment among the participating agencies. If the business 

case is not persuasive, it may end with a recommendation to table the project concept for 

future consideration. Falling technology costs, the steady growth of commercially available 

spatial data, and regulatory changes can make a huge difference in the costs and benefits of a 

GIT project. Participating agencies may wish to revisit tabled business cases as part of an 

annual strategic planning process to determine whether circumstances have changed 

sufficiently to warrant an updated analysis. 

A business case may be extremely brief or may be hundreds of pages long. Larger investments often 

require more detailed (longer) business cases. If a business case is more than a few pages long, it 

should include a brief executive summary. 

53
CHAPTER 7 

RESEARCH FINDINGS AND RECOMMENDATIONS 

KEY CHAPTER OBJECTIVES 

This chapter summarizes the research findings that are included in the appendices of the workbook. 

This includes the Literature Review and Case Study Findings. Recommendations regarding 

application of the research and further research directions are provided in this section. 

LITERATURE REVIEW FINDINGS 

The multi-agency literature review shows a variety of approaches for describing project benefits and 

presents a strong case for the importance of quantifying and communicating shared data and services 

GIT project benefits. However, methodology for quantifying the cost savings of these benefits has 

not been generally well developed nor does there appear to be a common set of standards. It has 

been more the case that benefits are described qualitatively and as strategic benefits. In cases where 

benefits metrics have been developed, these may not have been translated into cost savings needed 

for a complete financial analysis of a project. There does not appear to be a flexible methodology or 

toolset suitable to adaptation to the diverse range of benefits found in multi-agency GIT projects. 

Additionally, the components of multi-agency projects have typically not been analyzed in detail to 

study how their parts fit together to make a business case for the project as a whole, or for the 

complete life cycle of the project. There have been efforts to study a portion of the issues of multiagency business cases, such as an analysis of 15 states’ approaches to working with funding sources 

for GIS projects, but there has been no comprehensive toolset for bringing all of these components 

into a financial analysis of an entire project. Existing tools do not appear suitable for multi-agency 

project management tasks during, for example, the stages of a complex project implementation. 

Further, methodology has not been developed for strategic analysis of multi-agency projects, taking 

into account the diverse needs, goals and constraints of the participating agencies. These issues may 

have been described as a subset of an analysis, but there has been no methodology developed to 

assist in analysis of the business case for the project as a whole with the various participating agency 

component parts. The literature review shows no significant efforts toward integrating strategic 

analysis and traditional financial analysis for evaluation of multi-agency projects, although it points 

out the need for such a methodology as cases are described. 

CASE STUDY FINDINGS 

The following case study demonstrates the robustness and effectiveness of the developed ROI toolset 

in meeting the needs of a broad range of GIS programs. The organizations represented by this 

project include a combination of local, regional, state and federal organizations. The toolset has 

54
benefited greatly from exposure to this wide range of circumstances in that it has grown to 

accommodate the requirements of each participating agency. The WA-Trans case study includes 

separate financial analyses from a wide variety of agencies that will share data and services. These 

separate analyses are then consolidated to provide an overall project financial analysis (from the 

perspective of a state taxpayer rather than the perspective of a single agency). 

WA-Trans Washington Statewide Transportation Framework 

Organizations served include the Washington State Department of Transportation (WSDOT), which 

is funding the bulk of the project, as well as a number of other agencies that will share the 

transportation data. Participating organizations include: Puget Sound Regional Council, multiple 

county governments, Sound Transit, County Road Administration Board (CRAB), a U.S. Bureau of 

Census Regional Office, Washington Department of Natural Resources, and Washington Department 

of Fish and Wildlife. Nineteen different organizations contributed to the case study. 

The state DOT's mission is to keep people and business moving by operating and improving the 

state’s transportation systems. WA-Trans will support this mission by providing a seamless, 

statewide transportation location-based data set that includes the best information available about 

roads, railroads, airports, ferry terminals and routes, port facilities, and non-motorized transportation 

routes such as bike paths and horse trails. The data will be used to improve transportation planning, 

analysis and design capabilities not only for the state DOT but also for local and regional 

organizations across the state. Better transportation planning will ultimately lead to better 

transportation infrastructure and more effective utilization of existing resources. 

In order to integrate data from local, state, federal and tribal governments, the scope of the WATrans project includes: 

• Completing the development of the statewide spatial database and related data standards; 

• Implementing supporting applications that provide access to the spatial database and 

support integration of disparate data sets; and 

• Developing interagency agreements in support of data sharing to formalize collaborative 

data collection and maintenance. 

The strategic analysis addresses the relationship of the project to the organization’s mission and 

goals. It presents costs and benefits that cannot be quantified and are therefore ignored by the 

financial analysis. Sometimes, a project has such significant strategic value that it is worthwhile 

even if the financial analysis is not persuasive. Examples for this case study could fall in the areas of 

emergency management and response, cross-governmental communication, and public 

communication. Additionally, WA-Trans is identified as a part of the state enterprise architecture as 

a strategic data resource. 

55
From the sole perspective of Department of Transportation, the financial return on this investment 

appears small (NPV just over $255,000 and ROI below 1%). But when the financial impact on all 

participating agencies is considered, the project shows a very healthy return (NPV of over $17 

million and ROI of over 10%). The WA-Trans project furthers the mission of WSDOT and is 

projected to be a financially sound investment for taxpayers. 

CONCLUSIONS

Each phase of this project has brought a distinct perspective to this broad study of return on 

investment methodology. 

The literature review found that qualitative information on geospatial investments at government 

agencies is more common than quantitative analysis. This is not surprising, as intangible benefits are 

particularly important for agencies that typically have public service as a primary function. There 

have been some attempts to establish valuation of service provided to the public but there has been 

no development of corresponding systematic methodology. The literature showed no consistent 

methodology for use in financial analysis of multi-agency projects. Similarly, there has been no 

unified approach to strategic analysis for the combined effects of multiple agencies participating in a 

GIT project. 

The case study provides insight into issues of actual implementation of the developed return on 

investment methodology as well as some findings about geospatial implementations at agencies. 

Large shared data and services GIT projects across a community have large costs and accompanying 

large benefits. In many cases, productivity benefits are dominant. Mature GIT implementations 

enable the return of substantial benefits from the development of new applications based on the 

existing technology at marginal additional cost. Complex projects involving multiple agencies can 

provide substantial quantifiable and strategic benefits, but it may be time consuming to collect 

thorough and consistent benefit data from all affected agencies. 

RECOMMENDATIONS FOR USING THESE TOOLS AND FOR FUTURE 

RESEARCH 

This shared data and services GIT return on investment project has resulted in many new ideas for 

implementation of the methodology in a variety of governmental organizations. In performing the 

case study, the GITA ROI Team has adapted the methodology to make it more useful to the needs of 

the case study organizations as well as potential future users of this resource. Our recommendations 

focus on opportunities for further improving the usefulness of the tools developed by this project. 

To better educate individuals on the use of these tools, it would be very worthwhile to take a workshop 

approach for the initial working with the templates. This project has demonstrated that the workshop 

approach is more productive than the more typical iterative procedure, in which one person develops 

drafts of templates, and circulates them for review and comment. 

56
In organizing workshops for education in ROI methodology and collection of data for a case study, it is 

extremely important that participants be given a briefing on data requirements prior to conducting the 

workshop. If individual participants are able to bring supporting metrics to the workshop, they will 

receive a better understanding of the process of determining ROI for their projects. The financial analysis 

will thus benefit from the availability of the best possible metrics. 

Agencies can benefit from a clear understanding of the uses of financial analysis at all stages of a 

project’s life. Further work in this area should address the appropriate use of financial analysis at the 

various stages of a project’s life: from making the business case in order to obtain project funding, to 

setting the stage for analysis of project performance, to full historical analysis once full benefits have 

been realized. 

Finally, one area of improvement would be to perform a more in-depth review of each of the 12 

application areas and create more specific templates, or validated benchmarks, that a agency should 

consider when considering an application in that particular area. A second area of improvement would 

be the compilation of sample legal agreements for sharing GIT data and services. GITA will be assessing 

these opportunities in the future based on demand from industry. 

57