 |
|
|
|
|
|
|
|
|
 |
|
HHS IRM Policy for Conducting Information Technology Alternatives AnalysisJanuary 8, 2001HHS-IRM-2000-0002 TABLE OF CONTENTS
1. Purpose This circular establishes the policies and responsibilities for conducting alternative analyses throughout the Department of Health and Human Services (HHS). 2. Background The Clinger Cohen Act (CCA) of 1996, the Chief Financial Officer Act 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 have clearly stated that each Executive agency must actively manage its information technology (IT) program to provide assurances that technology expenditures are necessary, purposeful, and will result in demonstrated improvements in mission effectiveness and customer service. The Clinger-Cohen Act (CCA) legislatively mandates the prudent management of IT investments. One key goal of the CCA is for agencies to develop policies and processes that will result in implementation of systems at acceptable costs, within reasonable and expected time frames, and are contributing to tangible, observable mission performance. These processes must be institutionalized throughout the organization, must ensure compliance with the Department’s Information Technology Architecture (ITA), and will be used for all IT-related decisions. 3. Scope This policy applies to all Departmental (i.e., Operating Divisions’) 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. 4. Policy Each Operating Division (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. The OPDIVs and the Department shall identify designs for alternatives analysis. Each OPDIV shall identify previously conducted alternatives analyses, cost/benefit analyses, or risk/benefit analysis studies that may be used in lieu of conducting its own analysis, if the previous studies are consistent with the OPDIV’s requirements and weighted criteria. An OPDIV shall perform a gap analysis against the previous analysis rather than a complete alternatives analysis, thereby reducing the time and cost of conducting a duplicative study. If previous studies cannot be found, the OPDIV shall inform the Department’s Office of Information Resources Management (OIRM) that 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 alternative 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. The Department shall establish a central list of Department-wide enterprise 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. 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 to determine the cost and benefit of using or expanding the existing system or site operation. To the extent possible, each OPDIV shall utilize existing installations/instantiations to consolidate its computer systems, telecommunications, hardware, software, and staff operations (including grant programs). This approach will reduce overall Departmental costs in facilities, utilities, hardware, software, and staff. It will also reduce the risk of security vulnerabilities and retaining multiple technical staffs. The Enterprise Infrastructure Management (EIM) initiative has conducted a Total Cost of Ownership (TCO) business case for HHS. This analysis includes investments in Framework Event Technology, Network, Systems, Security and Services Event Management, Software Distribution, Asset Management, Change Management, Configuration Management, Performance and Availability, Storage Management, User Account Management, Problem Management, and Knowledge Management. As long as the OPDIV’s investments in these technologies are validated by OIRM to conform with the EIM architecture, standards, 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, security plans, performance measurement plans, and procurement. The OPDIV modules are an addendum or update to the existing EIM documentation rather than a completely separate set of documentation. 5. Roles and Responsibilities The HHS Chief Information Officer (CIO) The CIO is 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 CIO works directly with the CFO to ensure that the Department also complies with the CFO Act and JFMIP. The 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 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. The Deputy Assistant Secretary for Information Resources Management The Deputy Assistant Secretary for Information Resources Management (DASIRM) shall assure that HHS IT investments satisfy the CCA, effectively and efficiently support mission requirements, meet strict efficiency and performance criteria, and conform to the HHS architecture. OIRM shall track and provide a registry of previously conducted alternatives analysis from its roles as the Executive Secretariat of the Department’s ITIRB. OIRM shall provide advice as to the construction of each alternatives analysis 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. The DASIRM 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 is responsible for the architecture and design of EIM. 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. 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. 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 alternative analyses and advice as to the construction of the alternative analyses so that other OPDIVs may benefit from the study in the future. 6. Applicable Laws/Guidance The following Legislative Mandates are applicable: The Clinger Cohen Act of 1996 at URL: www.itpolicy.gsa.gov/itpolicy/2.pdf The CFO Act of 1990 at URL: www.npr.gov/library/misc/cfo.html The JFMIP at URL: http://www.jfmip.gov/jfmip/download/document/01312002_endorsement_letter_final_option.doc HHS-IRM-2000-0001: Capital Planning and Investment Control 7. Information and Assistance 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. 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/__________________________ _01/08/01__ John J. Callahan Glossary Activity - Identifies what needs to be done to achieve a stated mission or purpose, without addressing how it is to be accomplished. Alternative 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. 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. 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. Infrastructure – A sub-structure or underlying foundation; the basic installations and facilities on which information systems depend (i.e., hardware platform, operating system, telecommunications). 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.
|
Last revised: November 20, 2003
 |