TREASURY INSPECTOR GENERAL FOR TAX ADMINISTRATION

 

 

Prototype Process Improvements Will Benefit Efforts to Modernize Taxpayer Account Administration

 

 

 

November 24, 2010

 

Reference Number:  2011-20-001

 

 

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

Email Address   |  inquiries@tigta.treas.gov

Web Site           |  http://www.tigta.gov

 

 

HIGHLIGHTS

PROTOTYPE PROCESS IMPROVEMENTS WILL BENEFIT EFFORTS TO MODERNIZE TAXPAYER ACCOUNT ADMINISTRATION

Highlights

Final Report issued on November 24, 2010

Highlights of Reference Number:  2011-20-001 to the Internal Revenue Service Chief Technology Officer.

IMPACT ON TAXPAYERS

The mission of the Customer Account Data Engine (CADE) 2 Program is to provide state-of-the-art individual taxpayer account processing and technologies to improve service to taxpayers and enhance Internal Revenue Service (IRS) tax administration.  Once completed, the new modernization environment should allow the IRS to more effectively and efficiently update taxpayer accounts, support account settlement and maintenance, and process refunds on a daily basis, which will contribute to improved service to taxpayers.

WHY TIGTA DID THE AUDIT

The overall objective of this review was to determine the effectiveness of CADE 2 Program prototype efforts, including applicable security provisions, designed to validate the first phase of development plans.

WHAT TIGTA FOUND

The CADE 2 Program Management Office created five prototype teams to demonstrate confidence in the CADE 2 solution by verifying system viability and performance and by defining components that will serve as the foundation for development activities.  The prototype teams generally managed their objectives effectively.  The teams also identified risks that faced the successful execution of the prototype plans and took steps to overcome the barriers.

The CADE 2 Program Management Office can improve management of:  1) work breakdown structure (task assignments) development, 2) prototype testing documentation, 3) organizational conflict of interest documentation, and 4) security documentation for contractor personnel working with prototype teams.

The CADE 2 Program Management Office has been vigilant in monitoring the prototypes to provide direction and support to development activities.  The prototype teams recognized the limits in approaching some of the original objectives and made modifications to keep the prototype activities relevant to future CADE 2 Program development.  However, the ability of the CADE 2 Program to process individual taxpayer accounts as envisioned cannot be determined until the prototype results and recommendations are understood and implemented.

WHAT TIGTA RECOMMENDED

TIGTA recommended that the Chief Technology Officer have the CADE 2 Program Management Office reemphasize compliance with the elements of the CADE 2 Prototype Process to ensure planning, execution, and reporting activities are followed and incorporate guidance to include:  1) appropriately detailed work breakdown structures, 2) testing plans and documentation standards that follow Internal Revenue Manual and Enterprise Life Cycle guidance, 3) effective management of contracting activities to ensure that issues concerning organizational conflict of interest are properly managed, and 4) timely completion of all necessary security documentation for contractor personnel.

In its response to the report, the IRS agreed with TIGTA’s recommendations.  The IRS plans to: 1) update the CADE 2 contracting guidelines, 2) embed Contracting Officer’s Technical Representatives within the CADE 2 Program Management Office to assist future prototype teams, 3) update the CADE 2 Program Management Plan’s Prototype Process document, and 4) update the Prototype Lessons Learned presentation to address TIGTA’s findings.

 

November 24, 2010

 

 

MEMORANDUM FOR CHIEF TECHNOLOGY OFFICER

 

FROM:                            Michael R. Phillips /s/ Michael R. Phillips

                                         Deputy Inspector General for Audit

 

SUBJECT:                    Final Audit Report – Prototype Process Improvements Will Benefit Efforts to Modernize Taxpayer Account Administration (Audit # 201020004)

 

This report presents the results of our review of the Customer Account Data Engine 2 Program prototype efforts.  The overall objective of this review was to determine the effectiveness of Customer Account Data Engine 2 Program prototype efforts, including applicable security provisions, designed to validate Transition State 1 development plans.  This review was included in our Fiscal Year 2010 Annual Audit Plan and addresses the major management challenge of Modernization of the Internal Revenue Service.  Management’s complete response to the draft report is included as Appendix VII.

Copies of this report are also being sent to the Internal Revenue Service managers affected by the report recommendations.  Please contact me at (202) 622-6510 if you have questions or Alan Duncan, Assistant Inspector General for Audit (Security and Information Technology Services), at (202) 622-5894.

 

 

Table of Contents

 

Background

Results of Review

The Customer Account Data Engine 2 Program Initiated Prototypes to Aid the Modernization of Individual Taxpayer Account Administration

Prototype Teams Generally Managed the Objectives Effectively

The Customer Account Data Engine 2 Program Identified Risks to the Prototype Efforts

Process Improvements Will Help the Prototypes Achieve the Objectives and Make Future Prototype Efforts More Efficient and Effective

Recommendation 1:

Customer Account Data Engine 2 Program Implementation Is Dependent on the Prototype Results

Appendices

Appendix I – Detailed Objective, Scope, and Methodology

Appendix II – Major Contributors to This Report

Appendix III – Report Distribution List

Appendix IV – Enterprise Life Cycle Overview

Appendix V – Customer Account Data Engine 2 Transition States

Appendix VI – Glossary of Terms

Appendix VII – Management’s Response to the Draft Report

 

 

Abbreviations

 

CADE

Customer Account Data Engine

IRS

Internal Revenue Service

TIGTA

Treasury Inspector General for Tax Administration

 

 

Background

 

The IRS Commissioner directed the CADE 2 Program Management Office to build on the substantial progress accomplished by the current CADE and leverage its lessons learned to date.

In August 2008, the Internal Revenue Service (IRS) Commissioner established the Modernized Taxpayer Account Program Integration Office to manage the transition of current individual income tax processing, which consists of multiple computer systems for processing tax returns, payments, and other transactions that affect individual taxpayer accounts.  Working in conjunction with IRS business owners, the Program Integration Office decided to integrate elements from both the existing Individual Master File[1] and current Customer Account Data Engine (CADE) processes into a new CADE 2 Program.  The proposed plan incrementally transfers taxpayer accounts from the current Individual Master File and CADE processing systems to a new CADE 2 relational database.  The CADE 2 Program strategy involves three phases:

Ÿ  Transition State 1 will modify the Individual Master File to run daily (currently individual taxpayer accounts are processed on a weekly basis) and establish a new relational database to store all individual taxpayer account information.  This phase will also provide tools for the IRS to more effectively use the data for compliance and customer service.  The IRS plans to implement Transition State 1 in January 2012.

Ÿ  Transition State 2 will put a single processing system in place.  Applications will directly access and update the taxpayer account database, and continued effort will be made in addressing previously identified financial material weaknesses.  The IRS is performing additional analysis to establish an estimated date for Transition State 2 implementation.

Ÿ  Target State will consist of a single system using elements of the Individual Master File and the current CADE and will eliminate all transitional components such as those used to link the current CADE, the Individual Master File, and the Integrated Data Retrieval System.  Further, the complete solution plans to address all financial material weaknesses identified at the inception of the Modernized Taxpayer Account Program.  The IRS is performing additional analyses to establish an estimated date for the Target State to be implemented.

Appendix V presents conceptual models of the as is, transition, and target state individual income tax account processing.

The CADE 2 Program was established in June 2009 and published its charter in January 2010, with the mission to provide state-of-the-art individual taxpayer account processing and technologies to improve service to taxpayers and enhance IRS tax administration.  The CADE 2 Program plans to accomplish this by creating a modernized processing environment that supports daily account posting and settlement capabilities where applications access and update an authoritative relational database that will house all individual taxpayer account data.  This will enable the IRS to improve the accuracy and speed of individual taxpayer account processing, enhance the customer experience through improved access to account information, and increase the effectiveness and efficiency of agency operations.  The CADE 2 Program charter established goals and defined its scope.  Figure 1 presents the goals and scope of the CADE 2 Program.

Figure 1:  CADE 2 Program Goals and Scope

CADE 2 Program Goals

Establish a solid data foundation for the future by leveraging relational database processing capability.

Address financial material weaknesses, demonstrate compliance with Federal Financial Management System Requirements, and maintain a clean audit opinion.

Improve security and privacy posture by addressing identified weaknesses.

Continue the focus on moving away from 1960’s technology (i.e., aging infrastructure, applications, and sequential flat file processing).

Demonstrate substantive progress toward achieving long-term viability.

 

CADE 2 Program Scope

Establish the authoritative database for individual taxpayer accounts.

Replace the current Individual Master File applications and current CADE applications with a single, state-of-the art solution.

Expand the Integrated Production Model to include individual taxpayers and individual taxpayer accounts.

Provide daily outputs to the Integrated Data Retrieval System and other downstream systems as they are able to support daily processing.

Source:  CADE 2 Program Charter Version 1.0, dated January 28, 2010.

While the CADE 2 Program and IRS business owners have established conceptual models to attain these goals within a defined scope, a consensus still needs to be reached on key implementation approaches and on the best technology choices.  To accomplish this, the following five prototype teams have been created to settle the remaining uncertainties:

  1. Java Programming Language for the CADE 2 Solution.
  2. Database/Extract Transform and Load.
  3. Penalty and Interest Calculation.
  4. Performance Modeling and Monitoring.
  5. Database Performance Test.

The objective of each prototype is to demonstrate confidence in the CADE 2 Program approach by verifying system viability and performance and by defining components that will serve as the foundation for development activities.

This review was performed at the Modernization and Information Technology Services facilities in New Carrollton and the Office of Procurement in Oxen Hill, Maryland, during the period February through July 2010.  We conducted this performance audit in accordance with generally accepted government auditing standards.  Those standards 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.  Detailed information on our audit objective, scope, and methodology is presented in Appendix I.  Major contributors to the report are listed in Appendix II.

 

 

Results of Review

 

The CADE 2 Program Management Office took steps to formulate and initiate prototype efforts.  These steps included development of program guidance and prototype processes, and steps to identify and manage risks related to the prototyping efforts.  Further, the CADE 2 Program Management Office took actions to monitor and evaluate progress in accomplishing the prototype objectives.  These actions included the recognition of the risks to the CADE 2 Program strategy previously identified Audit Risk, Delivery Risks, Funding and Schedule Risks, Operational Risks, People Risks, and Technical/Complexity Risks.  We also recognize the CADE 2 Program Management Office is addressing challenges the Treasury Inspector General for Tax Administration (TIGTA) offered in our December 2009 report.[2]

The Customer Account Data Engine 2 Program Initiated Prototypes to Aid the Modernization of Individual Taxpayer Account Administration

On October 14, 2009, the CADE 2 Program initiated its prototype efforts to accomplish the following objectives:

Ÿ  Settle uncertainties in technology and solution approach.

Ÿ  Gain confidence in system viability and performance.

Ÿ  Define effective and proven design patterns.

Ÿ  Define components that serve as a foundation for the formal development.

Ÿ  Establish an agile and rapid development methodology.

Ÿ  Build architectural foundations that can be leveraged for the entire IRS.

The CADE 2 Program initially proposed four specific prototypes to address the above objectives:  1) Java Programming Language for the CADE 2 solution; 2) Database/Extract Transform and Load to identify account changes, extract, transform, and load taxpayer data to the database and use the CADE database for extracts and viewing; 3) Penalty and Interest Calculation performance and integration of common code with Java applications; and 4) Performance Modeling and Monitoring.  The CADE 2 Program later added another prototype effort Database Performance Test Prototype 5.

The initiation also outlined a delivery model designed with an iteration cycle that includes steps to plan, design, build, test, and evaluate prototype progress.  Further, the initiation provides a governance structure with related roles and responsibilities that includes an executive sponsor and prototype manager assigned to each prototype.  The governance also includes a CADE 2 Prototype Management and Integration Lead whose responsibilities are to:

Ÿ  Coordinate activities across the prototypes and integrate schedules and dependencies across all prototypes.

Ÿ  Engage partner organizations as appropriate (e.g., Computing Centers for access to resources).

Ÿ  Manage the integrated prototype plan and collect and distribute status from prototype teams.

Ÿ  Establish an agenda and chair the CADE 2 Prototype Advisory Council.

Ÿ  Facilitate identification and capture of risks and develop mitigation strategies.

Ÿ  Capture action items related to prototypes and manage common action item log.

Further work was developed through the Program Management Office to develop the CADE 2 Prototype Process.  This guidance was issued January 15, 2010, and provides a structured prototype process to help identify, define, assess, select, plan, execute, and monitor prototypes.

Prototype Teams Generally Managed the Objectives Effectively

To ensure that it is able to operate effectively and achieve its goals, the IRS has established a well-defined governance structure for the CADE 2 Program.  The governance structure has assigned decision-making authority and designed the accountability framework to encourage desirable behavior.  The IRS has also identified a set of “enabling characteristics” for CADE 2 Program governance.  These characteristics serve as evaluation criteria as the IRS establishes governance standards, processes, procedures, and templates for the CADE 2 Program. 

The governance structure includes a Program Governance Board, Program Management Office, executive sponsors, the Chief Architect, prototype project managers, and prototype advisors.  Also, the CADE 2 Prototype Management and Integration Lead has effectively fulfilled the proposed responsibilities including coordinating activities among prototypes and with the CADE 2 Program Management Office.  The Lead has also monitored and communicated prototype development progress with regular status meetings that include identification, assessment, and resolution of risks at the prototype level.

Enabling Characteristics of the CADE 2 Program Governance

Ÿ   Foster rapid decision-making, proactive risk management, and issue resolution.

Ÿ   Promote accountability for Program success at multiple levels.

Ÿ   Ensure that the appropriate stakeholders are making the decisions and all the required stakeholder groups are represented.

Ÿ   Ensure that the right data are presented when decisions are required.

Ÿ   Structure decision-making authority so that decisions can be made at the appropriate level – allowing decisions to be made by those most affected by them, without creating undue risk for the Program.

Ÿ   Ensure that all decisions are clearly documented and communicated and provide an “audit trail” about how, when, and why decisions were made.

 

The prototype effort included formulation of objectives and proposed deliverables for each prototype, the approach to achieving the objectives, and estimates of the schedule and duration of the prototypes.  Resource needs including hardware, software, and IRS and contracted staffing needs were identified.

Each prototype team focused its work relative to defined CADE 2 Program Transition States.  We assessed each prototype team’s work in addressing the objectives related to Transition State 1.

Java Programming Language for the CADE 2 Solution Prototype 1

The Prototype 1 team began its work on December 11, 2009.  The prototype work was originally planned to last approximately 8 months, with a completion date of July 30, 2010.  The original objectives for the Prototype 1 team were to:

Ÿ  Define effective and proven design and development patterns that are the basis for design and development of the CADE.

Ÿ  Examine the performance and scalability for high-performance batch posting and financial settlement applications using Java programming language.

Ÿ  Define an effective Common Operating Environment for Java components.

The Prototype 1 team accomplished its objectives and provided deliverables that included identifying the Java Common Operating Environment for the CADE 2 Program and a database of taxpayer accounts for testing prototype applications under various account and load conditions.  Initial test results demonstrated that Java has adequate performance capability, scalability, and viability.

Database/Extract Transform and Load Prototype 2

The Database/Extract Transform and Load Prototype 2 team began its work on December 17, 2009.  The prototype work was originally expected to last approximately 6 months with a completion date of June 30, 2010.  The original objectives for the Prototype 2 team were to:

Ÿ  Evaluate approaches to extract changes from the Individual Master File, transform to a database format, and load the CADE database.

Ÿ  Evaluate approaches to accomplish Integrated Data Retrieval System extracts from individual accounts on the CADE database.

The prototype team successfully demonstrated the use of the Informatica tool on the IRS platform to extract taxpayer data from the Individual Master File and transform the data into a compatible format to load the data onto the CADE 2 database.  However, the prototype team experienced several setbacks leading to scope changes in the prototype objectives.  These setbacks involved:

Ÿ  Contract issues that delayed access to key resources.

Ÿ  Analysis and design work that took longer than planned.

Ÿ  Unforeseen technical issues that arose related to the movement of data between systems.

The scope changes by the CADE 2 Program Management Office in May 2010, based on the prototype team findings, resulted in a material course correction to the original Prototype 2 work.  Additional analysis and testing relating to the use and capabilities of the Informatica tool was removed for the prototype scope at that time.  Prototype 2 was originally planned to develop solution patterns to accomplish daily processing time frames.  However, performance testing of the database to confirm the ability to achieve daily income tax account processing routines was broadened to include a more comprehensive database performance test and shifted to a new Prototype 5 (Database Performance Test).

With the rescoping of the prototypes, the Prototype 2 team took steps to reduce program-level risks related to the development of the CADE 2 Program Transition State 1 Data Implementation project.  It redefined the scope of work for Prototype 2 (Database/Extract Transform and Load) and defined the scope of work Prototype 5 (Database Performance Test).  Further, the Prototype 2 team, in conjunction with the Program Management Office, secured additional funding to extend contractor support for resources to complete both Prototype 2 and Prototype 5.

Penalties and Interest Calculation Prototype 3

The Penalties and Interest Calculation Prototype 3 team began its work on December 1, 2009.  This team’s work relates to the IRS’s calculations of penalty and interest charges applied to delinquent individual taxpayer accounts.  The prototype work was originally planned to last approximately 5 months with a completion date of April 30, 2010.  The original objectives for the Prototype 3 Team were to:

Ÿ  Analyze existing Penalties and Interest C-Language code and other common code modules to determine reasons for poor performance and memory leaks.

Ÿ  Recommend changes to allow common calculations for the CADE 2 solution, the Business Master File, and the Integrated Data Retrieval System.

The Penalty and Interest Calculation Prototype 3 team successfully completed its work for Transition State 1 activities on April 21, 2010.  The Prototype 3 Penalty and Interest Transition State 1 Performance Analysis and Improvement Enhancements for C-Common Code Report was timely completed on April 27, 2010.  The Prototype 3 team initially reported reductions in penalty and interest processing time by as much as 50 percent.  In July 2010, the Prototype 3 team reported further reductions in processing time.  The IRS has deployed these enhancements into the current processing environment.

Performance Modeling and Monitoring Prototype 4

The Performance Modeling and Monitoring Prototype 4 team began its work on December 11, 2009, with its work expected to continue through the life of the CADE 2 Program.  The CADE 2 Program plans to use this team to provide further performance modeling and requirements as the CADE 2 development activities advance.  The original Transition State 1 objectives for the Prototype 4 team were to:

Ÿ  Create a performance model that is based on the workload that must be processed in each transition state.

Ÿ  Define the performance requirements and performance budgets for major design components for Transition State 1.

Work related to designing and building the performance model for Transition State 1 was completed on April 8, 2010.  This included providing initial Transition State 1 performance specifications for Prototypes 1, 2, and 3.  Work on the final prototype specifications was completed September 17, 2010.

Database Performance Test Prototype 5

The Database Performance Test Prototype 5 team was proposed on June 26, 2010, and approved by the CADE 2 Governance Board on July 26, 2010.  The prototype work is planned to last approximately 5 months, with a completion date of November 30, 2010.  The objective for the Prototype 5 team is to set effective and proven design and development patterns that will establish the basis for design and development work, assuring all processing demands can be satisfied.

The Customer Account Data Engine 2 Program Identified Risks to the Prototype Efforts

We assessed prototype team actions taken to identify and manage risks, including contractor management and the need to provide appropriate security measures.  The Prototype Management and Integration Lead, along with the prototype teams, adequately identified risks that faced the successful execution of the prototype plans.  These risks included the availability of resources and the scope of work.

The prototype teams initially experienced concerns related to securing contractor support and managing resource contention issues.  Each prototype team was able to use its existing staff or obtained sufficient qualified staff to manage identified risks to accomplish the objectives.  The process used to identify prototype requirements is acceptable, and there are adequate controls in place to manage changes (e.g., the CADE 2 Governance Board, the prototype sponsors, and the Chief Architect).  Further, the work performed by the prototype teams specifically addresses assigned objectives, and controls are in place for all prototype teams to clearly understand when they have completed prototype activities and are entering CADE 2 Program Transition State 1 development activities.

Organizational Conflict of Interest Mitigation Plans were established for contractors working on the CADE 2 prototypes

The Federal Acquisition Regulation states that an organizational conflict of interest occurs when, because of other activities or relationships, a person or entity is unable or potentially unable to render impartial assistance or advice to the government, or their objectivity in performing the contract work is or might otherwise be impaired, or they may have an unfair competitive advantage.  The CADE 2 Program Management Office took steps to address organizational conflicts of interest early in the acquisition process.  Organizational Conflict of Interest Mitigation Plans for each contractor on the prototype teams included an individual nondisclosure agreement, established a “firewall” for a period of at least 6 months and up to 2 years after completion of performance, provided Organizational Conflict of Interest Mitigation Plan training, and included plan monitoring.

In addition, two of the Organizational Conflict of Interest Mitigation Plans provided some avoidance of the organizational conflict of interest by not allowing contractor personnel to participate with the IRS in drafting requirements related to competitive follow-on acquisition efforts and incorporated an organizational conflict of interest analysis in their step review process for new proposal activity.

The prototype teams considered appropriate Federal Government and IRS security guidelines as part of the prototype analyses.

As the work progressed, the prototype teams gave more consideration to the security provisions.  For example, in April 2010, one of the prototype teams made an effort to ensure its contractors have access to the IRS Web sites that contain the security and architecture requirements.  In addition, nearly all of the 40 contractor employees timely completed the required Fiscal Year 2010 Annual Security Awareness Training.  Only three contractors had not completed the training by the designated due date.

Subsequently, on June 3, 2010, a meeting was held with the Cybersecurity and Infrastructure Architecture and Engineering offices to provide a technical overview of the CADE 2 Prototype efforts and to determine the level of Cybersecurity office involvement.  This meeting laid the foundation for more opportunities of Cybersecurity office involvement with the prototypes by establishing Cybersecurity office points of contact for future meetings.

Process Improvements Will Help the Prototypes Achieve the Objectives and Make Future Prototype Efforts More Efficient and Effective

We analyzed prototype team plans, actions, and documentation to meet their objectives.  Our analyses found the CADE 2 Program Management Office can improve management of the following activities.

Work breakdown structure development and detail

A work breakdown structure is a project management tool used to define and group a project’s individual work elements (or tasks) in a way that helps organize and define the total work scope of the project.  Further, it provides the necessary framework for detailed cost estimating and cost control, along with providing guidance for schedule development and schedule control.  It forms the basis for dividing work into definable increments from which a statement of work can be developed and technical, schedule, cost, and labor-hour reporting can be established.

Prior to startup activities, each prototype team, working in conjunction with the Prototype Management and Integration Lead and the contractor, created its own work breakdown structure to manage day-to-day activities.  However, three of the four prototype teams did not develop effective work breakdown structures.

The Prototype 1 (Java) work breakdown structure provided the detail necessary to timely accomplish its objectives.  However, the Prototype 2 (Database/Extract Transform and Load) work breakdown structure tasks were incomplete and, as a result, the team did not timely complete assigned objectives.  While the Prototype 3 (Penalties and Interest) and Prototype 4 (Performance) work breakdown structures needed additional task decomposition, the teams were able to timely complete assigned objectives.

Prototypes 2, 3, and 4 subsequently published effective work breakdown structures in June 2010.  Each prototype team updated its tasks on a weekly basis and was able to effectively manage day-to-day activities by documenting the work completed and the work remaining for each task.  In July 2010, 9 months after prototype planning activities began, work breakdown structures for each prototype were finally incorporated into the CADE 2 Program Transition State 1 Integrated Master Schedule.

The absence of effective work breakdown structures during the early stages of prototype development occurred for several reasons.  The initial CADE 2 Prototype planning meeting for the prototypes took place in October 2009.  At this meeting, required objectives and deliverable dates were identified for each prototype.  By mid-January 2010, work on all four prototypes was well underway, but it was not until February 2010 that the CADE 2 Program Management Office drafted integrated master schedule and work breakdown structure guidelines.  These guidelines required work breakdown structure activities and tasks to be decomposed into segments which could be completed within 10 business days.  The guidelines also required the identification of all known dependencies, Enterprise Life Cycle artifacts and work products, and resource assignments.

The absence of an effective work breakdown structure during the early stages of Prototype 2 development negatively affected the completion of the original prototype objectives and may affect the CADE 2 Transition State 1 Database Implementation Project design activities.

The CADE 2 Program Management Office guidelines targeted Enterprise Life Cycle preliminary and detailed design work stages and exempted vision and strategy, project initiation, and domain architecture stage activities and deliverables.  However, the guidelines did not clearly specify prototype work as part of its directive.  As a result, three of the four prototype teams did not use the guidelines to develop their work breakdown structures until prototype work was in the final stages of completion.

The absence of an effective work breakdown structure during the early stages of Prototype 2 development negatively affected the completion of its original objectives.  The absence contributed in part to the setbacks experienced by the Prototype 2 team in managing contract, design work, and unforeseen technical issues.  These issues required the prototype team to reduce scope and delay its original delivery date from June 30, 2010, to October 4, 2010.  In May 2010, a deliverable that would have added complexity to the previously processed taxpayer data by adding tables and more capabilities was removed to address the rescheduling.  In June 2010, the scope was further reduced by moving performance-related deliverables to a new Prototype 5 (Database Performance Test).

The CADE 2 Program Transition State 1 Integrated Master Schedule did not incorporate comprehensive prototype work breakdown structures until 9 months after prototype planning began.

Since performance is a major concern, Prototype 5 must define, implement, and demonstrate its ability to be expanded to the current processing environment.  The original schedule called for the new prototype to deliver its results by November 30, 2010.  However, in July 2010, the CADE 2 Governance Board approved a new proposal to return several performance tests to Prototype 2 and defer two Prototype 2 deliverables (i.e., Integrated Data Retrieval System and Corporate On-line Files solutions) to CADE 2 Program Transition State 1 activities.  While this action moved the Prototype 5 delivery date up to September 29, 2010, the CADE 2 Program Transition State 1 Database Implementation Project’s preliminary design delivery date was rescheduled from September 29, 2010, to December 23, 2010.

The absence of an effective work breakdown structure during the early stages of Prototype 2 development may also negatively affect the CADE 2 Program Transition State 1 Database Implementation Project.  The Project’s physical design, which describes how the new CADE 2 relational database processing will be performed, requires delivery of Prototypes 2 and 5 results by December 15, 2010, to allow time to complete the detailed design activities.  While the revised schedules for Prototypes 2 and 5 allow some reserve for further rescheduling, a delay in completion of the Data Implementation Project’s physical design could put the planned Transition State 1 January 2012 delivery in jeopardy.

Prototype testing documentation

Test result documentation provides evidence to support the conclusion and/or recommendations for each prototype.  The Internal Revenue Manual and the Enterprise Life Cycle provide guidance for documenting test plans and test results. 

Ÿ  The Internal Revenue Manual provides guidance in the form of Test, Assurance, and Documentation Standards and Procedures.

Ÿ  The Enterprise Life Cycle requires projects to maintain test plans and test results, including issues logs.  Test plans provide a blueprint of what is to be tested and ensures business requirements and specifications are not missed.  In addition, a well-developed test plan ensures requirements and specifications are functionally met and will be operating in production.  Test results documentation provides evidence to support the conclusion and/or recommendations for each prototype.  Test results documentation also provides assurance and evidence that business requirements are met and defects are resolved or approved.  An issues log provides for an audit trail of issues and/or defects identified through testing.  A well-developed issues log should include, but is not limited to, the status of each issue, resolution, date found, date resolved, and approval to pass on an issue.  These “best practices” will enhance requirements gathering, design, and development procedures.

The Prototype 1, Prototype 2, and Prototype 3 teams did not initially document test plans, test results, and issues logs.  Due to the nature of the work in Prototype 4, test plans, test results, and issues log were not required.  In April 2010, we discussed the status of prototype efforts with the prototype managers, including the plans for testing and evidence about the results to date.  The prototype managers did not have this information documented at that time and subsequently took actions to document their test plans, test results, and maintain issues logs.  However, when comparing the work performed by the prototype teams to document the testing activities to the Enterprise Life Cycle templates, the following were omitted:

Ÿ  Assumption and Constraints.

Ÿ  Entrance and Completion (Exit) Criteria.

Ÿ  Defect Summary (including defects found and resolved and defects unresolved).

In July 2010, we presented these omissions to the CADE 2 Program executives, prototype managers, and prototype team members.  They agreed with our analysis and took additional corrective actions to be applied to subsequent testing.  The Prototype 1 work is complete and included all of the critical elements identified above.  The Prototype 2 and Prototype 3 teams will apply our suggestions in all future testing.

The CADE 2 Program Prototype Process document provides a high-level framework for achieving CADE 2 prototype objectives.  However, during the audit process, gaps were identified between the CADE 2 Program Prototype Process document and the Enterprise Life Cycle.  Specifically, insufficient detail in test plans, test result documents, and issues logs can have the following results:

Ÿ  Without test plans, inclusion of relevant business requirements needed for testing may be omitted.  Missed requirements can result in costly rework.

Ÿ  Without adequate test results documentation, there may not be sufficient evidence showing all necessary requirements were tested.  Also, test results provide details about the types of test performed.  Without adequate documentation, retesting of failed tests (defects) would be difficult.  Inadequate test results documentation could result in deployment of applications that do not include the expected capabilities.

Ÿ  Without an issues log, the same issue/defect could recur without having the previous resolution readily available.  When defects requiring resolution are not resolved, subsequent processing can be negatively affected.  System downtime and costly reprogramming can result.

Organizational conflict of interest documentation

The Federal Acquisition Regulation requires a written analysis, including a recommended course of action, for avoiding, neutralizing, or mitigating an identified organizational conflict of interest.  IRS policy provides that when a conflict or potential conflict has been identified, the contracting officer may require the contractor to submit a mitigation plan.  If a plan is required, the plan’s actions should be included in the contract. 

Further, IRS policy and procedures require a nondisclosure agreement for contractor personnel to access Sensitive But Unclassified information.  Each nondisclosure agreement will reference the conditional nature of access to Sensitive But Unclassified information with respect to the contract work, or specialized project, for which such access is required.  The IRS should sign and date these agreements prior to granting access to Sensitive But Unclassified information.

Although the CADE 2 Program Management Office recognized and took actions with plans to manage organizational conflict of interest concerns, further improvements are necessary to address the following conditions:

Ÿ  A documented acquisition strategy does not exist for two vendors although their work on the prototypes posed an organizational conflict of interest. 

Ÿ  A process does not exist to track prototype contractors’ restrictions in future contracts.

Ÿ  Issues with four Organizational Conflict of Interest Mitigation Plans reviewed showed one plan was not timely executed, two plans were not signed by both the IRS and the contractor, and three plans did not provide consequences of noncompliance.

Ÿ  Contract clauses did not incorporate actions agreed upon in the Organizational Conflict of Interest Mitigation Plan (i.e., the nature of the organizational conflict of interest and duration of the proposed restraints) and the contract language provided in the IRS’s Organizational Conflict of Interest Policy and Procedures.

Ÿ  Nondisclosure agreements for contractors working on the CADE 2 prototype teams were not always timely and properly completed.  In the nondisclosure agreements required for 34 contractor employees, we found:

o   21 nondisclosure agreements were untimely because they were not fully executed prior to providing the contractors access to Sensitive But Unclassified information on IRS systems and/or not executing the agreements prior to allowing staff-like access to the contractors.

o   10 nondisclosure agreements were not properly completed.  These agreements did not reference the specific task orders requiring limited access to Sensitive But Unclassified information or did not include the required signature and date of appropriate IRS personnel.

These conditions existed because the appropriate IRS personnel were not familiar with the Federal Acquisition Regulation as it relates to organizational conflict of interest provisions and Department of the Treasury requirements for nondisclosure agreements.  When organizational conflict of interests are not properly managed, unfair competitive advantages can result which compromises the integrity of the procurement process.  When agencies fail to take appropriate actions to address these unfair advantages, the Government Accountability Office and Court of Federal Claims have sustained protests based on an agency’s violation of the organizational conflict of interest provisions of the Federal Acquisition Regulation.  Also, there is an increased threat of improper disclosure of sensitive information in which violations are punishable by both civil and criminal penalties.  Lastly, the cost and delay associated with resolving potential organizational conflicts of interest after-the-fact adversely affects agency programs and the public interest.

Security documentation

A minimum background investigation must be completed prior to allowing contractors staff-like access approval.  Further, contractor employees who require a password or access to an IRS system remotely must be approved for staff-like access before an Online 5081 (Information System User Registration/Change Request) is initiated. 

Contractors’ security documentation included minimum background investigation information and Live Data Requests/Waivers.  The minimum background investigation information granting contractors staff-like access was completed timely for all but three contractors.  One of these three contractors was given access to IRS systems prior to the completion of their minimum background investigation.  Two other contractors required issuance of a new Memorandum of Final Staff-Like Access Approval because their previous minimum background investigation information was for a previous contract.

IRS policy and procedures provide that when a live data request is made, a Live Data Request (or Waiver) Packet has to be completed, reviewed, and approved by the IRS Office of Privacy.  At a minimum, the live data request must include a detailed description/justification for the live data request, a justification for why live data must be used in lieu of sanitized live data or simulated test data, a plan for the creation of simulated test data for future use, and the security risks associated with the use of the live data being requested, in addition to proposed mitigation strategies.

Although the IRS generally met the minimum requirements, live data request documentation allowing contractors to work with live taxpayer data was not adequate for one of the two prototype teams that are using live data.  The Prototype 2 team submitted five live data requests.

Ÿ  Two requests did not include approval pages with signatures and approval dates.

Ÿ  One request was incomplete and did not reference the contract work.

Ÿ  One request was submitted that did not include the IRS Office of Privacy approval and specified a time period that had already passed. 

Ÿ  One request did not have documentation that readily identified the specific contractors to be provided access to live taxpayer data.

Protecting individuals’ privacy requires adhering to established privacy and security safeguards when handling individual’s personal data within a live data testing setting.  Organizations often prefer to use live data (data that will be used in production) during testing because they can offer a real-world setting.  However, use of live data can pose significant risk to the public and the IRS and, in many cases, may not be necessary.  Use of live data is strictly prohibited without proper completion of a Live Data Request and prior approval.  Disclosure and security laws provide criminal and civil penalties for noncompliance.

Recommendation

Recommendation 1:  To address the controls and activities to help ensure success of prototype activities, the Chief Technology Officer should have the CADE 2 Program Management Office reemphasize compliance with the elements of the CADE 2 Prototype Process to ensure planning, execution, and reporting activities are followed.  Specifically, the processes and activities to be emphasized should include the following:

  1. Appropriately detailed work breakdown structures that are developed prior to initiating work that will also provide a meaningful Integrated Master Schedule.
  2. The use of testing plans and documentation standards following the guidance provided in the Internal Revenue Manual and the Enterprise Life Cycle.
  3. Timely and effective oversight for contracting activities to ensure that issues concerning organizational conflict of interest are properly managed.
  4. Timely completion of all necessary security documentation for contract personnel associated with prototype teams.

Management’s Response:  The IRS agreed with our recommendations.  The IRS plans to:  1) update the CADE 2 contracting guidelines, 2) embed Contracting Officer’s Technical Representatives within the CADE 2 Program Management Office to assist future prototype teams, 3) update the CADE 2 Program Management Plan’s Prototype Process document, and 4) update the Prototype Lessons Learned presentation to address TIGTA’s findings.

Customer Account Data Engine 2 Program Implementation Is Dependent on the Prototype Results

Prototypes provide an organization the opportunity to develop and assess models for business solutions.  The CADE 2 Program prototype effort initiated prototypes with relevant objectives to help achieve a level of confidence about the viability of potential business solutions.  As previously discussed, the original prototype efforts either met the originally planned objectives or modified the objectives to obtain a more relevant understanding of the potential capabilities the CADE 2 Program may deliver. 

The CADE 2 Program Management Office has been vigilant in monitoring the prototypes to provide direction and support to development activities.  The prototype teams recognized the limits in approaching some of the original objectives and made modifications to keep the prototype activities relevant to future CADE 2 Program development.  However, the ability of the CADE 2 Program to process individual taxpayer accounts as envisioned cannot be determined until the prototypes results and recommendations are understood and implemented.

In our December 2009 report, we identified challenges the CADE 2 Program faced if it was to deliver a successful system to process individual tax accounts.  One of these challenges was to develop contingency plans in the event that the new CADE Strategy cannot be fully implemented.  For example, what are the options if the Individual Master File programs cannot be modified to run daily or as frequently as needed?  The approach by the CADE 2 Program Management Office in facing these challenges, including the development of contingency plans, will be clearer as the prototype results and recommendations are determined.

 

Appendix I

 

Detailed Objective, Scope, and Methodology

 

The overall objective of this review was to determine the effectiveness of CADE 2 Program prototype efforts, including applicable security provisions, designed to validate Transition State 1 development plans.  To accomplish the objective, we:

I.                   Determined whether the prototypes achieved their objectives by verifying system viability, performance, and security requirements that serve as the foundation for development activities.

A.    Obtained general information about each of the prototype activities including staffing assigned; meeting schedules; and prototype documents such as charters, prototype plans, and meeting minutes.

B.     Reviewed and assessed Prototype 1 (Java Programming Language[3] for the CADE 2 solution) team efforts to determine whether:

1.      Adequate prototype development plans for the CADE 2 Common Operating Environment and testing strategy were prepared.

2.      An assessment was made of the Java programming language’s viability for use in the CADE 2 solution. 

C.     Reviewed and assessed Prototype 2 (CADE 2 Database/Extract Transform and Load) team efforts to complete planned objectives and deliverables to determine whether:

1.      A CADE 2 database with populated test data containing 1 percent of the Individual Master File was developed with:

a.       The ability to process a day’s work within a day.

b.      Specifics about tax module data, entity data, or any other data used.

c.       Daily quality, including the ability to identify and reject invalid data.

d.      Time periods for delivery of the test database to the Prototype 1 (Java) team.

2.      Informatica viability was used to extract, transform, and load data from the Individual Master File and the current CADE to the CADE 2 database. 

3.      Solution patterns provided data extracts from the CADE 2 database to the Integrated Data Retrieval System.

4.      Solution patterns provided a capability to view taxpayer account data stored in the CADE 2 database using Individual Master File online commands. 

D.    Reviewed and assessed Prototype 3 (Penalty and Interest Calculation) team efforts to determine the adequacy of solution patterns for improving the efficiency of the penalty and interest calculations for use by the CADE 2 Program.

E.     Reviewed and assessed Prototype 4 (Performance Modeling and Monitoring) team efforts to determine whether:

1.      A performance model was developed defining the performance requirements and performance budgets for major design components.

2.      CADE 2 Program Transition State 1 performance requirements and performance budgets were developed for Prototype Team 2 (CADE 2 Database/Extract Transform and Load) and Prototype Team 3 (Penalty and Interest Calculation).

II.                Reviewed and assessed individual prototype team actions taken to manage prototype risks, including prototype vendor selection concerns.  Specifically, we determined whether:

A.    Prototypes have sufficiently qualified staff to accomplish their objectives.

B.     The process used to identify business requirements for the prototypes was adequate.

C.     The work performed by the prototype teams specifically addressed the assigned objectives (i.e., scope management).

D.    The vendors working on the prototypes will be accorded an unfair competitive advantage resulting in an organizational conflict of interest.

E.     Appropriate security documentation for the prototype team contractors is in place.

F.      Appropriate Federal Government and IRS security guidelines are being considered as part of the prototype analyses.

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:  CADE 2 prototype activities, development, and security provisions including the Enterprise Life Cycle; the work performed by the Modernized Taxpayer Account solution teams, which identified risks associated with the CADE 2 Program prototype activities; and the initiation documents used as guidance for the CADE 2 Program Management Office.  We supported this work by interviewing CADE 2 Program Management Office executives, prototype team executive sponsors, project managers, and team members, including contractor employees.

 

Appendix II

 

Major Contributors to This Report

 

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

Scott A. Macfarlane, Director

Edward A. Neuwirth, Audit Manager

Bruce Polidori, Senior Auditor

Esther M. Wilson, Senior Auditor

Kevin Liu, Information Technology Specialist

David F. Allen, Auditor

 

Appendix III

 

Report Distribution List

 

Commissioner  C

Office of the Commissioner – Attn:  Chief of Staff  C

Deputy Commissioner for Operations Support  OS

Commissioner, Wage and Investment Division  SE:W

Associate Chief Information Officer, Applications Development  OS:CTO:AD

Associate Chief Information Officer, Enterprise Services  OS:CTO:ES

Associate Chief Information Officer, Modernization Program Management Office  OS:CTO:MP

Deputy Associate Chief Information Officer, Applications Development  OS:CTO:AD

Deputy Associate Chief Information Officer, Business Integration  OS:CTO:ES:BI

Deputy Associate Chief Information Officer, Systems Integration  OS:CTO:ES:SI

Director, Procurement  OS:A:P

Director, Risk Management  OS:CTO:SP:RM

Director, Test, Assurance, and Documentation  OS:CTO:AD:TAD

Director, Strategy and Capital Planning  OS:CTO:SP:CP

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:

Associate Chief Information Officer, Applications Development  OS:CTO:AD

Associate Chief Information Officer, Enterprise Services  OS:CTO:ES

Director, Procurement  OS:A:P

Director, Program Oversight  OS:CTO:SM:PO

 

Appendix IV

 

Enterprise Life Cycle Overview

 

The Enterprise Life Cycle is the IRS’s standard approach to business change and information systems initiatives.  It is a collection of program and project management best practices designed to manage business change in a successful and repeatable manner.  The Enterprise Life Cycle addresses large and small projects developed internally and by contractors.

The Enterprise Life Cycle includes such requirements as:

·         Development of and conformance to an enterprise architecture.

·         Improving business processes prior to automation.

·         Use of prototyping and commercial software, where possible.

·         Obtaining early benefit by implementing solutions in multiple releases.

·         Financial justification, budgeting, and reporting of project status.

In addition, the Enterprise Life Cycle improves the IRS’s ability to manage changes to the enterprise; estimate the cost of changes; and engineer, develop, and maintain systems effectively.  Figure 1 provides an overview of the phases and milestones within the Enterprise Life Cycle.  A phase is a broad segment of work encompassing activities of similar scope, nature, and detail and providing a natural breakpoint in the life cycle.  Each phase begins with a kickoff meeting and ends with an executive management decision point (milestone) at which IRS executives make “go/no-go” decisions for continuation of a project.  Project funding decisions are often associated with milestones.

Figure 1:  Enterprise Life Cycle Phases and Milestones

Phase

General Nature of Work

Milestone

Vision and Strategy/
Enterprise Architecture Phase

High-level direction setting.  This is the only phase for enterprise planning projects.

0

Project Initiation Phase

Startup of development projects.

1

Domain Architecture Phase

Specification of the operating concept, requirements, and structure of the solution. 

2

Preliminary Design Phase

Preliminary design of all solution components.

3

Detailed Design Phase

Detailed design of solution components.

4A

System Development Phase

Coding, integration, testing, and certification of solutions.

4B

System Deployment Phase

Expanding availability of the solution to all target users.  This is usually the last phase for development projects.

5

Operations and Maintenance Phase

Ongoing management of operational systems.

System Retirement

Source:  The Enterprise Life Cycle Guide.

 

Appendix V

 

Customer Account Data Engine 2 Transition States

 

Figures 1 through 4 present conceptual models of the As Is, Transition States 1 and 2, and Target State processing flows for individual income tax accounts.

Figure 1:  As Is Processing

Figure 1 was removed due to its size.  To see Figure 1, please go to the Adobe PDF version of the report on the TIGTA Public Web Page..[4]

Figure 2:  Transition State 1 Processing Plan

Figure 2 was removed due to its size.  To see Figure 2, please go to the Adobe PDF version of the report on the TIGTA Public Web Page.

Figure 3:  Transition State 2 Processing Plan

Figure 3 was removed due to its size.  To see Figure 3, please go to the Adobe PDF version of the report on the TIGTA Public Web Page.

 

Figure 4:  Target State Processing Plan

Figure 4 was removed due to its size.  To see Figure 4, please go to the Adobe PDF version of the report on the TIGTA Public Web Page.

 

Appendix VI

 

Glossary of Terms

 

Term

Definition

Business Master File

The Business Master File is the IRS database that consists of Federal tax-related transactions and accounts for businesses.  These include employment taxes, income taxes on businesses, and excise taxes.

Common Operating Environment 

All computers in a common operating environment use the same operating system, the same programs, and the same icons.  This provides standardization and makes administration of each computer an easier task to perform. 

Computing Center

Supports tax processing and information management through a data processing and telecommunications infrastructure.

Core Data Store

Provides the system of record for all tax return processing that replaces the tape-based Master File systems and the current CADE system.

Corporate Files On-Line

This system provides online transactional access to Individual and Business Master File data, Information Return Program data, and various other related data collections.  These files are accessed via IRS-developed Customer Information Control System command codes.

Current Processing Environment

The IRS’s existing entire Information Technology environment including business applications, data stores, data interfaces and processing flows, infrastructure, and Information Technology services, as well as involved organizations, locations, processes, policies, and people.

Enterprise Life Cycle

A structured business systems development method that requires the preparation of specific work products during different phases of the development process.

Federal Acquisition Regulation

The codification and publication of uniform policies and procedures for acquisition by all Executive Branch agencies.

Firewall – Organizational Conflict of Interest

Information about a project and personnel with access to protected information in one part of a company, preventing other parts of the company from having knowledge or influence over a project.

Individual Master File

The IRS database that maintains transactions or records of individual tax accounts.

Individual Master File On-Line Processing

This system provides online transactional access to Individual Master File data. 

Informatica

A comprehensive, open, unified, and economical data integration platform which supports all five steps in the data integration life cycle.  It sustains all roles involved in data integration data stewards, data analysts, architects, administrators, and developers.

Infrastructure

The fundamental structure of a system or organization.  The basic, fundamental architecture of any system (electronic, mechanical, social, political) determines how it functions and how flexible it is to meet future requirements.

Integrated Data Retrieval System

An IRS mission-critical system consisting of databases and programs supporting IRS employees working active tax cases.  It manages data retrieved from the Master File, allowing IRS employees to take specific actions on taxpayer account issues, track status, and post updates back to the Master File.

Integrated Master Schedule

The Integrated Master Schedule provides a schedule for project development and integration of all modernization projects.

Integrated Production Model

Intended to be a data store to meet IRS needs for data analytics and long-term reporting, and as a source for other types of analytic data that supplement the transactional core data store.

Java Programming Language

A computer programming language that is general-purpose, concurrent, class-based, and object-oriented, and is specifically designed to have as few implementation dependencies as possible.  It is intended to let application developers “write once, run anywhere.”

Live Data

A form of Sensitive But Unclassified data that includes taxpayer information, tax return information, live employee data, and other sensitive information.

Master File

The IRS database that stores various types of taxpayer account information.  This database includes individual, business, and employee plans and exempt organizations data.

Physical Design

Describes how the processing will be performed (e.g., whether data are input by a person or read by a bar code reader and whether a file is electronic or print).  Tools to represent the physical design include system flowcharts and structure charts.

Relational Database

A relational database is a collection of data items organized as a set of formally described tables from which data can be accessed or reassembled in many different ways without having to reorganize the database tables.

Release

A specific edition of software.

Tax Module

A tax module contains records of tax liability and accounting information pertaining to one tax period.  Each tax module contains groups of data including assessed tax liability, payments and other credits, balance due amounts, refund checks sent, and other accounting information relating to a specific tax period.

 

Appendix VII

 

Management’s Response to the Draft Report

 

 

DEPARTMENT OF THE TREASURY

INTERNAL REVENUE SERVICE

WASHINGTON, D.C. 20224

 

CHIEF TECHNOLOGY OFFICER

 

 

October 26, 2010

 

 

MEMORANDUM FOR DEPUTY INSPECTOR GENERAL FOR AUDIT

 

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

    Chief Technology Officer

 

SUBJECT:                       Draft Audit Report - Prototype Process Improvements Will Benefit Efforts to Modernize Taxpayer Account Administration (Audit #201020004)

 

Thank you for the opportunity to review your draft audit report and to discuss earlier draft report observations with the audit team.

 

We were pleased to read your comments and observations acknowledging the CADE 2 Program Management Office's development of program guidance and prototype processes to achieve a level of confidence in the viability of potential business solutions. In addition, we are also pleased with your recognition of the establishment of a well-defined governance structure for the CADE 2 Program to provide a framework for decision making authority and accountability.

 

While the initial set of prototypes has been successfully closed out, we have implemented steps to help ensure the continued success of future prototypes based on your guidance. And, while no new prototypes have been initiated at this time, we are actively evaluating the technical risk areas in our Program to determine what other prototypes may be needed. The assistance and guidance you have provided during our initial set of prototypes will help to ensure that future prototypes will be equally successful.

 

We are committed to continuously improving our information technology systems and processes. We value your continued support and the assistance and guidance your team provides. If you have any questions, please contact me at (202) 622·6800 or Peggy Hueston at (202) 283-4915.

 

Attachment

 

RECOMMENDATION #1: To address the controls and activities to help ensure success of prototype activities, the Chief Technology Officer should have the CADE 2 Program Management Office reemphasize compliance with the elements of the CADE 2 Prototype Process to ensure planning, execution and reporting activities are followed, and incorporate guidance to include:

  1. Appropriately detailed work breakdown structures that are developed prior to initiating work that will also provide a meaningful integrated Master Schedule.
  2. The use of testing plans and documentation standards following the guidance provided in the Internal Revenue Manual and the Enterprise Life Cycle.
  3. Timely and effective oversight for contracting activities to ensure that issues concerning Organizational Conflict of Interest are properly managed.
  4. Timely completion of all necessary security documentation for contract personnel associated with prototype teams.

 

CORRECTIVE ACTION #1: The IRS agrees with this recommendation, with the understanding that appropriate considerations will be made around level of process to accommodate an iterative development path. The following actions will be taken to address this recommendation to ensure adequate controls and activities on CADE 2 prototype work going forward:

  1. Update the CADE 2 Acquisition Strategy and Plan to enhance contracting guidelines to address Organizational Conflict of Interest (OCI) issues, Non-Disclosure Agreements and the proper management of them.
  2. Embed Contracting Officer's Technical Representatives (COTRs) within the CADE 2 Program Management Office (PMO) to assist future prototype teams with the monitoring of OCI Mitigation Plans and to ensure the timely completion of security documentation.
  3. Update the CADE 2 Program Management Plan's Prototype Process document incorporating guidance to:
    1. Leverage the CADE 2 PMO's integrated master schedule and work breakdown structure guidelines;
    2. Leverage the Internal Revenue Manual and the Enterprise Life Cycle's testing and documentation standard guidelines at the appropriate level of detail per the ELC development path selected and the nature of the prototype to ensure that the documentation supports the resulting recommendations; and
    3. Reference the CADE 2 Acquisition Strategy and Plan on the proper monitoring of OCI agreements and Security Requirements.

4. Update the Prototype Lessons Learned presentation to address TIGTA's findings.

 

IMPLEMENTATION DATE: February 1, 2011

 

RESPONSIBLE OFFICIAL: Associate Chief Information Officer, Modernization – Program Management

 

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

 



[1] See Appendix VI for a glossary of terms.

[2] Reengineering Individual Tax Return Processing Requires Effective Risk Management (Reference Number 2010-20-001, dated December 7, 2009).

[3] See Appendix VI for a glossary of terms.

[4] See Appendix VI for a glossary of terms.