Fred Held was CIO at Mattel Toys Inc. for most of the 1970s. He recalls the day a gung-ho marketing executive, apparently having just read Popular Science, asked, "Can we put a chip in every product, hook up to spy satellites and track where everyone goes, so we can really see who buys our toys? We could check which stores have too much inventory and transfer product accordingly."

Disregard the fact that the technology was at least three decades away. The marketing guy was proposing to insert a tracking device inspired by Cold War espionage in every Hot Wheels car and Barbie doll sold worldwide. Can you say "worst public relations calamity ever"?

Needless to say, Held -- who is now a partner at Tatum Partners, a professional services firm -- declined. "You have a great deal of foresight," he told the exec. "This isn't quite possible right now, but we're going to keep an eye on it." Thus the marketing guy went away flattered, and Held turned him down cold with no ill effects.

This is by no means an easy thing to do, and since Held's days at Mattel, it has only gotten tougher. In today's corporations, IT is supposed to be an enabler, a conduit rather than a gatekeeper. When a line-of-business executive proposes a project, IT is supposed to make it happen.

Unfortunately, some of those ideas are too risky, difficult to justify given the company's overall IT picture or just plain hare-brained. But the IT executive who says no may be putting his career on the line.

The key, according to CIOs, project managers and other experts, is to ask for and provide facts until the person who made the request is forced to acknowledge that the idea won't fly.

'Press statement' method

"You need to get everyone to recognize risks and alternatives," says Jerry Luftman, author of Competing in the Information Age: Align in the Sand (Oxford University Press, 2003) and a professor at the Stevens Institute of Technology in the US. "You can't just say no, put your hands over your ears and walk away. You want to get them to recognize why the answer has to be no; that's the trick."

This diplomacy may not come naturally to many in IT, a discipline long known for bluntness. Carolynn Benson, a senior consultant at Ouellette & Associates Consulting, says that in training courses, she teaches clients to say no with a "press statement" -- a positively worded refusal. "The way to say no is with options," Benson says.

A typical hell-no press statement might begin, "IT is committed to helping your department meet its business goals. After reviewing your proposal, we believe the following options will help achieve those goals and provide value for the company." Absent from the list of options, of course, is the one proposed by the manager.

What do you do when an executive doesn't like this answer? "You push back with your press statement," she says. If things get nasty, you bump the conflict up to the next level with another statement: "The person who can put your request back on track is the CEO. Shall we go to the CEO together and present our arguments?"

Frequently, the big "no" concerns a completely unrealistic time frame for a project. Then IT is not so much refusing to tackle the project as making sure it gets the time needed to do the job properly. Dave Berg, CIO at Tanner Co and president-elect of the Society for Information Management's InterMountain Chapter, tells of a recent dust-up.

For more than half a decade, the employee-award company had wanted to automate certain pricing and product-replacement tasks in its backbone application, but the request always fell to the bottom of the pile. Late in 2004, without warning, the head of manufacturing and the chief operating officer "decided all of a sudden that this was the most important thing in the world", Berg says, and they wanted it in January. Berg countered with March. They compromised on February.

IT was on target to make the release date, but an error was discovered in testing. Then came the moment of truth: Berg faced heavy pressure to release the feature with a significant flaw. He'd been forced into a tough spot: a buggy release would cause hundreds of employees to grumble and blame IT. On the other hand, Berg might be viewed as obstinate, a typical perfectionist techie, if he insisted on holding up the release to fix the error. He held his ground and insisted on additional programming and testing, followed by a clean March release.

Were there some tense discussions when Berg demanded to let the schedule slip? Sure. But that's not the end of the world. As Berg puts it, "If you never say no, you must be a yes man -- and nobody likes a yes man."