InformationWeek

"Think or blink".

A high school teacher of mine used to ask questions in class a lot. If students were slow to respond, he ran through a routine that went something like this:

"Well? What do you think?"

Silence.

"What do you think you think?"

Silence.

"Think something! Think anything!"

Silence.

Dear Jeff:
Thanks for your comments. They brought back memories. I have a feeling that we may have either gone to the same high school or else the dialogue you quote is standard procedure for frustrated teachers.

In all fairness to the club attendant at the airport, he's probably not the only person working with a computer who cruises on mental autopilot. Besides the tedium of the job, the guy suffers from the same syndrome as anyone who relies overly on the rule book and the computer screen: Brain cells tend to go into hibernation.

Those of us who have designed systems almost always had the objective of providing information to viewers so they don't have to go through a lot of work. As the next logical step, we did our best to interpret that information so that users don't have to do much (if any) analysis. The result is that we, as consumers of computerized information, tend to accept whatever we see on the tube or a printout as gospel. It's a pervasive syndrome. After all, maybe you and I review our own credit-card statements to make sure that the charges are correct, but how often do we check to see if the computer added correctly?

Visual Basic, PowerBuilder, and Delphi are the main tools in the China market. I cannot find data about their sales volume and market share in 1998 and 1999, both global and within China.

I suppose that these data can be found in your Web site, an industry publication that looks at trends, but, in fact, I didn't find it from your official site or publications, so I am seeking help from you.

If you could send me the information or notify me about ways to access the data, I will be very appreciative. Thank you for your precious time on this mail and wait for your favorable response.

With best regards.

Yours sincerely,
Gu Xin

Dear Gu Xin:
Rapid Application Development is growing increasingly important as companies find it necessary to respond quickly to E-business competition. No longer do we have the luxury of waiting months to implement new initiatives. As you might expect, many vendors are touting tools that can help IT shops with this problem.

The most efficient way to get the data you seek about RAD tools is to use the Internet. Search-engine tools such as Google and Infoseek , as well as indexed sites such as Yahoo and Lycos can provide a wealth of data. Letters to the public affairs departments of the vendors of the tools themselves, such as Microsoft, will get you access to any sales figures that are not considered proprietary.

Good luck with your project.

We are in the process of recruiting Oracle programmers at my firm. The chief programmer doesn't believe in resumés or interviews. He says that talking to someone and getting a feel of their personality is all you need to know if the person is right for the job. I believe in using resumés as screening devices and giving technical tests to access knowledge.

Who do you think is right? What strategies do you use to hire people?

Thanks for your time.

Gabriel E. Pagan

Dear Gabriel:
There are valid arguments for both points of view. Resumés are an efficient method of identifying the individuals who seem the most promising while eliminating people from the review process who don't have the experience that you seek. Likewise, technical interviews can show whether someone is overstating their qualifications. On the other hand, your chief programmer recognizes that skilled Oracle programmers are in short supply and many of them may not feel the need to write a resumé or subject themselves to technical tests.

Personally, I find nothing is as good an indicator of a successful match as a recommendation from someone I know well--especially someone who works with me. My priorities have always placed their suggested new hires at the top of the interview list.

My practices fall somewhere between those of your chief programmer and you. I use resumés and technical interviews, since I've never been comfortable with the assumption that I was a good-enough judge of character to base a decision on my reading of someone's personality. However, I 'm not a proponent of testing for anything other than basic-skill jobs or for professional certification. The problem I have with testing is that I find it difficult to assure myself that tests are necessarily indicative of how well a person will do in the job.

As the manager of the department, I know it can depend on how much outsourcing etc. is allowed or required, but in general is there a tool or reference materials that would be a good guide? Our IT department is in its infancy and I would like some up-to-date information to make educated decisions as our department evolves.

Thank you.
Scarlet

Dear Scarlet:
No, there isn't a formula. But lots of consultants will be willing to sell you one.

OK, I suppose that was too short of an answer--so, here's what I mean. While there are general metrics such as you describe, they all work on the basic premise that they are valid regardless of your company's underlying challenges and goals. However, this assumption is a real leap of faith. Further, the metric itself is open to significant interpretation. For example, if you use IT spending as a percentage of sales, what does it really mean? If one company spends less than another, is it more efficient or not as advanced?

Here's what I suggest. First, determine with your management what the IT department is supposed to accomplish. The answer is rarely intuitively obvious and the dialogue will take longer than you might think. Next, decide what the measurements might be based on your company's culture. The metrics have to be something meaningful to your management. In other words, something like cost, number of hours per year of downtime, etc.--not lines of code produced.

With that preparation, go to the literature and read what other companies are doing. Talk to people in your industry or those who work for companies admired by your bosses, even if the industry is different. At this point, go back and modify, as necessary, your thinking. Bring in a consultant or two if you want. After all the homework that you have done, if you still need help, you are now prepared for making use of outside talent effectively.

I'll admit that I have a hard time staying in the same line of work for more than about five years, and I'm looking down the road. I have interests in networking, but not much education or experience. I have experience and education in materials management and logistics, as I said earlier, but I'm a little bored with it.

I am currently gaining experience delivering ERP solutions, with some potential to get involved with integrating ERP and E-commerce. I'm looking for your two cents here. Should I: