Ogilvy & Mather Worldwide has a tradition of jumping on technologies early. The New York-based advertising agency was in the vanguard of virtual private network use, and by 2003, Web services were active on the company's network. Some might say that Ogilvy's IT group violates an unwritten IT management rule that cautions against investing in nascent technologies too soon.
But to Yuri Aguiar, a senior partner and chief technology officer, breaking these rules was strategically sound. "We knew we'd be able to achieve much better application integration by adopting Web services, so the reward was greater than the risk," he says.
Like any field, IT management has its unwritten rules and conventional wisdom that managers ignore at their peril. But most IT managers occasionally break or bend a rule, so we talked with some of them about when and why you should consider doing so.
Know the rules
Before you can break the rules, you have to know what they are. Other than the rules prohibiting unethical and illegal acts, there are few universal IT management edicts. What is prized in one corporate culture may seem foolish in another.
For example, Rich Hoffman recalls that project planning was discouraged at an entertainment company where he once worked. "They prided themselves on not planning. IT was fast and loose," he says.
That was a rule made to be broken, but Hoffman, who is now president and CEO of Hyundai Information Service North America in California, still had to beware of the culture police. "You had to be a closet planner, because if you openly admitted that you were a planner, they insisted that in their culture, it couldn't be done," he says.
Once you know the rules, ask yourself if you have a good reason for wanting to break one. Rule-breakers are rarely rebels without a cause, says Mark Lutchen, a partner at New York-based Price Waterhouse Coopers who formerly served as the global CIO for Price Waterhouse. "Often, people break rules not because they want to be renegades but for purposes of expediency," he explains.
Particularly in IT, he says, rules can become outdated quickly. "A rule has to be constantly re-evaluated, because IT is constantly changing," Lutchen says. "You may have a set of rules that were for a different era or infrastructure."
You break it, you own it
Before you break a rule, consider the consequences. "Assess the risk component and whether you're willing to accept it," says Lutchen. For example, he says, if a company were facing bankruptcy and its software engineers were leaving for more secure jobs, the only way to keep IT functioning might be to outsource all or most of IT. In that case, a CIO might accept the risks associated with outsourcing core competencies, even though that's breaking a major rule. But outsourcing the actual management of IT would probably be judged an unacceptable risk because the CIO is ultimately accountable for management decisions.