Tax Systems Modernization: Blueprint Is a Good Start But Not Yet Sufficiently Complete to Build or Acquire Systems
Released: 1998-02-24T00:00:00

Letter

Background

IRS envisions a future in which its tax processing environment will be virtually paper-free and taxpayer information will be readily available to IRS employees to update taxpayer accounts and respond to taxpayer inquiries. To accomplish this, IRS embarked on an ambitious systems modernization program, called Tax Systems Modernization (TSM). In 1995, we identified serious management and technical weaknesses in TSM that jeopardized its successful completion, made more than a dozen recommendations to fix the problems, and designated TSM as a high-risk information technology initiative in our biennial report series on high-risk federal programs. We again designated TSM as high-risk in our 1997 report series.

To correct modernization weaknesses, we recommended in our 1995 report, among other things, that the Commissioner of Internal Revenue ensure that IRS (1) implements disciplined processes for requirements management, investment decision management, and system development management, and (2) completes an integrated system architecture, including data and security subarchitectures. IRS agreed with all of our recommendations.

In June 1996, we reported that while IRS had initiated a number of actions to address our recommendations, many of these actions were incomplete and none, either individually or collectively, responded fully to any of our recommendations. Accordingly, in the conference report accompanying the fiscal year 1997 appropriations act (P.L. 104-208, Sept. 30, 1996), the Congress took several actions, including directing Treasury to develop a blueprint to define, direct, and control future modernization efforts. On May 15, 1997, Treasury submitted its modernization blueprint to the Congress. The blueprint consisted of four documents: (1) an SLC overview that provides a high-level framework for defining a disciplined set of processes for managing the modernization, (2) about 3,600 broad business requirements, (3) high-level functional and technical architectures that generally describe the target systems environment, and (4) a general sequencing plan for transitioning from IRS’ current to its target systems environment.

IRS’ SLC Overview Is Conceptually Consistent With Best Practices but Lacks Adequate Process and Product Definition

IRS’ SLC overview is consistent with general approaches used by successful private and public sector organizations for managing large information technology investments. The macro-level practices described in the overview provide the framework for planning, controlling, developing, and deploying information systems based on defined activities, events, milestones, reviews, and products.

IRS’ SLC overview, which is summarized in table 1, consists of phases, processes, and products. The phases, listed as columns in table 1, are:

Requirements Management. This phase addresses the questions of what is needed and how to satisfy the need(s). It includes (1) identification and definition of information technology needs; (2) conduct of technical analyses (e.g., cost estimates, architectural impact assessments) for each defined need; (3) development of individual business cases (i.e., investment justifications) that include architectural impact and cost/benefit results; and (4) prioritization of competing business cases by type (new development, maintenance, and research and development). Investment Decision Management. This phase includes activities and documentation to determine how much should be spent and what should be developed and deployed. During this phase, business cases are rank ordered by type on an agencywide basis, investment decisions are made (i.e., business cases are approved and funded on the basis of investment costs and benefits), and investment decisions are monitored over time to determine actual costs incurred and benefits realized.

System Development/Operations Management. This phase defines, sequences, and documents activities necessary to develop, deploy, operate, and maintain systems. It consists of (1) research and development, which includes prototype development and evaluation; (2) engineering, which includes system requirements analysis, systems design, release definition, release requirements analysis, and release system design; (3) design and development, which includes configuration item requirements analysis, preliminary design, detailed design, code and unit testing, and integration and testing; (4) integration, test, and deployment, which includes release integration and testing, release system acceptance testing, system piloting, and system rollout; and (5) maintenance, which includes release design, code and unit test, and integration and test.

Management Control and Oversight. This phase spans each of the three aforementioned phases. It includes change control management (i.e., determining what to change and when), configuration management (i.e., capturing and maintaining records of the changes), performance management (i.e., measuring progress against baselines), organizational management (i.e., determining who is responsible for what), and audit and evaluation process management (i.e., determining whether SLC processes are effective and being followed).

Associated with each phase, and shown as rows in table 1, are (1) detailed process definitions, which describe the functions that are performed and how they are performed, (2) key actions that need to be taken to implement the processes, and (3) key products that are prepared as a result of the processes’ execution.

IRS’ SLC Is Incomplete

While the SLC overview provides a framework that is consistent with public and private sector best practices, IRS’ SLC is incomplete and does not yet provide the specificity needed for building or acquiring systems. As IRS recognizes, its SLC does not yet specify how technology investment activities will be performed. For example, it does not specify (1) how work processes will be reengineered; (2) how business requirements will be specified; (3) how engineering solutions will be developed; (4) how business cases for technology investments will be formulated and evaluated; (5) how systems conforming to architectural standards will be developed; (6) how operational systems conforming to architectural standards will be maintained; and (7) how technology investments will be evaluated using performance metrics.

The SLC shortcomings fall into three categories (see table 2). First, IRS does not yet have detailed process definitions for any of the SLC phases. For instance, IRS has not clearly defined how requirements will be formulated and how they will be assessed and prioritized; how projects will be controlled and evaluated; what data will be required and what evaluation criteria will be used; how system designs will be assessed and how system developments and acquisitions will be managed; and how architectural compliance will be determined and enforced. Without these process definitions, IRS cannot validate that the blueprint products published as of May 15, 1997, are correct and consistent. Moreover, IRS cannot adequately develop the level of detail and precision that, as discussed in the following section of this report, these blueprint products currently lack.

Second, because it has not yet defined detailed SLC processes, IRS has not yet implemented its SLC. For example, handbooks have not been prepared and training has not been conducted for any of the SLC phases. Further, organizational roles and authorities have not been adequately specified, making it unclear who does what in each SLC process and phase. For instance, as described in the modernization blueprint, the IRS chiefs will be responsible for reengineering business processes and developing business requirements, but it is unclear who has the responsibility and the authority to ensure that the reengineered processes and specified requirements are prioritized and optimized agencywide. Similarly, although the CIO is responsible for developing architecturally compliant engineering solutions to satisfy business requirements, the CIO does not control all system development resources. Moreover, as discussed later in more detail, neither the CIO nor any other organizational entity has sufficient authority to implement SLC processes and enforce architectural compliance agencywide.

Third, many SLC products have not been defined or developed. For example, IRS does not have an agencywide, rank ordered, portfolio of investment options. Moreover, some investments are not supported by business cases (i.e., business need documents, cost and schedule estimates, analyses of the organizational and technical impact of the proposed solution(s) on the phases and releases of the sequencing plan and on the architecture, and analyses of the proposed solution(s) expected return on investment).

Blueprint Products Are a Good Start but Are Incomplete or Insufficient

While the products constituting IRS’ May 15, 1997, modernization blueprint represent a good first step and a foundation upon which to build, none are complete. In particular, the business requirements are not precise enough and the architecture is not sufficiently complete to build or acquire systems. Additionally, the sequencing plan does not provide sufficient detail to understand the transition to the target systems environment.

Business Requirements Are Insufficiently Precise

IRS has divided its tax administration workflow into the following six core functional areas.

Submissions processing, which is the primary source of data entering the workflow. It provides for the collection and correction of data extracted from paper and electronic tax returns, payments, and information returns as well as forwarding of these data to the corporate processing function for storage and access control.

Corporate data processing, which includes receipt of data from the submissions processing function and storage of data in enterprisewide databases. It provides for controlled access to a single, authoritative source of corporate data in support of the customer service, compliance, and financial reporting workflow functions.

Customer service, which provides the primary, non-face-to-face interface to taxpayers primarily through correspondence and telephone contacts.

Compliance, which provides the primary, face-to-face interface to taxpayers in resolving collection, exam, and other compliance cases.

Financial reporting, which is integrated with each of the workflow functions that update financial data and provides traceability to the source of all financial updates and summary financial reporting. Information system infrastructure, which supports the other five functional areas by providing communication networks, computing platforms, workstations, and development facilities.

For each of these core functional areas, the IRS business users developed “guiding principles” that were intended to provide a framework for developing modernization business requirements. For example, the submission processing guiding principles state that IRS will (1) receive submissions from taxpayers and third parties on approved media, (2) perform up-front manual processing for nonelectronic submissions, (3) define interface protocols for electronic submissions, (4) transform nonelectronic submissions into electronic representations, and (5) perfect submissions. Similarly, some of the customer service guiding principles state that IRS will (1) provide non-face-to-face communication with taxpayers via various communication media, (2) provide access to taxpayer account and non-account data without geographic restriction, and (3) accept taxpayer data via various communication media.

Using these guiding principles, IRS developed about 3,600 business requirements that it believes represent IRS’ mission needs. To IRS’ credit, some of these requirements provide for significant improvements in IRS’ financial management capabilities. For example, they include a general ledger that is transaction-based and conforms to federal automated capture of nonfinancial performance information, such as the number of transactions, calls, paper returns filed, and electronic returns filed; improvements in management information for receivables; the ability to trace significant transactions and documents; and prompt and accurate recording of seized asset transactions.

However, some of the requirements are insufficiently precise to be useful in building or acquiring systems. For instance, our audits of IRS’ financial statements have reported the need for IRS to correct the serious problems that caused us to designate IRS’ accounts receivable as a high-risk area. To help address these weaknesses, we have recommended that IRS maintain a subsidiary ledger or similar mechanism to routinely track the status of and to assist in managing accounts receivable. However, the business requirements do not describe the subsidiary accounts receivable records in sufficient detail to show that IRS plans to implement such a mechanism. For example, they do not specify whether the subsidiary records will provide for tracking accounts receivable on a receivable-by-receivable basis and include such information as (1) the age of the receivable, (2) the status of any payments received, (3) the accrual of any interest and penalties, (4) the status of the taxpayer’s ability to pay any remaining balances, and (5) the nature of the receivable (i.e., a balance due, created by examination).

In another case, a business requirement under the infrastructure systems core functional area calls for “supporting all five levels” of the Software Engineering Institute’s (SEI) software development Capability Maturity Model (CMM). The model’s five levels of maturity provide users with a four-step, sequential approach for incremental process improvement. In 1995 and 1996, we reported that IRS was a CMM level 1 organization, SEI’s lowest level, meaning that its software development processes were ad hoc and sometimes chaotic. Since a substantial process effort is required to move from CMM level 1 to level 2, and from there to each higher level, IRS’ stated business requirement of “supporting all five levels” is too vague and imprecise to be meaningful. Rather than calling for support of all five CMM levels, IRS needs to require incremental attainment of CMM levels, as SEI advocates, according to a specified schedule, such as level 2 within 2 years and level 3 within 4 years. Without precise goals, IRS cannot implement an effective process improvement program.

Also, some of IRS’ guiding principles are not reflected by specific business requirements. For example, the guiding principles that (1) 45 percent of all taxpayer inquiries be resolved via automated systems and (2) 95 percent of all inquiries be resolved in the initial contact could not be reconciled with customer service business requirements specifying the volume of calls that will be resolved. In addition, some key terms in the principles are not well defined. For example, the terms “initial contact” and “resolution” are not defined. IRS is currently reassessing its guiding principles and its business requirements.

Architecture Is Insufficiently Detailed

IRS’ architecture consists of two components: a functional architecture and a technical architecture. The functional architecture defines in business terms the activities/subfunctions that support the six core functional areas discussed earlier, the relationships among these activities/subfunctions, and the data required to support these activities/subfunctions. The technical architecture defines subsystems, configuration items, data allocations, interfaces, and common services that collectively provide a physical view of the target systems environment.

Consistent with best practices in both industry and government, the architecture provides traceability among the business requirements, functions and subfunctions, and subsystems. That is, each of the blueprint’s approximately 3,600 business requirements can be mapped to general points in the architecture where they are addressed. Traceability is critical to ensuring that systems meet users needs.

The architecture has other positive attributes. For example, it specifies a data subarchitecture consisting of five primary databases and 18 supporting databases characterized as (1) mission-critical, such as a financial accounting database required to support revenue accounting, tracking, and reporting; (2) submissions management support, such as a state return database containing the data of electronically filed state tax returns; (3) security requirements support, such as a security audit database containing data used to track and audit behaviors observed by technical mechanisms that secure sensitive data; and (4) systems management and systems development support, such as a configuration management database containing information used to manage the development and operational configuration of the modernization systems.

Also, the architecture includes a security subarchitecture that addresses data privacy and security. It articulates the need to provide user identification and authentication, to build security profiles specifying transactions and patterns of transactions for which a user is authorized, and to limit the transactions that users can perform to those included in their profiles. Information transmitted over data communications networks like the Internet would be protected through the use of encryption. Security-relevant audit data would also be collected, aggregated, and analyzed.

Despite the architecture’s positive attributes, it does not yet include implementation details and therefore is insufficiently complete to use in building or acquiring systems. For example, whereas the intention to ensure the confidentiality of taxpayer data is clear, the method to be used is unspecified; and whereas the intention to use data encryption is clear, encryption products and approaches are unspecified. Additionally, the architecture does not sufficiently define the data administration function, and business requirements have not been allocated to specific configuration items (i.e., actual hardware or software components). As a result, it is not yet known which of the system components will satisfy which of the requirements, or how it will do so.

Sequencing Plan Is Not Sufficiently Complete

To aid in implementing its target architecture, IRS developed a sequencing plan for transitioning from its current to its target systems environment. To do so, IRS first analyzed existing system platforms, applications, databases, and infrastructures to identify system duplications and gaps as well as systems with “the best functionality” that should be preserved. According to IRS, it then applied three criteria to define a cost effective, risk mitigated sequence within which it would introduce new or modified systems and retire existing systems. The criteria are: focus on systems to support IRS business priorities; limit the need for complex system interfaces, large-scale data conversions, and continuous disruption of business operations; and minimize the need to develop interim systems and interfaces and make centralization of duplicative, stand-alone applications and systems a priority.

The result was a sequencing plan that divides the transition into six incremental phases within which software, hardware, and supporting infrastructure components will be developed, acquired, and deployed. Each phase in turn is segmented into multiple releases, which consist of actual software/hardware upgrades, improvements/enhancements, and replacements as well as existing system capability retirements or deactivations. According to IRS, the order of the phases is based on criteria such as IRS’ business priorities and a migration plan. (See table 3 for a summary of the six phases.)

While the sequencing plan describes IRS’ general intentions for migrating from its current to its target systems environment, the sequencing plan does not provide the fundamental and critical detail needed to fully understand or execute this transition. For example, it does not specify (1) the schedule and cost estimates for any of the phases or releases, (2) the projects that will constitute the phases or releases, (3) the projects’ cost and schedule estimates, and (4) the projects’ interdependencies.

Additionally, the sequencing plan does not describe precisely what is intended to occur as subfunctions evolve through the various phases and releases. For instance, a subfunction called Case Analysis and Resolution is shown as new in phase 1/release 1. It is then shown as changed in 10 subsequent releases, but none of the planned changes are explained.

Further, the sequencing plan indicates that several legacy systems, such as the Electronic Audit Research Log (an automated tool to monitor and detect browsing) and the Integrated Data Retrieval System (the primary system through which IRS employees access taxpayer accounts), will be replaced. However, the plan does not identify what will replace them or how the replacement will be accomplished.

SLC Products Have Not Been Validated Using Defined, Implemented SLC Processes

The processes to validate SLC products, including the business requirements, the architecture, and the sequencing plan, have not yet been defined in detail nor have they been implemented. As a result, none of the products submitted as part of the IRS blueprint on May 15, 1997, have been validated using defined, implemented SLC processes.

Agencywide Responsibility and Authority for Implementing and Enforcing the Blueprint Has Not Been Established

Information management reforms enacted in the Paperwork Reduction Act of 1995 and the Clinger-Cohen Act of 1996 direct the heads of major agencies to appoint CIOs. The legislation assigns a wide range of duties and responsibilities to CIOs, including (1) helping to establish sound information technology investment management processes, (2) implementing an integrated agencywide technology architecture, and (3) strengthening the agency’s capabilities to effectively manage information resources and develop needed systems. Additionally, this legislation, Office of Management and Budget guidance, and our research into how leading public and private sector organizations successfully manage information technology define common tenets for the CIO position. Among these tenets is the need for the agencies to support the CIO position with an effective CIO organization and management framework for implementing agencywide information technology initiatives.

The legislation establishes the CIO position at executive branch agencies and sets forth special requirements for CIOs at the 24 agencies where the Chief Financial Officers Act of 1990, as amended, established chief financial officer positions. In addition, we have supported the establishment of a CIO structure at the agency subcomponent and bureau levels, such as IRS. Such a management structure is particularly important in situations where the departmental subcomponents, like IRS, have large information technology budgets or are engaged in major modernization efforts that require the substantial attention and oversight of a CIO. In the Conference Report on the Clinger-Cohen Act, the conferees recognized that agencies may wish to establish CIOs for major subcomponents and bureaus. These subcomponent-level CIOs should have responsibilities, authority, and management structures that mirror those of the departmental CIO.

In 1995, we reported that IRS had not established an effective organizational structure to manage systems modernization agencywide. Specifically, IRS’ modernization management structure was fragmented and did not provide for agencywide control over all new modernization systems and all upgrades and replacements of operational systems. As a result, we recommended that the Commissioner assign the Associate Commissioner/Modernization Executive management and control responsibility for all systems development activities, including those of IRS’ research and development organization. Since that time, IRS has appointed a CIO and established an Investment Review Board, and Treasury has taken a more active role in overseeing the modernization. However, organizational control over IRS’ huge information technology investment portfolio continues to be a problem. The CIO does not control all information systems activity and thus cannot effectively enforce compliance with established system process and product standards. In particular, the CIO does not have budgetary and organizational authority over all IRS systems development, research and development, and maintenance activities.

Congress Has Limited IRS Modernization Spending Until Blueprint Is Completed

In June 1996, we reported that while IRS had initiated a number of actions to respond to our recommendations for correcting pervasive management and technical weaknesses in TSM, many of these actions were incomplete and none, either individually or collectively, responded fully to any of our recommendations. Accordingly, we suggested that the Congress consider limiting TSM spending to only cost effective efforts that (1) support ongoing operations and maintenance; (2) support ongoing IRS efforts to instill requisite SLC discipline, including completing and enforcing the architecture, institutionalizing disciplined software development and acquisition processes, and improving its information technology investment management; (3) are small, represent low technical risk, and can be delivered in a relatively short time frame; or (4) involve deploying already developed systems, only if these systems have been fully tested, are not premature given the lack of a completed architecture, and produce a proven, verifiable business value. The act (P.L. 104-208, Sept. 30, 1996) and conference report providing IRS’ fiscal year 1997 appropriations limited IRS’ information technology spending to efforts that were consistent with these categories.

In September 1997, we briefed IRS’ appropriations and authorizing committees on the results of our assessment of IRS’ May 15, 1997, blueprint. In the conference report accompanying the IRS fiscal year 1998 appropriations act, the conferees agreed with our findings. Accordingly, they limited IRS spending for fiscal year 1998 to efforts that were consistent with the aforementioned spending categories. Additionally, IRS’ fiscal year 1998 appropriations act (P.L. 105-61, Oct. 10, 1997) states that fiscal year 1998 or prior year “Information Systems” appropriations are not available to award or otherwise initiate a prime contract to implement IRS’ modernization blueprint. The act also states that fiscal year 1998 “Information Technology Investments” funds are not available for obligation until IRS and Treasury submit to the Congress a plan for expenditure that, among other things, implements the blueprint. The conference report on the act adds that details of the blueprint need to be completed before IRS commits to build or acquire new systems.

Conclusions

IRS’ May 15, 1997, modernization blueprint provides the foundation for specifying IRS’ future systems environment and a disciplined approach for delivering this environment. However, none of the blueprint components are detailed or complete. As a result, the components do not yet provide an adequate basis for effectively and efficiently developing or acquiring systems. In addition, the business requirements, architecture, and sequencing plan have not been validated using defined and implemented SLC processes. As a result, IRS cannot assure itself that these SLC products constitute the correct course of action for the agency to follow in modernizing its information systems.

IRS’ CIO recognizes these shortcomings and has committed to completing, implementing, and enforcing all SLC processes and completing, validating, and enforcing compliance with all SLC products before acquiring or developing systems. However, the CIO does not have the authority needed to enforce the modernization blueprint (once it is completed) agencywide. Until such authority is assigned, it is uncertain that even a completed blueprint could be used to overcome existing system incompatibilities and correct inefficient and ineffective IRS operations.

Recommendations

To ensure that IRS develops a complete blueprint for modernizing its information systems, we recommend that the Commissioner of Internal Revenue require the IRS CIO to: complete the definition and implementation of all SLC processes, including processes for ensuring disciplined software development and acquisition and for validating SLC products; for each phase of the modernization, define business requirements and complete the architecture with sufficient detail and precision to build or acquire systems; formulate a sequencing plan that specifies (1) phase and release cost and schedule estimates, (2) projects that constitute the phases and releases, (3) project cost and schedule estimates, (4) project interdependencies, (5) the evolution of architectural subfunctions, and (6) the projects that replace legacy systems that are eliminated; and validate the business requirements, architecture, and sequencing plan using the completed and implemented SLC processes.

To ensure that the modernization blueprint is implemented and enforced agencywide, we recommend that the Commissioner give the CIO: responsibility for developing, implementing, and enforcing SLC processes and products across IRS and requisite budgetary and organizational authority over all IRS systems development, research and development, and maintenance activities.

Further, until mature SLC processes for developing and acquiring systems have been implemented across IRS, we recommend that the Commissioner limit requests for future appropriations for information technology to only cost-effective efforts that support ongoing operations and maintenance, including all efforts to make IRS systems Year 2000 compliant; support ongoing IRS efforts to instill requisite SLC discipline, including completing and enforcing the architecture, institutionalizing disciplined software development and acquisition processes, and improving its information technology investment management; are small, represent low technical risk, and can be delivered in a relatively short time frame; or involve deploying already developed systems, only if these systems have been fully tested, are not premature given the lack of a completed architecture, and produce a proven, verifiable business value.

Agency Comments

In its comments, IRS characterized this report as complete, thoughtful, and balanced. IRS also agreed that (1) the blueprint is not yet complete and does not provide sufficient detail and precision for building or acquiring new systems and (2) the SLC needs to be completed and implemented as a precondition to completing and validating the blueprint as well as proceeding with the modernization. Additionally, IRS agreed with our concern about assignment of agency responsibility and authority for managing information technology and committed itself to addressing each of these findings in the coming months. IRS added that the report provided important insight and perspective in shaping these plans and moving IRS forward in a responsive and responsible manner.

We are sending copies of this report to the Ranking Minority Members of the Subcommittee on Treasury and General Government, Senate Committee on Appropriations and Subcommittee on Treasury, Postal Service, and General Government, House Committee on Appropriations; the Chairmen and the Ranking Minority Members of the Subcommittee on Taxation and IRS Oversight, Senate Committee on Finance, the Subcommittee on Oversight, House Committee on Ways and Means, the Senate Committee on Governmental Affairs, the House Committee on Government Reform and Oversight, and the Senate and House Committees on the Budget. We are also sending copies to the Secretary of the Treasury, the Commissioner of Internal Revenue Service, and the Director of the Office of Management and Budget. Copies will be available to others upon request.

This work was performed under the direction of Dr. Rona B. Stillman, Chief Scientist for Computers and Telecommunications, who can be reached at (202) 512-6412. Other contributors to this report are listed in appendix III.

Objectives, Scope, and Methodology

Pursuant to congressional direction in the conference report accompanying the fiscal year 1997 Omnibus Consolidated Appropriations Act (P.L. 104-208), on May 15, 1997, IRS issued a blueprint for defining, directing, and controlling its modernization. We assessed the blueprint’s four principal components (SLC, business requirements, architecture, and sequencing plan) to determine whether the blueprint provided the foundation needed to develop or acquire modernized systems. Our specific objectives were to determine whether IRS’ SLC was complete and consistent with best industry and government practices; the business requirements were sufficiently precise and the functional and technical architectures were sufficiently complete to build or acquire systems and the sequencing plan was sufficiently complete to understand the transition to the target systems environment; the business requirements, functional and technical architectures, and sequencing plan had been validated using defined and implemented SLC processes; and the information technology management structure was conducive to effective implementation and enforcement of the blueprint.

To accomplish our objectives, we interviewed senior IRS officials responsible for developing the modernization blueprint to determine how the blueprint was derived, including the processes followed, the participants involved, and the bases for and analyses supporting decisions made in developing it. We then reviewed and analyzed each component of the blueprint and its related documentation for completeness and sufficiency.

With respect to IRS’ SLC, we analyzed the overview document in relation to generally accepted government and industry standards for life cycle management of information technology investments. In the case of business requirements, we focused on two functional areas—customer service and financial reporting—because of their criticality to IRS’ tax administration mission and because we have completed a significant amount of audit work in these areas. For customer service, we determined whether the business requirements were consistent with IRS’ stated guiding principles. For financial reporting, we examined whether IRS’ requirements addressed Federal Accounting Standards Advisory Board standards as well as concerns that we have raised about IRS’ financial management capabilities in prior GAO reports. We also reviewed business requirements in IRS’ other core functional areas to determine whether they were generally clear and unambiguous.

Concerning the architecture and sequencing plan, we compared both documents to published architectural guidance to determine their completeness and specificity. For each of the blueprint components, we also questioned senior IRS officials about the documents’ completeness and specificity, as well as IRS’ plans for evolving, validating, implementing, and enforcing them.

With respect to IRS’ information technology management structure, we interviewed IRS officials about assignment of organizational and budgetary authority over IRS information technology investments as well as other formal mechanisms in place or planned to enforce IRS information technology investment (research and development, new systems development or acquisition, and system maintenance) conformance to the modernization blueprint.

In August and September 1997, we briefed senior IRS and Treasury officials, including the Acting Commissioner of Internal Revenue, the IRS CIO, the Treasury CIO, and the Treasury Acting Chief Financial Officer, on our assessment results, including our conclusions and recommendations.

We performed our work at IRS headquarters in Washington, D.C., between May 1997 and September 1997 in accordance with generally accepted government auditing standards.

Comments From the Internal Revenue Service

Major Contributors to This Report

Accounting and Information Management Division, Washington, D.C.

General Government Division, Washington, D.C.

Atlanta Field Office

Seattle Field Office

Karlin Richardson, Senior Evaluator Elizabeth Naftchi, Auditor The first copy of each GAO report and testimony is free. Additional copies are $2 each. Orders should be sent to the following address, accompanied by a check or money order made out to the Superintendent of Documents, when necessary. VISA and MasterCard credit cards are accepted, also. Orders for 100 or more copies to be mailed to a single address are discounted 25 percent.

U.S. General Accounting Office P.O. Box 37050 Washington, DC 20013 Room 1100 700 4th St. NW (corner of 4th and G Sts. NW) U.S. General Accounting Office Washington, DC Orders may also be placed by calling (202) 512-6000 or by using fax number (202) 512-6061, or TDD (202) 512-2537.

Each day, GAO issues a list of newly available reports and testimony. To receive facsimile copies of the daily list or any list from the past 30 days, please call (202) 512-6000 using a touchtone phone. A recorded menu will provide information on how to obtain these lists.