Critical Processes and Dependencies Need to Be Addressed to Avoid Further Delays in Deployment of the Enterprise Systems Management Project
Reference Number:† 2002-20-084
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.
May 2, 2002
FOR DEPUTY COMMISSIONER FOR MODERNIZATION &
CHIEF INFORMATION OFFICER
FROM:†††† Pamela J. Gardiner /s/ Pamela J. Gardiner
†††††††††††††††† Deputy Inspector General for Audit
SUBJECT:†††† Final Audit Report Ė Critical Processes and Dependencies Need to Be Addressed to Avoid Further Delays in Deployment of the Enterprise Systems Management Project† (Audit # 200120018)
This report presents the results of our review of the Internal Revenue Serviceís (IRS) Enterprise Systems Management (ESM) project.† The overall objective of this review was to determine whether the ESM project team was effectively developing its major sub-systems and following the key processes necessary to ensure the projectís success.† To address this objective, we assessed whether the projectís intended benefits would be delivered on schedule and within the original budget, whether certain critical processes were followed, and whether the project was taking appropriate actions to comply with the Enterprise Architecture.
The ESM project was designed to improve the availability and performance of IRS modernized information technology by providing management capabilities for the computer systems and networks.† These capabilities include monitoring of all IRS computer systems and networks to ensure they are consistently available to the employees relying on them, and the consolidation of 19 help desks throughout the IRS into a single help desk to better serve the users of the systems and networks.† Because of a cutback in the funding available for the modernization contractor to develop all aspects of the ESM project, the IRSí Information Technology Services (ITS) organization agreed to provide assistance in the delivery of some of these capabilities.†
In summary, we found that two modules of the ESM project, an improved asset management system and a consolidated user help desk application, were deployed in 2001 and are providing benefits to the IRS.†† While these portions of the ESM project were successfully delivered, the ESM project team continues to experience delays in delivering key capabilities, such as monitoring of dispersed systems.† Aggressive scheduling and late delivery of assistance from the ITS organization have contributed to these delays.† In addition, informal processes to gather requirements from other projects, and non-conformance with established risk management processes could result in deployment of a system that does not meet the needs of the projects it was designed to support.† If project delays continue or critical requirements are not addressed, the IRS may not have the systems management capabilities in place to monitor the performance of the modernized systems it plans to deliver in 2002, or to identify and correct system problems before they have a significant impact on employee productivity or service to taxpayers.
The IRSí Business Systems Modernization Office (BSMO) needs to implement actions it has previously agreed to complete in order to address continuing concerns with overly aggressive scheduling and ensure that schedules provided by the ITS organization are monitored so that any delays are quickly identified.†† The BSMO should also conduct a quality review of ESM project testing because testing time frames were tightly compressed.
When we discussed these issues with BSMO personnel, they indicated that they had successfully conducted their ESM project testing, and that the contractor had conducted a quality review of the testing.† We did not validate this information because the testing and quality review were conducted after we completed our audit work.
Since other modernization projects are dependent on the functionality of the ESM project, it is important that the ESM project team work with other project teams to ensure their business needs are documented and met.† The BSMO should require the ESM project team to implement more formalized, proactive techniques to assist other project teams in developing and refining business requirements.† The BSMO should also require the ESM project team to address recommendations made by the MITRE Corporation related to business requirements.† Lastly, the BSMO should require the ESM project team to follow established risk management processes.
In addition to the above issues and recommendations, we included two observations that relate to the overall Business Systems Modernization program.†† These observations may be developed further in future audits that address program-related issues.†
Copies of this report are also being sent to the IRS managers who are affected by the report recommendations.† Please contact me at (202) 622-6510 if you have questions or Scott E. Wilson, Assistant Inspector General for Audit (Information Systems Programs) at (202) 622-8510.
The Internal Revenue Service (IRS) is in the midst of a major effort to modernize its computer and related information technology systems.† This modernization effort, known as Business Systems Modernization (BSM), is expected to last up to 15 years and cost approximately $5 billion.† The IRS organized the Business Systems Modernization Office (BSMO) to oversee BSM, and contracted with the Computer Sciences Corporation (CSC), the PRIME contractor for modernization, to develop and integrate the various BSM projects.
Successful modernization requires an integrated and organization-wide approach to the management of computer systems, including network and systems management, software distribution, end-user support and help desk functions, asset management, and configuration management.† The Enterprise Systems Management (ESM) project was started in June 1999 to develop the integrated systems management environment.
The ESM project represents an important step in improving the ability of the IRS to manage its information technology resources.† It is considered an infrastructure project and is overseen by the IRSí Infrastructure Executive Steering Committee, which meets monthly to discuss the projects under its purview.† After July 2002, ESM will be merged with the other infrastructure projects into a single project called Infrastructure Shared Services.
The ESM project currently consists of four sub-projects, which are planned to deliver the following functionality:
1. Integrated Enterprise Systems Management (IESM) - Delivers the capability to monitor and report on the status of networked computers and other devices to help ensure their availability for employee use.
2. Enterprise Help Desk (EHD) - Establishes a single virtual help desk that operates 24 hours a day, and eliminates the current 19 separate help desks.
3. Information Technology Asset Management System (ITAMS) - Delivers an inventory system that will enable tracking, reporting, and management of information technology assets.
4. Performance Measures & Reporting (PMAR) - Establishes a system for collection, storage, analysis, and reporting on information technology performance data.
In January 2001, the IRS Commissioner and other executives made the decision to reduce BSM funding for infrastructure projects in order to provide more funding for projects that offered greater functionality for taxpayer needs.† To compensate for the reduced infrastructure budget, the executives determined that some functionality of the ESM project could be provided by the IRSí Information Technology Services (ITS) organization.† The ITS organization agreed to continue the development of the ITAMS and EHD sub-projects.†
The ESM project team, along with the ITS organization, has implemented some initial modules of two sub-projects, and prepared for its Fiscal Year (FY) 2002 release scheduled between January and March 2002.† The projectís FY 2002 release is designed to provide additional systems monitoring, help desk, inventory management, and software distribution tools, as well as enable the IRS to generate management information statistics.
We performed fieldwork in the BSMO facilities in New Carrollton, Maryland, and at the CSC facilities in Landover, Maryland.† The audit was conducted between May and December 2001 in accordance with Government Auditing Standards.† Detailed information on our audit objective, scope, and methodology is presented in Appendix I.† Major contributors to the report are listed in Appendix II.
The IRS has made progress in developing and deploying portions of the ESM project.† In March 2001, the ITS organization deployed one module of the ITAMS as part of its effort to improve tracking of information technology assets.† Nationwide implementation of a second module of the ITAMS began in October 2001.† This module includes a problem management tool, which standardizes processes among help desks and defines and implements clear processes and procedures to ensure consistent service to customers.
These initial modules of the ITAMS sub-project should enable the IRS to begin improving its tracking of information technology assets.† Since 1983, the IRS has consistently reported that control over its assets has been a material weakness.† We recently reported on deficiencies in the IRSí control over its assets, as has the General Accounting Office (GAO).† Full implementation of the ITAMS is one of the actions planned to address these weaknesses in controls.
Another major area of focus for the ESM project team has been consolidating help desk services.† In November 2001, the ESM project team implemented a single nationwide toll-free telephone number to enable IRS employees to obtain access to technical support areas in the ITS organization.† This single telephone number is an initial step towards replacing 19 separate help desks across the country, and should greatly increase the consistency and ease of addressing computer-related problems.
Although the above modules of the ESM project have been deployed, we identified several weaknesses in the ESM project development processes that could contribute to project delays and cost increases.
Aggressive scheduling and late delivery of work by the ITS organization have contributed to delays in the ESM project and have resulted in tight time frames for system testing.
Aggressive project schedule
The ESM project team established a highly aggressive project schedule and has experienced significant delays.† Originally scheduled to move from the design phase to the development phase in January 2001, the ESM project team delayed this until August 2001.† This 7-month delay occurred in part because of the re-prioritization of business and infrastructure projects and in part because the BSMO and the CSC had not timely completed negotiations on the ESM project development phase work order (task order), obtained approvals of design phase deliverables, or selected a sub-contractor to assist in project development and deployment.
At the end of our audit work, the project team was delaying the date they expected to complete development and begin deployment.† The ESM project team expected to complete development in November 2001; however, management officials delayed this completion until February 2002.† This delay occurred at least in part because the testing environment was not available when it was originally scheduled, and because changes occurred in the Security and Technology Infrastructure Release (STIR) project schedule on which the ESM schedule was dependent.†
The aggressive schedule that was in place for the project did not allow for any contingencies such as the delay in availability of the testing environment or dependencies on other projects.† If ESM project delays continue, the BSMO may deliver modernization projects without the systems management capabilities to monitor performance and identify and correct system problems before they impact employee productivity or service to taxpayers.
In addition to the above delays, we are concerned about the aggressive schedule for testing the IESM sub-project.† Because the testing was just beginning at the time we completed our audit work, we focused our work on whether adequate time had been allocated for ESM project testing.† When we inquired about the time scheduled for testing the IESM sub-project, the project team indicated that although testing activities, such as development of test scenarios, were scheduled over several weeks, it had only allocated 4 days of project testing in the assigned test laboratory.† We asked how the time requirements for this testing were determined, and the team indicated that the time was based primarily on when the laboratory was available and the due date for the project, rather than on an objective analysis or model of the time needed to test the requirements.
In a recent executive meeting, the IRS Commissioner raised concerns regarding scheduling sufficient time for testing of modernization projects.† He indicated that the experience from the Customer Communications 2001 (CC01) project demonstrated that more time was needed for testing.† Sufficient time for testing is especially critical for infrastructure projects because they are not always subject to independent testing for quality by IRS personnel.
Lessons learned documentation from the CC01 project, prepared in June 2001, indicated that the project teams should develop detailed and realistic plans and schedules with adequate time for reviews.† These schedules should include all key activities, dependencies, and owners, and establish a critical path.† In addition, the schedule should include accurate estimates of task durations, and these estimates should not be developed by simply backing up from the agreed upon release date.†
The BSMO responded that it would require contingencies for unforeseen events to be incorporated into future project schedules.† In addition, it would require that the CSC requirements be rewritten to strengthen schedule quality.† However, we could not determine when these actions would be completed, and it does not appear that the lessons learned regarding scheduling were implemented in the ESM project.
Additionally, a previous audit report on the CC01 project recommended that the BSMO ensure project managers build sufficient reserves and recovery time into work schedules to allow for the impact of unplanned events on project delivery.† The BSMO agreed to this recommendation, and indicated that it reviewed the schedules submitted by the modernization project teams to determine if they were realistic.
Delays in completion of ITS tasks
Because funding for infrastructure projects was significantly reduced in early 2001, the ITS organization is developing two of the ESM sub-projects.† The ESM team submitted several Requests for Information Services (RIS) to document necessary assistance from the ITS organization in June 2001.† However, the ITS organization has not consistently completed the agreed tasks within the established time frames.† These delays were due at least in part to recent changes in the organizational structure of the ITS.† When we met with the newly appointed executive over this area, she indicated that the ITS organization was revising its responses to the RISs including the time schedules, and is quickly catching up in its efforts.
The restructuring of the ITS organization may cause further delays in the deployment of ESM functionality.† Key ESM project documentation showed that deployment would require a significant number of employees in the ITS organization, particularly in the areas of desk-side support and help desk.† However, the new ITS organization had not been finalized at the time we completed our audit work, and a date for finalizing the new structure had not been determined.† Because the help desk and other functions of the ESM project will be operated by ITS employees, the delays in the ITS reorganization could impact the ESM projectís deployment.†
The ESM project team had documented a risk related to the dependencies on the ITS organization, but the risk reduction activities were not on schedule.† The project team indicated that they could not take action on these risk reduction activities because completion of the activities was the responsibility of the ITS organization.†
Since infrastructure projects provide the foundation of all BSM systems, any further delays in deployment or inadequate testing of ESM sub-projects could result in problems with all BSM systems, including those planned to provide increased service to taxpayers in 2002.† For example, any further ESM project delays could delay the deployment of system monitoring and management capabilities for the Internet Refund/Fact of Filing (IRFOF) project, which will allow taxpayers to check on the status of their tax refunds via the Internet.
Management Actions:† When we discussed these issues with BSMO personnel, they indicated that they had conducted a successful test of the ESM project and that the contractor had performed a quality review of the testing.† We did not validate these actions because the testing was performed after we completed our audit work.
To ensure the ESM project is available to support other modernization projects and achieves the planned internal benefits to the IRS, we recommend that the BSMO:
1. Implement previously agreed-to actions to address continuing issues with aggressive scheduling, and ensure that schedules provided by the ITS organization are monitored so that any delays are quickly identified.
2. Conduct a quality review of the testing performed on the IESM sub-project to ensure it was adequate and thorough.
Managementís Response:† Lessons learned have been applied to the ESM project schedule, the ITS schedule has been incorporated into the modernization Integrated Master Schedule (IMS), oversight activities have been conducted to monitor the project schedule, and new procedures have been implemented to oversee the project.† New processes were issued, effective February 25, 2002, for reviews of the RIS activities and the IMS.† This will help the PRIME and the IRS establish firm IMS activities and provide for regular reporting on activity status to reduce or minimize future delays.
The PRIME conducted a review to ensure the project was ready to start system and release integration tests.† The PRIME Quality Assurance and Configuration Management organizations reviewed the testing documentation and system baseline information prior to testing, and the project team conducted a review of the system integration test results.††
The IRS and CSC created a process for developing BSM projects called the Enterprise Life Cycle (ELC).† The ELC establishes a set of repeatable processes and integrates with the IRS processes by which managers are accountable for making key decisions about resource allocation for system development, enhancement, and management.†
Because the ESM project was primarily an implementation of off-the-shelf software packages, the project team determined it would follow an approved ELC path that includes less formal requirements management techniques.† Although the ESM team developed a formal System Requirements Report (SRR) to provide the basis for the projectís logical design, the less formal activities that were performed to gather requirements from the various projects did not timely identify and document all the needs the ESM project will be expected to address.† In addition, analysis of requirements for feasibility and completeness was not documented, and issues identified in a third-party review of the SRR were not addressed.† As a result, the requirements that the ESM project team must address for the projects that will deliver taxpayer benefits during 2002 were not identified and documented at the conclusion of our review.
Methods used to gather and analyze ESM project requirements did not timely identify and document key needs of projects
The ESM project is an infrastructure project that will provide systems management support to other projects.† The ESM project team is dependent on other project teams to provide their needs and expectations for the systems they are attempting to develop.† Some modernization project teams have found it difficult to identify their system performance requirements.†
For example, the STIR project team, which plans to deploy an initial release in early 2002, experienced significant delays in refining the specific services that they require from the ESM project for successful deployment of the release.† The agreement that documents the needs of a project team and the services that will be provided to meet these needs is known as a Service Level Agreement.† The IRFOF project, which is also scheduled for deployment in early 2002, had not yet completed a Service Level Agreement to document its needs from the ESM project team when we completed our review.† Without a timely agreement, the ESM project may not be able to provide the data that managers need to monitor whether or not the system is meeting taxpayersí needs.
In March 2001, the ESM project team hosted a 2-day review of the first draft of the SRR with 11 representatives from the ITS organization.† The ELC recommends this type of an initial workshop to identify and quantify functional, performance, operational, and programmatic requirements.† Additional meetings, workshops, or other techniques are recommended to further define and validate system requirements.† However, although the project team indicated that other meetings were held, it could not provide documentation of these meetings or any other techniques used to assist projects in further defining their system requirements.† In addition to the requirements development issues, the ESM project team did not document any analysis of requirements for feasibility, completeness, and consistency.†
The more formal ELC path requires that system requirements be analyzed to ensure they are complete, consistent, verifiable, and feasible within existing projected technical, schedule, and budget constraints.† In this path, project teams are responsible for:†
∑ Developing complete, consistent, and feasible requirements that the system will meet.
∑ Developing a comprehensive system verification approach based on the defined requirements.
∑ Validating that the requirements satisfy business needs and are consistent with enterprise-wide business and technical standards.
However, the ESM project team selected an approved path with a much less stringent process for managing system requirements.† The path the ESM project team selected does not include formal requirements management as an integral component of the process.† Use of a more formal process for ESM project requirements would provide better assurance that projects designed to serve taxpayers in 2002 and into the future will be appropriately managed.
In February 2001, the ESM project team documented the modernization projectsí inability to identify their specific performance parameters and operations support requirements as a risk.† The ESM project team had developed action items to reduce this risk, including the preparation of a detailed questionnaire to solicit needed requirements.† However, these risk reduction activities were not being performed or tracked.
The ESM project manager indicated that his team is working to develop a more formal process to obtain requirements from the projects they support.† In addition, a field may be added to the Requirements Management database for documentation of the analysis of system requirements.† However, these activities had not occurred at the time of our review.
Requirements issues identified by an independent contractor were not addressed
The MITRE Corporation is under contract to assist the IRS with systems modernization.† MITRE provides the IRS with specific expertise in areas including evaluating proposals, performing specific research, and conducting testing activities.† During April 2001, MITRE reviewed version 2 of the draft SRR.†
The SRR is designed to capture and substantiate the requirements for a project.† This task is difficult, particularly for an infrastructure project such as the ESM project, which touches all modernization and operation projects.
Although some improvement had been made to the SRR document, MITRE identified several process steps from the ELC that were not being followed and made several recommendations to be incorporated into the final SRR.† These recommendations included:
∑ Adding activities to the work breakdown structure to maintain issue reports or issue logs for developing requirements.
∑ Working with business owners to establish Service Level Agreements and to identify performance measured parameters.
∑ Making requirements more explicit or detailed so that they can be tested or substantiated in the testing phase.
MITRE indicated that following ELC processes were critical to the success of the ESM project team in recognition of other project issues, including integration issues with the ITS organization and the aggressiveness of the deployment schedule.
The ESM project team could not provide us with any evidence that they had addressed MITREís concerns in the final version of the SRR.† The ESM project manager indicated that the ESM project team did not address these concerns because they were not directed to do so by the BSMO.† While we understand the BSMO has the option to accept or reject MITREís recommendations, we believe that some of the actions recommended to improve the SRR, such as the establishment of performance parameters and making requirements more detailed, should have been taken.†
When requirements are not readily identifiable, the ESM infrastructure project team should be proactive in assisting the projects in developing them, and should follow stringent requirements management processes as described in the more formal path of the ELC.† When system requirements are not analyzed for completeness, consistency, and feasibility, the ESM project team cannot guarantee that the expectations for service and support will be met for the BSM projects it supports.†
Although the FY 2002 projects may be deployed without having all of their ESM project requirements fully defined, data that managers need to ensure taxpayers are being adequately served may not be available.† In addition, problems that occur within these systems may not be timely identified or resolved without the capabilities that the ESM project will provide.
To help ensure that business requirements are adequately identified and included in the ESM project, we recommend that the BSMO require the ESM project team to:
3. Develop and implement formalized, proactive methods for assisting other modernization projects in developing Service Level Agreements and refining their system requirements.† These methods and the results of the workshops to develop requirements should be documented.
4. Address MITREís recommendations from the review of the ESM projectís SRR.
Managementís Response:† The ESM requirements manager works proactively with modernization projects to educate and gather requirements from stakeholders.† The project team has developed a guide to help project members understand how to develop ESM requirements and includes an interview questionnaire.† Since the audit was completed, the ESM project has considered MITREís recommendations and has incorporated them into guidance as appropriate.
The ESM project team was not following critical risk management processes included in the ELC requirements.† We found that the risk management database used by the project manager to track risks and mitigation action items was not adequately maintained.
For example, the description of one of the project risks was very long, and was almost a ďcatch-allĒ risk that covered various potential problems related to the ESM projectís dependency on the ITS organization.† In addition, risk reduction actions had not been assigned or monitored, and several critical items, including those related to requirements management and dependencies on the ITS organization, were past due.† Also, several project risks remained open, even after they should have been closed.†
The ELC states that risks must be managed throughout the project.† Managing risk requires the identification, evaluation, mitigation, and re-evaluation of events that may have an unfavorable impact on the work.
In June 2001, the ESM projectís risk manager left and for several months the project team used an interim risk manager, who was less familiar with the ELC requirements for managing the risk process.† The ESM project manager recently appointed a new risk manager, and at the time we completed our review, the ESM project team was focused on updating the risk management database and identifying new risks.
In order for the ESM project to be successful, the project team must actively manage its risks and the activities designed to reduce those risks.† When this does not occur, risks could be realized, resulting in project delays or an inability to provide critical support for modernization projects that are designed to provide service to taxpayers.
To ensure that project risks are adequately managed, we recommend that the BSMO require the ESM project team to:
5. Timely identify, document, assign, track, and report on all project risks and associated mitigation action items.
Managementís Response:† The BSMO requires the PRIME to use the Issues Tracking System and associated risk management processes.† The ESM project manager and other assigned personnel are conducting weekly reviews of the risk database to ensure timely actions are taken to help mitigate project risks.
Because of delays in development and deployment of the overall BSM program Enterprise Architecture, the ESM project team did not have complete guidance to develop portions of its project.† The ESM project team was requested to help develop sections of the overall architecture.† As a result, the project appears to be driving the architecture rather than the program architecture providing the direction for the project.† The ESM project team believes this may be addressed in the draft version 2.0 of the Enterprise Architecture that was recently released.† We are following up on this issue in a separate audit of the Enterprise Architecture.
Secondly, significant amounts of ITS funding, outside of the modernization funding process, are being used to develop portions of the ESM project.† Funds used in the modernization program are subject to high levels of Congressional and third party oversight and scrutiny because of past modernization failures by the IRS.† Although we do not necessarily disagree with the use of ITS funding for modernization projects, we believe that this use, when significant, should be disclosed in the spending plans that are prepared for and reviewed by the Congress, the GAO, and the Office of Management and Budget.†
The overall objective of this review was to determine whether the Enterprise Systems Management (ESM) project team was effectively developing its major sub-systems and following the key processes necessary to ensure the projectís success.
To complete our work on this review, we conducted the following tests:
I.† † Determined whether the ESM project was being effectively developed to deliver its intended benefits on schedule and within its original budget.
A.††††††††††† Reviewed the past and current Business Systems Modernization (BSM) Expenditure Plans, the Core Business Systems Executive Steering Committee meeting minutes, and the ESM Work Breakdown Structures to determine whether the projectís activities and costs were on target.† When the project exceeded its schedule and budget, we determined whether the milestone dates had changed.
B. Interviewed project personnel and reviewed relevant documents to determine the current status of the project.† When the project was behind schedule, determined the reasons for and the impact of the schedule slippage and cost overruns.
II.† Determined whether the ESM project was following critical Enterprise Life Cycle (ELC) processes.
A.††††††††††† Configuration Management:
1. Determined whether the ESM project configuration management plan addressed the key processes and controls required by the ELC.
2. Determined whether a repository for project documentation had been established.† Reviewed how it was maintained, who was responsible for maintenance, and whether all of the projectís approved baselined documents were controlled in the repository.
a. Determined whether all approved documents for Milestones 1, 2, and 3 had been baselined, assigned a logical version control number, and controlled in the repository.
b. Determined whether access to the baselined documents in the project repository was properly restricted.
c. Determined whether ESM project personnel had received training in configuration management processes, procedures, and use of the repository.
B.†† Risk Management:
1. Determined whether all critical documented risks were timely reported to the appropriate officials and addressed with mitigation plans.
2. Reviewed mitigation plans to determine whether the plans addressed the risks, and whether the action items contained in the plans had been assigned, were being tracked, and were on schedule.
3. Analyzed the most current Work Breakdown Structure to determine how far the project was behind schedule.† Ensured the impact of the slippage was properly documented in the Risk Inventory and Assessment Worksheet.†
C.††††††††††† Requirements Development:
1.††††† Interviewed project management to determine the changes in the ESM projectís baseline scope, requirements, and overall responsibility.
2.††††† Interviewed project management to determine the reason for the shift in responsibility from the ESM project team to the Information Technology Services (ITS) organization.
3.††††† Determined whether a formal process was being used to gather systems and operations support requirements from other modernization projects.
4.††††† Determined whether the requirements were documented; analyzed for consistency, completeness, and feasibility; and approved by both Business Owners and ITS management.
5.††††† Reviewed the projectís System Requirements Report and determined whether recommendations made in the MITRE Corporationís review of the draft version of this report were addressed.
6.††††† Determined whether a process had been developed for coordinating requirements with the ITS organization.
7.††††† Interviewed project management to determine the impact of the changes in scope, requirements, and schedule on the other modernization projects.
8. Interviewed project management and reviewed the March 2001 BSM Expenditure Plan to determine if the changes in the ESM projectís requirements and the impact of schedule delays had been reported to the appropriate Congressional Subcommittees.
III. Determined whether the ESM project team was taking all of the necessary actions to ensure compliance with the Enterprise Architecture plan.
A. Interviewed project management to determine the actions taken to ensure the ESM projectís design was developed in compliance with the Enterprise Architecture.
B. Determined whether the Architecture and Engineering Group (AEG) approved project deliverables and whether the ESM project team attended meetings and workshops conducted by the AEG to discuss the updates to the Enterprise Architecture.† Obtained copies of approval documents, relevant meeting minutes, and lists of attendees.
C. Determined whether the Computer Sciences Corporation integrated, reviewed, and refined the business and technical architecture during the ESM projectís design and development (Milestone 3) before integration and testing (Milestone 4).
D. Reviewed the projectís Package System Design Report and determined how the delay in completing the Enterprise Architecture version 1.1 impacted the project design and initial release strategies.
E. Determined whether the Director of Architecture and Engineering approved the ESM projectís architecture and whether certification had been received from the IRSí Chief Information Officer prior to exiting Milestone 3.
Scott E. Wilson, Assistant Inspector General for Audit (Information Systems Program)
Scott Macfarlane, Director
Tammy Whitcomb, Audit Manager
Michelle Griffin, Senior Auditor
Jimmie Johnson, Jr., Senior Auditor
George Franklin, Auditor
Albert Greer, Auditor
Suzanne Noland, Auditor
Deputy Commissioner† N:DC
Associate Commissioner, Business Systems Modernization† M:B
Advisor to Associate Commissioner, Business Systems Modernization† M:B
Deputy Associate Commissioner, Systems Integration† M:B
Director, Infrastructure Modernization† M:B:IF
Chief Counsel† CC
National Taxpayer Advocate† TA
Director, Legislative Affairs† CL:LA
Director, Office of Program Evaluation and Risk Analysis† N:ADC:R:O
Office of Management Controls† N:CFO:F:M
††††††††††† Associate Commissioner, Business Systems Modernization† M:B
The response was removed due to its size.† To see the complete response, please go to the Adobe PDF version of the report on the TIGTA Public Web Page.