This circular establishes the policies and responsibilities
for performing information technology capital planning and investment control
(CPIC) processes throughout the Department of Health and Human Services
(HHS).
Investments in information technology (IT) can dramatically
enhance organizational performance. When carefully managed, IT becomes a
critical enabler to improve business processes, makes information widely
available to all that can benefit from it, and reduces the cost of providing
essential Government services. As IT rapidly evolves, the challenge of realizing
its potential benefits also becomes much greater.
Congress and OMB have clearly stated that each executive agency
must actively manage its IT program to provide assurances that technology
expenditures are necessary 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 contribute 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.
This policy applies to all Departmental system development,
maintenance efforts, and infrastructure computing resources at all levels
of sensitivity, whether owned and operated by HHS, or operated on behalf
of HHS.
This policy supersedes Circular No. IRM - 201, Capital Planning
and Investment Control, dated March 1999.
HHS is required to conform with the Clinger-Cohen Act of 1996
to which this policy conforms. Specifically Section 5122 of the Clinger-Cohen
Act of 1996 (CCA), which states the following:
SEC. 5122. CAPITAL PLANNING AND INVESTMENT CONTROL.
(a) DESIGN OF PROCESS- In fulfilling the responsibilities
assigned under section 3506(h) of title 44, United States Code, the head
of each executive agency shall design and implement in the executive agency
a process for maximizing the value and assessing and managing the risks
of the information technology acquisitions of the executive agency.
The Clinger Cohen Act requires that capital investments related
to IT must be reviewed on an annual basis by the Department CIO. To accomplish
this, each OPDIV shall establish an Information Technology Investment Review
Board (ITIRB) and an ITIRB process in accordance with this policy. Regardless
of the size, complexity, risk, or cost, the same process shall be followed.
All OPDIV expenditures shall follow the process shown in Figure A, "
ITIRB Review Process with Required Products". However, based on the
size, complexity, risk, cost and phase of the IT investment, the granularity
of the detail of the IT investment review, analysis, and documentation will
vary. The highest priority IT investments will then be further reviewed
by the Department CIO to ensure CCA compliance and ensure that HHS is effectively
managing its IT costs and risks associated with HHS mission and infrastructure.
For investments and expenditures that meet or exceed the criteria below,
Department level reviews shall be required.
All OPDIV expenditures that meet any of the criteria Section
4.3 shall provide a Capital Planning and Investment Control Project Summary
(see Figure B, "Capital Planning and Investment Control Project Summary")
to the Office of Information Resources Management for review. This summary
is based on the results of documentation from the OPDIV ITIRB review. OIRM
shall review the summary, and based on size, complexity, cost and risk factors,
OIRM shall then determine whether the OPDIV ITIRB is sufficient to serve
as the Department ITIRB for review or whether a Department ITIRB is required.
Wherever possible, existing documentation shall be used to meet the requirement
for providing documentation to the OPDIV ITIRB and the Department ITIRB.
In making this assessment, OIRM may request, and the OPDIV shall provide,
additional documentation. In addition, each OPDIV CIO shall provide and
certify annually an inventory of all current and future initiatives that
contain an IT component.
All IT expenditures meeting either of the criteria below shall
be presented to the Departmental Information Technology Investment Review
Board (ITIRB):
The Department CIO or Deputy Assistant Secretary for OIRM
retains the discretion to direct that any specific system be brought to
the Department ITIRB.
For all IT investments submitted to the Department ITIRB, the OPDIVs
shall provide a business case and associated products including at least
the following products. At each stage in the ITIRB review process, as
shown in Figure A, " ITIRB Review Process with Required Products",
specific products are to be reviewed.
Each of the elements for a given stage must be addressed.
If they do not apply, the response shall state the reason for non-conformance.
Each system meeting the requirement of Sections 4.2 or 4.3 shall be subject
to the Departmental ITIRB at each review point shown in Figure A, "
ITIRB Review Process with Required Products". For projects not subject
to Departmental ITIRB review, the same review points shown in Figure A,
" ITIRB Review Process with Required Products", shall be applied
by the respective OPDIV, with products produced at the level of specificity
appropriate to the size, complexity, cost and risk of the project. Guidance
for preparing these documents can be found in the attached guidelines.
Each OPDIV shall establish and manage capital planning and
investment control (CPIC) processes and ITIRB review structures in a manner
consistent with the requirements of this policy, including Appendix A: Legislative
Requirements and Guidance for Capital Planning and Investment Control. Requirements
also include:
5. Roles and Responsibilities
5.1 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 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 agency,
including improvements to work processes of the agency.
The CIO is a member of the Federal CIO Council, and chairs
the HHS CIO Council. The CIO also chairs the HHS ITIRB. The HHS CIO is the
final approval authority for the HHS ITIRB.
5.2 The Deputy Assistant Secretary
for Information Resources Management
The Deputy Assistant Secretary for Information Resources Management
(DASIRM) is the vice chair for the HHS ITIRB. The DASIRM shall ensure 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 will serve as the executive secretariat,
preparing agendas, scheduling meetings, and taking notes and minutes of
the proceedings for distribution to the CIO and the Deputy CIO, the OPDIVs,
and OPDIV staff.
The DASIRM formulates and issues policy, requirements, and
procedural guidance for OPDIV use in conducting ODPIV ITIRBs and in preparing
for Departmental ITIRB evaluations, reviews, documentation of status, and
investments in HHS mission critical systems.
The DASIRM is the Deputy CIO, is a member of the Federal CIO
Council, and is the vice chair of the HHS CIO Council. 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.
5.3 The OPDIV CIOs
The OPDIV CIOs shall be responsible for performing capital
planning and investment control (CPIC) for their OPDIV consistent with current
legislation and HHS policy, including establishment of an OPDIV ITIRB. The
OPDIV CIO is responsible for performing functions similar to those of the
HHS CIO and the HHS DASIRM. The OPDIV CIOs are members of the HHS ITIRB.
The OPDIV CIO shall provide material to support system justification to
the HHS Deputy CIO and the pertinent desk officer in advance of an ITIRB
meeting.
Annually, the OPDIV CIO shall provide and certify an inventory
of all current and future initiatives that contain an IT component.
5.4 The Desk Officers
The OIRM desk officers support the DASIRM in his or her role
as the vice chair of the Departmental ITIRB and are the focal point for
working with their OPDIVs on critical IT issues throughout the system life
cycle. These issues include initiatives such as a single HHS ITA, security,
systems development activities, CPIC processes, and Independent Verification
and Validation (IV&V). Each desk officer shall be responsible for having
a thorough knowledge of his or her OPDIV and work collaboratively with the
OPDIVs on CCA issues.
The desk officers shall request and receive documentation
from their respective OPDIVs for designated IT investments. The desk officers
shall analyze the material provided to support the business case for the
system, and make recommendations for action. The OIRM desk officers are
responsible for reviewing IT-related documents, OMB Form 300B and OMB Exhibit
53. The desk officers may attend the Departmental and OPDIV ITIRB meetings
for informational purposes.
5.5 The HHS ITIRB
The HHS ITIRB has the responsibility and authority to review
investments that meet the criteria established in Section 4, "Policy,"
above. The HHS ITIRB will meet at least quarterly to consider new IT system
developments and upgrades, and to review the progress of the already approved
IT development, upgrades, and operations.
The ITIRB shall consist of the CIO, the Deputy CIO, the OPDIV
CIOs, and the Deputy Assistant Secretaries, Grants and Acquisition Management
(OGAM), Finance (OF), Budget (OB), and Human Resources (HR). Key OPDIV program
managers may be invited to discussions affecting their programs. The Deputy
CIO, OPDIV CIOs and the ASMB Deputy Assistant Secretaries will attempt to
reach consensus, and make recommendations for system approval, disapproval
or other action (e.g., suggestions to improve the business case), to the
HHS CIO.
The HHS ITIRB shall submit proposed results and recommendations
of the ITIRB to the HHS CIO, who may accept, alter, or reject the ITIRB
recommendations.
Specifically, the ITIRB members shall:
1. Assess the candidate IT investment by reviewing the
products specific to the current stage as shown in Figure C, "HHS
Capital Planning and Investment Control Checklist".
2. Ensure that the proposed project is in conformance with the HHS ITA.
3. Consider and recommend any necessary emergency system development or
upgrade requests.
4. Assess the adequacy of HHS information asset protection through the
system’s information security (cyber and physical), and fraud and abuse
detection mechanisms, consistent with Federal and Departmental security
policy and guidance.
5. Ensure that security controls and authentication tools to be deployed
are consistent with the protection of personal privacy (i.e., medical
records, human resource documents, and financial statements) as determined
through privacy impact assessments.
6. Evaluate already approved system development, upgrades, baseline operations
and maintenance to ensure continued acceptable performance.
7. Recommend continuation, termination of, or changes to, previously approved
projects.
8. Assess the CPIC processes for "lessons learned" at least
annually.
9. Establish and maintain systems compliance with Section 508 of the Workforce
Investment Act of 1998.
6. Applicable Laws/Guidance
See Appendix A, "Legislative Requirements and Guidance
for 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, (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 affect
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 DATE
Assistant Secretary for Management and Budget
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.
Figure A: ITIRB Review Process
with Required Products
Figure B: Capital Planning
and Investment Control Project Summary
|
|
|
|
Capital Planning and Investment
Control Project Summary
|
|
|
|
|
|
Agency
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bureau
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Project Owner
|
|
|
|
|
|
|
|
|
|
|
|
|
Executive Sponsor
|
|
|
|
|
|
|
|
|
|
|
|
|
Program Activity
|
|
|
|
|
|
|
|
|
|
|
|
|
Name of Project
|
|
|
|
|
|
|
|
|
|
|
|
|
Check One
|
New Project
|
|
|
|
Ongoing Project
|
|
|
|
|
|
|
Was this project approved by an Investment
Control Board (or and Executive Review Committee)?
|
Yes
|
|
No
|
|
|
Is this project a financial management
system?
|
|
|
|
|
|
Yes
|
|
No
|
|
|
If so, what percentage of the system
is financial?
|
|
|
|
|
|
|
|
%
|
|
|
What percentage of the costs are for
security?
|
|
|
|
|
|
|
|
|
|
|
SUMMARY OF SPENDING
FOR PROJECT STAGES
|
|
|
|
|
|
|
|
|
|
|
(In Thousands)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Prior Year-1
& Earlier
|
Prior
Year
|
Current
Year
|
Fiscal Year+1
|
Fiscal Year+2
|
Fiscal Year+3
|
Fiscal Year+4
|
Fiscal Year+5
|
Outyears
|
Total
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Planning
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Est.Budget Authority
|
|
|
|
|
|
|
|
|
|
|
|
|
Actual Budget Authority
|
|
|
|
|
|
|
|
|
|
|
|
|
Outlays
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Full Acquisition
|
|
|
|
|
|
|
|
|
|
|
|
|
Est. Budget Authority
|
|
|
|
|
|
|
|
|
|
|
|
|
Actual Budget Authority
|
|
|
|
|
|
|
|
|
|
|
|
|
Outlays
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Total, sum of stages (excludes maintenance)
|
|
|
|
|
|
|
|
|
|
|
Est.Budget Authority
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
|
Actual Budget Authority
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
|
Outlays
|
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
0
|
|
|
Maintenance
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Est. Budget Authority
|
|
|
|
|
|
|
|
|
|
|
|
|
Actual Budget Authority
|
|
|
|
|
|
|
|
|
|
|
|
|
Outlays
|
|
|
|
|
|
|
|
|
|
|
|
|
|
TOTALS
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
I. MISSION SUPPORT: Describe how
the project supports the core/priority mission functions that need
to be performed by the OPDIV/Bureau. List the organizations, components,
or groups served by this effort. State the authority that entitles
the agency to develop the project or whether the project implements
a legislative requirement.
|
|
II. BUSINESS NEED: Provide a high
level requirements or problem statement used to define the system
design requirements, and define the scope of the problem. Identify
the specific deficiency or need this project will fulfill and resulting
profit or advancement what will be gained when the project is completed.
|
|
III. FINANCIAL AND ALTERNATIVE ANALYSES:
Provide projections on the approach and schedule for completion.
Identify the alternatives, including no action, and other COTS solutions,
developmental solutions and any reasonable combination of hardware,
software and migration/transition solutions. Briefly summarize the
results from the cost analysis, schedule analysis and risk analysis
for each alternative. Show how the project meets Government Performance
and Results Act (GPRA) goals and the OPDIV’s strategic goals.
|
|
GPRA Goal
|
|
Project Objective
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A. Project Alternatives:
|
|
|
|
|
|
|
|
|
|
|
|
1. Enumeration of options and their
projected costs. Include any obvious influence this may have on
costs borne by other HHS organizations:
ð· Option 1: Cost:
ð· Option 2: Cost:
ð· Option 3: Cost:
|
|
2. Describe analysis of alternative
options and identify any underlying assumptions. Provide estimates
of complexity, costs, risks, i.e., rationale for "high,"
"medium," and "low" for each alternative.
ð· Option 1: Briefly
describe
ð· Option 2: Briefly
describe
ð· Option 3: Briefly
describe
|
|
3. Decision: Financial Basis for
Selecting the Project: Summarize the analysis of full life-cycle
costs of ownership: results of cost/benefit analyses, including
return on investment, and any tangible returns that benefit the
Agency but are difficult to quantify.
|
|
B. Adherence to Architecture and
Infrastructure Standards
1. Describe whether the project
is compliant with the Department’s information technology architecture
and technical infrastructure and, if not why not.
2. Identify standards for information
exchange and resource sharing.
3. Demonstrate adherence to government-wide
standards where applicable.
4. Identify use of commercial-off-the-shelf
software (COTS) versus custom, justify custom components.
|
|
C. Describe the Security Plan for
this investment
|
|
|
|
|
|
|
|
|
|
D. Timeline Information: Implementation
Schedule: list milestones and dates
|
|
|
|
|
|
|
|
Fiscal year
|
|
Tasks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
E. Acquisition Strategy
|
|
|
|
|
|
|
|
|
|
|
|
1. Procurement Risk Management
2. Contract Vehicle
3. Summary of Acquisition Strategy
4. Type of Contract(s) Selected and
Selection Rationale
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
F. Actual Performance and Variance
from Approved Baseline (Original or Current):
|
|
|
|
|
|
|
1. Variance in Cost
2. Variance in Schedule
3. Variance in Performance
4. Corrective Actions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
G. Program Management
|
|
|
|
|
|
|
|
|
|
|
|
1. Is there a program manager and contracting
officer devoted to the project? Please name the person.
|
Yes
|
|
No
|
|
|
2. Who is the contracting officer?
|
|
|
|
|
|
|
|
|
|
|
|
3. Will an Integrated Project Team
be established to assist with the Management of the project? If
so, who will be on the team?
|
Yes
|
|
No
|
|
|
H. Please describe any Government
Paperwork Elimination Act (GPEA) initiative
|
|
|
|
|
|
|
|
|
I certify the information presented
is complete and accurate as of the date of my signature.
|
|
|
|
OPDIV CIO Certification Signature
|
Date
|
|
|
|
|
|
|
|
|
|
Figure C: HHS Capital Planning
and Investment Control Checklist
This checklist is provided as guidance both for those preparing
documents for ITIRB review and those conducting ITIRB reviews. This is intended
to be an illustrative but not exhaustive list of questions to answer. It
does not attempt to specify a scoring and ranking system to be used in the
evaluation process.
| |
|
(1) Business need statement
|
|
Stage
Decision Point DP
|
Project Title Selected
|
Provide a project title.
|
|
ALL
|
Project Owner Selected
|
Provide the name of the primary project owner who is responsible
for the day-to day activities.
|
|
DP 2,3
|
Sponsor of the Project
|
State the OPDIV and office that is the primary sponsor or advocate
for the project.
|
|
ALL
|
Lead Component Selected
|
State the office or other component responsible for managing the
project. (The project owner may or may not be the same person as
the sponsor.)
|
|
ALL
|
Project Description
|
Describe the scope and nature for the project. Identify the business
problem (administrative, programmatic, technological, or administrative
savings). Describe how this investment will improve service or result
in programmatic, technological, or administrative savings. Describe
efficiencies and economies of scale.
|
|
ALL
|
Customers
|
List the organizations, components, or groups served by the effort.
|
|
ALL
|
Customer Needs
|
Identify the specific deficiency or need this project will fulfill
and resulting profit or advancement that will be gained when the
project is completed.
|
|
ALL
|
Authority/Mandate
|
State the legal or regulatory authority that entitles the agency
to develop the project. Also state whether the project implements
a current legislative requirement.
|
|
ALL
|
Type of Investment
|
State whether the project is major or non-major.
|
|
ALL
|
Impact of Not Funding
|
If this is a new investment, state the impact of failing to make
the investment; i.e., what opportunity will be lost, or what mandated
change will not be made. If a continuation of a prior year investment,
state what customer system will be negatively affected if the project
is terminated or the funding level is reduced.
|
|
ALL
|
Investment Size
|
Provide any information necessary to explain the funding requirements.
|
|
DP 2,3
|
Period of Performance
|
State the total period of performance for the project.
|
|
DP 2,3
|
Architectural Integration
|
Confirm that the technical strategy complies with the existing
enterprise architecture. Describe any aspects that are not compatible
and what steps are being taken to correct the deviation. List dependencies
with other systems and projects.
|
|
(2) ROI and cost/benefit/alternatives analysis
|
|
DP 2,3
|
Cost-Benefit Analysis
|
State the anticipated outcome of the project in quantifiable terms.
Provide a formal Return on Investment (ROI) on the recommended option.
|
|
(3) &(5) Risk assessment and mitigation plan and economic
sensitivity analysis
|
|
DP 2,3
|
Risk Assessment
|
Provide a risk analysis that describes the factors or events that
can jeopardize the success of the project. Describe any analysis
of these dependencies and identify those events that pose the greatest
risk to the success of the project. Describe the availability of
specific resources (technology, staff, training, etc.). Provide
a risk mitigation plan that addresses the way each risk will be
dealt with if it occurs.
|
|
(4) Technical strategy and plan
|
|
ALL
|
Technical Strategy
|
Describe the overall technical strategy (e.g., mid-tier or mainframe,
COTS, new system, etc.).
|
|
DP 2,3
|
Technical Plan
|
State the basic or underlying technical assumptions regarding project
implementation. State the specific technical approaches and methodologies
that will support your solution.
|
|
(6) Performance measurement plan
|
|
DP 2,3
|
Performance Measures
|
Explain how the progress of the investment, while being implemented,
will be measured. State the final anticipated outcome or level of
performance after implementation. For each performance measure,
state the information collection method and any estimated or anticipated
results.
|
|
(7) Spending and procurement plan
|
|
DP 2,3
|
Detail Information
|
Estimate the funding requirements by cost category and fiscal year.
These categories include hardware, software, telecommunications,
systems development, support and maintenance, staffing travel, training.
|
|
DP 2,3
|
Staffing
|
List the types of staff and the number of hours that they will
devote to this project for the life of the project. Include both
government staff and contractor staff.
|
|
(8) Project plan, schedule and work breakdown schedule
|
|
DP 2,3
|
Project Life Cycle Phases
|
Identify the specific phases of the project. Describe the modularity
of the project. Enumerate the discrete activities and points of
success that exist within the project. State the activities within
each phase of the project.
|
Appendix A: Legislative Requirements
and Guidance for Capital Planning and Investment Controls
The requirements and guidance for capital planning and investment
control include:
(1) The Clinger-Cohen Act (CCA) (includes the Information
Technology Management Reform Act and the Federal Acquisition Reform Act).
The CCA requires the head of each executive agency to design and implement
a process for maximizing the value and assessing and managing the risk
of information technology (IT) acquisitions, development of an information
technology architecture (ITA), and designation of Chief Information Officers
(CIOs).
(2) OMB Circular A-130, Management of Information Resources.
This provides uniform information on information resources management
(IRM) policies required by the Paperwork Reduction Act, in Section 8(b).The
term "major" information system, means an information 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.
(3) OMB Memorandum 97-02, Funding Information Systems
Investments. This guidance memorandum, which is commonly referred to as
the "Raines’ Rules," establishes eight decision rules that OMB
uses to evaluate major information system investments proposed for submission
in the President’s budget.
(4) The Government Performance and Results Act (GPRA).
The GPRA requires agencies to set goals, measure performance, and report
on their accomplishments, and require IT investments to directly support
the accomplishment of these goals.
(5) OMB Circular A-76, Performance of Commercial Activities.
The A-76 establishes policy regarding the performance of commercial activities
and implements the statutory requirements of the Federal Activities Inventory
Reform Act of 1998. The supplement to this circular sets forth the procedures
for determining whether commercial activities should be performed under
contract with commercial sources or in- house, using Government facilities
and personnel.
(6) OMB Circular A-11. Circular A-11 consists of Part
1, entitled "Preparation and Submission of Budget Estimates,"
Part 2, "Preparation and Submission of Strategic Plans and Annual
Performance Reports," and Part 3, "Planning, Budgeting, and
Acquisition of Capital Assets." A supplement to Part 3, "Capital
Programming Guide," is also included.
(7) OMB Circular A-127, Financial Management Systems.
CircularA-127 prescribes policies and standards for executive departments
and agencies to follow in developing, operating, evaluating, and reporting
on financial management systems.
(8) The Joint Financial Management Improvement Program
(JFMIP). The JFMIP encourages and promotes the government-wide sharing
and exchange of information concerning good financial management techniques
and practices. Included are financial management events and training calendars,
listings of best shared practices, project reports, news, announcements,
and meeting minutes.
(9) The Paperwork Reduction Act (PRA). The PRA requires
Federal agencies to define program information needs and develop strategies,
systems and capabilities to meet those needs; the PRA also requires the
development of a five-year strategic plan.
(10) The Chief Financial Officers (CFO) Act. The purpose
of the CFO Act is to bring more effective general and financial management
practices to the Federal Government, and to improve accounting, financial
management, and internal controls, and to provide for complete, reliable,
timely, and consistent financial information.
(11) OMB Circular A-94, Guidelines and Discount Rates
for Benefit-Cost Analysis of Federal Programs. A-94 provides guidance
for conducting cost-benefit and effectiveness analyses, and provides guidance
on the discount rates to be used in evaluating Federal programs whose
costs and benefits are distributed over time.
(12) The Workforce Investment Act of 1998. The Workforce Investment Act
revised Section 508 of the Rehabilitation Act of 1973 by requiring Federal
agencies to ensure that the electronic and information technologies used
in federal programs are accessible to individuals with disabilities to
the same extent as those without disabilities. The Act strengthens Section
508 by imposing strict requirements for any electronic and information
technology developed, maintained, procured, or used by Federal agencies.
Section 508 also establishes mechanisms for enforcing these strict requirements
through civil actions or administrative complaints.
(13) The Federal Acquisition Streamlining Act of 1994 (FASA) requires
OMB to report on the cost, schedule and performance goals for asset acquisitions
and how well agencies are meeting their goals.
(14) Internal Revenue Service Model Information Technology
Privacy Impact Assessment, adopted by Federal CIO Council as model policy.
