ISSUES AT LARGE - Test Patterns for Your Y2K Conversion

1 2 Page 2
Page 2 of 2

Users themselves need to ensure that the application is producing the desired output. Auditors must verify that there were no gaps in the testing process that could expose the company to liability. And peers within IT can hold each other to high standards on a project with plenty of potential to become a deadline-driven mad rush. But what's important is that all three groups share a set of criteria that establish what the organisation's goals are for Y2K.

"You need common definitions of compliance," says Robbins at Chase. "When is something tested and ready for the real world?"What Happens After New Year's Day?Is thorough testing something companies will resort to only in times of crisis, as with the millennium bug, or will it become standard operating procedure? In other words, can we expect the Software Engineering Institute's 67 percent figure to increase as a result of Y2K? Again, there's no consensus.

"My hope is that this will be a retained competency, and it should be," says Howard Rubin, president of Rubin Systems and chairman of the computer science department at New York City's Hunter College. "Y2K is a wake-up call for bad technology habits."The skeptics, however, say that some things never change. "A lot of people are treating this as a necessary nuisance that we have to put up with," says Commercial Union's Kern. "They're not trying to look beyond it and see what we can learn and use for the future."Whether testing wedges its way into every organisation's culture or not, there's no denying that it has achieved something of a celebrity status as a result of Y2K. The stakes are high, and testing is crucial to a successful conversion effort. And some of the biggest testing hurdles-for most companies-still remain to be discovered. "We need to get a dialogue going around testing," says Judith List at Morristown, N.J.-based Bellcore, which consults with telephone companies all over the world. "We're only beginning to scratch the surface to see what some of these challenges are going to be."The Test PyramidNo matter how thorough an organisation's testing effort, there's always the chance that something unexpected will go wrong. Bad data from a business partner could corrupt a database, or an embedded system could wreak havoc on a plant floor. How to prepare for such unpleasant surprises? Contingency planning.

"You need to run the 'what ifs,'" says Pam Fredette, a solutions division president at Computer Horizons Corp. in Mountain Lakes, New Jersey. "If certain critical business applications fail, how will you get around that?"Some IT executives scoff at the thought of both doing rigorous testing and constructing a Plan B. "Our contingency planning basically says we'll make it work," says David Mounce, vice president of production operations at Options Clearing Corp. in Chicago. "We're not planning on failure."That kind of attitude irks William Ulrich, president of Tactical Strategy Group Inc. in Soquel, California. "The guys who know about the problem won't admit that you need a contingency plan. It would be acknowledging the possibility of defeat," he says. "On the other side, the business people aren't aware of the risks of this problem. Because of that, no one's driving."Someone needs to get in the driver's seat and begin drafting plans for workarounds and backups. "You need to take a look at having a fallback strategy for everything that's critical to the business," says Allan Graham, senior vice president for operations at Comdisco in Rosemont, Illinois. "They may be Band-Aids, but they're better than nothing." Graham also recommends having a SWAT team on standby over the long weekend of Jan. 1, 2000, ready to attack unanticipated snafus.

At Brown Williamson Tobacco Corp., the Louisville, Kentucky-based company's Y2K steering committee is responsible for outlining contingency plans. "I've asked everyone in the group to investigate their disciplines and areas," says CIO John Hanaberry. "What if that bank isn't ready, or this distributor or that government agency? How do we respond?" Spreading the work among multiple business units is a good way to make sure that all the important scenarios are explored, says Hanaberry. Having a small group do contingency planning can often be too myopic.

And contingency planning, like every other aspect of the Y2K project, needs to begin as soon as possible. As Ulrich says, "The folklore suggests that the year 2000 problem is isolated to a brief period near the end of December 1999," but that's simply not the case. Applications will fail before that date as well as after it. Solid contingency plans ensure that any failures won't cripple the organisation.

(Scott Kirsner, a Boston-based writer and consultant, is working on a series of articles for CIO on the Y2K problem. He can be reached at

Copyright © 1998 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams