I read with interest your opinion piece on the year 2000 ( 2001: An IS Oddity ). I am the editor of a year 2000 Web channel -- and an analyst covering year 2000 companies. There are a couple of questions that come to mind in reference to your article that I would appreciate answers to. I will provide a direct quote and then my question. Please excuse my relative technological ignorance, as I am a financial analyst and journalist more than a computer person.

1) "The issue is damage control for the inevitable mistakes we make when we miss patching some critical systems." My question here is how does one prepare -- resource- or manpower-wise -- for such damage control work when there seems to be no possible way to guess how much damage there will be. (Perhaps we will get clearer estimates of this as more systems begin to fail.)

2) "The major year 2000 cost was finding the problem in the code." The latest industry estimates I am seeing indicate that testing, not software analysis, is the major year 2000 cost ranging between 40% to 60% of total migration expenditures. Could you please clarify this?

3) "I pointed out that it is faster and cheaper to correct the obvious." What is more obvious or less obvious about date-code analysis results? Do you mean code with clues that clearly indicate that it has obvious date references rather than instances where the co de is more obscure?

Adam K.

Dear Adam:

You've asked some good questions. Perhaps my answers will provide a somewhat different perspective than what you may have been reading elsewhere.

Your first question is about preparing when you don't know the size of the problem. The key here is to be sure that you have a solid plan for how to respond. It's like disaster recovery planning. You don't know the magnitude of the crisis or even what it is, but you cannot sit back and do nothing. Let me emphasize that I said to correct the obvious problems and to train on rapid response. That includes planning for what to do if the problem is larger than you anticipate. So far as being able to estimate the size of a problem about which we don't know everything, we do that every day -- sometimes more successfully than others. It certainly is feasible.

Your second question is about testing being the key element, not finding the problem . Here we have a semantics issue. The code fixes are normally easy once you've found the problem; you just have to worry that your fix hasn't messed up something else. Ensuring that may mean a lot of testing to be comfortable that your correction hasn't created any new problems. So from my perspective it means the major difficulty is in finding all of the problems -- the old ones and any you may have created with your fix.

Your third question is about it being faster and cheaper to correct the obvious. The important thing is not whether individual code has an obvious reference or clues as to a date reference. The idea is to put your emphasis on looking at results and what the modules do. If we are looking at a production scheduling system -- wow, this is important. If we are talking about order-entry screens or the report that sorts employees by age for Human Resources, then we are not at the same level of concern and may not spend much time worrying about it. Overall, taking this approach means the total job is completed faster and cheaper.

I just got a job with a manufacturing company that is doing well. However, we need to implement new standards, procedures, training, and install a new ERP system.

In my experience , many new IS executives try to make changes when they're new to a company, and the results are not always good.

My question is : How long should I wait before I make changes in the department?

JAM

Dear JAM:

Make the changes as soon as you feel comfortable that you've:

1. spoken to everyone who thinks they know enough to help you,

2. gotten enough of a feel for the company such that an employee with an additional six months seniority would think you knew enough to take action, and

3. actually developed a reasonable idea as to what should be fixed and how.

I just read your column " The Data Said What? " Actually, I think data warehousing is a very useful concept. It is a great vehicle for creating long-term projects that put money into the pockets of the major consulting firms. Of course, it may not have much benefit for the client!

Patrick

Dear Patrick:

You are cynical. I love it. Keep in mind that neat terminology keeps the economy rolling along. If the client fully understands what you are saying, it is time to shift paradigms -- or something like that.

I enjoy reading your articles. It is nice to know that I'm not the only one facing those problems about getting people to train (" Won't Train? Don't Complain "). I f ace many training issues similar to ones you mention. Do you find that users really don't care about the training until they have to use it every day? What are some things you try to encourage users to seek software training? How do you recommend reviewing the seldom-used features of an application that users forget but can be important?

Thanks again.

Greg L.

Dear Greg:

Users are normally so busy that they loathe having to attend training classes. Further, if training is given too far in advance of actual use, the knowledge that was gained disappears. What seems to work best is to give multiple short sessions in anticipation of implementation with intensive training right before cut-over. Seldom-used features are more easily assimilated if shown during either follow-up refresher seminars or in "helpful hints" sheets that are distributed periodically.

I've been given the daunting task of getting our IS department to stop spinning its wheels and move forward. I work for a large corporation, and our little slice of heaven consists of two plants (200 node/100 node LANs) and one executive/administrative(300 node LAN) building and 190 branches (each with two to three remote nodes). We have a staff of 11 that supports everything from help desk, telecom, LAN, and special-project coordination.

Our big IS boss is overwhelmed with meetings and needs the staff to be independent yet productive while maintaining forward motion. Could you give me any advice on where to start, what to read, etc.? I'm starting to feel that first trickle of perspiration on the brow.

Thanks,

BSK
Jack of all Trades

Dear BSK:

I feel for you. What you are undertaking is a very tough task, normally one in which the CIO is intimately involved. While I usually endo rse reading books as a way of avoiding others' mistakes, it sounds like you need more direct action to develop a plan quickly and begin to implement it.

To have any chance of success, here are a few of the things I would consider doing: First, I suggest you sit down with your big boss and get as much information as you can about the direction and goals of the organization. If you don't know where you are going, it doesn't much matter how you get there.

Next, I would focus on meeting with people in your corporation outside of IS to get an assessment of what they think and what problems they see. Make sure that while you are there, you test your boss' ideas as to the direction and goals for the organization. Then I would take the time to visit people you know who run IS organizations that may face similar problems. Pick their brains, go home, build your plan. After you've done that, review it with the people in your corporation who gave you input, fine-tune it and present it for approval to the IS execu tive.

Good luck!

I actually knew someone named Herbert once and he worked with a guy named Lovelace. Plus, I have a plant named Herbie. Do you think we might just be long-lost acquaintances?

And now I'm wondering, do you think there is cost benefit to having telecommunications in IT departments? We have an interesting political (note that small "p" in politics) discussion going on here because the phones, switch, and all voice communications are in the Support Services Department and all data comm is in the Info Tech department. Here in Info Tech we think both functions should be our department. What do you think?

Awaiting your reply,

Queen of the Geeks

Dear Queen:

I don't know if we are long-lost acquaintances. I suppose it is possible. I had a very pretty tropical fish once that we named Queenie. Do you treat your plant, Herbie, kindly? Is Herbie a happy plant?

Telcom managers can be happy, too, if they are able to negotiate voice and data services at the same time. Since the same telecommunications company probably provides both of these services to you (or certainly can) it may cut your administrative costs as well as provide you with the opportunity for negotiated savings if the functions are merged into one department or the other.