TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION

 

 

Affordable Care Act – The Income and Family Size Verification Project:  Improvements Could Strengthen the Internal Revenue Service’s New Systems Development Process

 

 

 

March 29, 2013

 

Reference Number:  2013-23-034

 

 

This report has cleared the Treasury Inspector General for Tax Administration disclosure review process and information determined to be restricted from public release has been redacted from this document.

 

Phone Number  /  202-622-6500

E-mail Address /  TIGTACommunications@tigta.treas.gov

Website           /  http://www.treasury.gov/tigta

 

 

HIGHLIGHTS

AFFORDABLE CARE ACT – THE INCOME AND FAMILY SIZE VERIFICATION PROJECT:  IMPROVEMENTS COULD STRENGTHEN THE INTERNAL REVENUE SERVICE’S NEW SYSTEMS DEVELOPMENT PROCESS

Highlights

Final Report issued on March 29, 2013

Highlights of Reference Number:  2013-23-034 to the Internal Revenue Service Chief Technology Officer.

IMPACT ON TAXPAYERS

In March 2010, the President signed into law the Patient Protection and Affordable Care Act (ACA) to provide more Americans with access to affordable health care by January 1, 2014.  The Income and Family Size Verification (IFSV) Project is a core project of the ACA Program and will support open enrollment beginning in October 2013.  The IFSV Project is important to the functionality and success of the ACA Program because it is responsible for developing a solution that will verify income and family size, based on tax return data, for determining an individual’s eligibility for the advanced premium tax credit for health insurance. 

WHY TIGTA DID THE AUDIT

This audit was initiated to determine whether the IRS adequately managed systems development risk for the IFSV Project.  Specifically, TIGTA evaluated whether the IFSV Project adequately managed project management risk related to the new Iterative Path of the Enterprise Life Cycle and whether the IFSV Project developed a security plan to protect taxpayer data.  To accomplish these objectives, TIGTA reviewed high-risk areas related to the IRS applying the new Iterative Path to the IFSV Project as its systems development life cycle rather than a traditional sequential life cycle (e.g., Waterfall Systems Development Life Cycle Path).  TIGTA also considered information technology security documentation for the IFSV Project.

WHAT TIGTA FOUND

By the end of August 2012, the IFSV Project had completed all six systems development components, each delivering a piece of approved functionality.  While cost data specific to the IFSV Project were not readily available during this audit, the IRS is generally managing systems development risk areas with the implementation of the new Iterative Path within the Enterprise Life Cycle.  However, process improvements are needed to better ensure that (1) the IFSV Project team adheres to configuration management guidelines when baselined requirements are changed and (2) the ACA Program Configuration Control Board emergency meeting processes are effectively communicated.  Further, an integrated suite of automated tools could improve requirements management and testing for the IFSV Project.

WHAT TIGTA RECOMMENDED

TIGTA made three recommendations to the Chief Technology Officer.  In management’s response to the report, the IRS agreed with our first two recommendations and plans to implement corrective actions for both.

However, the IRS disagreed with our third recommendation to implement a standard suite of integrated, automated tools for the ACA Program and ACA projects to manage sprint processes, develop and manage requirements, develop and manage test cases, and bidirectionally trace requirements and test cases.  Notwithstanding the IRS’s response, TIGTA believes that an action plan to address this recommendation would permit the IRS to better ensure long-term success for the IFSV Project along with the many other information technology components and systems supporting new functionality and transactions required to address its mission-critical capabilities under the ACA.

Lastly, the IRS disagreed with the statement in the report that cost data were not readily available during the audit.  TIGTA maintains that cost information was not readily available because it took the IRS 28 business days to provide basic budget and cost data.

 

March 29, 2013

 

 

MEMORANDUM FOR CHIEF TECHNOLOGY OFFICER

 

FROM:                       Michael E. McKenney /s/ Michael E. McKenney

                                         Acting Deputy Inspector General for Audit

 

SUBJECT:                  Final Audit Report – Affordable Care Act – The Income and Family Size Verification Project:  Improvements Could Strengthen the Internal Revenue Service’s New Systems Development Process (Audit 201220312)

 

This report presents the results of our review of how the Income and Family Size Verification Project managed the new Iterative Path as its systems development life cycle.  The overall objective of this review was to determine whether the Internal Revenue Service (IRS) is adequately managing systems development risk for the Income and Family Size Verification Project under the Affordable Care Act Program.  This audit was included in the Treasury Inspector General for Tax Administration Fiscal Year 2012 Annual Audit Plan and addresses the major management challenge of Implementing Major Tax Law Changes.

We request that the IRS Acting Commissioner submit, within 30 calendar days of the final report issuance date, a written reply regarding the disagreed recommendation to the Assistant Secretary for Management and Chief Financial Officer of the Department of the Treasury, with a copy to the Treasury Inspector General for Tax Administration.

Management’s complete response to the draft report is included as Appendix V in the attached PowerPoint presentation.

Copies of this report are also being sent to the IRS managers affected by the report recommendations.  Please contact me or Alan Duncan, Assistant Inspector General for Audit (Security and Information Technology Services), if you have questions.

 

Attachment

 

TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION

 

Affordable Care Act – The Income and Family Size Verification Project: Improvements Could Strengthen the Internal Revenue Service’s New Systems Development Process

 

March 29, 2013

 

 

Reference Number: 2013-23-034

 

 

This report has cleared the Treasury Inspector General for Tax Administration disclosure review process and information determined to be restricted from public release has been redacted from this document.

 

 

Phone Number / 202-622-6500

E-mail Address / TIGTACommunications@tigta.treas.gov

Website / http://www.treasury.gov/tigta

 

 

Table of Contents

Background

Audit Objective

Results of Review

The IFSV Project Is Generally Managing Systems Development Risk Areas

The IFSV Project Did Not Always Adhere to Configuration Management Guidelines

Recommendation 1:

Communication of Configuration Management Processes Would Improve Implementation of the Iterative Path

Recommendation 2:

An Integrated Suite of Tools Could Improve Requirements Management for the IFSV Project

Recommendation 3:

Appendices

Appendix I – Detailed Objective, Scope, and Methodology

Appendix II – Major Contributors to This Report

Appendix III – Report Distribution List

Appendix IV – Glossary of Terms

Appendix V – Management’s Response to the Draft Report

Abbreviations

Abbreviation

Description

ACA

Affordable Care Act

CCB

Configuration Control Board

ELC

Enterprise Life Cycle

IFSV

Income and Family Size Verification

IRS

Internal Revenue Service

PMO

Program Management Office

TIGTA

Treasury Inspector General for Tax Administration

 

Background

¨  In March 2010, the President signed into law the Patient Protection and Affordable Care Act (ACA)1 to provide more Americans with access to affordable health care by January 1, 2014.

¨  Much of the ACA is funded by changes to the tax law. As the Federal agency that administers the tax laws, the Internal Revenue Service (IRS) will administer the tax provisions included in the ACA legislation.

¨  The IRS ACA Information Technology Program Management Office segmented implementation of the ACA into various releases.

¨  Figure 1 provides a brief description of the ACA releases.

 

1 Pub. L. No. 111-148, 124 Stat. 119 (2010) (codified as amended in scattered sections of the U.S. Code), as amended by the Health Care and Education Reconciliation Act of 2010, Pub. L. No. 111-152, 124 Stat. 1029.

 

Figure 1: Description of ACA Releases

ACA Release

Go Live Date

Description

ACA 1.0

In Production

January 2011

Includes the functionality of several ACA provisions, e.g., the Small Business Healthcare Tax Credit and the Charitable Hospital Reporting provisions.

ACA 2.0

In Production

July 2011

Includes functionality to support the Branded Prescription Drug provision of the ACA.

ACA 3.0

October 2013

Includes the functionality of the following ACA process areas: Eligibility and Enrollment, Customer Service, Reporting, and Non-Exchange.

ACA 4.0/4.1

January–October 2014

This release will build on the transactional and bulk data processes established in ACA 3.0, will expand the breadth of data stored in the data repository, and will enhance reporting capabilities.

ACA 5.0

June 2015

Includes the functionality of at-filing compliance.

ACA 6.0

December 2015

Includes the functionality of post-filing compliance.

Sources: Affordable Care Act Program Baseline Requirements, Solution Architecture and IT Roadmap, Version 2.2; Affordable Care Act Program Management Office Program Management and Integration Plan, Version 1.0; and the Implementing Tax Law Changes From the Affordable Care Act in the IRS Information Technology Briefing dated August 27, 2012.

 

¨  ACA 3.0 is focusing on the Eligibility and Enrollment process area. As part of ACA 3.0, the Income and Family Size Verification (IFSV) Project will support open enrollment and is one of six core ACA Program projects being implemented in October 2013.

¨  Based on tax return data, the IFSV Project will verify income and family size for individuals requesting eligibility for an advanced premium tax credit for health insurance.

¨  Due to ongoing interpretation of provisions established by the ACA legislation, the IRS decided to apply the new Iterative Path to the IFSV Project as its Systems Development Life Cycle, rather than a traditional sequential life cycle (e.g., Waterfall Systems Development Life Cycle Path).

¨  The new Iterative Path of the Enterprise Life Cycle (ELC) is considered an agile2 approach to systems development and is suited for projects that change quickly and have requirements that are undefined. The Iterative Path facilitates development of the defined requirements while other requirements are being established.

¨  Under the new Iterative Path, a process known as “sprints” develops a piece of functionality of the system with repeated cycles of requirements discovery, planning, design, development, and testing.

 

2 The IRS applies the term “agile” to represent a type of software development methodology based on iterative and incremental methods that promotes teamwork, collaboration, and process adaptability throughout the life-cycle of the project.

 

¨  Benefits expected by the ACA Program Management Office (PMO) with the implementation of the Iterative Path include:

o   Increased collaboration between stakeholders and the information technology development team.

o   Incremental functionality and shorter time periods through sprints.

o   Better alignment between the product and stakeholders’ requests.

¨  The IFSV Project is being developed primarily by IRS employees within the ACA PMO.

¨  Cost data specific to the IFSV Project were not readily available during our audit.

 

Audit Objective

 

¨  Determine whether the IRS is adequately managing systems development risk for the IFSV Project under the ACA Program.

o   Evaluate whether the IFSV Project is adequately managing project management risk related to the new Iterative Path of the ELC.

o   Determine whether the IFSV Project has developed a security plan to protect taxpayer data and whether Federal requirements have been considered.

Results of Review

 

¨  The IFSV Project Is Generally Managing Systems Development Risk Areas.

¨  The IFSV Project Did Not Always Adhere to Configuration Management Guidelines.

¨  Communication of Configuration Management Processes Would Improve Implementation of the Iterative Path.

¨  An Integrated Suite of Tools Could Improve Requirements Management for the IFSV Project.

 

The IFSV Project Is Generally Managing Systems Development Risk Areas

 

¨  The IFSV Project is generally managing risk areas when using the new Iterative Path of the ELC. Specifically, in the areas of:

o   Stakeholder involvement – Stakeholders are committed to the new Iterative Path process, embedded in the IFSV Project team, and involved on a continuous basis by providing feedback to the project team.

o   Project planning activities – The IFSV Project conducted sprint planning activities to identify and prioritize requirements to be coded and tested and received stakeholder agreement on tasks to be completed during a sprint.

o   Sprint systems development and testing activities – Controls are in place to ensure that requirements are coded and tested during a sprint and that stakeholders approve sprint results prior to starting the next sprint.

o   Iterative Path lessons learned – The IFSV Project incorporated lessons learned from a prior ACA project that piloted the new Iterative Path methodology.

¨  A security plan intended to protect taxpayer data was developed that incorporated Federal Information Security Management Act and National Institute of Standards and Technology guidelines.

¨  The IRS informed us that governance models, including Control Objectives for Information Technology, were considered and evaluated to complement the IRS’s ELC to provide a control framework for the design and development of all IRS information technology projects. We performed a limited assessment of the overall ELC control framework for the IFSV Project.

¨  By the end of August 2012, the IFSV Project had completed all six scheduled sprints, each developing a piece of approved functionality including receiving and validating requests for household income verification and family size, locating tax records based on information in the requests, and calculating individual and household modified adjusted gross income.

¨  The IRS is currently conducting project integration testing of ACA 3.0, which includes the IFSV Project.

 

The IFSV Project Did Not Always Adhere to Configuration Management Guidelines

 

¨  The ACA Program Configuration Management Plan requires that a change request and impact assessment be prepared and approved to change baselined requirements.

¨  We judgmentally sampled3 and reviewed six of 19 total IFSV Project change requests as of July 5, 2012. We selected these six because they were designated by the IRS as critical.

¨  We determined these six critical change requests were processed in accordance with the configuration management guidelines.

¨  We also judgmentally sampled and reviewed six of 61 baselined requirements to determine whether possible changes to the requirements adhered to configuration management guidelines. We selected six baselined requirements, which are each important to the basic functionality of the IFSV Project. A change request and impact assessment should be prepared for every changed requirement.

3 A judgmental sample is a nonstatistical sample, the results of which cannot be used to project to the population.

 

¨  Four of the six baselined requirements that we sampled were changed. Our review determined that the IFSV Project team did not adequately prepare a change request and an impact assessment for one of these four requirements.

¨  Specifically, the change request4 and impact assessment did not include the requirement or address the potential impact of the change on other ACA requirements.

¨  If configuration management guidelines are not properly followed, IRS management may not be able to determine the potential impact of changed requirements on IFSV Project requirements, other ACA projects, and system functionality. As a result, all functionality may not be properly developed, which could negatively impact ACA Program deployment.

¨  Management Action: Once we advised the IFSV Project Manager of this finding, a change request and impact assessment were prepared and approved during our audit fieldwork.

4 This change request for a baselined requirement is intended to ensure that if any Social Security Administration Name Control in the Health and Human Services’ request does not match the Name Control in the National Account Profile record by Taxpayer Identification Number, the IFSV shall not provide tax record information for any applicant listed on the request.

Recommendation

 

¨  Recommendation 1: The Chief Technology Officer should complete a broader review to evaluate the effectiveness of existing controls to ensure that change requests and impact assessments are adequately developed and processed as required by the ACA Program Configuration Management guidelines.

¨  Management’s Response: The IRS agreed with this recommendation. The IRS plans to conduct a review across the ACA PMO to evaluate the effectiveness of existing controls for change requests and impact assessments.

Communication of Configuration Management Processes Would Improve Implementation of the Iterative Path

 

¨  The ACA Program Configuration Management Plan outlines change management processes for the ACA Program and projects.

¨  The IFSV Project uses this plan as the primary guidance for change management. Guidance states that proposed changes to baselined requirements are submitted via change requests.

¨  The ACA PMO informed us that emergency Program Configuration Control Board (CCB) meetings have been convened, when needed, to review and approve proposed change requests.

¨  The ACA Program CCB Charter states that the Program CCB may meet monthly or convene emergency meetings to review and approve proposed change requests. However, the IFSV Project team expressed concern over the Program CCB’s untimely response to an important change request5 during our review.

5 This change request recommended that IFSV directly interface with the ACA Coverage Data Repository.

 

¨  Further, the ACA Program Configuration Management Plan does not include procedures for a project to request an emergency Program CCB meeting prior to the next scheduled monthly meeting when a timely response is needed to address a change request.

¨  An emergency Program CCB meeting may be necessary to align with IFSV Project sprints that typically last only four to six weeks. Untimely responses to change requests by the Program CCB could result in IFSV Project delays and negatively impact ACA Program deployment.

Recommendation

¨  Recommendation 2: The Chief Technology Officer should ensure that the ACA Program Configuration Management Plan is updated to include procedures to request and convene emergency ACA Program CCB meetings when timely program-level responses are needed.

¨  Management’s Response:  The IRS agreed with this recommendation. The IRS plans to update the ACA Program Configuration Management Plan documentation, providing clear direction for convening emergency Program CCB meetings when needed.

An Integrated Suite of Tools Could Improve Requirements Management for the IFSV Project

¨  The Rational RequisitePro tool is the IRS Enterprise Architecture standard for requirements management. The IFSV Project team uses the Rational RequisitePro tool to manage their requirements. Requirements are manually imported into the IFSV sprint management tool, Rational Team Concert. However, Rational RequisitePro and Rational Team Concert are not integrated to automatically update changes to requirements in both tools. Therefore, the IFSV Project team must manually input changes in both tools to ensure that requirements are accurately updated. To ensure timely and consistent requirements management, this process should be integrated and automated.

¨  The IRS’s current manual process heightens the risk that requirements may not be timely and accurately reflected in both tools. As a result, the project could be developed based on inaccurate requirements, which could negatively impact ACA systems functionality.

Recommendation

¨  Recommendation 3: The Chief Technology Officer should ensure that a standard suite of integrated, automated tools is implemented for the ACA Program and ACA projects to manage sprint processes, develop and manage requirements, develop and manage test cases, and bidirectionally trace requirements and test cases.

¨  Management’s Response: The IRS disagreed with this recommendation6. The Chief Technology Officer stated in his written response to the draft report that this recommendation “does not offer flexibility for projects that are not good candidates for automated tools.” Further, the Chief Technology Officer commented that “automated tools are not always necessary to maintain control over requirements, test cases management, and traceability, so we do not agree with TIGTA [Treasury Inspector General for Tax Administration] prescribing their use.”

6 We made a similar recommendation in a previous report (TIGTA, Ref. No. 2012-20-122, Customer Account Data Engine 2 (CADE 2): System Requirements and Testing Processes Need Improvements (Sept. 2012)). The IRS also disagreed with this recommendation at that time.

¨  Office of Audit Comment:  The IRS disagreed with this recommendation and consequently the Chief Technology Officer does not plan to take corrective actions. We discussed this finding and recommendation with IFSV Project officials during the audit closing conference. At that time, we explained that this recommendation is specific to the ACA Program and ACA projects, and that the recommendation is not directed generally toward other IRS programs and projects.

The IRS recognized that the current manual requirements management process heightens the risk that information technology requirements may not be timely and accurately reflected across the separate management tools. This audit concluded that a standard suite of automated tools could help the IRS to mitigate this risk. In addition, best practices suggest the current manual processes should be integrated and automated to efficiently manage sprint processes, develop and manage requirements, develop and manage test cases, and bidirectionally trace requirements and test cases.

Our audit also considered that there are multiple projects under the ACA Program, which is managing volumes of information technology requirements in a highly dynamic environment. Consequently, TIGTA maintains that this recommendation requires an action plan to develop and implement a suite of integrated, automated tools to support all phases of the ACA Program and ACA projects. Such an action plan would permit the IRS to better ensure long-term success for the IFSV Project along with the many other information technology components and systems supporting new functionality and transactions required by the IRS to address mission-critical capabilities under the ACA.

The IRS also disagreed with the statement in the report that cost data were not readily available during the audit. We agree that cost information was requested after the audit closing. We requested information on the IFSV Project’s budget and actual cost data that could be provided quickly and easily. However, it took the IRS 28 business days to provide basic budget and cost data for the IFSV Project. TIGTA maintains that cost data specific to the IFSV Project were not readily available during our audit, due to the length of time it took the IRS to provide basic budget and cost data.

Appendix I

Detailed Objective, Scope, and Methodology

 

¨  Overall Objective: Determined whether the IRS is adequately managing systems development risk for the IFSV Project under the ACA Program. Specifically, we:

¨  Evaluated whether the IFSV Project is managing project management risk related to the new Iterative Path of the ELC. Focus areas included:

o   Culture change.

o   Stakeholder involvement.

o   IFSV Project planning activities.

o   IFSV Project sprint systems development and testing activities.

o   Control framework applied with the IFSV Project.

o   IFSV Project requirements and change management – we judgmentally sampled and reviewed six of 19 total IFSV Project change requests. We selected these six because they were designated as critical. Also, we judgmentally sampled six of 61 baselined requirements, which are each important to the basic functionality of the IFSV Project. Both samples were selected to determine whether the configuration management guidelines were followed.

¨  Determined whether the IFSV Project developed and documented a security plan to protect taxpayer data and whether Federal Information Security Management Act and National Institute of Standards and Technology guidelines were considered.

¨  For conditions identified, obtained documentation and interviewed personnel to support and determine the cause.

¨  This review was performed at the Information Technology organization (formerly known as the Modernization and Information Technology Services organization) in Farmers Branch, Texas, in the ACA PMO from June through August 2012.

¨  We conducted this performance audit in accordance with generally accepted government auditing standards, which require that we plan and perform the audit to obtain sufficient, appropriate evidence to provide a reasonable basis for our findings and conclusions based on our audit objective. We believe that the evidence obtained provides a reasonable basis for our findings and conclusions based on our audit objective.

Internal Controls Methodology

¨  Internal controls relate to management’s plans, methods, and procedures used to meet their mission, goals, and objectives. Internal controls include the processes and procedures for planning, organizing, directing, and controlling program operations. They include the systems for measuring, reporting, and monitoring program performance.

¨  We determined the following internal controls were relevant to our audit objective: 1) the Internal Revenue Manual and related IRS guidelines and 2) the processes followed in the development of information technology projects using the Iterative Path.

¨  We evaluated these controls by conducting interviews with management and staff; making on-site observations of sprint planning, system development, and testing activities; and reviewing documentation.

¨  Documents reviewed include the IFSV Project Management Plan, the Iterative Development and Testing Process Description, and other documents that provided evidence of whether the IRS is adequately managing systems development risk for the IFSV Project.

Major Contributors to This Report

 

¨  Alan R. Duncan, Assistant Inspector General for Audit (Security and Information Technology Services)

¨  Gwendolyn McGowan, Director

¨  Suzanne Westcott, Audit Manager

¨  David F. Allen, Lead Auditor

¨  Wallace Sims, Senior Auditor

¨  Linda Nethery, Information Technology Specialist

Report Distribution List

 

¨  Acting Commissioner C

¨  Office of the Commissioner – Attn: Chief of Staff C

¨  Deputy Commissioner for Operations Support OS

¨  Deputy Commissioner for Services and Enforcement SE

¨  Deputy Chief Information Officer for Operations OS:CTO

¨  Acting Director, Affordable Care Act Office SE:ACA

¨  Director, Privacy, Governmental Liaison and Disclosure OS:P

¨  Associate Chief Information Officer, Affordable Care Act – Program Management Office OS:CTO:ACA

¨  Chief Counsel CC

¨  National Taxpayer Advocate TA

¨  Director, Office of Legislative Affairs CL:LA

¨  Director, Office of Program Evaluation and Risk Analysis RAS:O

¨  Office of Internal Control OS:CFO:CPIC:IC

¨  Audit Liaisons: Deputy Commissioner for Services and Enforcement SE

¨  Director, Risk Management Division OS:CTO:SP:RM

 

Glossary of Terms

Term

Definition

Change Management

The transition of a changed or new product through development to deployment into the current production environment with minimum disruption to users. This can occur in a number of ways including, but not limited to: (1) implementation of a change to a product baseline, (2) establishing a new product baseline, and/or (3) a change to a Service Level Agreement.

Change Request

The method for requesting approval to change a baselined product or other controlled item.

Configuration Control Board (CCB)

Serves as the change approval authority for baselined products.

Configuration Control Board Charter

The ACA Program CCB Charter establishes the ACA Program CCB and defines its authority, threshold, responsibilities, and membership.

Configuration Management

Establishes proper control over approved project documentation, hardware, and software and assures changes are authorized, controlled, and tracked.

Configuration Management Plan

Documents the configuration management processes that the ACA PMO will use to maintain the integrity of configuration items, associated artifacts, and other products throughout the product life cycle as they relate to the technical baseline.

Control Objectives for Information Technology (COBIT)

An information technology governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues, and business risks. It enables clear policy development and a good practice for information technology control throughout organizations.

Eligibility and Enrollment Process Area

This is one of four ACA process areas to be delivered under ACA Release 3.0. It will provide verification of income and family size and determination of advanced premium tax credit.

Enterprise Life Cycle

The IRS’s software development life cycle for information technology projects. It provides the critical framework/foundation for IRS information technology projects. The Enterprise Life Cycle facilitates project success through critical step-by-step discipline and structure.

Federal Information Security Management Act

A statute that requires agencies to assess risks to information systems and provide information security protections commensurate with the risks. The Federal Information Security Management Act also requires that agencies integrate information security into their capital planning and enterprise architecture processes, conduct annual information systems security reviews of all programs and systems, and report the results of those reviews to the Office of Management and Budget. (Title III, P.L. 107-347.)

Framework

A structure that facilitates the understanding of a complex topic by breaking the topic into multiple pieces or features, classifying the features, illustrating relationships between the features, and organizing them in a manner that facilitates visualization and practical usage.

Impact Assessment

An evaluation of a change request to determine its impact on a project’s schedule, cost, other dependent projects, and upstream and downstream systems.

National Institute of Standards and Technology

A nonregulatory Federal agency within the Department of Commerce responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all Federal Government agency operations and assets.

Rational RequisitePro

An application used for requirements management. The IRS has established Rational RequisitePro as its Enterprise Architecture standard for requirements management. It is used to capture detailed requirement data such as the requirement text and any supporting attributes to organize or clarify the requirement. The application also has the capability to create and maintain full requirements traceability within a single project or across multiple projects.

Rational Team Concert

The tool the IFSV Project team uses to manage their sprint processes. Rational Team Concert provides a lean collaborative life cycle management solution with agile and formal planning, project reporting, process workflow, work item management, source code management, and build management in a single integrated product.

Requirement

A formalization of a need; it is the statement of a capability or condition that a system, subsystem, or system component must have or meet to satisfy a contract, standard, or specification.

Sprint

ACA projects conduct a series of “Sprints,” either sequentially or in parallel, within each release. The goal of each sprint is to get a subset of the project’s functionality to a “production-ready” state. At the end of the sprint, the functionality developed will be fully tested (although it will not be put into production until a later date). The duration of each sprint is typically four to six weeks.

Systems Development Life Cycle

The scope of activities associated with a system, encompassing the system’s initiation, development and acquisition, implementation, operation and maintenance, and ultimately its disposal, which instigates another system initiation.

Waterfall Path

The Waterfall Path is distinguished by sequential development of a solution with planned reviews and formal approvals required before continuation of work. The solution design evolves through a planned progression of successive levels from logical design to development, and then solution components are developed.

 

Management’s Response to the Draft Report

DEPARTMENT OF THE TREASURY

INTERNAL REVENUE SERVICE

WASHINGTON, D.C. 20224

 

CHIEF TECHNOLOGY OFFICER

 

 

March 5, 2013

 

 

 

 

MEMORANDUM FOR DEPUTY INSPECTOR GENERAL FOR AUDIT

 

FROM:                            Terence V. Milholland /s/ Terence V. Milholland

           Chief Technology Officer

 

SUBJECT:                       Draft Audit Report - Affordable Care Act:  The Income and Family Size Verification Project: Improvements Could Strengthen the Internal Revenue Service's New Systems Development Process - Audit# 201220312 (e-trak #2013-39233)

 

Thank you for the opportunity to review and respond to the subject draft audit reportI am pleased that the report documents the application of the Iterative Path in the systems development of the Income Family Size Verification (IFSV) project and recognizes some of the expected benefits - such as better alignment between the product and stakeholder's requests - in the implementation of this new approach.  The Iterative Path approach was well suited for the IFSV project as it gave the Affordable Care Act Program Management Office greater flexibility and adaptability in developing system functionality incrementallyThis effort has resulted in the successful completion of developmental sprints and functional testing for IFSV capabilities and, as a result, the project is on schedule for completion.

 

The IRS agrees with the two recommendations in the report pertaining to improving the configuration management and communication process; accordingly, we will implement planned corrective actions as documented in the attachment.  However, we disagree with the recommendation to implement integrated, automated tools to manage sprint processes, develop and manage requirements, and develop and manage test cases, etc., as we believe automated tools are not always necessary to maintain control over systems development activitiesThe IRS disagrees with the statement in the report that cost data was not readily available during the audit.  Cost information was requested after the audit closing and the cost data was provided.

 

We are committed to continuously improving our information technology systems and processesWe value your continued support and the assistance and guidance your organization provides.  If you have any questions, please contact me at (202) 622-6800 or a member of your staff may contact Gina Garza, Associate Chief Information Officer for the ACA PMO, at (202) 622-3587.

 

Attachment

 

Attachment

 

RECOMMENDATION #1:  The Chief Technology Officer should complete a broader review to evaluate the effectiveness of existing controls to ensure change requests and impact assessments are adequately developed and processed as required by the ACA Program Configuration Management guidelines.

 

CORRECTIVE ACTION #1:  The IRS agrees with this recommendationWe will conduct a review across the Affordable Care Act (ACA) Program Management Office (PMO) to evaluate the effectiveness of existing controls for change requests and impact assessments.

 

IMPLEMENTATION DATE:  July 1, 2013

 

RESPONSIBLE OFFICIAL:  Associate Chief Information Officer, Affordable Care Act PMO

 

CORRECTIVE ACTION MONITORING PLAN:  We will enter accepted corrective actions into the Joint Audit Management Enterprise System (JAMES) and monitor them on a monthly basis until completion.

 

RECOMMENDATION #2:  The Chief Technology Officer should ensure the ACA Program Configuration Management Plan is updated to include procedures to request and convene emergency ACA Program CCB meetings when timely program level responses are needed.

 

CORRECTIVE ACTION #2:  The IRS agrees with this recommendationWe will update the ACA Program Configuration Management Plan documentation, providing clear direction for convening emergency program Change Control Board meetings when needed.

 

IMPLEMENTATION DATE:  July 1, 2013

 

RESPONSIBLE OFFICIAL:  Associate Chief Information Officer, Affordable Care Act PMO

 

CORRECTIVE ACTION MONITORING PLAN:  We will enter accepted corrective actions into the Joint Audit Management Enterprise System (JAMES) and monitor them on a monthly basis until completion.

 

RECOMMENDATION #3:  The Chief Technology Officer should ensure that a standard suite of integrated, automated tools is implemented for the ACA Program and ACA projects to manage sprint processes, develop and manage requirements, develop and manage test cases, and bi-directionally trace requirements and test cases.

 

CORRECTIVE ACTION #3:  The IRS disagrees with this recommendation.  It does not offer flexibility for projects that are not good candidates for automated tools.  In addition, automated tools are not always necessary to maintain control over requirements, test cases management, and traceability, so we do not agree with TIGTA prescribing their use.

 

IMPLEMENTATION DATE:  Not Applicable

 

RESPONSIBLE OFFICIAL:  Not Applicable

 

CORRECTIVE ACTION MONITORING PLAN:  Not Applicable