CIO Challenge

Most CIOs have a symbiotic relationship with the business side of their respective institutions. But there inevitably comes a time when a business executive will ask a CIO to develop a project that the technology group sees as a disaster waiting to happen. It then is the CIO's job to intervene, offer alternatives and somehow ensure that everyone is happy with the outcome. Successful CIOs must find ways to be direct with the business side without burning bridges and actually come out on top.

The No. 1 mantra for getting the equation right, according to Michael Radziemski, CIO at Jersey City, N.J.-based Lord, Abbett & Co., is communication, communication, communication. "Our whole organization is aligned to the business organization," he says. As such, the firm has assigned individual technology leaders to set up development and support teams, each with a focus on a particular aspect of the business. These leaders are held accountable to the business side. "In this way, the business side knows who to go to when they need something, and the technology side gets to know what their counterparts' priorities and hot buttons are," Radziemski adds.

John Deane, chief technology officer of Houston-based AIM Management Group and its parent company, AMVESCAP (Atlanta), also stresses the importance of good communication between business leaders and IT. "I actually have the tech folks sitting on the same floor, next to the business side, so you can build a lot of trust there," he says. These individuals work for the IT department, but most of the application groups at AIM, in essence, work for the business side, Deane explains. This helps ensure that the technical side understands the needs of the business, and it gives the business side the ability to become more familiar with what is possible from a technological standpoint, he relates. "They understand our problems. They see how long it takes us to do something or that in some cases we don't have the critical skill that we need, so you really start to understand each other's problems, and that is the whole key to everything."

Valley Forge, Pa.-based Vanguard has taken this approach one step further. "Our technology leaders actually work side by side with the business people during the busy season so they can understand the pressures on IT," notes Tim Buckley, managing director and CIO at Vanguard. "The flip side is that the business side understands the pressures and challenges that the technology group faces."

Conflict Resolution

Nonetheless, conflicts, competing priorities and differences of opinion may arise. When this happens, keeping the lines of communication open and laying out all the options is even more important. That includes highlighting pitfalls and offering up alternative solutions, which may end up being cheaper in the long run, suggests AIM's Deane. "The business might ask for something that will be tough to deliver," Deane notes. "We'll say, 'If you really want us to do it, we'll do it, and here is what it will cost you," he continues. This often helps the business make the right decision, Deane asserts.

Planning ahead is another way to avoid combative scenarios, suggests Vanguard's Buckley. One option is to teach the business side about the various technologies and how they work. This often can pay off down the line. According to Buckley, Vanguard has established a technology review group that spends a lot of time doing business analysis and long-term planning alongside the business folks, explaining different architectures and the challenges of legacy systems. "We explain architectural concepts and directions around portals and service-oriented architecture [SOA] so that the business areas have heard of these technologies and their benefits once the planning season begins," he says.

Still, despite all the planning and conversations, the bottom line often is a top priority for business executives. Setting up a system in the quickest, least expensive way often sounds like a great idea at the time. But when it breaks down a year later, they'll often wish they took the long-term route, relates Lord, Abbett & Co.'s Radziemski. "The trade-off is theirs," he says. "But it's our job, as technologists, to give them accurate assessments of the cost, time and effort, so they can have reasonably accurate information on which to base those decisions," he says.

Vanguard's Buckley agrees, but, he notes, sometimes the decision is out of the executives' hands. "Nine times out of 10, we end up taking the architectural approach. But on the 10th, they may just say, 'Hey, we've got to get this done because of regulatory reasons,' or, 'We have something we need done for a client and we just have to do it,'" he says.

Make Your Case

More often than not, large infrastructure projects cause the most friction between the business and technology sides. For example, purchasing a large quantity of storage can be expensive, and the immediate business value is not always obvious to the business side, relates Lord, Abbett's Radziemski. "It's our job to articulate the value of the things we want to do," he says.

Similarly, the tech team at Vanguard was recently asked to put in a wire system that was intended for a single business line, a project that could have been accomplished relatively quickly. But, according to the firm's Buckley, the tech department instead recommended building the system using SOA principles, so that it could be reused across other business lines at Vanguard. "As a result, it is a little bit more expensive and it's going to take a bit longer, but Vanguard on the whole will be better off," Buckley says.

Problems also may arise when the business side tries to build something on its own, often with a limited understanding of the technology, observes AIM's Deane. It then becomes the burden of the CIO and folks on the technical side to fix or rebuild the system.

Such a scenario occurred at AIM involving a large database. The internal team within the business side had built a Microsoft Access Database, and it quickly became overwhelming within a couple of months, Deane relates. "The business side was convinced that if they handed it over to IT, the technologists could put it in their own infrastructure within a few weeks," he says. "It turns out it took six months to build it right, and it ended up costing everyone a lot of money."

Ultimately, no matter what caveats the IT department alerts the business side about, at the end of the day, it's up to the business to make the final decision on all projects. Given alternatives, they may indeed choose the cheaper, less-efficient or less-resilient one. To offset this risk, it's a good idea to have the technical team build systems with the maximum amount of flexibility, Deane points out. This way, the systems can be changed down the road, if necessary. "If it does break or doesn't do what it was supposed to, it won't have precluded us trying to fix it quickly," Deane says.

Nonetheless, most CIOs will put up a valiant fight if they think it will protect the business in the long run. "If I thought they wanted to go a route that would technologically put the business at risk, I would put my hand up and argue very vigorously relative to what I thought needed to be done," Lord, Abbett's Radziemski contends.

Ultimately, it's to the advantage of both sides to take the time to listen and understand each other. "If you look at successful technology organizations, the more intimate they are with the business, the more successful they are, because it works both ways," says AIM's Deane. Still, at the end of the day, it's the CIO who takes the heat when things go wrong in the technology departments. "Sure, but that's the life we chose," jokes Deane.