5 FAH-5 H-620
BENEFIT-COST ANALYSIS (BCA) PROCESS
(CT:ITS-4; 06-21-2012)
(Office of Origin: IRM/BMP/GRP/GP)
(Updated only to revise Office of Origin)
5 FAH-5 H-621 ANALYSTS PERSPECTIVE
(TL:ITS-1; 02-13-2002)
a. The analyst preparing the BCA must follow the 11
structured steps below designed to evaluate proposed alternatives. The steps
are as follows:
(a) Step 1Determine and/or define project objectives;
(b) Step 2Document current process;
(c) Step 3Estimate future requirements;
(d) Step 4Collect cost data;
(e) Step 5Choose at least three alternatives;
(f) Step 6Document BCA assumptions;
(g) Step 7Estimate costs;
(h) Step 8Estimate benefits;
(i) Step 9Discount costs and benefits;
(j) Step 10Evaluate alternatives; and
(k) Step 11Perform sensitivity analysis.
b. The following guidelines describe these steps in
detail and explain the techniques to use in the BCA process. Keep in mind that
the BCA effort must be tailored to the size of the project. The examples
provided herein come from a variety of sources and do not relate to one
specific project.
c. The BCA systematically compares alternative ways of
meeting specific objective. It analyzes and compares costs, benefits, and
uncertainties to determine the most cost effective and beneficial means to
satisfy the objective, regardless of the size of the project. The information
collected, processed, and presented in the 11 steps varies according to the
size of the project. All BCAs must incorporate the following four basic
principles:
(1) Include alternatives that are operationally and
technically feasible to satisfy objectives;
(2) Consider both current and future costs and
benefits;
(3) Consider not only the costs associated with each
alternative but also when the costs will occur. Do this by expressing costs
(and benefits) in present value terms; and
(4) Compare alternatives.
5 FAH-5 H-621.1 Step 1 - Determine
and/or Define Project Objectives
(TL:ITS-1; 02-13-2002)
a. The BCA should include the project objectives and
other pertinent background information so that it stands on its own and can be
understood by a reviewer who is not intimately familiar with the organization
and its work process. The objectives should be designed to improve the work
process so the Department of State can better perform its mission.
b. Need is the foundation of the BCA. State the need
in clear and concise terms; the remainder of the BCA process is based on this
statement.
c. Although it is important for the reader to
understand the project objectives, the crucial issue is that the project
manager and management understand what it is they are trying to accomplish.
d. In some environments, a BCA may be initiated when
management has only generally defined the problem. When that occurs, the time
and effort required to complete the BCA, would be increased significantly.
5 FAH-5 H-621.2 Step 2 - Document
Current Process
(TL:ITS-1; 02-13-2002)
Everyone involved in the preparation and review of the BCA
needs to understand the current process because it is the baseline for nearly
all decisions regarding new alternatives. Therefore, the current process
must be thoroughly documented. The areas to be addressed are:
(1) Customer services; and
(2) System capabilities, technical architecture, and
system costs.
The current documentation should be revised if it does not
address these areas, or does not reflect the current environment. If no
environment is available, it will have to be created.
5 FAH-5 H-621.2-1 Customer
Service
(TL:ITS-1; 02-13-2002)
a. Because every process or IT system provides services
to customers, each customers relationship with the processing organization
should be clearly documented.
b. While this information provides the basis for
identifying benefits, most IT system and operational procedures do not explain
how the services provided to customers help them perform their function faster
and/or better. That question is addressed in 5 FAH-5
H-621.8 Step 8Estimate Benefits.
5 FAH-5 H-621.2-2 System
Capabilities
(TL:ITS-1; 02-13-2002)
System capabilities are the resources required for
providing peak demand customer service. Some examples of system capabilities
are:
(1) 100 megabytes of disk storage space;
(2) Help Desk personnel to support 50 users; and
(3) On-line access to 100 users.
5 FAH-5 H-621.2-3 System
Architecture
(TL:ITS-1; 02-13-2002)
The system architecture includes the hardware, software,
and communication links as well as the physical facilities required for systems
operations. The documentation should go beyond a simple inventory to include
other information necessary for determining systems costs and evaluating the
future utility of individual items. The documentation should indicate whether
items are owned or leased by the U.S. Government, or owned or leased by a contractor.
(1) For hardware, the following information is
desirable:
(a) Manufacturer;
(b) Make;
(c) Model;
(d) Year;
(e) Cost;
(f) Expected life;
(g) Upgradability;
(h) Power requirements;
(i) Maintenance requirements; and
(j) Operating systems supported.
(2) For software, the following information is
desirable:
(a) Manufacturer;
(b) Name;
(c) Version number;
(d) Year acquired;
(e) License term;
(f) Hardware requirements; and
(g) Cost (annual or purchase).
(3) For physical facilities, the following information
is desirable:
(a) Location (address, room number);
(b) Size (number of square feet);
(c) Capacity (number of machines or people);
(d) Type of structure (office, storage);
(e) Availability (how long is it guaranteed?); and
(f) Annual cost.
5 FAH-5 H-621.2-4 System Costs
(TL:ITS-1; 02-13-2002)
The cost of the current system provides the baseline. The
benefit cost analysis must include all elements. The cost element table in 5 FAH-5
Exhibit H-621.2-4 addresses many of the cost elements for most systems. More
detailed information on costs are addressed in Step 7. A particular system may
not include all elements identified within a particular category and may
include some activities not shown.
5 FAH-5 H-621.3 Step 3 - Estimate
Future Requirements
(TL:ITS-1; 02-13-2002)
Future customer requirements determine the system
capabilities and architecture, and ultimately affect system costs and
benefits. Thus, it is important to accurately estimate the future
requirements. The two important items to consider are the system life cycle
and the peak life cycle demands.
5 FAH-5 H-621.3-1 Determine Life
Cycle Time
(TL:ITS-1; 02-13-2002)
a. The first step is to determine how far into the
future to plan. This period is called the life cycle cost horizon or the system
life cycle. The period for the analyses of IT projects should cover the system
life cycle. For this guidance, the system life cycle includes the following
activities:
(1) Initiation;
(2) Design;
(3) Acquisition;
(4) Implementation;
(5) Operations; and
(6) Maintenance.
b. A system life cycle ends when the system is
terminated or is replaced by a system with significant changes in processing,
operational capabilities, resource requirements, or system outputs. Some of
the factors to consider are the speed of hardware and software changes, the
probability of major changes in system requirements, and the estimated costs of
maintaining the system. Large, complex systems should have a life cycle of at
least five years, and the maximum length of time for a BCA should normally be
no more than 10 to 12 years. The system life cycle model (SLCM) presented in
the Managing State Projects (MSP) methodology and 5 FAM 600 provides a
structured framework for developing information systems. The BCA is an
integral part of this framework that first begins in the initiation phase of
the cycle. The table in 5 FAH-5
Exhibit H-621.3-1, System Life Cycle Management, shows the purpose for the
BCA during the various phases.
5 FAH-5 H-621.3-2 Estimate
Life-Cycle Demands
(TL:ITS-1; 02-13-2002)
a. The first step in estimating the user demands over
the system life cycle is to determine the best measures of the demand. Use
those measures to determine what the demands were for several proceeding years,
calculate the change in demand from year to year, average this change, and use
the average to make the predictions. For example, if you have averaged an
increase in demand of 10 percent per year over the last five years, assume that
this trend will continue, and demand will increase by 10 percent every year
over the life cycle of the study. The example in 5 FAH-5
Exhibit H-621.3-2, Average Annual Increase, uses one measure, and
demonstrates a 10% average for the past four years.
b. The danger of this approach is that past history is
not always a high-quality indicator of the future. The mainframe computer
centers that assumed mainframe usage would continue to increase in the 80s at
the same rate as the 70s were not prepared for the PC explosion. Use this
method when external factors have been evaluated to confirm that the past
should be good indicator of the future. Consult staff members who have been
involved with the current system operation for a significant period of time.
c. A second method to determine life-cycle demands is
to survey your customers. The advantage to the survey method is that it can
identify major changes in customer requirements. Another possible outcome to a
survey is that you will find that your customers have problems for which there
is an IT solution. These value added solutions should be noted and
quantified for inclusion under benefits. Surveying your customers properly
requires time and expertise. Surveys must be prepared and evaluated with
extreme care to ensure that the results are interpreted properly.
5 FAH-5 H-621.3-3 Other
Considerations
(TL:ITS-1; 02-13-2002)
a. If possible, make more than one forecast using
different estimating methods. This will serve as a sanity check for the
original forecast and add validity to the overall estimate.
b. Include averages and peak demands in your
estimates. If the system is not designed to meet peak demands, there must be a
good reason (usually cost) not to do so.
c. Use professional experience to temper the results
of any forecast. Do not ignore this experience about future demands and
technology trends. Experience will enable you to identify and explore local IT
issues and trends.
d. Get comments from other IT professionals on your
estimates. Other analysts can point out potential shortcomings in the
estimates or provide confirmation of methods and results.
e. Try for an estimating range in addition to the point
estimate. The point estimate is the basis for developing your alternative
systems, but the high and low values are important for the sensitivity
analysis.
f. Document everything. Good documentation backs up
your estimates, thus minimizing uncertainty during reviews. The documentation
will also facilitate the (inevitable) updates to the estimate.
5 FAH-5 H-621.4 Step 4 - Collect
Cost Data
(TL:ITS-1; 02-13-2002)
Cost data must be collected to estimate the cost and
benefits of each project alternative. Six sources of data are:
(1) Historical organization experience;
(2) Current system costs;
(3) Market research;
(4) Publications;
(5) Analyst judgement; and
(6) Special studies.
This is one of the most difficult steps in a BCA, but also
one of the most important; the quality of your analysis is only as good as the
quality of the cost data.
5 FAH-5 H-621.4-1 Historical
Organization Data
(TL:ITS-1; 02-13-2002)
Historical contract data for an organization can be used
to estimate the future purchase prices of hardware, software, and services. If
contracts were used to provide system support in the past, they can give you
the costs for leasing and purchasing hardware and hourly rate contractor
personnel. Contracts for system support services for other systems in your
organizations or other ICs can provide comparable cost data for the development
and operation of a new system. The numbers will probably need to be adjusted
to account for differing quantities and qualities for the proposed system. If
necessary, adjust the cost to reflect current year price levels. Document all
adjustments for future reference.
5 FAH-5 H-621.4-2 Current System
Costs
(TL:ITS-1; 02-13-2002)
The cost of your current computer system can be used to
price similar alternatives. A study performed by the Department of Housing and
Urban Development (HUD) before their decision to outsource IT functions, for
example, assumed percentage increases and decreases from their current system
when estimating different alternatives. Cost elements were addressed in 5 FAH-5
H-621.2-4 and will be addressed in more detail in Step 7.
5 FAH-5 H-621.4-3 Market Research
(TL:ITS-1; 02-13-2002)
a. Contact several sources to provide cost estimates
for computer hardware, software, networks, user support, outsourcing, etc.
Prepare clear, detailed performance requirements to be the basis for the
estimates. Quotes from multiple sources (if possible) will provide an average
figure that should be a realistic price. Check the technical content and scope
of the quotes: low estimates may be omitting some necessary (and costly)
services. Also, remember that a vendors quote is not usually prepared with
the same level of effort as a bid on a contract.
b. Vendors are usually happy to provide cost
information because it gives them an opportunity to market their services. Be
sure to let them know you are only looking for generic cost data for planning
and analysis purposes, and that no procurement is planned at the present time.
Organizations such as the Gartner Group and IDC Government can also provide
assistance in developing costs data.
c. The Government-wide agency contracts (GWACS) are
also good sources of current cost data for personnel, hardware, and software.
5 FAH-5 H-621.4-4 Publications
(TL:ITS-1; 02-13-2002)
Trade journals and industry publications are good sources
of cost data. Trade journals usually conduct annual surveys that provide
general cost data for IT personnel. Included in this category are government
sources such as the General Services Administration (GSA) pricing schedule.
The supplement to the Office of Management (OMB) Circular A-76 provides
inflation rates and tax rates.
5 FAH-5 H-621.4-5 Analyst
Judgment
(TL:ITS-1; 02-13-2002)
a. In some cases, data may not be available to provide
an adequate cost estimate. In that situation, the best alternative is to use
the judgment and experience of BCA team members to estimate costs. To provide
a check against the teams estimates, discuss them with other IT professionals,
both the government and industry. These discussions can highlight the
strengths and weaknesses of the estimating logic and provide alternative estimates
for comparison. Detailed documentation is important, because it will
facilitate your discussion with others and renders a history for later
verification and validation.
b. Analyst judgment is also a legitimate tool for
evaluating costs obtained through other means. The teams experience and
knowledge must ensure that data gathered from other sources is applicable to
the cost being estimated, and that the data is applied correctly.
5 FAH-5 H-621.4-6 Special Studies
(TL:ITS-1; 02-13-2002)
Special studies are sometimes done to collect cost data
for large IT projects. For example, the State Department, which outsources its
data centers, used three different in-house studies to provide costs for
software conversion, internal operations, and potential benefits. These data
sources became the foundation of the State Departments benefit-cost analysis.
While the number and scope of the studies may seem excessive, the Department
was trying to gather as much information as possible before deciding how to spend
hundreds of millions on automated data processing. Such studies are not
feasible for a quick analysis, but should be considered before committing to
outsourcing or other large, mission-critical projec