Transportation IT crew makes a party of systems testing

Transportation IT crew makes a party of systems testing

Year 2000 coordinator Jim Slaughter, with cigar, says a party atmosphere sometimes developed among Pennsylvania Transportation staff members who worked late and on weekends.

Name: Jim Slaughter

Agency: Bureau of Information Systems, Pennsylvania Transportation Department (PennDOT)

Title: Year 2000 coordinator and application development chief

Background: I've been working for PennDOT for more than 25 years. I worked my way up from a fledgling programmer analyst. My background is in applications development and computer system analysis, and I had a 10-year stint in operations in charge of mainframe computers and telecommunications.

How year 2000 has changed my job: Y2K has certainly enhanced it tremendously. I'd say I have spent probably 30 to 40 percent of every day with Y2K for the last 18 months to two years. But what I've done is simply extended my day'I'm expected to do that as a manager, and I do it.

A lot of my people have also worked extended hours when we had to do weekend implementations for continuous-demand systems. Sometimes on a Saturday night, we had to bring in staff and consultant partners to do the code remediation. Consultants would be elbow-to-elbow with us. It was fun'a lot of times it was a party atmosphere. People have gotten closer in many cases.

When PennDOT began year 2000 work: We naturally began working on it much in advance of other agencies back in the 1980s, when we discovered glitches in the records of drivers who were suspended and revoked past 1999. We have actually tested the driver's licensing systems as of the year 2100 because some people have their licenses revoked until then.

But we earnestly began overall Y2K work back in 1995, when the department put together a task force of information systems and business folks. We did an agencywide assessment in the spring of 1996 and budgeted for the coming three years to make sure we remediated code, looked at embedded technology and prepared ourselves so our multiple layers of customers would see no adverse impact.

Scope of work: We counted a total of 39 major application production systems. In those 39 systems, we had 4,665 computer programs. That includes databases that have well over 20 million records each. We have more than 5,000 PCs, and we have only 200 that are not yet Y2K compliant. We'll replace them by October.

How my department avoided unpleasant surprises: In estimating what systems work needed to be done, we took the catastrophic approach: We made the worst of all assumptions. We assumed that where Murphy lived, Murphy was going to do his work. And thankfully, we have found a better situation in every instance.

For example, we budgeted in PennDOT more than $8.6 million to augment our staff with outside consultants to help remediate code over three years. We found out we ended up spending only $3.7 million, largely because the gross assumptions we made early on were not the case. That's just an example of what I call good planning.

Testing methodology: We have four levels of testing before a program or system can be put back into production status, the fourth level of which is a series of user acceptance testing where our internal customers partner with us on a side-by-side final test. We finished that testing on all of our systems and put them back into production last summer.

In addition, we have disconnected an old mainframe we replaced last January and loaded it with all operating systems, production libraries, production compilers and programs and have been doing separate final readiness testing on that machine since June by rolling forward to key dates. We plan to finish that by the end of this month.

Our contingency planning process: We're looking at six kinds of risk for each of our mission-critical business functions. But we're making an assumption here based on reasonableness. For example, if the power goes out, we don't assume that it's going to be out for more than one to three days. I've been working with the Public Utility Commission, and I think our utilities are in good shape.

How I think things will go: When we had a fire in our data center in 1994, we were able to create a brand-new data center offsite 10 miles away from our headquarters, and we switched over in 34 seconds. In many cases, customers never even knew we did it, and it didn't get a lot of media attention. It is wonderful whenever you do something potentially catastrophic and it is uninteresting to the news media. I really believe the same kind of thing is going to happen in Pennsylvania on Jan. 1, 2000. I'm not saying we're not going to have hiccups'we'll have some problems. But I believe they're not going to be three-inch headline kinds of news.

Where I'll be on Dec. 31: We'll probably be here checking the systems out, and that'll be our New Year's Eve party.

'Claire E. House


  • Records management: Look beyond the NARA mandates

    Pandemic tests electronic records management

    Between the rush enable more virtual collaboration, stalled digitization of archived records and managing records that reside in datasets, records management executives are sorting through new challenges.

  • boy learning at home (Travelpixs/

    Tucson’s community wireless bridges the digital divide

    The city built cell sites at government-owned facilities such as fire departments and libraries that were already connected to Tucson’s existing fiber backbone.

Stay Connected