|
Jim Seymour advises companies on how to survive y2k. If a company has not started its repair by now, it's dead. That's his assessment.
Those that started late -- i.e., all of them -- are now facing the pain of lopping off whole sections of their operations. They fight this. He gets paid to tell senior management, "Bite the bullet; we're out of anesthetic."
When I think of Jim Seymour, I envision the doctor in GONE WITH THE WIND in Atlanta. Remember the scene where the camera pulls back, and there is a sea of men writing on the ground? Remember the screams of the man with gangrene in his leg. "Don't cut it off! Don't cut it off!"
There's Dr. Seymour, saw in hand.
Notice the final example: a 27-year-old programming manager who was recruited by a competitor: $200,000 a year for five years, a no-cut contract, and a $50,000 bonus.
These are still skeptics out there who say, "We can fix it." Tell that to the company that just lost their whiz kid.
Company A may make it. Companies B-X won't. Then company A will go bankrupt because the resulting depression shuts off its cash flow. Or its bank goes bankrupt and cuts off its credit line.
Y2K is systemic. There is no stopping it.
This is from PC MAGAZINE (June 30).
* * * * * * * *
I've watched reactions to the impending Y2K crunch go through five distinct phases. First there was classic, bury-your-head-in-the-sand denial: It ain't gonna happen.
Second, smart early-response companies developed and sometimes put into place comprehensive plans to test and fix everything having to do with Y2K date errors in their software and hardware well before the end of 1999.
Third, we moved into a period of shock and dismay as we discovered just how much of that old spaghetti code is still Out There and in daily use and how large and daunting the problems really are.
Fourth, we went through the "don't fix it, dump it" stage, when companies decided they had to abandon that legacy code and the creaking boxes that ran the code by moving on to modern hardware and software in client/server architectures. That was a smart and ultimately cost-effective strategy indeed, which did wonders for the likes of Baan, SAP, and others while there was still time to design, implement, and test those new systems.
Today we have moved into the fifth stage, which I can only call triage. Companies are recognizing that unless their Y2K-fix programs are already well underway and they're starting to get into testing their new code, they haven't a chance of fixing everything in time. So they're engaging in battlefield triage, deciding which of their vital systems they're going to let go boom! on January 1, 2000, and which absolutely, inescapably must--and still can--be fixed by then.
It's a bloody, ugly process. Telling a manager you've decided one or a dozen of the systems his troops rely on will probably go south in eighteen months, and you've decided you can't even try to fix the problem by then, leads to very tense sessions. I know; clients have been calling me to come sit at the table while they tell managers this unpleasant truth. . . .
We'll spend a day trying to whittle down a list of 275 programs to an agreed-upon target of, say, 90; and at the end of that long and wearying day, we'll find we've succumbed to so many special pleas to keep just this one, or just that one, that our list still includes 211 proposed survivors. It doesn't work that way, so the next morning (or continuing that night over bad take-out food and bitter coffee) we tackle the list again. . . .
If you see some movement in your company, but not much, toward anticipating and solving the Y2K dilemma, you're not alone. A recent report by Triaxis Research captures the situation today very well: At the 250 largest public U.S. companies, which together have total projected Y2K-fix expenditures of $30-billion plus, only 20 percent of that amount has been spent so far. . . .
Deciding what to let go, while protecting things like payroll and accounts receivable and payable--and all those other well-hidden programs that are the information nervous system of your company--is a tough road, but it's the only approach that will let you focus sufficient resources on the essential, salvageable survivors.
And there are very few competent, experienced people available to help you fix the old systems. I've seen elderly COBOL programmers, who retired in the 1970s after making $32,000 at their peak, brought back in 1997 as $85,000-a-year contract employees. And last month a client hired a 27-year-old who was heading one of several Y2K teams at a competitor to run that client's Y2K teams--for a five-year, no-cut contract at $200,000 a year, plus a $50,000 signing bonus. He was a nervy guy and asked for the million bucks on a take-it-or-leave-it basis. And he got what he wanted.
|