INFORMATION TECHNOLOGY MANAGEMENT GUIDE DRAFT
Prepared by THE OFFICE OF INFORMATION RESOURCES MANAGEMENT OFFICE OF ADMINISTRATION OFFICE OF MANAGEMENT OFFICE OF THE DIRECTOR NATIONAL INSTITUTES OF HEALTH
December 1996
12/04/96
NIH IT MANAGEMENT GUIDE
The Information Technology (IT) Management Reform Act of 1996 (i.e., ITMRA or Cohen Bill), which is effective August 8, 1996, places focus on the life cycle management of IT and the processes supported by that technology, rather than simply on the procedures and process used to acquire IT. The Act removes the requirements for obtaining a Delegation of Procurement Authority (DPA) from GSA, the Department of Health and Human Services (DHHS), NIH's Office of Information Resources Management (OIRM), or the Institute, Center, or Division (ICD) for IT acquisitions. It also places an emphasis on the management of IT as a "capital investment" and establishes new requirements related to the management of IT resources that include:
Developing and using performance metrics that measure how well the IT resources used by or acquired by an ICD to support the ICD programs
Determining whether the functions supported by the IT resources should be performed by the private sector
Reviewing planned IT initiatives to ensure that:
high risk or new technology projects receive closer scrutiny and more points of review and evaluation;
out-of-date, ineffective, or inefficient procedures and work processes are not automated; and
they proceed, on a timely basis, toward agreed-upon milestones within the system life cycle, meet user requirements, and deliver intended benefits.
The ITMRA also emphasizes requirements previously established in the Paperwork Reduction Act (PRA) of 1995 and implemented by the Office of Management and Budget (OMB) in revisions to OMB A-130. These requirements include:
IT Planning: Establishing and maintaining a strategic IT management plan that is linked to the agency strategic plan required by the Government Performance and Results Act (GPRA), Public Law 103-62, and ensures that IT resources support the achievement of agreed-upon mission goals;
Cost Benefit Analysis: Preparing an analysis for IT initiatives to demonstrate how the IT resource will meet ICD mission requirements, support ongoing management oversight processes, maximize return on investment and minimize financial and operational risk;
Security Plan: Preparing a plan for the IT initiative to meet security requirements and controls for all information collected, processed, transmitted, stored, or disseminated by the proposed IT resources.
12/04/96
The purpose of this document is to provide guidance to the NIH Institutes, Centers and Divisions (ICDs) in developing and maintaining their IT management processes. Because we have so little experience with the new law, this will be a living document that will change as we gain experience, receive new guidance from OMB or DHHS, and have access to more examples of successful practices and procedures. Comments and suggestions for improving this guide are welcomed anytime.
Much of the information that will assist in establishing a process for ITMRA implementation is available electronically. The OIRM home page has been modified to provide access to an ITMRA home page. The OIRM home page can be accessed through the NIH home page (http://www.nih.gov) by selecting "Institutes and Offices," "Office of the Director," and "Office of Information Resources Management." One of the topics on the OIRM home page will be "Information Technology Management Reform Act (ITMRA)." The ITMRA home page will provide direct access or hot links to a wide variety of ITMRA related information. Some key items are listed below:
The Information Technology Management Reform Act (ITMRA) of 1996.
The July 17, 1996, Executive Order addressing Federal Information Technology (this is almost an executive summary of the Act).
Access to the GSA IT Policy OnRamp that currently has the following items related to ITMRA: access to the following documents that are pertinent to ITMRA implementation:
Letter of July 17, 1996, summarizing the effect of ITMRA on some of the current IT programs and activities managed by GSA's Office of Policy, Planning and Evaluation (Repeal of Brooks Act).
Federal Register Notice abolishing the Federal Information Resources Management Regulation (FIRMR) - Printed July 24, 1996
An Analytical Framework for Capital Planning and Investment Control for Information Technology (a GSA publication)
Access to the OMB Circulars - Pertinent circulars are A-11, A-76, A-94, and A-130.
Access to OMB ITMRA guidance documents
Access to GAO reports - One of current interest is the NASA CIO report
The content of the ITMRA home page will be changed as necessary to provide easy access to the most pertinent ITMRA materials.
The ITMRA introduced several new terms and abolished the legislation that defined several key terms. The following definitions provide the basis for understanding the new IT management process.
The definition of Information Technology (IT) is the same as the definition of Federal Information Processing (FIP) contained in the Federal Information Resources Management Regulations (FIRMR). It includes Automatic Data Processing (ADP) and Telecommunications (TC) hardware, software, services, and support services. The formal definition from the ITMRA is as follows:
INFORMATION TECHNOLOGY - (A) The term information technology', with respect to an executive agency means 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 executive agency. For purposes of the preceding sentence, equipment is used by an executive agency if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that (I) requires the use of such equipment, or (ii) requires the use, to a significant extent, of such equipment in the performance of a service or the furnishing of a product.
(B) The term information technology' includes computers, ancillary equipment, software, firmware and similar procedures, services (including support services), and related resources.
The term information technology' does not include any equipment that is acquired by a Federal contractor incidental to a Federal contract.
IT System - An IT system is the process and procedures that utilizes IT resources to store, process, retrieve or transmit data or information using IT hardware and software.
ADP - IT resources whose primary purpose is the storage, retrieval, and processing of data will be considered ADP. All hardware, software, or services (including support services) resources associated with computers will be considered ADP. For IT management purposes, local area networks (LANs), including the desktop computers, will be considered ADP systems.
Telecommunications - IT resources whose primary purpose is the transfer of information will be considered TC. All hardware, software, or services (including support services) resources associated with telephones, pagers, radios, television, facsimiles or electronic mail will be considered TC.
IT Architecture - Information Technology Architecture means an integrated framework for evolving or maintaining existing information technology and acquiring new information technology to achieve the agency's strategic goals and information resources management goals.
Major IT Initiative - A major IT initiative includes an IT project defined by the ICD as:
Crosscutting - those projects with shared benefit to and impact for more than one component of the ICD. (NIH would consider a project to be crosscutting if it impacted more than one ICD.) and
(High Risk - projects that, by virtue of their size, complexity, use of innovative technology, have a high risk of failure, or High Return - projects that by virtue of their total potential benefits, in proportion to their overall cost, have a significant value to the ICD or the public)
The establishment of, or a major modification of a Local Area Network (LAN), which includes all of the associated hardware, software, and support personnel, would be an example of a major IT initiative.
Major Information System - A system that requires special management attention because of its importance to an ICD mission; its high development operating, or maintenance costs; or its significant role in the administration of ICD programs, finances, property, or other resources. A large infrastructure investment (e.g., major purchase of personal computers or local area network improvements) should also be considered equivalent to a major information system from an investment review perspective.
WORK PROCESS - The personnel and procedures used by an ICD to accomplish a goal or objective that contributes to the accomplishment of the ICD mission.
The basic philosophy of the ITMRA for the management of IT includes the following concepts:
Each ICD should establish effective and efficient capital planning processes for selecting, managing, and evaluating the results of all of its major investments in IT systems.
The IT management process should be integrated with the processes for making budget, financial, and program management decisions within the ICD.
The process should provide for identifying, for a proposed investment, quantifiable measurements for determining the net benefits and risks of the investment.
The process should provide for evaluation of the work process to determine the best place for it to be performed and the best way for it to be performed before the process is automated.
The process should provide the means for senior management personnel of the ICD to obtain timely information regarding the progress of an investment in an information system, including a system of milestones for measuring progress, on an independently verifiable basis, in terms of cost, capability of the system to meet specified requirements, timeliness, and quality.
The acquisition of commercial off the shelf (COTS) IT hardware and software should be handled in the same manner as furniture, supplies, and other types of commodity equipment and materials.
The amount of management activity expended on IT should be commensurate with the size and complexity of the IT activities.
The basic foundation for ICD IT Management program is a management structure that provides an environment that supports the concept of managing IT.
The ITMRA requires each Federal Agency to appoint a Chief Information Officer (CIO). DHHS has appointed a CIO (the Assistant Secretary for Management and Budget) and has asked each of the Operating Divisions to appoint a CIO. The Interim CIO for NIH is the Deputy Director for Management; the Director of OIRM serves as his alternate, and the Director of NIH intends to appoint a permanent CIO that will report directly to the Director. The ITMRA specifies that the CIO will replace the Senior Information Resources Management (IRM) Official in the Paperwork Reduction Act and other existing legislation. It is clear that Congress wants the CIO of an organization to be primarily responsible for managing IT in an organization. ICDs may want to appoint a CIO. Although it is not required, it is strongly recommended that the ICDs ensure that a senior manager have responsibilities similar to those of a CIO. That manager should be responsible for:
Providing advice and other assistance to the Director of the ICD and other senior management personnel of the ICD to ensure that IT is acquired and information resources are managed for the ICD in a manner that is consistent with the ITMRA;
Developing, maintaining, and facilitating the implementation of a sound and integrated IT architecture for the ICD that is compatible with NIH IT architecture standards;
Promoting the effective and efficient design and operation of all major IT processes for the ICD, including improvements to work processes of the ICD;
Monitoring the performance of IT programs of the ICD, evaluate the performance of those programs on the basis of the applicable performance measurements, and advise the head of the ICD regarding whether to continue, modify, or terminate a program or project;
Coordinating with NIH management on the development and implementation of enterprise systems and IT infrastructure projects; and
Participating in the strategic planning and performance evaluation process by:
Assuming responsibility for formulating an IT plan and an IT budget;
Establishing competency requirements for ICD personnel regarding IT knowledge and skill for facilitating the achievement of the performance goals established for IT;
Developing strategies and specific plans for hiring, training, and professional development in order to rectify any deficiency in meeting the competency requirements; and
Reporting to the director of the ICD on the progress made in improving IT capabilities.
The summary of the GAO report on the NASA CIO function will be available through the ITMRA home page. It gives insight on what the GAO is expecting of a CIO in an organization.
One of the key elements of IT management process is an investment review. The ITMRA stresses the importance of reviewing proposed IT investments and proceeding with those most likely to provide the most benefit to the ICD. The DHHS will be using an Investment Review Boards to assist the CIO in the review of proposed IT investments. The DHHS IT Investment Review Board (ITIRB) document can be accessed through the ITMRA home page. It seems clear that some type of review body would be appropriate for major IT initiatives in an ICD. The name, membership and responsibilities of that body would be left to the ICD. The OMB document entitled "Evaluating Information Technology Investments (available on the ITMRA home page) provides guidance on what the review criteria should be, and which investments should be reviewed by the review body.
Many organizations have IRM support activities located in a number of different components of the organizations. That type of management structure may have advantages for the individual components, but may not be the most efficient and effective for the organization as a whole. Some consideration should be given to centralizing some of the IRM functions in an appropriate component of the ICD, or, at a minimum, have IT reporting done through a central focal point.
The ICD IT Management Process should include a standard procedure for addressing IT requirements. OMB's document titled Evaluating Information Technology Investments provides insight into their approach. The GAO report on the NASA CIO Function provided a clear indication of what GAO is looking for in a CIO function and the type of IT management program that agencies should have. There are many different ways to define process that is effective; the steps below address the functions that are considered essential to an effective management process.
The first step is to define the problem. Normally, management perceives a problem with a particular work process that supports or is an integral part of accomplishing the organization's mission. It may be taking too long to process requests, action items may not receive proper attention, or there are too many mistakes being made in processing. The problem should be documented in a manner that clearly defines the problem for everyone involved in finding a solution to the problem. Sometimes the problem may be that the process has been done a particular way for so long that it is time to see if there is a better way of doing it.
The first issue that needs to be addressed is whether or not the organization should be performing the function/work process where the problem, actual or potential, has been identified.
The first question is whether or not the function needs to be performed at all. Does it contribute to the accomplishment of the organization's primary mission?
The next question is whether or not the function should be performed by your organization.
Could this function be combined with another function to increase the efficiency and/or effectiveness of the organization?
Would it be more appropriate for another federal organization to perform the function?
Would it be more appropriate to outsource the function? (A discussion of some of the outsourcing issues is addressed in the summary of the Outsourcing Forum sponsored by GSA, which can be accessed through the ITMRA home page.)
The answer to all of these questions should be documented and, if a cost comparison is necessary, OMB Circular A-76 and its Supplemental Handbook provide guidance on determining costs.
Those documents can be accessed through the ITMRA home page.
The second issue that needs to be addressed is whether or not the work process can be performed more efficiently or more effectively. Many systems were developed to support work processes before some of the current technology was available. The work process needs to be re-examined with a view towards utilizing the latest technology to develop an IT system that will allow management to restructure the work process to increase the efficiency and effectiveness of the process. The work process also needs to be examined to determine if the conditions that existed when the process was established have changed enough to re-examine the utility of the current process. The results of that analysis should be documented.
The work process analysis can range from a quick review of a simple work process to a full business process re-engineering (BPR) project for a complex work process. This activity is technically a new requirement of ITMRA; however; GSA was pushing this concept during the last year or two that it was reviewing agency procurement requests (APRs). BPR is very broad issue and detailed guidance for that is beyond the scope of this document; however, references to BPR information will be made available through the ITMRA home page in the future, and a GSA document on BPR Readiness Assessment is available now.
After a decision has been made to continue to perform the function in the original organization and the work process has been evaluated, the next step is to define the IT requirements for the current or proposed work process. Defining the requirements has been done for many years using the Requirements Analysis format that was used as part of the clearance and delegation process. The format is not important as long as the requirements are clearly and fully defined. GSA published "A Guide for Requirements Analysis and Analysis of Alternatives" in 1990. Federal Information Processing Standard Publication (FIBS PUB) 124, Guideline on Functional Specifications for Database Management Systems may also be helpful in determining the format and content of IT requirements documents. Some of the factors used to determine information requirements are:
Information that is currently being received in the organization
Information that is needed, but is not currently being received
Information that needs to be provided to or obtained from the public and other agencies
Sources that are available to obtain the needed information
Information relationships and outputs (reports)
The requirements for validation, integrity, accuracy, completeness and reliability of the information to be processed or stored
Quantity, timeliness, location and format of information required
The requirements for accessibility, privacy and security of the stored information
Functional processing requirements
Detailed guidance will be provided as we find good examples that have been shown to be successful. The lack of detailed guidance may be part of the reason that requirements have not been defined well in the past.
The requirements for accessibility, privacy and security of the stored information will determine the security measures that will be needed to protect the confidentiality and integrity of the data. A Security Plan, which is a description of how security requirements and controls for all information collected, processed, transmitted, stored, or disseminated by the proposed system will be addressed, must be developed before the system is approved. The DHHS Automated Information Systems Security Program Handbook provides detailed guidance on the development of a security plan (see Chapter IX. Application Systems and Data Security). The DHHS Handbook and other related security information is available by selecting the NIH Systems Security Information item on the OIRM home page. OMB Bulletin 90-08, Guidance for Preparation of Security Plans for Federal Computer Systems Containing Sensitive Information, which can be accessed on the ITMRA home page, may also be useful.
The IT requirements should be developed on the assumption that the IT system will provide a more efficient and/or more effective work process that supports the mission of the organization. Performance measures for the work process should be developed to measure its progress toward accomplishing the mission. This is a requirement of the Government Performance and Results Act (GPRA) of 1993, which has not been fully implemented at this time. As a result, performance measures may not be available for the overall mission of the ICD or the work process that is part of the ICD. Ideally, some indicators that measure the impact of the IT on the mission performance measures would be developed to measure the performance of a proposed system.
Performance measures must be developed for each proposed system, and a method for collecting that information must be established. Most of the performance measures should be indicators of how well the system is meeting the requirements defined for the system. GSA has a Performance Pathways item on its web site that has a significant amount of information that should be helpful in developing performance measures. The ITMRA home page will have a link to that site. NIH personnel that develop performance measures will likely require training before good performance measures are developed. OIRM will be sponsoring training for the development of IT performance measures and will utilize contractor support to develop generic performance measures that can be used at NIH.
The National Academy of Public Administration (NAPA) defines performance measurement as a group endeavor which seeks to improve performance and accountability of an organization, process, program, product, or service through the use of a performance measure process. The key steps they recommend being in a performance measurement process are:
Agree on basic principles for mission, goals and objectives
Brainstorm many ideas for measures
Select the best measures
Take action, i.e., develop a plan and monitor progress
Evaluate and calibrate the measures
Some of the generic performance measures used by private sector firms to account for the value and impact of information technology are:
process/product/service improvement
Cycle time reduction
Customer Satisfaction
Cost-effectiveness
NAPA performed a study for the Department of Defense (DOD) and identified the following generic information management performance measures:
Percent change in life cycle costs
Percent change in work process cycle time
Percent change in acquisition time to deliver an information management product or service
Percent change in functional products/services quality (e.g., fewer errors rates in transactions)
Percent change in satisfied customers
Percent change in major automated information systems projects that are on schedule, within budget, and achieve expected results
Percent change in systems that comply with architectures and standards
Percentage of systems project management staff which meet acquisition and information management education and training requirements
Some of the "Lessons Learned" by NAPA are:
Involve key stakeholders
Focus first on most costly or troubled programs
Develop measures in the context of goal setting and management controls, e.g., plans and budgets
Choose measures that are outcome-oriented, quantifiable, and can demonstrate value
Select a "vital few"
Do not overpromise
Educate and train stakeholders in performance measurements
The justification for the development or major modification of an IT system will be based primarily on an analysis of the cost and the proposed or known benefits of the proposed system. Cost benefit analyses were done as part of the clearance process in the past, and the same basic concepts will apply under the new IT management process; however, there is one major difference. Ideally, the benefits would be based primarily on indicators that measure the impact of the organization's mission performance measures. The key to the cost benefit analysis is to make it commensurate with the size and complexity of the system. If performance metrics are not developed for the work process supported by the IT system, the analysis may have to be done without using impact measures that are easily identified, measured and assigned dollar values. The broad definition of an IT system will allow managers to consider several small systems as one large system or 2 or 3 medium size systems for IT management purposes.
There are a number of documents that provide guidance on cost benefit analysis. The GSA Guide for Requirements Analysis and Analysis of Alternatives addresses cost benefit analysis and references OMB Circulars A-11, Preparation and submission of Budget Estimates, A-76, Performance of Commercial Activities, A-94, Discount Rates to be Used in Evaluating Time-Distributed Costs and Benefits, and A-130, Management of Federal Information Resources. The circulars can be accessed through the ITMRA home page.
The review of the cost benefit analysis should be done by an individual or group with authority to withhold the funding for the project if the justification is not adequate. Systems should be reviewed at the lowest possible level to determine if the plans for development or modification should be implemented. Proposed information systems that potentially impact the users of more than one component of the ICD should be reviewed at the ICD level. All systems are subject to review by NIH, DHHS, and OMB, if it meets their criteria for investment review.
All IT systems should be reviewed by management, at the appropriate organizational level, prior to development or major modification. A schedule should be established to review all operational systems within three years. The investment reviews should focus on the following issues:
Has the work process been evaluated to determine if the organization is best place for the function to be performed, and is the current process the best way to meet the current needs?
Have appropriate performance metrics been developed to measure how well the system supports the mission of the ICD and the ICD component?
Has an adequate cost benefit analysis, commensurate with the size and complexity of the system, been done to determine if the benefits are worth the cost?
Has an analysis been done to determine whether the system should be developed and/or operated in-house or by contractors?
Has a risk analysis been done to determine the appropriate safeguards, and has a security plan been developed for the system?
Is the planned hardware and software in compliance with the NIH IT Architecture (ITA)? If not, is there justification for non-compliance?
Have milestones been established for review of the system to determine if it is on schedule, within budget, and achieving the projected benefits?
The review process should be used to determine which proposed systems should be funded when sufficient funds are not available to support all proposed IT systems. Projects should not proceed until the investment has been approved at the appropriate management level. The depth of the review and the management level at which it is reviewed should be commensurate with the cost and potential impact of the systems.
The DHHS IT Investment Review Board document, referenced in Section 4.2, will provide guidance on how the Department is doing its investment reviews. The OMB guidance is titled "Evaluating Information Technology Investments," and may be accessed via the ITMRA home page. The OMB guidance is quite detailed and makes it very clear what OMB expects from the review process.
Each ICD should develop and update, on an annual basis, IT Planning Documentation (e.g., IT Management Plan, formerly known as the IRM Strategic Plan, and the ITS Budget Submission) that ensures that IT resources support the achievement of agreed-upon mission goals as part of the IT Management Planning process required by the ITMRA, OMB A-11 and OMB A-130. ICDs should develop IT planning documentation that identifies specific information needs identified by ICD programs to address specific major program goals. The IT planning documentation should describe a proposed strategy for addressing the information needs and identify IT requirements to address them. The planning documentation should briefly describe the initiative, how it will support the ICD's mission, and how the ICD will monitor performance. Acquisition planning, which will almost always be required, should begin as soon as the ICD has identified an IT requirement as described in the IT planning documentation.
The key to successful planning and budgeting for IT activities is to integrate the IT planning and budgeting tasks with the other program and management activities. Previous efforts to develop IT plans and budgets as separate activities were not valuable management tools.
OMB Circular A-11 addresses budget submissions to OMB. As new major IT initiatives are identified and incorporated into an ICD's IT Management Plan, the ITS budget should be updated to reflect any changes that might be needed to implement the new or modified IT initiative. OMB has also issued a draft Capital Programming Guide that might be useful developing planning guidance. It is not available electronically at the present time; however, the ICD budget offices should have copies available and it will be available through the ITMRA home page as soon as possible. OMB issued a memorandum dated October 25, 1996 addressing decision criteria for evaluating major information system investments proposed for funding in the FY 1998 President's budget. That memorandum is available on the ITMRA home page.
All IT hardware, software, services and support services should be considered a component of an IT system. Individual acquisitions of IT resources should be justified as part of the review process for IT systems and each individual acquisition would not be subject to additional justification and approval. Individual acquisitions should be reviewed at some level to ensure that they are consistent with the plan that was approved during the investment review.
The ICD should, to the maximum extent practicable, use modular contracting for an acquisition of a major system of information technology. Under modular contracting, an ICD's need for a system is satisfied in successive acquisitions of interoperable increments. Each increment complies with common or commercially accepted standards applicable to information technology so that the increments are compatible with other increments of information technology comprising the system. A contract for an increment of an information technology acquisition should, to the maximum extent practicable, be awarded within 180 days after the date on which the solicitation is issued and, if the contract for that increment cannot be awarded within such period, the increment should be considered for cancellation. The information technology provided for in a contract for acquisition of information technology should be delivered within 18 months after the date on which the solicitation resulting in award of the contract was issued.
When the development or major modification of an IT system has been completed, the performance metrics should be monitored to determine if the proposed benefits of the system are being achieved. The benefits of the system should be formally evaluated on a periodic basis, at least annually. For major information systems. If the expected benefits are not being achieved, action should be taken to modify or abolish the system. This evaluation should be based upon the proposed benefits and performance metrics identified in the cost benefit analyses.
When modular contracting is being used, the progress of the system development should be evaluated at the end of each development phase. If modular contracting is not being used, the system development effort should be evaluated every six months to determine if the project is making adequate progress toward a cost beneficial system.
The ICDs should perform the following liaison functions:
Coordinate review of Major ICD IT initiatives by NIH, DHHS or OMB, as required.
Coordinate with NIH, DHHS, or GAO personnel reviewing ICD IT management activities.
Participate in the development and maintenance of NIH and DHHS IT Management Policies.
A senior manager, or a group of senior mangers, should be responsible for the management of IT within the ICD. Ideally, the Executive Officer or the CIO would be responsible for the ICD IT Management Process. A formal system should be established to monitor the IT investments within the ICD. The system should provide the responsible ICD person(s) accurate and timely information to oversee the ICD IT management process.
If the process delegates review and approval authority to a lower organizational or management level, the process should also provide for a periodic review of the lower level program(s) to ensure that they comply with the ITMRA and other legislation that involves IT resources. The ICD component files should be reviewed to determine whether they include sufficient documentation to support the ICD's decisions to proceed with new systems or modify existing systems. Based on the results of this review, the ICD will, if necessary, make recommendations to the ICD component management on mechanisms to further improve their IT management process.
Home | Search | Index | Map | Comments | Disclaimers | Privacy
Page last updated: 05/09/2000