Continued Review of the Tax Systems Modernization of the Internal Revenue Service: Interim Report (1994)

This interim report is the fifth document in a series¹ begun by the National Research Council in 1990 at the request of the Internal Revenue Service. The purpose of the series has been to review the IRS’s Tax Systems Modernization (TSM) program. Like its predecessors, this report draws on IRS documents, agency briefings, follow-up meetings of committee subgroups, committee members’ expertise, and deliberations. Over the past 4 years, the committee has noted a number of beneficial changes in the IRS during the TSM program, including:

• the distribution of a concise business vision document;

• an agency-wide evaluation of how best to reorganize processes and people to leverage the capabilities provided by TSM;

• the inclusion of the Human Resources organization and the National Treasury Employees Union in the decision-making process;

• the creation of the privacy advocate position;

• the creation of an architect’s office, staffed with experienced system developers;

• the use of “technology refresh” clauses in procurement vehicles to reduce the use of obsolete technology; and

• the adoption of an incremental development schedule based on realistic functional requirements and existing capabilities.

All of these changes were necessary for TSM to progress and effectively improve IRS operations. In fact, 10 years from now, a retrospective analysis will show that much progress has been made. However, the committee continues to have very serious concerns about the IRS’s ability to successfully complete, on time and within budget, all of the TSM plans as currently defined.

An often-asked question concerning the IRS is, Will TSM succeed? The committee believes that this is the wrong question to ask. TSM is an extremely complex set of activities, and any attempts to analyze it must address the rate and direction of progress toward the overall project goals. A more appropriate question might be, Where does the IRS go from here with regard to TSM?

At this time, the committee believes that the IRS must improve its ability to:

• define and describe the overall architecture of TSM in sufficient detail to allow accurate analysis;

• adapt to, and incorporate evolutionary changes in, technology;

• manage a large number of related contract tasks over a long period of time;

• adapt to changing funding levels; and

• develop a mature software development organization.

In the sections that follow, the committee details its specific concerns and recommendations. Here it summarizes the most critical issues and recommendations:

• In response to congressional funding cuts, the IRS must prioritize and tighten TSM project plans. The total program must be leaner for the coming year, especially if funding is not restored to requested levels. The business vision document should be used as a test for inclusion of projects in the “tightened” TSM plan. Furthermore, some near-term and highly visible TSM deliverables are needed to provide clear evidence that the IRS is capable of progress toward TSM objectives.

• The IRS must develop a clear and concise software structural description for TSM that defines its fundamental capabilities, the overall design of key components, and the relationship between critical modules. That description must be used as the basis for all technical development decisions.

• Compared to other government agencies, the IRS’s systems development capability is still largely dated and rudimentary. Furthermore, the IRS’s efforts to improve its system development capability may not be able to keep up with changes in the field or the projected pace of TSM development. The IRS’s top managers appear to recognize this problem, but they need to prepare an overall process improvement plan that is closely coordinated with TSM schedules and contracts. They also need to hire key experienced development leaders and begin the improvement process immediately.

• The IRS has made significant progress with regard to the establishment of the privacy advocate’s office. The committee recommends that the IRS continue to enhance safeguards to privacy through the use of TSM capabilities. Furthermore, the IRS could assume a leadership role among federal agencies regarding the protection of information and personal privacy.

• Recognizing that the security architecture is incomplete, the committee recommends that senior IRS business managers direct and support a review of all in-place projects as well as projects currently being developed with regard to their security requirements and mechanisms. These evaluations will prevent expensive future program modifications.

• The Concept of Operations, Business Master Plan, Design Master Plan, and Integrated Transition Plan/Schedule must be made more precise during the current revision period by removing duplication, blending the plans from top to bottom, and matching them with the major goals in the business vision.

The committee emphasizes that comments and recommendations that appear to be critical of the IRS and TSM should not be interpreted as a diminution of the committee’s strong and continued support for TSM. Rather, they should be interpreted as a continuing endorsement of TSM and as an expression of the committee’s concern that TSM be moved forward as rapidly as possible so as to achieve the greatest degree of functionality possible within the current time and budget constraints.

The remainder of this report discusses the following topics:

• Background,

• Oversight and budgets,

• Software development,

• Privacy,

• Security,

• Planning and management,

• Human resources, and

• Telecommunications.

Each section describes what the committee has learned to date, outlines the issues of concern to the committee and, where appropriate, includes recommendations for specific actions.

Finally, it should be noted that many of the concerns discussed in this report have been raised previously by the committee; it is time to resolve them conclusively.

In 1990, the IRS asked the National Research Council to conduct a review of the Tax Systems Modernization initiative and provide an independent analysis of the feasibility of the program, taking into account both technical and management issues. The Committee on Review of the Tax Systems Modernization of the Internal Revenue Service met every two months from August 1990 to May 1992, usually with IRS representatives from both headquarters and field offices. Those representatives provided briefings and answered committee questions. The committee also examined a wide variety of documents and other material provided by the IRS.

The Tax Systems Modernization program was originally discussed as a set of integrated technical projects aimed at increasing the technical capabilities of the IRS. The total cost of the initiative was estimated to be approximately $8 billion (1991) and was expected to take approximately 10 years. Initial committee discussions focused on the planning and management of the program itself and on the specific technical capabilities being sought. Over time, however, both the committee and the IRS began to discuss the ramifications of TSM for almost every aspect of IRS operations, including human resources, training, operational support, and facilities management.

The committee issued an interim report to the commissioner of internal revenue on August 21, 1991, and published a full report in 1992.² The reports focused on the overall aspects of the TSM project and how the project would affect the IRS. The committee reported that there was an urgent need for a major IRS modernization, that the undertaking would require the cooperation of all IRS employees, and that it would take a long time to complete. Of particular concern to the committee was the need to encourage the active involvement of all operational elements within the IRS throughout the TSM process. Specifically, the committee expressed concerns about:

• a lack of clarity regarding the position(s) within the IRS that are accountable for TSM’s success,

• the need to involve operations and human resources leaders in all stages of TSM design and development,

• the need to develop a mature system and software development organization,

• a lack of understanding regarding the impact of TSM capabilities on the privacy of taxpayer information, and

• the need to develop a concise set of planning documents for the overall project and a consistent set of schedules and cost estimates that could be used to effectively manage the project.

The committee has noted previously that the IRS has made significant strides in responding to many of the comments and recommendations made in its reports and to inputs from various oversight organizations. Specifically, the committee has endorsed:

• the creation of the privacy advocate’s office to be the focus for all privacy concerns of the IRS,

• the creation of the architect’s office to be the focus for all TSM systems and software design and architecture issues,

• the inclusion of operational and human resources leaders in the decision-making process, and

• the recognition by IRS leadership that TSM involves more than just technological improvements.

In 1993, the IRS asked the National Research Council to continue reviewing the TSM program, focusing more on development and transition issues. A second committee was formed, including a number of members from the original committee and with more emphasis on technical (as compared to management) expertise. During 1994, the committee again met with IRS representatives to discuss what had transpired since the committee’s 1992 full report and the IRS’s plans for the future. Among the significant activities performed by the IRS during that period were:

• the refinement of the privacy policy document and the hiring of the privacy advocate,

• the publication of the Business Master Plan, including a concise vision of where the IRS hoped to be in operations and taxpayer services by 2001,

• a major reorganization of the IRS into core business groups that are headed by chief officers,

• the elevation of the TSM program manager to the executive level, and

• the start of the detailed planning for the transition of TSM into the operational areas.

This report represents an interim response to the commissioner of internal revenue and is intended to highlight those issues that are of particular concern to the committee and the IRS at this time. As such, some of the issues are still open to consideration and will be discussed throughout the next year. The committee’s concluding report will be published in late 1995.

During the past 18 months, two major factors have seriously, but understandably, delayed progress on TSM in many areas. The first factor was the reorganization of the IRS to more adequately mesh with its new business vision. This reorganization was previously recommended by this committee. Nevertheless, delays and plan revisions slowed progress.

The second and more recent major factor was the severe downward revision of the IRS’s appropriation request. As a result, previous plans and schedules are now outdated, and a concerted effort is now under way to bring them into alignment. While these delays are explainable and understandable, the committee perceives the IRS view to be that TSM will simply slip farther into the future and remain basically “as is”; that is, the IRS appears to be compensating for current budget reductions by simply waiting until “next year.”

Significantly, both the House Surveys and Investigation Staff (SIS) and the General Accounting Office have called for greater TSM program management oversight before significant investments are made in TSM. The reduction of the IRS’s modernization budget from $989 million to $650 million for FY 1995³ therefore is not surprising. The resulting budget cuts will affect (by the IRS’s own admission) the acquisition of the Document Processing System, software support acquisition, and the continued use of the Treasury Multiuser Acquisition Contract for desktop system acquisition, among other things. Rather than waiting until the cut was announced, IRS management should have developed contingency plans for such a situation. In fact, this reduction affirms the committee’s long-standing view that the TSM project is too large and all-encompassing to be achievable without extraordinary planning, comprehensive and enforceable controls, and strong management involvement throughout the organization. TSM will not just happen. IRS management must be monitoring every aspect of the program and plan for changes rather than react to them. The IRS cannot rely on the hope that funding levels will rise in FY 1996; it must develop strategies to deal with multiple possible funding levels.

The committee recommends that the following actions be undertaken immediately:

• The IRS must reprioritize TSM projects for 1995. The Business Master Plan must be revised and scaled back to the true essentials that will achieve the business vision without destroying it.

• Several “risk scenarios” (i.e., contingency plans) anticipating several different funding levels must be developed to allow the IRS to deal with future changes.

• Some immediate and highly visible deliverables are needed to show Congress, other government agencies, and the public that the IRS is capable of progress in the technical dimensions of TSM. The prioritization process must identify candidate projects (particularly those nearing completion) and focus management attention and resources on successfully implementing them within the next 12 months. Implementation results must be identifiable and measurable. A “public information” initiative about these projects must accompany these efforts.

Compared to accepted modern standards, the IRS’s internal systems development capability is still largely dated and rudimentary. The IRS’s efforts to improve this capability may not be able to keep up with changes in the field or the projected pace of TSM development. Further, the IRS’s ability to manage outside contractors who might correct these deficiencies is unproven at best. The principal problems faced by the IRS’s software development organizations are similar to those found in other government agencies that are attempting to modernize. Some problems are inherited, while others exist because of the sheer magnitude of the task at hand. Most importantly, there are no coherent software structural descriptions (architecture) by which to judge implementation issues or that will permit rational management of the overall software development effort.

Overall, the committee sees little evidence in the IRS of the type of “systems thinking” and large-system development experience that is absolutely necessary to make effective progress on complex system development projects. This deficiency is especially critical among senior management and thus in the fabric of the organization. While current efforts to hire experienced, highly qualified personnel are important, it should be noted that these new personnel will work in a complex organization. Even with more systems orientation at senior levels of management, it will still take considerable time to develop the overall organizational context in which effective systems development can be controlled. Although it will be a lengthy process, the IRS must move in the direction of building an organizational culture that understands system development; otherwise TSM will fail. The IRS would benefit greatly by examining how major corporations like Motorola, for example, have developed high-quality system development organizations.

Further investigation is warranted with regard to IRS software development capabilities and will be the committee’s focus during the next phase of its study. This investigation is certainly necessary to make more constructive suggestions and to help assess the degree of probable progress of TSM.

The IRS systems architecture document states that “heat and fury, but little light attend attempts to encourage diverse groups to settle on a common definition” of the term “architecture.” In order to be clear about the committee’s concerns (and to avoid the “heat and fury” of arguments regarding the definition of “architecture” or even “functional architecture”), the committee will use the term “structural description” to refer to a subject area that is of great concern.

A software structural description (SSD) is a specification of the software modules of which a system is composed and the informational interfaces or dependencies among those modules. (A module is a unit of software that has a name, can be manipulated as a

unit, and has a defined interface.) An SSD describes how the components within a system interact to perform the tasks required by an organization; that is, an SSD defines not only the parts of a system, but also how those parts work together. An SSD might also indicate:

• how capabilities are distributed across physical, organizational, or functional boundaries;

• evolutionary or scalability alternatives;

• how existing capabilities are leveraged; or

• how off-the-shelf products are used.

What the committee calls the SSD determines most of the essential characteristics of a system. A system’s complexity, efficiency, development cost, maintainability, and modifiability are strongly affected by the software structure. Without an SSD, it is impossible to evaluate the architecture or the design of a software system.

At this time (October 1994), the committee has not seen a software structural description of TSM. The committee has reviewed the functional architecture document for TSM and has found that it contains part of what would be in a TSM SSD. However, not all of the necessary information is in that, or any other, document. The committee is NOT suggesting that a new document be defined as part of the IRS development process. Rather, the necessary information for an SSD should be contained somewhere in the many existing documents, and a technical expert should be able to find and review the information throughout the development process.

The committee also notes that the representation used in an SSD is important. The real subject of a software structural description is the set of relationships among the modules. In order to understand the SSD, one must be able to comprehend these relationships. It is very difficult to understand these relationships when they are described using only narrative text (including tables). Diagrams that show the modules and their mutual dependencies in ways that are easily understood must form the core of a good SSD. Such diagrams help integrate the development hierarchy from front-line programmers to the chief information officer by facilitating unambiguous communication of complex details among the many designers, implementors, proposal evaluators, and contract monitors; that is, diagrams can be used effectively by the administrative, technical, contract, and business parts of the organization. The committee has not been shown any such diagrams for TSM or any of its parts. Therefore the committee must express serious concern that no such representations of software structural descriptions exist and that no representation standard has been selected for this purpose.

An SSD is necessary for understanding and validating the functionality of a system, as well as providing a basis for predicting and measuring the performance of the system against the specified performance requirements. It is the intention of the IRS that TSM will allow the agency to handle taxpayer actions with “one phone call.” Therefore, a variety of performance requirements should be established for this goal and incorporated into a TSM SSD. For example, the time to retrieve up-to-date taxpayer information from the database is determined by the modules, including multiple security “firewalls,” that enter and retrieve data. Without an accurate and clear structural description, there is no way to estimate whether TSM can meet the IRS’s goals.

Summarizing, the committee is concerned that:

• the critical importance of a software structural description is not appreciated by either the IRS management or its staff;

• no software structural description exists for TSM or any major component of it;

• no pictorial representation for software structural descriptions has been selected;

• performance requirements cannot be assessed effectively without examining software structural descriptions; and

• this committee cannot properly evaluate the TSM architecture without reviewing software structural descriptions of it.

The software development capability of an organization is a combination of its organizational structure and its people. In previous reports⁴ the committee has commented on organizational structure. Here, the committee addresses the need to develop a strong cadre of developers.

At this time, the committee is concerned that the IRS lacks the proper mix of skilled and experienced technical and management personnel to fully carry out all of the TSM plans. The IRS is clearly aware of this deficiency, and various efforts to improve this situation are under way, including training, recruiting, and process improvement. As noted elsewhere, however, the time scale of these efforts is, at best, too long in comparison to the demands of the projected TSM schedule.

Nowhere is the radical change that the IRS is undergoing in order to achieve modernization more evident than in its software development capability. New skills are required to transform its software development staff from one whose responsibility has largely been maintenance of existing systems using dated generations of software to one that employs modern techniques of software design and development. Short-term goals (i.e., next year’s funding round) will continue to hinder long-term investment in high-quality software professionals, tools, and techniques, as well as discourage the kinds of experiences (i.e., failures) that lead to technical lessons being learned, internalized, and applied to development projects. High-quality software professionals avoid low-productivity workplaces, thereby perpetuating the problem that the IRS faces.

There is a real danger that the IRS will adopt an approach to software development that consists of filling in the blanks of a checklist software development methodology. For example, a recent draft of the IRS Development Methodology Handbook shows little change from the original source; that is, it was not modified to suit the specific needs of TSM and the IRS development structure. Though it provides more structure than in the past, such an approach—by itself—will merely lead to “paint by numbers” solutions.

The committee is also concerned about the existing structure of the software and system development organizations, especially given the 2,000 dependencies among projects identified by the IRS. Because the Information Systems organization is still largely functional, a number of dependencies may be due to “throwing requirements over the wall to programming, and waiting for outputs to be thrown back.” Even after discussion in subcommittee meetings, the committee does not know precisely what the IRS has

discovered about these many interdependencies. It is the committee’s belief that a more cross-functional, team-based organization would be more effective for the larger critical projects. This approach would focus accountability more directly on the team and its project manager, and eliminate or decrease the amount of overlap now apparent between the current functional departments.

Many of the software objectives of TSM are variations of problems that have been approached by private industry with varying degrees of success. U.S. businesses have been “downsizing” and “rightsizing” for several years. The defense and aerospace industries have been laying off large numbers of highly experienced and capable people. This process may increase the supply of qualified talent available to the IRS—talent that would help develop and implement creative solutions.

The IRS’s top management appears to recognize the need for systematic efforts to improve its system development processes and has taken initial steps to carry out such improvements. Assessments, specifically those defined by the Software Engineering Institute (SEI), have been conducted for parts of the development organizations. As expected, the overall results show that the organization is at Level 1 of the SEI model. (The SEI model defines five maturity levels, with Level 1 representing the lowest level of maturity.) Software process improvement action plans (as defined in the SEI model) have been formulated, and process improvement groups (i.e., the Software Council and Software Engineering Process Group) have been set up and are actively working. These actions respond to committee recommendations made in the 1992 full report and the 1993 letter report. Further, it must be realized that moving an organization up the software maturity hierarchy typically takes 2 to 3 years per level. However, given the size and complexity of the task, the committee is concerned with the overall experience of the people responsible for improving the quality of the entire software development process.

To begin the maturation process, a concise, overall process improvement plan of action must be defined immediately. Such a plan must include short- and long-term goals, how quality will be assured, and how the process improvement efforts will dovetail with development efforts.

The committee has three suggestions with regard to process improvement:

• The IRS should prepare an overall process improvement plan (including suppliers of software) that is closely coordinated with the schedules and needed capability levels of the technical plans for TSM. Such a plan, at the top level, should spell out needed development capability levels (not just the SEI levels) for various groups of IRS developers (e.g., all personnel involved in database development should be trained in data modeling techniques and structured query language). As an overall strategy, the process improvement plan should be concise (e.g., less than 50 pages in length).

• The IRS should immediately hire key leaders who have experience with similar process improvement efforts. These leaders should, in turn, be empowered to bring on board personnel and/or contractors who can carry out an effective process improvement activity.

• The IRS should choose one or two moderate-sized projects and immediately begin to utilize the tools and techniques of a Level-2 organization as a way of driving forward the IRS-wide improvement of processes. This step was recommended by the committee in its 1993 letter report.

Because of the significant increase in complexity of the TSM program relative to previous IRS software efforts, more aggressive contractor management procedures will be required to ensure timely production of high-quality IRS system software. It is the committee’s finding that some contractors are viewed by the IRS as experts who do not require technical supervision. After several committee briefings it was not clear whether or how various contractors for major TSM subsystems were being controlled. As a result, these contractors may create architectures and designs that cannot be successfully integrated. Therefore, the IRS should manage their efforts more closely.

Two actions are suggested to mitigate some of the risks associated with contractor management:

• Continually and objectively assess the capability of contractors to produce quality products. In this regard, the experience of the Department of Defense would be useful. A number of methods are in current use: the Air Force Materiel Command’s Software Development Capability Evaluation, the DOD’s Cost/Schedule Control System Criteria (C/SCSC), and the Software Engineering Institute’s Software Capability Evaluation. These methods have been effective in evaluating contracts before award and in providing incentives to contractors to put software process improvement programs into effect.

• Hire people experienced in software development management procedures for both contractor selection and contractor supervision. With the current downsizing of the DOD, there should be a good selection of experienced people available. There are many high-quality software development contract analysts who have significant experience with large programs and are seeking career advancement. In the long term, building a team of individuals who understand the IRS culture, who are familiar with TSM, and who are experienced with large programs would serve the TSM program quite effectively.

The IRS has made significant strides in addressing the privacy concerns set out in the committee’s 1992 full report. Such progress is exemplified by the development of the privacy policy and the privacy advocate’s office. Nevertheless, the committee continues to have concerns about threats to taxpayer privacy associated with TSM. Violations of taxpayer privacy at the IRS are reportedly growing and can undermine the integrity of the agency and the tax system. As people and institutions become increasingly interconnected and as communications technology affords new opportunities to instantaneously transfer data and information, threats to privacy grow. In hearings before his Senate Governmental Affairs Committee, Senator John Glenn said, “IRS employees

must understand that browsing is not acceptable for whatever reason.”⁵ Commissioner Margaret Richardson agreed: “We do have zero tolerance for that kind of activity.” The committee recognizes that it was the IRS’s own investigation that disclosed “file browsing” by its employees, but it underscores that preventing such breaches is the principal goal.

During Senate hearings, William Stalcup, acting director of systems management, acknowledged that “[p]rivacy and security are the very foundation of our voluntary compliance system. If we don’t respect privacy rights, then the system has no basis.”⁶ Nevertheless, the IRS, because of the detailed and sensitive information it collects about taxpayers, is particularly susceptible to privacy threats. Through requests for interagency data sharing, for example, the IRS is also vulnerable to social and political pressures for compromising privacy.

As an initial and general recommendation with respect to privacy, the committee urges the IRS to seek to correct the agency conditions that threaten taxpayer privacy (as discussed below). If it is successful in this effort, the IRS could assume a leadership role among federal agencies regarding the protection of information and personal privacy.

The transition to TSM should be viewed by the IRS as an opportunity to set standards and develop new approaches to enhancing privacy through the use of technology. TSM should be viewed as an opportunity to enhance privacy through the creative use of technology. Although new technology may create new threats to privacy, technology can also be used to protect privacy. For example, electronic footprints (i.e., system-use audit records) make it easier to detect unauthorized access to data. Also, computer technology may enable identifiers to be stripped from files (during initial stages of review) so that taxpayers can remain anonymous. As Mr. Stalcup noted, “IRS employees don’t need unlimited access to taxpayer data…. Tax Systems Modernization hinges on our ability to protect taxpayer data.”

As the IRS moves forward, it should consider the following issues and topics (not necessarily listed by priority) in attempting to exercise leadership in the domain of information privacy.

The establishment of the privacy advocate’s position was a positive step. The selection of an experienced, highly competent professional further signaled the IRS’s commitment to privacy protection. The privacy advocate recently joined IRS, however, and has had little time to develop policies and procedures, or even to fill staff positions. The privacy advocate’s office is clearly a key to the IRS taking a leadership role in the protection of citizens’ privacy. Thus, it is vital that sufficient resources and authority be provided to this office. The privacy advocate must be able to hire sufficient numbers of staff and, perhaps more importantly, select staff with relevant skills. In many instances, privacy offices are treated as “security operations,” with a staff composed of technicians. It is necessary for the IRS privacy advocate’s office to have personnel with substantive

knowledge of privacy policy, approaches to protecting privacy, and an understanding of the dangers posed by the use of inadequate, invalid, or unverifiable data.

Previously, the committee recommended that a high-level, interdirectorate committee be established in the IRS to focus on privacy.⁷ Such a committee was established and will be vital to the success of the Privacy Advocate’s office in dealing with privacy matters.

In most instances, the determination of benefits from revenue collections are straightforward, while the costs and consequences resulting from violations of privacy are difficult to quantify. Taxpayers may be angry or embarrassed that the information they deem confidential has been compromised, but the affront to the dignity of the person is hard to measure. A consequence may be that taxpayers lose confidence in the IRS and distrust the tax system.

Therefore, it is essential for IRS personnel to appreciate the value of privacy and the need for privacy protection. The organizational culture and mission of the IRS are directed toward compliance and revenue collection. IRS is to be commended for developing training for privacy awareness. The agency should continue and even extend that effort.

Despite the inherent difficulties of creating external advisory boards under the Federal Advisory Committee Act, the need for feedback to the IRS regarding its privacy and information disclosure policy seems to argue for such a mechanism. An advisory group should include privacy experts and taxpayers. As in any organization, there is a tendency within the IRS among its employees to develop an organizational mind-set. The same shared view that helps create teamwork and esprit de corps may also create blinders. For example, in working to increase taxpayer compliance, IRS personnel might assume that citizens who are concerned about their privacy must have “something to hide.” The diversity of views among advisory committee members may help sensitize IRS employees to the importance of respecting privacy without simultaneously suspecting fraud.

The IRS is viewed as an exploitable source of data for a wide array of governmental purposes ranging from collection of student loan debts to the tracking down of persons not providing legally mandated child support. Over the years, new clauses have been added to section 6103 of the tax code by Congress, providing new rationales and exemptions for the disclosure of taxpayer data. This increased data sharing is not only a trend in the tax law but also, partly as a result of the goals of the National Performance Review, a government-wide trend. However, as more and more exemptions are written,

the potential for unwarranted invasion of privacy escalates. In the committee’s judgment, the IRS constitutes a special case with regard to the federal government’s needs for efficiency in data collection and sharing. There is not only a possibility that disclosure of taxpayer data to third parties can undermine voluntary compliance, but also the serious possibility that other agencies and organizations will violate taxpayers’ privacy through the use of such data. Currently, the IRS has processes to perform compliance reviews to determine whether other organizations using IRS data are abiding by IRS guidelines for the use of the data and for the protection of privacy. However, the efforts are currently understaffed. Moreover, effective compliance reviews consume considerable time and resources.

There is little likelihood in the near future that adequate protections will be in place for third-party use of IRS taxpayer data. Indeed, implementing sufficient controls on other organizations, even given adequate resources, is an uncertain proposition at best. With regard to IRS privacy considerations, the general trend toward data sharing should be sharply limited. Perhaps more than any other database, the IRS’s taxpayer databases should be viewed as being held in public trust and as being protected from such broad access. The committee realizes, of course, that the IRS is subject to congressional action regarding section 6103 exceptions, and each year the Congress has provided new exceptions to confidentiality. The committee suggests that, in light of TSM capabilities, the IRS and Congress undertake a critical review of the current breadth of section 6103 confidentiality exemptions.

The IRS is to be commended for its development of basically sound principles regarding the confidentiality of taxpayer data. However, these goal statements are too broad and nonspecific to provide adequate guidance regarding “who has access to which data under what circumstances.” The committee recommends that protocols be job-specific and data-specific, utilizing the technology to strip identifiers and segregate data, screen access requests, and monitor employee compliance with the protocols.

Strict protocols should govern the destruction or sealing of data. Even when there is adequate need to obtain information from a third-party source to supplement or compare with IRS data, that information should be sealed or purged once the purpose for its use has been satisfied. Here again, the use of automated techniques to manage such information would effectively increase the degree to which policies are enforced.

The prescription and monitoring of confidentiality protocols are management responsibilities. The IRS has begun to consider privacy management in its performance criteria, another important step in providing incentives for the protection of privacy. After a suitable period, the IRS should reexamine the performance criteria and evaluate their effectiveness.

Increasingly, the IRS is using data provided by third parties (e.g., other agencies and levels of government, professional and business associations) to develop information about taxpayer groups. This information is often used to make better decisions about which groups to audit or to examine more closely for possible failure to file or report fully. While this effort is in many ways commendable, it poses a number of possible hazards.

First, most databases, even ones of reasonably high quality, contain substantial errors. The error rate in data entry alone is typically 5 percent or higher. The committee recommends that the IRS take steps to determine the validity and accuracy of data provided by others.

When one database is being integrated with another, the possibilities for error escalate. Matching third-party data from separate sources is often used to make inferences about taxpayer behavior. However, there is the danger of making unsound inferences from the data and making auditing or inspection decisions based on invalid logic. Currently, IRS has procedures in place for approval of data matching and inference projects and, under Compliance 2000 (the IRS’s plan for collecting revenues), there is every intention to develop adequate approval processes. However, given the severity of the problems that may be caused by targeting certain groups based on data matching, trend extrapolation, and inferential reasoning, any safeguards must be carefully evaluated for their effectiveness. In particular, the quality of decisions will be only as good as the quality of the data used in those decisions.

There is a basic privacy concern about the collection of too much information about a person in a single file. The IRS, which of necessity has a great deal of information about individuals, should be very cautious about collecting more. It should not add nontax information, that is, information from sources other than tax returns, unless its value is clear and provable. Even then, the agency should collect the minimum necessary and have solid rules for eliminating such information when it has served its tax-related function. Any large-scale data collection effort should be supported by sampling and controlled studies.

The IRS has made significant progress in establishing safeguards for taxpayer privacy, but more remains to be done, and continued vigilance is required. TSM is a tool for helping to do that job and ensure the necessary vigilance. However, as characterized above, TSM also represents a serious threat to the IRS’s privacy goals.

Several significant TSM security developments have occurred since the committee’s July 1993 letter report. In particular, a security architect has been appointed, and the IRS security policy has been approved by the commissioner. Under the leadership of the TSM system architect’s office, the IRS has developed the IRS High-Level Security Requirements and the IRS Functional-Level Security Requirements (both of which were reviewed in draft form by the committee). A revised TSM security architecture will be developed only after these TSM security requirements have been completed. While this process was started later than both the IRS and the committee desired, the committee strongly endorses the policy-to-requirements-to-architecture flow, providing that the IRS enforces hard deadlines for the accomplishment of each step.

The substantive challenge facing the IRS is to implement adequate security into its ongoing and future procurements and then effectively operate the security program. This challenge is especially complex in the case of the IRS for several reasons. There is a very strong culture of independent and geographically decentralized autonomous management, and there is a rapidly changing environment of people and systems with the TSM program. Both can work against a consistent and effective security posture. Before the security architecture is complete and promulgated, critical ongoing programs and near-term procurements are at risk of proceeding without a comprehensive set of security requirements. The potential has thus been created for development of a set of

independent systems that may operate with one another, but be incompatible from a security point of view, making provision of adequate security difficult, expensive, or impossible. Recognizing that the security architecture is incomplete, the committee recommends that the senior business managers use their authority to direct and support a security review of in-place programs and those in progress to avoid expensive future program modifications.

The security architect’s office has not ignored this problem, and at least one TSM security-related procurement has been delayed. The committee believes it is essential that the program managers for all ongoing TSM programs and ongoing procurements immediately review their programs for potential major security weaknesses in view of the published security policy and the high-level and functional-level security requirements. Specifically, the IRS should look for any hardware or software capabilities that are being purchased or leveraged that conflict with the published security requirements. For example, are floppy disks being deployed on all workstations even though the security architecture might assume that no such output media exist? (This risk was noted in the committee’s 1992 full report.) Alternatively, does the security architecture preclude the use of a technical capability that is needed by a specific project to achieve an economical and functional solution?

Another welcome development is the IRS’s stated desire to use a mix of government-mandated and industry-endorsed digital encryption and/or signature schemes when doing business with nongovernment individuals and entities. Especially in the area of electronic filing, the argument for using only expensive, government-mandated encryption and/or digital signature schemes seems weak. The committee recommends that the IRS take further steps to make secure and properly authenticated electronic filing (e.g., using digital taxpayer signatures) as easy for the taxpayer as possible using whatever mechanisms are widely available.

The IRS has recently observed that data responsibility (that is, identifying specific personnel and organizations responsible for the integrity and security of particular pieces of tax data) is an IRS infrastructure issue important to both security and privacy. The committee strongly endorses IRS efforts to effectively assign responsibility for data to specific organizations.

The committee remains concerned about the linkage between taxpayer privacy considerations and TSM security. It is recommended that TSM security personnel work with the new IRS privacy advocate to develop metrics to be included within the TSM security requirements that will enable the IRS to assess when TSM has succeeded in supporting the IRS’s security and privacy policies. These metrics should be approved by the IRS privacy advocate in writing and should be reviewed by IRS privacy stakeholder groups (e.g., the GAO, Commissioner’s Advisory Group). The approval process for these metrics will likely involve the development of security and privacy policy decisions beyond those articulated in current IRS security and privacy policies.

Both the Treasury Communications System (TCS) and the telecommunications planning for TSM shown in the Design Master Plan (DMP) reflect a telecommunications architecture of universal connectivity. Thus, it is left to the TSM security architecture and its management approach to defend against intrusions that may violate taxpayer privacy. This management discipline will also need to extend to features of the DMP, such as allowing remote terminals to have access to the system via modems that might expose the system to unauthorized monitoring of identification numbers and passwords at each point in the public network through which the connection passes. Most unauthorized activities to date have been the result of internal browsing by IRS employees. Yet intrusions from outside the IRS may be expected as a consequence of expanded connectivity.

As of September 1994, the security policy was said to be awaiting Executive Committee approval in the IRS. As described, it will have no technical limitations, but only managerial ones. There will be three tiers of data compartments—the secure data domain, the services domain, and the user domain—with access based on the “skill profile” of the user. A user will have to pass a firewall to get to the services domain, and another one to get to the secure data. Each firewall will entail an as-yet-to-be-specified time delay for the necessary screening to take place. It is not yet clear how much delay will occur for each transaction, or whether the data will be downloaded to local storage. In the latter case, local data security and eventual data purging will have to be specified. System audit trails will have to be reviewed and investigated more extensively than at present, given the displeasure shown recently in the Congress about the current level of incursions.

Given the fact that the TCS will accommodate a wide variety of specialized security methods, Treasury maintains that the IRS should be able to do whatever it wants or needs with regard to TSM security. Does the IRS know what it wants or needs? The agency speaks of user profiles, roles, application profiles, and data compartmentalization as the basis for its approach to security, rather than the hardware devices themselves. This seems to be appropriate, but what does the IRS have to do beyond achieving the capabilities provided directly by the TCS contract to make that happen? What impacts will there be on the TSM projects themselves? The committee is concerned that the IRS has not provided a clear set of answers to these questions or a plan to manage security within the enhanced connectivity of the TCS.

The IRS’s business vision document should be the basis for all TSM planning. In fact, the business vision should serve as the “litmus test” when considering the merits of a given project within TSM. Unfortunately, such an influence is not obvious when examining the planning documents. When the IRS revises these plans, the committee recommends that they be made more consistent with the goals stated in the business vision. Furthermore, the IRS should clearly define how the documents relate to each other, make them mutually consistent, and eliminate the overlapping detail that is currently apparent.

During the period covered by this report, the planning approach of the IRS has been one of continuous evolution. The committee has reviewed the Business Master Plan, the Integrated Transition Plan/Schedule, and the revised Design Master Plan. The IRS is also currently developing a concept of operations document to serve as the central TSM document. All of the documents have been either created or significantly revised during

the recent extension of the committee’s tenure. Furthermore, the committee’s present understanding is that most of these plans will be revised in the balance of calendar year 1994 to reflect the present budget tightening by the Congress for FY 95 and to prepare for the FY 96 budget presentations. Given this evolution, most of this section is in the form of suggestions for revisions rather than concerns about the plans made available to date.

The concept of operations (CONOPS), or how the IRS will operate, is intended to present the business vision from the perspective of the employee and the taxpayer. As such, it should be expected to address the tactical plans of the operational leaders in much the same way as the Design Master Plan addresses the tactical plans of the chief information officer. A list of these plans explaining the relationship of each to the chief officers has been supplied to the committee, but the tactical plans have not been reviewed at this time. The TSM requirements document also lists the business requirements, and it is not clear how these fit into the CONOPS.

The Business Master Plan (BMP) appears to be the one planning document that combines both current operations and TSM. However, there is too much detail for a business master plan in the annual plans and appendices, particularly since this material is again repeated for information systems in the Design Master Plan (DMP) (and possibly in the other tactical plans not yet viewed by the committee).

Most strategic plans begin with a review of the environment. The planning assumptions in the BMP, which has obviously been well researched and presented, do this only in part. Comparison with industrial strategic plans suggests two thoughts. First, most environmental assessments end with a summary of opportunities and threats for the organization. While opportunities are addressed throughout the BMP and summarized in the performance goals, the corresponding section on threats is not apparent. Perhaps the constraints of creating a public document such as the BMP preclude such a section. Nonetheless, there are sufficient prospective threats that their omission is noticeable. For example, it does not seem sufficient to merely list these in the information systems plan in section 923(12)1 of the DMP and not summarize the threats in the BMP.

While most industrial plans include a risk assessment (contingency) plan to counter known threats, such plans are not public documents. Contingency planning should still be performed at the IRS on an annual cycle, even though the planning is not published in open written plans. For example, as suggested above, the IRS should ready a course of action should Congress decide again not to approve the full appropriation request for TSM.

Additionally, most industrial strategic plans have a section on strengths and weaknesses, to complete the cycle known as SWOT (Strengths, Weaknesses, Opportunities, Threats) analysis. To some extent, these elements are included in scattered places in the BMP, but a frank discussion of strengths and weaknesses would be desirable (again, subject to the limitations of a public document). Including the weaknesses only in section 924.21 of the DMP does not reflect sufficient attention at the BMP level, where there are weaknesses other than those in the information systems area. In the next

revision of the BMP, the committee suggests inclusion of sections on threats, strengths, and weaknesses.

The BMP section on organizational change raises additional issues. Though one goal is to “reduce layers of management,” an additional management layer—that of the modernization executive and of the chief officers—has been added. The comments in the BMP on the future roles of regional offices and commissioners lack a description of the real organizational need for improvement. Further, the descriptions replicate the roles described for the chief officers and/or the district managers. For example, section 920 of the DMP gives a much clearer view of the chief officers’ tasks than does the BMP. This raises the concern that the BMP may have been too much the work of the modernization executive’s office, and not enough the view shared by the operational leaders. This matter is particularly relevant with regard to the chief office of compliance, whose role should be more clearly defined.

The BMP is to be recognized in its first attempt to introduce measures of goals against which accomplishments may be gauged. In the details, however, many of the baselines are still to be determined, leaving incomplete the measurements against which accountability is to be judged.

The Integrated Transition Plan/Schedule (ITP/S) is, by its nature, limited to modernization only. The charts presented to the committee combine all areas except Information Systems (IS) and Management and Administration (M&A) into a catchall category called “business operations.” In an industrial business plan, the business operations of the chief officers are usually spelled out individually. The committee suggests that the IRS’s business operations be categorized accordingly.

The section on managing modernization has a top-down focus. Such a focus is appropriate for the present time, when the modernization executive is still trying to get full control (including cost control). Implementation, however, requires a plan to change behavior at the project level, and that plan is not yet apparent in the ITP/S charts shown to the committee.

The ITP/S, which describes how the BMP will be achieved, is now being issued and will need prompt revision to reflect the issues mentioned above on the revised budgets. It appears to be a very positive step, if used correctly. The costs, benefits, and time frames, which are to be added by year-end, are essential. Like the Integrated Project Schedule (IPS) (but at a much higher level), there are many dates and dependencies that need to be identified and reconciled very soon. The ITP/S needs early revision, and the missing costs, benefits, and new time frames should be incorporated as quickly as possible.

In order for management of change to be effectively handled within ITP/S, appropriate thresholds and approval levels need to be enforced at a level high enough to ensure that proper cost/benefits and trade-offs are taken into consideration. Thresholds and approval levels set too low will mire the process in paperwork to the point of destroying it. On the other hand, thresholds and approval levels that are set too high will result in a “wish list” of capabilities. Finally, controls must be in place to prevent project managers from circumventing the system by breaking projects down into components that will pass under the thresholds, but without the proper scrutiny of management.

The Design Master Plan (DMP) is the tactical plan of the chief information officer (CIO). The opening section seems to unnecessarily duplicate the BMP. Some reconciliation seems in order to reduce the overlap and consequent number of pages in either the DMP or BMP, or both. A clear transition is lacking between those tasks assigned to the CIO in the BMP and a recapitulation of those tasks in the DMP. Much of the history of the Service Center Organization Study (SCOS) and the District Organization Study (DOS) in the DMP is repetitious—a plan should look forward toward actions still needing to be done. The DMP is to be recognized for the sections on threats (923.(12)1), risks (924.22 and 926.4), and weaknesses (924.21), which are well thought out and carefully described. Summaries of these sections would enhance the proposed BMP sections on the same topics.

The location of the section on architecture near the back of the plan (in Appendix 93H.5) is not very effective. Not all of the IRS systems architecture (ISA) document needs to be included in the DMP, but early in the DMP there should be some reference to the ISA, as well as a summary of the very important design guidelines given in the “General Considerations” and “Data Management” subsections of Appendix I of the ISA.

The management section (924) correctly details the management structure desired. For a planning document, the missing element is how to make it happen, for which the implementation plan (926) seems to need reinforcing. The risk section (926.4) of the implementation plan is well prepared but appears to belong with the earlier risk section (924.22) (since it does not really address how the IRS intends to implement the Information Systems (IS) part of TSM). Action assignments to individuals need to be more clearly stated. The plan should indicate what measures are to be used in evaluating performance. The BMP makes a good start on these metrics, but the corresponding measures are missing in the DMP. Personnel who are rewarded for meeting their measurements have an incentive to do better and deliver the performance desired by management. The postevaluation mechanisms and consequent rewards should be more clearly described. It would be helpful to indicate what lessons have been learned to date from some of the longer-running projects like the Document Processing System, so that such lessons can be used to guide future management actions.

In summary, the DMP is an essential document for IS planning purposes. It would be better to publish it annually in the autumn so that it can be used for budget preparation and support. Furthermore, the clarity of the DMP would improve if the IRS eliminated the specific project details that are adequately addressed in other documents. For example, it has been suggested that only the design guidelines from the ISA be used, so as not to replicate the full ISA in the DMP. If the project plans are sufficiently detailed, it may not be necessary to restate that information in the DMP.

The Integrated Project Schedule (IPS) is off to a good start. It is being built on several project management systems that have been used to date, thus preserving the project managers’ efforts to keep their projects under control. These systems are being brought into a common overall reporting format for the IPS. However, progress in implementing the IPS is still not clear to the committee. One concern is that there is no quantitative calibration or rating built into the IPS, such as “percent accomplished versus planned,” or “proportion of dates slipped.” To be useful at the project level, there must be useful feedback to the project managers, and not just “red flagging” to upper

management. A cultural change that rewards timeliness in achieving commitments must be effected if TSM is to be successful. It is suggested that the reporting of “percent complete” now being used is less indicative than requiring reporting of “percent still required to complete.” Also, the present line-item detail may be excessive because of too fine a subdivision of projects.

Baselines are just being established in a few of the projects and in the IPS. The committee is concerned about the slow progress to date of finalizing the written requirements and specific measures to be made for all projects. There is also a concern regarding the exact allocation of resources in terms of staff hours and money to implement all projects. Such exact numbers are necessary for accurately tracking expenditures. Costs and staff hours need to be brought into the IPS as well as milestone dates—otherwise the IPS cannot be analyzed effectively. A slip in dates may be due to poor estimating, changing requirements, or insufficient staff hours. Only by tracking hours and costs can any diagnosis be done through the IPS. The committee’s most recent indication is that costs and hours are to be included by the end of this calendar year.

As mentioned above, configuration management has been outlined to the committee only on a top-down basis. Configuration and change management from a program/project perspective does not seem clear. There is a committee concern that change management cannot be done effectively in view of the incomplete specifications and baselines just mentioned. A cultural resistance to being specific (because it may constrain freedom of action) was noted in some meetings with IRS personnel.

The IPS must be administered in a way that promotes an atmosphere of honesty regarding project status, including the ability to report “bad news” when it occurs. Project managers must embrace the IPS as a meaningful tool for themselves and use it to learn about problems before they are “blind-sided” by IPS staff or from above.

The IPS staff must also walk a fine line in terms of requiring significant data and milestones (rather than minute details that are laborious to amass). There is a danger that the IPS will take on a life of its own rather than produce the end result of accurately indicating project status.

Some discussion has taken place on the method of implementing quality assurance through an integration facility at Culpepper, Virginia. The goal is to take the accepted products of the various project contractors and run them together at Culpepper to establish compatibility before sending them on to operating sites. This type of integration facility is often used in large development projects to centralize configuration management and problem reporting and response, and to update distribution and technological evolution.

While the merits of such a centralized approach are understood, some individual committee members have expressed the view that this technology transfer will have to take place twice, and at added cost: once from the project to the integration facility, and a second time from that facility to the operating location. At each such transition there will be a “relearning” process with some loss of effectiveness. Committee members who have experienced this process in industry have skipped the intermediate integration step to make the end result more effective, and at lower total cost. Admittedly, there is some risk of disruption at the operating location from taking such a direct approach. However, it is the collective observation of this committee that greater involvement and acceptance by the people who have to make a transition lead in the end to better performance.

Before it can make final comment, the committee needs more information about how this quality assurance facility will be implemented, including details on how it will be used and staffed both in the project input side and the operations output transfer. Also needed is a concept of operations for control of the process of integration and transmittal

to operations. Integration testing needs some metrics, rules for interacting with the project teams, and an indication of the levels at which naturally occurring conflicts will be resolved. Resources will be needed, probably mostly in software, to apply “quick fixes.” Some concern is building among individual committee members regarding the priority that a quality assurance facility should have in a period of budget rationing when costs and timeliness may have to take precedence over such an additional intermediate facility. The committee is concerned that the plans for the Culpepper facility are not sufficiently formulated regarding how it can be used effectively and how its addition will be managed so as to make the technology transfer to operations a more direct process without additional steps.

In the transition to IRS modernization, human resources is the linchpin. The IRS is consolidating responsibilities within the field organization to facilitate the delivery of the new operational capabilities.

Human Resources (HR) has been consistently responsive to the advice of the committee regarding necessary and active involvement in TSM. HR has moved from a position of limited understanding and involvement in TSM to being a proactive participant.

HR exhibits clear leadership regarding:

• personnel displacement (resulting from TSM),

• dealings with unions,

• personnel redeployment,

• skills assessment, and

• facilities planning.

Areas of concern to the committee and HR are the following:

• Succession planning for IRS leaders. Specifically, there is a lack of personnel suitable to replace director-level positions in Information Systems and Human Resources. This deficiency needs to be addressed immediately.

• Contractors. As noted previously to the committee, the IRS lacks sufficient competence to manage and lead large contractor efforts. Such competence includes technical expertise as well as experience managing large integrated efforts using multiple contractors.

• Facilities planning and implementation. Since the facilities efforts are budgeted and implemented separately, there is considerable concern that implementation of the TSM computer center and systems will lag behind building programs. Risks include the cost of unoccupied space and logistics problems arising from planned moves.

• Hiring the right people. Although there is a recruitment program in progress, the committee does not have a clear picture of the required skill sets for TSM. The question is, Is the IRS hiring the people it will need?

• Retooling (rehabilitating) of application design and development personnel. According to the IRS, approximately half the people in the software development organization (1,000 to 1,200 people) need to be trained to work on TSM. Specifically, they need to be trained to develop and maintain software in a distributed, client/server environment with graphic user interfaces. It is unclear to the committee whether retooling is being implemented other than in an ad hoc manner. A specific program built around the capabilities needed for TSM should be instituted.

The Human Resources organization fits into the overall IRS modernization strategic and business plan in the following five major areas:

• IRS/National Treasury Employees Union (NTEU),

• Training,

• Facilities planning,

• Communications, and

• Translation of systems to Human Resources programs.

Since its last report, the committee has worked to understand Human Resources’ strategic plans, target dates, and implementation procedures. The following comments on specific areas highlight the committee’s positive reactions as well as its concerns.

IRS management and the National Treasury Employees Union have entered into a total working partnership agreement that radically redefines the traditional relationship between management and labor. This agreement:

• represents a systems management approach to actively improve work processes;

• provides empowerment from the perspective of the individual and the organization;

• is an evolutionary change in the relationships among IRS managers, the union, and employees; and

• includes implementation of a quality-of-life plan to enhance productivity and employee pride.

The committee’s visits and discussions with IRS staff and employees indicate that positive advances have in fact been made to ensure a cooperative attitude. The continued development of a working relationship must remain a constant priority.

The committee recognizes that IRS management has not been trained in dealing with all aspects of major organizational changes. Until the modernization program, major changes were not a part of the IRS environment. To ensure that managers are equipped

to handle the organizational changes that the IRS faces in the short- and long-term planning cycles, the following steps have been or are being implemented:

• The IRS is in the process of creating an internal education system, which will become the preferred provider of training for managers and employees. Training will be based on desired competencies and skills, rather than on job category, position, or organizational level. In all cases, the curriculum will be linked to the IRS’s mission and the Business Master Plan. The key building blocks for the corporate education structure will be the concepts of continuous learning; building on previous skills; delivery of “just-in-time” training; and the use of effective, state-of-the-art delivery methods.

• Management and Administration (M&A) has initiated a conceptually new approach to assessing management of the IRS’s human resources. Measures were established to assess how well line managers were utilizing their human resources in the following areas: labor relations environment, work force repositioning, performance and recognition, labor costs, and ethics. In 1994, baselines for these measures were established that will allow for the development of performance goals for 1995 and beyond.

The plan for developing the skills of the software and systems development staff is not clear. Further, it is unclear how the gaps in expertise will be determined for recruitment.

The committee notes the complexity of major organizational changes and the comparative modeling efforts currently under way by outside contractors. These models deal with facilities planning, employee retraining, relocation and major transition of centers, and the issue of facilities termination.

At this time, it is not possible to comment on the quality of the models being developed, although the briefing titled “Facilities Planning to Support Tax Systems Modernization” appears well done. It is critical, however, that these modeling efforts be piloted and evaluated at a very early stage to confirm their validity.

Effective organizational communication is needed to prepare IRS personnel for how TSM will change their jobs and careers. It should be simple, redundant, and consistent, and line managers must lead the communication efforts. To its credit, the IRS has made several major efforts to inform employees of the ongoing and expected changes, such as development and distribution of the publication “IRS in Transition.” However, Human Resources must continue to develop a communications plan that has a single message and is directed to all IRS employees.

In the area of employee feedback, the committee is pleased to see that the IRS is committed to periodic surveys across the entire organization. Employee perceptions may be the most important kind of data IRS managers can obtain. The first survey cycle was completed in the summer of 1993. All IRS employees were given the opportunity to

complete a survey, and over 90,000 employees, managers, and executives responded (an outstanding 75 percent response rate). Managers were provided the results for their work groups. With that data as a starting point for discussion, feedback sessions were held to determine what areas within each work group were most in need of, and could best benefit from, improvement actions. Further, as a result of analysis of the overall survey data at the national level, the IRS is now focusing on improvements in the following four areas:

• Increasing the level of candor and two-way open communication throughout the organization;

• Improving the internal rewards and recognition system;

• Improving commitment to the accepted principles of quality improvement, specifically, increasing the use of objective process analysis techniques; and

• Improving the agency’s focus on the customer in all endeavors.

In addition, to gain the sense of urgency needed for a project of this size, a prototype has been developed by the IRS for a radically new approach to assessing performance: systems-based performance management. This approach focuses on outcomes and on improving organizational performance. Employees’ performance objectives are linked directly to the mission and strategic goals of the organization. Instead of relying on a static backward glance to assess performance annually, ongoing process reviews are conducted to determine what needs to be done to ensure successful completion of a project or activity. At some of the sites where this system is being tested, the committee is recommending the use of cross-functional teams. The committee believes that such teams maximize contributions to organizational effectiveness. Approximately 1,200 managers and management officials at seven sites were trained and are participating in these pilots, with IRS-wide implementation scheduled by the end of FY 1995.

In appraising the extent of activity related to modernization and the extensive changes required along with the IRS’s admitted need for new communication programs, the committee urges IRS management to be very sensitive to personnel problems at all levels of staff and employees.

In prior reports, the committee observed that the Treasury Communications System (TCS) is a requisite portion of the infrastructure required to support TSM. Initially scheduled to be awarded in 1993 (still pending), the TCS is intended to replace the Treasury Consolidated Data Network (CDN), providing a data communications utility for TSM well into the next century.

The TCS procurement schedule has slipped for several reasons. First, the mandatory use of FTS-2000 has lengthened the bidding process, and obtaining unit prices from the Treasury FTS-2000 provider has been difficult for TCS bidders. Second, the Department of the Treasury has changed the organizational structure supporting the TCS program, shifting TCS procurement responsibility from the U.S. Customs Service to the IRS and executive agency responsibility from Customs to the Department of the Treasury. The committee has been somewhat puzzled by these changes, particularly that of the

executive agency, since reports over several years from Treasury, IRS, and Customs have indicated that the previous organizational relationships were working well. The committee has been told that the ability of Customs to service the TCS contract has been diminished by recent staffing cuts at Customs—however, the resources to support TCS are evidently available. Third, the scope of TCS appears to be growing, partially in light of the Clinton administration’s National Information Infrastructure (NII) initiative, to support agencies other than the Department of the Treasury.

Notwithstanding the above considerations, the fact remains that TCS, an essential part of the TSM infrastructure, continues to be delayed. The committee has been told that the CDN continues to meet all IRS data communications requirements. However, Treasury is now in the position of extending the CDN contract for at least a third year in order to support departmental needs. An extension of only 1 year was initially envisioned, and the CDN contract, which will now have to run (at least) 11 years, is likely to prove to be difficult to extend further. The quest for an “ideal” TCS procurement must not be pursued at the expense of essential TSM infrastructure. In particular, any substantial changes in the scope of the program to serve agencies beyond the Department of the Treasury might further delay the program at the expense of TSM. The IRS must consider this issue as it proceeds with TSM and must be prepared to alter its plans if the TCS contract is delayed or modified further.

The committee has developed technical concerns about TSM telecommunications response time (end-to-end communications delay). These concerns emanate in significant part from an apparent lack of stated targets for this network parameter, particularly in light of the evolving distributed TSM architecture and TSM communications and data security requirements. For example, given maximum connectivity per the IRS’s Design Master Plan, an IRS user’s data might need to transit three local area networks, two bridge/routers, and a voice/data switch to get to TCS, with the potential for similar off-TCS connectivity at the data’s destination. This scenario involves 13 static delay nodes plus transmission delay plus security access delay, before traffic-related delays (e.g., congestion) are introduced.

Another concern of the committee is that there is not yet an objective target for security access delay time. Too short a target time either will require extra costs in providing for greater security protocol processing speed, or may require a less than desirable security protocol. If speed and protocol are fixed, as in one example discussed from a non-IRS system, the access delay time may prove to be excessive for adequate operational use. The IRS should define, in the revised IRS Telecommunications Tactical Plan, its end-to-end telecommunications delay requirements, including security access delay time, and use these requirements to validate both pertinent aspects of the TSM architecture and TCS delay requirements.