David Starr, recently named vice president and chief information officer at The Reader's Digest Association, calls 2000 "the biggest fraud perpetrated by consultants on the business community since re-engineering."
Although some systems can't distinguish between the 20th and 21st centuries because they recognise only two-digit years, he says, most IS organizations can fix that in the normal course of business.
Starr, the former CIO at ITT Corp. and at the Payment Products Division of Citicorp and a former senior manager at Price Waterhouse, spoke with senior editor Robert L. Scheier.
CW: Why do you call the year 2000 problem a fraud?
Starr: I was a consultant for half my career. I know what they're doing. As a CIO, I get copies of the letters people send our CEO and our CFO, and it's terror tactics. "The elevators are going to stop, and airplanes are going to fall from the sky, and your ATM's not going to work."
CW: But couldn't some of those things happen?
Starr: If everyone went along the way they're doing now and didn't do anything about the year 2000, some of this will happen. [But] people are going to do something. The vendor is targeting ... nontechnical people who don't know any better.
CW: Doesn't the complexity of just finding year 2000 bugs make it a major problem?
Starr: You have to do a risk analysis of the cost-benefits on it. You look at your key systems, and of your key systems, which are going to be likely to have year 2000 problems. But [you don't need to] bring consultants in for millions of dollars to do some proprietary fix for something as basic as changing something from two characters to four characters.
CW: Even when you identify your key programs, isn't it complicated to find the date routines in them?
Starr: [Cobol development shops] have scanning technology and text editors; you just go through and look for dates.
CW: How about the need to take all these programs out of production, test them, reintegrate them, and to manage and coordinate all the work?
Starr: Anybody who's got a development organisation has change control procedures. [You do them] the same way you would change any other bug, change or enhancement. It's nothing unusual for a development organisation.
CW: It's also not unusual for most information technology organizations to deliver applications late and over budget. Won't they do the same thing on year 2000 work?
Starr: Application development projects come in late and over budget because they don't have clear definitions up front. Most [IS] people know how to do the blocking and tackling of production systems.
CW: If this is so easy, why do so many year 2000 project managers say year 2000 work is more complicated than they thought?
Starr: Maybe the people you're talking to aren't hands-on people. Another thing that's even more insidious [is that] a lot of them are using the year 2000 to justify other projects.
CW: How does that work?
Starr: [Say] I wanted to get rid of this old, tired system for a long time, so I'm making people aware that it has a year 2000 problem and use that as a rationale for replacing this thing. If I went in and did a benefits analysis, I'd have a hard sell.
CW: If this is all so easy, where do you stand with year 2000?
Starr: We've got some issues, especially in Europe, where we've got some older systems. We're in the midst of doing detection testing [to find bugs]. We're not turning it into a big project.
CW: How big is "not big?"
Starr: Of my development budget, probably less than 5%.