PC Week Magazine

 

Just say no

By Joe Mullich

Sometimes it feels like all a CIO ever says is no.

No, you can't have that new piece of technology you read about, even if you are the CEO, because it's 10 times more expensive than you think. No, you can't have Mavis Beacon's typing tutorial on your computer because it will clutter your desktop. And no, no matter how urgent it is, your project isn't first.

No, no, no. And no, sir.

With all the conflicting demands placed on IT, Norman Vincent Peale wouldn't last 2 seconds as a CIO. The ability to say no--and have it stick--is one of the most crucial aspects of the CIO's job, but it's complicated. CIOs must deal with competing constituencies, with executives reading articles that appear to contradict the CIO and the suspicion IT is saying no to avoid work. Saying no requires today's CIO to be technologist, diplomat, educator, politician, and psychologist all rolled into one.

Making the case

The authoritative stance is out. With managers and end users more able to make runs around them, CIOs say their no's must take the form of a consultation. "We have to be an educator, not a demander," says Jason Ray, vice president of operations and information systems for Compex Systems Inc., a legal documents firm in El Segundo, Calif. "There has been a lot of priesthoodness among IT people."

The foundation for a no begins with trying to reach a common understanding. Often, a CIO will be presented with the user's idea of a solution rather than his or her problem. "I try to understand what problem they're trying to solve and why," says Bill Ledman, senior vice president of information systems and services at the Federal Home Loan Mortgage Co., in McLean, Va. "If I don't believe they have the right solution, I have to be able to explain in English why I would take a different approach and make sure they understand that. After you develop a business case, it's pretty straightforward."

Well, straightforward in a perfect world with reasonable people. But this is IT we're talking about. "If [executives] have a suggested solution, they're expecting to hear, 'Yes, sir, we can have it in place in 3 hours,' " says Ray.

The first thing Ray does when an executive approaches him with a technology idea he or she gleaned from a business magazine is dampen expectations. On one occasion, an executive read that creating a Web page cost a mere $50. He told Ray to dip into petty cash and get the company on the Net pronto. "We can look into that," Ray said, "but we'll also have to consider the cost of maintaining and updating the page so it provides value to the customer." With each item Ray ticked off, the Web site seemed pricier and more unappealing. Given perspective, executives often beat Ray to the no and tell him to forget the project.

"If he still wants me to look into it, at least I've set the stage," says Ray. "But if he's expecting to spend $50 a month and I just nod my head and come back later and tell him it will cost $5,000 a month, I'll look like an idiot."

One of the hardest things to make users understand is technical limitations. After all, IT can do anything, right? So if IT won't do something, it means they're lazy. Rich Egan, CIO of Ringier America Inc., a large printing company in Itasca, Ill., confronted this problem when his company gave salespeople laptops that allowed them to retrieve their E mail from remote locations. The salespeople became irate because the system stored E-mail from the road in a different place.

Egan had an analyst thoroughly research the problem. He even secured a white paper from the E-mail vendor explaining the only product that could meet the salespeople's request was Lotus Notes. "We told the sales staff we had invested so much in our E mail system and weren't going to change for this one issue," says Egan. That kind of hard documentation is essential.

"When you say no, you'd better have a lot of gunpowder, nice and dry," says Paul Strassmann, author of "The Politics of Information Management" (The Information Economics Press, 1995). "You need better reason the higher up you go. But even if you tell a programmer four levels below you no, you better have a reason because your whole position as leader depends on the trust people have in you." (continued)

 

1 2

 

Back to samples page