Task Master

Government Leader home > June 2005 issue

June 2005; Vol. 1 No. 2

Task Master

Former IRS commissioner Rossotti reflects on modernization turnabout Task Master.

Charles Rossottiis well acquainted with the trials and tribulations of overseeing large government IT projects. As IRS commissioner from 1997 to 2002, Rossotti had to deal with the agency’s behemoth modernization program, which is really a portfolio of big projects.

The agency’s efforts to modernize its information systems had been plagued by failures for decades.



You first have to start with a realistic set of expectations. ... That’s a very fundamental management responsibility. — former IRS commissioner Charles Rossotti

In 1998, after the latest project had lost nearly $4 billion, Congress passed the IRS Restructuring and Reform Act, which required the agency to overhaul its business processes and produce a multifaceted modernization strategy.

“From the day I agreed to accept the job as commissioner, I began working on how to accomplish the daunting task of completely rethinking and replacing the IRS’s technology systems,” he writes in his book Many Unhappy Returns: One Man’s Quest to Turn Around the Most Unpopular Organization in America (Harvard Business School Press, 2005). “The extent of the problem was stunning.”

Rossotti is now a senior adviser at the Carlyle Group in Washington. Before becoming IRS commissioner, he was chairman and CEO of American Management Systems Inc., now CGI Group Inc.

In a recent interview with Government Leader managing editor Richard W. Walker, Rossotti talked about lessons learned from his experience with the IRS project.

GL: When you arrived at the IRS in 1997, what were the biggest problems you faced with regard to the agency’s business systems modernization program?

ROSSOTTI: One thing that made the IRS modernization problem so difficult was that [the program] was big and complex. By itself, that would make it difficult. But what was unique in my experience was that it was so far behind for an organization that depended so much on technology. If this had been a private business, there is no way the IRS could have gotten this far behind and stayed in business.

The IRS is really dependent on technology for its everyday business and mission. There is virtually no employee in the IRS that can do any job without the data in his computer.

And yet the program was really monumentally behind. What that meant was that on the one hand you are totally dependent on technology; you can’t just stop and get rid of it. On the other hand, you have decades of incremental changes, loading this system on top of that system and making changes to the old systems in very obscure ways.

You couldn’t replace it all at once but if you wanted to replace any one piece, you had an extremely intricate puzzle to figure out how to keep everything going without breaking something.

Clearly, one of the lessons of it is, don’t ever get that far behind on a big technology project, because once you do you have a very risky and difficult problem.

GL: Some people might argue that the sheer size of big projects in government makes them a formidable, maybe impossible, challenge and perhaps that’s why many seem to struggle. Do you agree?

ROSSOTTI: Size is something that makes it more difficult. Size magnifies all the errors and increases the cost and all that. So it’s a factor. But it’s not enough to make them uniquely difficult. In the private sector there are projects that are comparable in size and complexity— in big financial institutions, for example.

GL: One of your first major moves in the modernization effort was to redirect the major IT organizations within the IRS to report to the headquarters CIO. Why did you restructure the lines of reporting?

ROSSOTTI: That was a perfect example of one of the things that was wrong. The basic IRS organization was fragmented into all these partly geographical and partly functional units. There were at least 15 independent IT departments that were part of these decentralized units.

At the time, the CIO at headquarters was directly in charge only of the headquarters IT. The result of that was that you had not only very different business practices but a lot of different procurement practices, different hardware and so on. So even if you developed a system you couldn’t roll [it] out. Each platform was different and each business practice was different. We needed to get control not only to improve the ability to manage the whole IT infrastructure but to manage the [business] modernization as well.

So we began to move the reporting relationships of all these IT departments under the CIO. But it took almost five years to get [the IT organization] completely realigned in an efficient way as a single, shared-services IT operation.

GL: In the end, what were the benefits of realigning the reporting relationships?

ROSSOTTI: There were immediate benefits even before we got to modernization because, for one thing, we standardized the basic IT infrastructure. For example, having a single directory for e-mail and voice-mail where you could communicate across the agency was a huge benefit. This was all stuff that had to be in the basic infrastructure before you ever got to what people think of as systems modernization.

Once you get to systems modernization, you then have a platform so that once you develop these systems you can actually roll them out.

GL: How much of a factor was the IRS’ enterprise architecture in getting the modernization project back on track?

ROSSOTTI: I’m a big believer in [enterprise architectures]. The Treasury Department had developed its first enterprise architecture before I got there. It was a useful tool, particularly for documenting in a thorough way what the installed base of systems was.

But the difficulty was that it didn’t lay out where the [IRS] was going from a business standpoint. I really had to turn the heat up to get the executive group to participate [in developing the business architecture] as there was a tremendous amount of other work happening at the time. But without their participation in a very serious way, we would have not been able to develop the business architecture.

The [updated architecture] laid out for the first time the basic business processes of tax administration across the whole IRS, from filing returns to maintaining customer accounts to assuring the payment of taxes due. It really helped to put into context all the different projects.

GL: How did the architecture impact the program after that?

ROSSOTTI: The program had to be broken up into a lot of smaller projects, which weren’t that small, but they were nonetheless projects. It was the architecture that guided that process.

GL: What lessons did you derive during your tenure from the IRS’ relationship with Computer Sciences Corp., which was awarded the prime contract for the program in 1998?

ROSSOTTI: When you have systems integrators that are responsible for overall technology modernization, it’s customary to talk about them as partners. They really are partners in the sense that you can’t succeed without them. And presumably they can’t succeed without you, the customer, getting results and paying them for what they deliver.

But when things go wrong, what in good times looks like a partnership, in bad times looks like a deadly embrace. If things are not going well, it’s quite difficult for either partner to disengage. The vendor obviously doesn’t want to because it would be a major loss. And the agency would pay a huge price in terms of lost time and money. It’s a very difficult balance at that point.

We had to come to grips with our contractor on two dimensions. One was who was going to be accountable for the slippages? One of my watchwords in the IRS reorganization was having accountability for results, and I felt that had to extend to the contractor as well. I have to give [Computer Sciences Corp.] a high degree of credit in that they stepped up to that responsibility and absorbed what was probably pretty significant cost for the problems that occurred on one major project as well as some other projects.

The second dimension was what were we going to do to make this work going forward and not have these problems happen again. And we went through a lot of joint work on that. I wasn’t there in 2004 but in that year the IRS probably delivered more new modernized systems in one year than any place I’ve ever seen.

GL: From your experience with IRS, didn’t you find that major issues on a project might have to be resolved between the agency and the contractor at the highest executive levels?

ROSSOTTI: Some issues do. You have to have an organized process of resolving issues. Clearly, you’d like to get every issue resolved at the lowest levels but what you don’t want to say is that if an issue is not resolved at the lowest level then it won’t get resolved. That’s what kills projects. Chief executives can’t shut their eyes [to a problem] and say, “Don’t tell me about it.”

Issues come up that require resolution on a broad basis at different levels of the organization— and sometimes even at the chief executive level.

You have to have a management process that has a basic ethic that says: Issues will be resolved expeditiously and they will be resolved at the lowest level; but if they can’t be resolved at the lowest level, we’ll continue to work on them until we do resolve them, even if it has to go all the way up to the chief executive. That’s the only way you can manage one of these [large IT] programs.

GL: How essential is leadership at the top level to the success of major projects?

ROSSOTTI: It’s true in any complex program that involves a lot of people that leadership of the management is critical. It actually may be the most critical factor, if you wanted to single out one. And it may not be one person, although generally there has to be one person who exercises a considerable amount of leadership over the overall program.

GL: What are key lessons for other government executives from the IRS’ experience with a big IT project?

ROSSOTTI: One thing is that you first have to start with a realistic set of expectations. It is not something that can be thought of as a side issue or can be completely delegated down to some low-level people. That’s a very fundamental management responsibility.

The second thing is that it’s not really a technology program. It’s really a business-change program. So you need to think through what you want your organization to do—how it’s going to function differently in the future—and drive that down [in the organization] so that people can figure out what the details are.