Critical Processes and Dependencies Need to Be Addressed to
Avoid Further Delays in Deployment of the Enterprise Systems Management Project
May 2002
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
MEMORANDUM
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.
Aggressive
Scheduling and Delays in Completion of Tasks Continue to Contribute to Project
Delays
The
Requirements Management Process Needs to Be Strengthened and Formalized
The Project
Team Was Not Following Critical Risk Management Processes
Observations
on Program-Related Issues
Appendix
I – Detailed Objective, Scope, and Methodology
Appendix
II – Major Contributors to This Report
Appendix
III – Report Distribution List
Appendix
IV – Management’s Response to the Draft Report
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.
Appendix I
Detailed Objective, Scope, and Methodology
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.
Appendix
II
Major Contributors to This Report
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
Appendix III
Commissioner N:C
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
Audit Liaison:
Associate
Commissioner, Business Systems Modernization
M:B
Appendix IV
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.