Crossing the Great IT/Business Divide

All too often during the past decade the opportunity for technology to support the insurance business in new ways has meant similarly novel opportunities to waste money. One of the principal causes of that waste has been the lack of mutual understanding between business and technology -- business professionals lacked the criteria by which to evaluate the suitability of any given technology for their operational needs, and technology people had little insight into the arcane ways of the insurance business. Both the frequency and magnitude of project failures have drawn attention to the problem, resulting in significant progress toward bringing the business and IT together through the proliferation of business-trained CIOs and the widespread establishment of more-rigorous governance and project management processes, for example. But perhaps the most decisive resources in closing the gap between the business and IT are the personnel who act as a bridge between those two camps -- typically business analysts. >> The role of business analyst has been around for a long time, but the revolution in technology's utility for the business has made the demands on the role far more exacting. It's clear to most insurers that to avoid the hazards associated with "throwing a project over the wall" -- and never being sure about what is likely to be delivered when it's thrown back -- they need people steeped in the business, knowledgeable about technology and experienced in project discipline. But how those people are best groomed and where they fit within the enterprise is an unsettled matter, varying with both internal considerations of company culture and size, and external factors associated with the continuing evolution of technology. That makes it hard to generalize about how a particular company should position its IT/business "bridge builders," but it only underscores the importance of cultivating these professionals one way or the other. Companies first have to ensure that the conditions for the success of those individuals exist. The foundation of IT/business alignment is an IT strategy that is congruent with business strategy and has the full support of the business, according to Paul McDonnell, senior vice president and U.S insurance segment lead, BearingPoint (McLean, Va.). Above that base should sit an IT planning process calibrated to the changing needs of the business. At the top, business and technology unite in the effective execution of projects within a defined business architecture -- and that's where it all happens. Critical Resource "The people who use that architecture and are probably the most critical resources for the success of those projects are the business analysts," McDonnell says. That is especially true today, considering insurers' focus on major initiatives related to compliance, business process automation and service-oriented architecture (SOA), he asserts. "Everybody wants to talk about the technology involved with SOA, but the technology is only 20 percent of the story," McDonnell observes. "When you look at the tasks that insurance companies have set for themselves, they have a heavy dependence on these resources." One of the difficulties of feeding that dependence is that effective business analysts are made, not born -- they are bred through years of experience within a particular company's business combined with an education in that company's technology capabilities. An appreciation of that genesis increasingly is influencing insurers to formalize the business analyst's career path, according to Don Laackman, senior executive, insurance practice, Accenture (Chicago). "We've seen IT departments building competency frameworks and different career development towers, or tracks, for IT professionals, and there's an increasing recognition that you need a business analyst tower," Laackman says. It is only with such a formalized track, he adds, that companies "will attract and retain the right kind of people who understand the technology issues and engage with the business to communicate how to translate technology advancements into business advantage."

Best of Both Worlds The mature business analysts who emerge from such cultivation represent the best of both worlds, in Laackman's view. They need both a deep understanding of the business and an understanding of what it takes to implement technology. "They also have to be current with both the state of available technologies and their company's existing capabilities," he adds. Some companies build their business analyst pool by rotating them in and out of the position, and making experience as a business analyst a prerequisite of advancement to higher executive positions on the business side, relates BearingPoint's McDonnell. Business analysts need not be located within a centralized group, he says, "but you need to identify them, track them and give them a career path." McDonnell also advises ensuring that business analysts are rewarded for the arduous work required to advance along that career path. Many candidates for the business analyst role are those who "are continually performing Herculean efforts," he insists. "These are the kind of people that show up at 6:30 a.m. and stay till 9 p.m. and are probably working six to eight hours over the weekend." McDonnell cautions against mistaking business architecture expertise for the kind of insight required of business analysts. "We've seen companies where pretty sophisticated business architecture groups have been organized that have loads of data on how much it costs to perform a particular business function, etc., but when the time comes to figure out how the application is going to affect the business, they're not clamoring to get people with that expertise involved," he relates. "At the end of the day, the paramount skill is having an in-depth understanding of the business." Bloomington, Ill.-based State Farm Insurance ($59.2 billion in revenue) has been drawing business analysts from the business ranks for decades, according to Randy Wiltse, vice president in charge of State Farm's P&C and agency systems. But it has made adjustments in their placement within the IT organization to ensure better IT/business alignment. From Silos to Solution Centers One of the most important changes affecting the business analyst role in recent times is the need for greater integration of systems across different parts of the enterprise, such as State Farm's auto, fire, life and health companies, argues Wiltse. "In the past, a business analyst could function very well having knowledge in only one of those silos since their systems weren't expected to interact with each other to a huge degree," he explains. "It became more difficult for a business analyst to operate because they had to be aware of things beyond their immediate environment." State Farm formerly pooled project skills in a centralized area, which it drew upon for particular initiatives. "People would be pulled out, form teams, do the work and come back to the main group again," Wiltse recalls. "That was conducive to building broad skills but not depth of knowledge in particular areas." The carrier also divided business analyst responsibilities between what Wiltse calls service and development assignments. "In the old world there was one group of business analysts who handled the keep-things-up-and-running responsibilities and another that was responsible for the project work, actually developing the new applications," he elaborates. "That's really where we experienced the toss-the-stuff-over-the-wall problem." In early 2005, State Farm reorganized its IT group into "solution centers" corresponding to major application areas -- such as auto/fire, enterprise CRM and agency -- that house about 80 percent of the carrier's business analysts. On a typical project, multiple solution centers are likely to interact, unlike the days of happily siloed activity. But the new scheme also recovers some of the focus on depth from the pre-integrated epoch. "What we found was that trying to be overly flexible probably isn't the best answer either," Wiltse comments. In the new environment, business analysts easily can be moved out of the development role into the service role for a particular application -- which builds in continuity and accountability, Wiltse explains. Because they are working within application areas, he adds, "They are working on similar things so that their depth of knowledge increases, and they are working with the same group of people so that they develop good working relationships."

Most important, State Farm has driven its business analysts to pair up with their business counterparts on a strategic level, according to Wiltse. "The business analyst's job is to completely understand not only what the business partner needs, but the downstream ramifications to other systems that may come into play, and be able to adequately describe that to the people who are going to be required to build this," he says. "It's not a passive role -- it's a very active role." While applying no less activity, UnumProvident (Chattanooga, Tenn.; $7.8 billion in premium income) bridges the IT/business gap through shared responsibility for project execution. For a typical project, a business project manager -- roughly resembling a business analyst -- works closely with the IT project lead. "During a given project, they become one team that is very much a mixture of IT and business people with coleadership," remarks Mike Jenkins, the insurer's vice president, IT, corporate systems. In the past, the carrier used the prevalent model of IT-based business analyst standing between the business and IT, but that model was found wanting, according to Jenkins. "Analysts were never going to learn quite as much about the business in IT as they were in the business area," he says. "This model emerged because we felt that that knowledge was the key to success." Roles and Expectations Cooperation is reinforced by UnumProvident's adoption of what it calls its Navigator project methodology, adapted to the carrier's needs from principles popularized by the Project Management Institute (PMI; Newtown Square, Pa.). The Navigator methodology enforces the defining of roles and identification of their associated expectations at the beginning of projects within a framework of process and concepts expressed in a shared language, according to Al Jarman, IT project leader. "From project to project, people are following the same methodology and speaking the same language, so when you are producing a deliverable, everybody understands what is being talked about," he says. The alignment achieved through interaction between IT and business project team members is not an overnight, "flip the switch" kind of thing, but rather something that builds over time, according to Jim Smith, business project manager, UnumProvident. Smith says his own understanding has grown over multiple project engagements with IT. "We try to bolster the knowledge both ways," he says. "For example, we've done some internal training for our IT folks around things like financial reporting." But while the accumulated familiarity with IT on the part of business-side professionals is important, training efforts are biased toward educating IT about the business, Jenkins insists. "There are two broad categories: one is helping the IT people understand exactly what the business is doing, why they're doing it and what they need; and the other is an effort to help both the IT and business folks involved in the project learn how to run it." Smith and Jarman recently put their project execution expertise to work as coleaders on an executive information dashboard initiative referred to internally as CHAMPS. The initiative began as a prototype for examining return on equity within a particular line of business, but eventually will be extended to all lines. "It will be a two-year project overall," relates Jenkins. "This was just the initial phase." The project was especially challenging in that it was UnumProvident's first foray into a business intelligence initiative of this kind. To complement its internal expertise, the carrier called upon Lincoln, Mass.-based consulting firm Palladium Group. According to Smith, success of the project was fostered by Palladium's ability to provide a parallel model of consultation, matching business and IT expertise. "They had both of those components," he says. "They understood the financials, and they understood the technical aspects of the project." The first phase of CHAMPS was completed on time and on budget, despite a tight time line, according to Jarman. "We signed software contracts in December and implemented by April 17," he says. The Navigator methodology played a crucial role in the team's ability to hit the ground running, according to Smith. "We already knew the processes and tools we use to manage projects -- we didn't have to learn that stuff," he says. "We were talking the same language from Day 1." The coleadership model also fosters speed, according to Jarman. "You can get things done a lot faster because you're cutting out a middle person so that you can talk directly," he argues. The model also gives him liberty on the IT side to move rapidly within his sphere of authority, Jarman adds. "As an IT project leader, I can reach out and touch whomever I need on the infrastructure side or anywhere else in IT and be able to move things along very quickly."

At Cincinnati-based Great American Insurance Co. (GAI; $1.5 billion 2005 statutory surplus), business analyst has become a formal career path with associated training and regularized responsibilities. Candidates typically come from the business and reside within the IT organization. Their work on a given project begins with meeting with business executives to determine their needs, according to Carol Adler, senior business analyst, GAI IT services. "From there, we develop requirements, which the business signs off on, and then we work with the developers," she relates. "We then create specifications with the developers and begin to work hand in hand with them." Among the benefits afforded by well-trained business analysts is that they are very good at uncovering what might be called "unidentified requirements," says Sherree Wilson, program manager, GAI IT. "Because they understand both business and technology, they're able to ask the right questions and translate the requirements into appropriate language so that the developers completely understand what is needed." GAI's business analysts also make use of a range of tools to speed the development process. "We did a lot of manual testing in the past," Wilson relates. "The discipline of the business analyst has come a long way in terms of tools, availability, training and career progression." She notes that the analysts use Irvine, Calif.-based Telelogic's DOORS during the requirements phase. They also use Mercury (Mountain View, Calif.) QuickTest Pro for automated testing and Mercury Quality Center for documenting test cases and recording results. Wilson adds that GAI business analysts develop test plans and are the front-line testers before business users receive an application. As a career path within the IT organization, the business analyst role parallels that of IT manager at GAI to a great extent. "They start as a 'developing professional,' which is a lower-end business analyst, and they receive training along the way," says Wilson. Along with ongoing training, analysts often are provided with one-on-one mentoring. "We hook up many of our business analysts in teams so that the more senior analysts can support the more junior ones and help them to grow their experience," relates Wilson. Developing a sufficient number of business analysts is an ongoing challenge, Wilson acknowledges. "It's easy to teach someone to program but hard to teach someone analysis, so we have more success taking people from the business units than from a programming background or hiring them from the outside," she explains. "Many of our analysts have gone on to expand their knowledge to become technologists and go into programming. There's a lot of opportunity for growth, but we find our best analysts come from the business." That fact was influential in the success of a recent project to replace multiple systems with a single policy admin, claims and accounting system for GAI's high-policy count/low-premium trucking division ($118 million in premium last year), according to Tina Young, assistant vice president of the division. Young declines to mention the system vendor or the cost of the project but says that 30 people worked on the project -- one of the largest ever undertaken by the division -- which entered the planning phase in 2002 and went live in pilot with five agents in August 2005. "We were able to keep much more on budget and not miss our time frames because our business analysts were able to catch requirements before they were missed," Young says. "The analysts have been in the roles we're creating the systems for; they know the workflow, so there was a very short ramping-up time to understand the need they had to fulfill. If the business had to correspond directly with the developers, this project would not be as far along as it is today." --A.O.