HHS IRM Policy for Conducting Information Technology Alternatives Analysis

June 13, 2003

Project: HHS IRM Policy
Document Number: HHS-IRM-2003-0002

Table of Contents

  1. Purpose
  2. Background
  3. Scope
  4. Policy
  5. Roles and Responsibilities
  6. Applicable Laws/Legislation
  7. Information and Assistance
  8. Effective Date/Implementation
  9. Approved
  10. Glossary
  11. Figure A: Sample Weighted-Score Analysis

1. Purpose

In compliance with a request from the CIO, this document establishes the policies and responsibilities for conducting information technology (IT) alternatives analyses throughout the Department of Health and Human Services (HHS).

Alternatives analysis is an essential element of the management review of new, changed, or enhanced programs that contain an IT component to ensure that the development and design approach adequately balances the sometimes conflicting goals of meeting business needs, architecture standardization, and cost control.

2. Background

The Clinger Cohen Act (CCA) of 1996, the Chief Financial Officer Act (CFOA) of 1990, and the Joint Financial Management Improvement Program (JFMIP) require each Department and its agencies/bureaus/operating divisions (OPDIVs) to establish and conform to an enterprise architecture, provide uniform systems, ensure cost effective investments, and deliver systems within reasonable budget and time frames. To comply, HHS has developed an enterprise infrastructure architecture; an enterprise resource planning working group for financial management and procurement; an enterprise human resource and payroll system program; and an enterprise asset management strategy. HHS is also the lead for the Grants Systems Requirements Team for JFMIP.

Congress and the Office of Management and Budget (OMB) have clearly stated that each Executive agency must actively manage its IT program to provide assurances that technology expenditures are necessary, purposeful, and will result in demonstrated improvements in mission effectiveness and customer service.

3. Scope

In accordance with Capital Planning and Investment Control (CPIC) guidelines, this policy applies to all Departmental (i.e., OPDIVs) systems development, maintenance efforts, and infrastructure computing resources at all levels of sensitivity, whether owned and operated by HHS, or operated on behalf of HHS that are classified as mission critical or cross cutting.

4. Policy

4.1. Initiating Products or Services

Each Operating OPDIV Program or Project Office Manager shall determine their business needs, requirements, and weighted selection criteria in concert with the Department’s architecture, requirements, and weighted selection criteria for the kind of product or service under consideration. (See Figure A.) Before investing in establishing or expanding services in a new installation or instantiation, the OPDIV shall conduct a gap analysis of existing systems or sites within and outside its organization that operate the same application and meet the current business needs in order to determine the costs and benefits of using or expanding the existing products or services. To the extent possible, each OPDIV shall utilize existing installations/instantiations to consolidate its computer systems, telecommunications, hardware, software, and staff operations for all programs (including grant programs). This approach will reduce overall Departmental costs in facilities, utilities, hardware, software, services, and staff. It will also reduce the risk of general security vulnerabilities and including risks involved in retaining multiple technical staffs.

4.2. Utilizing Existing Technologies and Systems

HHS has taken an enterprise approach to IT management. This approach includes investing resources in establishing program teams as well as investing in technologies and processes such as Framework Event Technology, Networks, Systems, Security and Services Event Management, Software Distribution, Asset Management, Change Management, Configuration Management, Performance and Availability, Storage Management, User Account Management, Problem Management, Enterprise Directory, Web Portal Development, Network Modernization, and Knowledge Management.

As long as the OPDIV’s investments in these technologies or systems are validated by OIRM to conform with the enterprise architecture, standards, enterprise licenses and products, the OPDIVs can take full advantage of this existing work and shall not be required to conduct and write separate Information Technology Investment Review Board (ITIRB) business cases, alternatives analysis reports, security plans, performance measurement plans, and procurement on the existing technology or system. The OPDIV modules are an addendum or update to the existing enterprise management documentation rather than a completely separate set of documentation. However, when it does not already exist, alternatives analysis shall be conducted to ensure that the existing technology best fits the business needs of the proposed program or project.

4.3. Utilizing Existing Alternatives Analysis

Each OPDIV may choose to identify previously conducted alternatives analyses, cost/benefit analyses, or risk/benefit analysis studies for similar, previously approved programs, technologies, or systems. These may be used in lieu of re-conducting separate analysis, if the previous studies still reflect the current or target architecture, standards, enterprise licensing, security requirements, and are consistent with the OPDIV’s requirements, phase of development within the System Development Life cycle (SDLC), and weighted criteria. An OPDIV shall perform a gap analysis against the previous program’s analysis rather than a complete alternatives analysis study, thereby reducing the time and cost of conducting a partial or complete duplicative study. If previous studies cannot be found, the OPDIV shall inform the Department’s Office of Information Resources Management (OIRM), and the OPDIV shall establish a new alternatives analysis study. The Department shall provide advice as to the construction of the alternatives analysis so that other OPDIVs may benefit from the study in the future. The Department shall also establish a central repository for completed alternatives analyses that shall be submitted by the OPDIVs upon completion. Additional guidance (e.g., compliance with Raines Rules) may be found in HHS IRM Policy 2000-0001: Capital Planning and Investment Control, dated January 8, 2001.

4.4. Utilizing Existing Software Licenses

The Department shall establish a central list of Department-wide enterprise software licenses. If the selected alternative requires the procurement of software licenses, the OPDIV shall utilize an existing enterprise license or work collaboratively with the Department to procure a Department-wide enterprise license.

4.5. Requirements/Responsibilities for Complete Alternatives Analysis

Prior to investing in the establishment or expansion of a new installation or instantiation, the OPDIV shall:

  • Conduct an alternatives analysis, as described in section 4.6, Guidance;
  • Include a gap analysis of functionally similar installations or instantiations that exist anywhere within HHS and its OPDIVs;
  • Use previous alternatives analysis documents that are adequate and recent enough to support the current project;
  • Notify OIRM of the OPDIV’s plan to use a previous alternatives analysis, update a previous alternatives analysis, or conduct a new alternatives analysis;
  • Comply with HHS’ advice regarding conduct of the alternatives analysis to make the analysis broadly beneficial to other OPDIVs and HHS; and
  • Include the alternatives analysis study within the business case submitted for the project.

4.5.1. HHS/OIRM shall:

  • Review OPDIV plans to conduct an alternatives analysis study and advise the OPDIV regarding construction of the study so that other OPDIVs may benefit from it in the future;
  • Review OPDIV alternatives analysis study recommendations for conformance with enterprise architecture, standards, enterprise licenses, and products;
  • Review OPDIV alternatives analysis study recommendations for optimized trade off among architectural conformance, support to business needs, and cost considerations, and provide comments to the OPDIV and the ITIRB.

4.5.2. The ITIRB shall:

  • Select and approve the project approach after reviewing the OPDIV alternatives analysis study recommendations and HHS/OIRM comments on the study.

4.6. Guidance

An alternatives analysis study must include/address the following alternatives and may include others:

  1. Current status quo (do nothing – current baseline),
  2. Integration (partial replacement),
  3. Interfacing (output hand-offs and add ons),
  4. New system (new requirements or full replacement of old system), and
  5. Duplicative efforts (similar systems exist).

If any of the alternatives listed above are not applicable, the study will include a statement to that effect along with an explanation. Additional alternatives may be required (e.g., if there is more than one system integration option or if there are substantially different options for the scope, technical approach, or other aspect of a new system).

4.6.1. Alternatives Analysis Study Report Requirements

The following components are required for a complete study report:

4.6.1.1. SYSTEM OVERVIEW

This section describes the mission and general business needs or requirements of the system to be developed and any schedule, cost, or other constraints that apply.

4.6.1.2. ALTERNATIVES

This section addresses each alternative individually and will include the following elements:

  1. Description. Provide a brief description of the alternative that gives the reviewer a clear picture of the alternative and distinguishes the alternative from each of the others.
  2. Criteria. Assess how each alternative meets or does not meet each of the criteria listed below. Also, provide a numerical rating of how favorably or unfavorably each alternative meets each criterion. Use a scale of 1 to 10 with 10 being highly favorable.
    • Mission. The elements of the OPDIV mission to be supported (i.e., business needs).
    • Requirements. Specific requirements that the new project must support.
    • Schedule. Phasing, durations and milestones.
    • Cost. Full life-cycle costs to include design, development, testing, training, migration, implementation, and operations and maintenance both in total and by fiscal year.
    • Security. Conformance with government and industry security standards.
    • Risk. Assessment of cost, schedule, security, technical, and overall risk.
    • Enterprise Compliance. Conformance with the HHS enterprise approach to IT management (architecture, standards, licenses, migration strategies, etc.).
4.6.1.3. TRADE – OFF ANALYSIS

This section compares and contrasts the individual alternatives considered in the study, which include:

  • Establishing weighted scores for each alternative (See Figure A). The project manager will bring forward the numerical rating of each criterion for each alternative. The project manager will also determine the relative weight to apply to each criterion and develop a brief rationale for the weighting scheme used if other than the one in Figure A. Multiplying each numerical rating by the weight will yield the weighted score for each criterion. Adding the weighted score for each criterion for an alternative will yield a weighted score for the alternative.
  • Selecting alternatives for final comparison. The top scoring alternatives will be selected for further comparison. The cutoff for selection will be determined on a case-by-case basis depending on the distribution of weighted scores.
  • Comparison of alternatives. Determine the pros and cons of each of the selected alternatives, focusing on the analysis criteria.
4.6.1.4. RECOMMENDATIONS

This section presents the recommended alternative, the rationale for the recommendation, and the rationale for not recommending any closely competitive alternatives.

4.7. Format

The alternatives analysis shall be included in the business case of any enterprise wide IT proposal (with no exceptions). The format for the business case is outlined in the HHS- IRM –2000-0001.001Policy for Capital Planning and Investment Control, dated January 8, 2001.

4.8. Selection

The selection of the approved alternative shall occur at the ITIRB. The ITIRB consists of the HHS CIO, all OPDIV CIOs, and the five Deputy Assistant Secretaries: Human Resources, Acquisition, Finance, Budget, and Technology. The alternatives will be discussed and selected under the leadership of the HHS CIO, who presides over the ITIRB.

5. Roles and Responsibilities

5.1. The Deputy Assistant Secretary for Information Resources Management (DASIRM)/HHS Chief Information Officer (CIO)

Through the combination of roles, the Deputy Assistant Secretary for Information Resources Management (DASIRM) also assumes the responsibilities of the Chief Information Officer (CIO), which includes being responsible for providing advice and assistance to the Secretary and other senior management personnel to ensure that information technology is acquired and information resources are managed for the agency in a manner that implements the policies and procedures of the CCA.

The DASIRM/CIO shall assure that HHS IT investments effectively and efficiently support mission requirements, meet strict efficiency and performance criteria, and conform to the HHS architecture. The DASIRM/CIO formulates the Department’s IT goals and strategies for defining measures of success for assessing and evaluating IT use and reporting the status of the Department’s IT programs. The DASIRM/CIO is responsible for the design and implementation of the enterprise architecture.

The DASIRM/CIO works directly with the CFO to ensure that the Department also complies with the CFO Act and JFMIP. The DASIRM/CIO is also responsible for developing, maintaining, and facilitating the implementation of a sound and integrated information technology architecture, and promoting the effective and efficient design and operation of all major information resources management procedures and processes for the Department.

The Office of Information Resources Management (OIRM) shall develop and maintain a repository of previously conducted alternatives analysis in its roles as the Executive Secretariat of the Department’s ITIRB. OIRM shall provide advice as to the construction of each alternatives analysis study so that other OPDIVs may benefit from the study in the future. OIRM shall work collaboratively with the OPDIVs to procure a Department-wide enterprise license.

5.2. The HHS Chief Financial Officer (CFO)

The CFO is responsible for providing advice and assistance to the Secretary and other senior management personnel to ensure that financial resources are managed for the agency in a manner that implements the policies and procedures of the CFO Act and JFMIP. The CFO is responsible for ensuring that the Department receives a clean financial opinion annually. The CFO shall review all documentation submitted to the ITIRB that pertains to financial systems and mixed systems which are partially financial.

5.3. The OPDIV CIOs and OPDIV Program or Project Managers

The OPDIV CIOs shall be responsible for performing ITIRB reviews of OPDIV-level program business cases, alternatives analyses, and other specific investment documents. The OPDIV CIOs, supported by OPDIV Program or Project Managers, shall be responsible for ensuring that this IRM policy is implemented for all programs or projects within their OPDIVs. Department level ITIRB criteria are described in both CCA and the Capital Planning and Investment Control Policy, HHS IRM 2001-0001.001, dated January 8, 2001.

5.4. The OIRM Desk Officers

The OIRM Desk Officers are the focal point for working with their OPDIVs on critical IT issues throughout the system life cycle. OIRM Desk Officer are responsible for budget review of exhibits 300 and 53 (OMB Circular A-11), information collection in compliance with the Paperwork Reduction Act (PRA) and Government Paperwork Elimination Act (GPEA) as well as information dissemination and records management. OIRM Desk Officers also serve as staff under the DASIRM/CIO and manage programmatic issues for CIO Council assignments and presentations and /or ITIRB requests and approvals.

The Desk Officers shall request and receive documentation from their respective OPDIVs regarding compliance with this IRM policy. The Desk Officers shall provide information to the OPDIVs regarding previously conducted alternatives analyses and advice as to the construction of the alternatives analyses so that other OPDIVs may benefit from the study in the future.

6. Applicable Laws/Legislation

The following Legislative Mandates are applicable:

7. Information and Assistance

Please direct questions, comments, suggestions, or requests for further information to the Deputy Assistant Secretary for Information Resources Management at (202) 690-6162.

8. Effective Date/Implementation

The effective date of this policy is the date the policy is approved. It supercedes the January 8, 2001 HHS IRM Policy for Conducting Information Technology Alternatives Analysis.

The HHS policies contained in this issuance shall be exercised in accordance with Public Law 93-638, the Indian Self-Determination and Education Assistance Act, as amended, and the Secretary's policy statement dated August 7, 1997, as amended, titled "Department Policy on Consultation with American Indian/Alaska Native Tribes and Indian Organizations." It is HHS' policy to consult with Indian people to the greatest practicable extent and to the extent permitted by law before taking actions that effect these governments and people; to assess the impact of the Department's plans, projects, programs and activities on tribal and other available resources; and to remove any procedural impediments to working directly with tribal governments or Indian people.

9. Approved

/s/ Kerry Weems
Kerry Weems
Acting Assistant Secretary, Budget, Technology, and Finance

June 13, 2003
Date

Glossary

Activity - Identifies what needs to be done to achieve a stated mission or purpose, without addressing how it is to be accomplished.

Alternatives Analysis - An evaluation of scenarios and design paths for meeting a general set of system design requirements described in a Business Need Document, or a specific technical/architectural issue. This evaluation presents alternatives, which include assessments of current system functionality and design that may satisfy some of the requirements as well as the functionality that may impact the interfaces with other systems. A set of evaluation criteria is used to weight the various alternatives against each other and provide a recommendation for the analysis.

Architecture - The organizational structure of a system or component (IEEE 90).

Baseline - A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control authority.

Business Case – A structured proposal for a business need that serves as an investment decision package to improve business operations. A business case consists of a business need, and a technical evaluation.

Business Need – Any request at a high or low level to improve, change, update, or add new systems that facilitate the agency’s missions, goals and objectives.

Business Need Document – A document is submitted by an individual or an organization. This document describes a request for a system change, system improvement, or a new system and provides the information required by the engineering community to develop a change or a new system.

Capital Planning – A discipline used by management to reduce the risk and increase the return associated with making investments of capital assets.

Change Request – The change instrument used to identify changes affecting the functional baselines and cost, schedule, and contractual data associated with information systems baselines. Change requests may also be used to identify changes from subordinate configurations that impact baselines outside their authority.

Enterprise – The entire agency and /or its components.

Gap Analysis – A comparison of the current system functionality against the proposed system requirements. If the proposed system exceeds the requirements or current system functionality, there is added value.

Impact Assessment – An analysis to determine the effect of a change to a current or new developmental system with the purpose of evaluating how the proposed change affects the target technical, cost, and schedule.

Information System – A discrete set of information technology, data, and related resources, such as personnel, hardware, software, and associated information technology services organized for the collection, processing, maintenance, use, sharing, dissemination or disposition of information.

Information Technology – Any equipment or interconnected system or subsystem of equipment, that is used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission or reception of data or information by the agency. . For purposes of this definition, equipment is “used” by an agency whether agency uses the equipment directly or it is used by a contractor under a contract with the agency which (1) requires the use of such equipment or (2) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product. Information technology includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources. It does not include any equipment that is acquired by a Federal contractor incidental to a Federal contract.

Infrastructure – A sub-structure or underlying foundation; the basic installations and facilities on which information systems depend (i.e., hardware platform, operating system, telecommunications).

Instantiation – To represent by a concrete occurrence.

Investment Control – Management investment oversight activities to monitor projects under development and operational systems to ensure that the cost, risk, and performance criteria used to select the investments are being achieved. Corrective actions and project continuation decisions are made based on periodic monitoring.

Legacy System – An established computer system that is currently operational and supports existing business functionality.

Maintenance – The set of activities which result in changes to the originally accepted baseline product set, in order to keep the system functioning in an evolving, expanding user and operational environment.

Major IT System – A system that requires special management attention because of its importance to an agency mission; its high development, operating, or maintenance costs; or its significant role in the administration of agency programs, finances, property, or other resources. Large infrastructure investments (e.g. major purchases of personal computers or local area network improvements) should also be evaluated against these criteria.

Net Present Value –Net present value (NPV) analyses are used to compare investment alternatives that occur over multiple years. Present Value requires that all quantifiable benefits and costs are brought back to current day dollar values, so that various alternatives can be compared directly.

Performance – The degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage (IEEE 90).

Phase – A level of the system life cycle that generally specifies major activities, products, reviews and organizations, roles and responsibilities; and that establishes the level of detail and establishes product accountability.

Pilot – The period of time, at a specific pilot site, when a system is delivered, installed, integrated, and tested in an actual production environment against customer requirements.

Pre-Coordination – Notification that a request is being considered for submission, but certain information is needed from stakeholders to determine whether the request will be submitted.

Process – an organized set of activities with defined inputs and outputs, performed to achieve a stated purpose.

Product – Anything used or produced to satisfy a need, for example, facilities, systems hardware, software, firmware, data, processes, materials, or services.

Program Area – A representation of customer organizations.

Program Management – The planning, organizing, directing, and controlling of the resources and schedules which coordinate the prioritization and sequencing of a collection of similar, or interdependent projects.

Release – A grouping of actual software and hardware upgrades, improvements, enhancements, replacements, new business, and information systems capabilities, as well as retirement of legacy systems.

Requirements Analysis - A problem-solving activity that involves studying the ways an organization currently retrieves and processes data to produce information, identifies any problem areas, and considers how the users’ needs might best be satisfied.

Requirements Management – The activities or processes that assess, refine, and prioritize business needs to address the requirements of the changing business environment, to establish and maintain an up-to-date understanding between business needs and the development organizations regarding the requirements to be addressed by the delivered product.

Return on Investment – Return on Investment (ROI) of the project shows how much the project benefits the organization in comparison to cost savings or cost avoidance.

Review – A formal evaluation procedure issued to determine the correctness of the products developed during a system life cycle phase.

Stakeholders – Individuals, organizations, review boards, and committees with vested interest in the result of a decision, process, review, or activity.

System - One or more of the following: (1) an integrated composite of people, products, and processes that provide a capability to satisfy a need or objective [MIL-STD-499B]; (2) an assembly of things or parts forming a complex or united as a whole; a collection of components organized to accomplish a specific function or set of functions; (3) an interacting combination of elements, viewed in relation to function [INCOSE95]. A system may be a product that is hardware only, hardware/software, software only, or a service. The term “system” is used to indicate the sum of the products being delivered to the customers or users of the products. See also the definition of information system.

System Life Cycle – A structured development approach with defined activities, phases, products, and reviews providing a standard to support the development of systems from identification of a business need through implementation, operation, maintenance, and eventual retirement.

System Requirement – A function or characteristic of a system that is necessary, or the quantifiable and verifiable behaviors that a system must possess, and constraints that a system must work within to satisfy an organization’s objectives and solve a set of problems.

Technical Evaluation – Activities to appraise the technical solutions and associated costs and schedules presented by a customer. The major activities include technical analysis on proposed solutions with cost and schedule, architecture impact analysis to determine the solution’s impact, and technical evaluation review presenting technical evaluation to stakeholders for approval.

Trade-Off Analysis – A method of determining the risk analysis and requirement satisfaction within certain constraints (trade-offs) in order to select an alternative.

Weight – A factor that quantifies the relative importance of a criterion within a group of criteria. The weight is a whole number between 1 and 100 (with 100 being most important). A criterion with a weight of 50 would be half as important as one with a weight of 100. The greater the range of weights within a set of criteria, the more useful the analytical exercise will be.

Figure A: Sample Weighted-Score Analysis

Criteria Weight Current Rate Current Score
(Weight x Rate)
Integration Rate Integration Score
(Weight x Rate)
Interfacing Rate Interfacing Score
(Weight x Rate)
New Rate New Score
(Weight x Rate)
Duplicative Rate Duplicative Score
(Weight x Rate)
Mission

 

100 4 400 6 600 7 700 9 900 6 600
Requirements 90 2 180 4 360 7 630 10 900 7 630
Schedule 60 10 600 8 480 7 420 5 300 6 360
Cost 70 10 700 7 490 4 280 2 140 5 350
Security 80 1 80 3 240 5 400 9 720 7 560
Risk 70 3 210 5 350 6 420 9 630 4 280
Enterprise Compliance 90 1 90 4 360 4 360 8 720 3 270
Total Weighted Score 560 31 2,260 37 2,880 40 3,210 52 4,310 38 3,050
Content created by Office of the Chief Information Officer (OCIO)
Content last reviewed