Plan now to pick up the Y2K
By Jerrold M. Grochow, PC Week
Online, October 5, 1998
There are fewer than 470 days
until Jan. 1, 2000, and systems professionals are
working double overtime to meet management
demands to resolve Y2K problems before they turn
into business problems or, potentially, societal
disasters. Will they succeed? Yes and no.
Only a few years ago, I was one
of many in our profession who wondered what all
the fuss was about. I thought that because my
colleagues and I had been programming for the
century rollover since the early '80s, there
really wasn't much to worry about. Just replace
those few systems hanging around from the '70s,
and we would be all set. How wrong I was. The
more I studied the problem, the more concerned I
became. And when I saw programs written in the
'90s (not by my staff!) that would not work for
the year 2000, I knew we were in for a lot more
trouble than I had imagined.
Now don't get me wrong: I'm not
a member of the "worldwide recession"
camp. But I am in the much larger group that
believes we will experience Y2K-related failures,
that some will be more than minor annoyances, and
that we need to develop contingency plans for
these occurrences if we are to get through this
period relatively unscathed.
According to IT consultant and
computer science educator Howard Rubin, many of
you are already into this stage of Y2K activity.
In a June sampling of Fortune 500 companies, he
found that 72 percent claimed to be doing Y2K
contingency plans--up from just 3 percent in a
survey taken three months earlier. This is no
doubt related to another survey that found that
84 percent of respondents said they weren't
meeting all their milestones on Y2K projects. Not
too surprising when you consider the size of most
Y2K projects: Some, and possibly many, of those
projects just won't be completed on time--I
absolutely guarantee it. If you need proof, just
ask yourself, What percentage of other system
development projects over the past several years
has come in on time? I'll wager a large sum that
the number is far less than 100 percent.
What constitutes a good
contingency plan? For some good templates, you
might look at the Web site for the President's
Council on Year 2000 Conversion (www.y2k.gov; search on "contingency
plan"). The first thing to consider is what
your objectives are in making the plan: staying
in business, bringing up failed systems,
minimizing customer complaints and so forth. Once
you decide that, you can begin to figure out what
your procedures are going to be when you are
operating under a "contingency." But
that isn't enough: You have to determine who is
going to be in charge and who is going to perform
those procedures, when and under what conditions
they should begin operating under the plan, and
when it's OK to go back to normal operation.
Your contingency plan needs to
be part of a broader Y2K risk management plan.
According to the bankers making up the Global
2000 Co-ordinating Group (www.global2k.com), your plan should address the
"four P's"--planning, prevention,
preparation and performance. It's a sound
approach as we get closer to triggeringY2K
This is my third annual Y2K
column, and I figure I'll be writing about it for
four more years before the issue is behind us.
Jerrold M. Grochow is CTO at American Management
Systems, an international consulting and systems
development company. He can be reached at email@example.com.