It's a little early for Halloween this year, but the ghosts of Y2k are already making the rounds. Last week one materialized in Washington, where the city's new payroll data system, which went live in April 1999, was in the news. According to The Washington Post, the system cost US$20 million, was already two years late when it was delivered and lasted just until early 2000 before being declared a disaster. Since then, the city has spent another $14 million trying to clean up the mess.
Note those dates: Behind schedule when it went live in 1999, a hopeless mess in 2000. They're telltale signs of Y2k ghosts.
D.C. has a long tradition of IT-related foul-ups that goes back long before Y2k. But for once, the city is not in a class by itself. Lots of other IT projects in both government and industry that were rushed into production in the months before the Y2k deadline have turned out to be dead on arrival -- or at least at death's door.
That happened in Portland, Ore., where a water-department billing system project went horribly wrong and cost $10 million or more in lost cash flow. There were big headlines when balky new packaged applications cost Hershey Foods 19 percent of its quarterly profits three years ago. New Hampshire's prisons department, a New Jersey toy distributor and many others hit the same kind of problems.
It's not hard to figure out why. Y2k fixes for existing systems soaked up lots of IT talent in the late 1990s. The dot-com boom skimmed another layer of cream, as did desperate efforts by non-dot-coms to build their own Internet presence. Packaged enterprise applications, supply chain automation and other hot technology projects grabbed still more warm bodies.
So when many organizations decided to junk antiquated systems and replace them as part of their Y2k programs, expertise was expensive and in short supply. As a result, corners were cut. Tests were skipped. Vendor salesmen were trusted.
And when those projects ran late, 1999 was the furthest they could slip. Ready or not, they went live. Shortly after that, many of them went brain-dead.
In case after case, the antiquated systems that were supposed to be junked had to be made Y2k-ready anyway -- some as stopgaps until the new systems were finally really ready, others so the projects could be rolled back entirely and the new systems junked.
And it's not over -- not by a long shot. Y2k may be gone, but its ghosts will haunt us in those systems for a long time.
If you're struggling with fixing one (or more) of these huge Y2k fiascos, you already know that. But if you're not, don't think Y2k's ghosts will leave you alone.
Remember those temporary fixes you made to applications in order to buy time as zero hour loomed? You found some of them in January 2001, when all the places you hard-coded "2000" stopped working properly. Did you really fix them, or just replace them with "2001" last year and "2002" this January?
What about places where you used "windowed" dates, where two-digit years refer to the 20th century in some cases and the 21st in others? Did you ever get around to fixing them for real? And if not, are you regularly adjusting those date windows?
And how about the work-arounds you sweet-talked users into accepting to help you get through the crisis? How many of those hoops do users still have to jump through? Is there a plan to clean them up?
Or did you forget about them, once zero hour was past and the Y2k budget dried up?
Don't ignore them. Clean up those small problems. Complete those not-quite-finished fixes. Put your own Y2k ghosts to rest, once and for all.
And be glad your IT shop isn't one of those that will be haunted by the ghosts of Y2k for years to come.