Building the Bridge Between Business and IT

By: James Watson, Jr., Pat Turocy, and Linda Andrews, Doculabs

Insurance companies have characteristically used technology to achieve three objectives: to streamline business processes, increase efficiency, and reduceoperating costs. But the competitive landscape has changed considerably in recent years. Carriers are now offering new products and expanding into new product lines—and they're also under pressure to offer those products through a wide range of new channels. The common thread across all of these business initiatives is that technology has a far more central role to play—in many instances serving as the enabler.

It's fair to say that for most organizations, business strategy and information technology (IT) strategy have become inextricably intertwined—with the corollary that it's now more important than ever to ensure alignment between the IT department and the business units that IT serves. With today's tightened IT budgets, no one can afford to make costly mistakes in technology acquisition; at the same time, the business units need to make sure that their specific requirements are taken into consideration as those acquisitions are made. What's needed is a professional "go-between"—a layer of organization that can serve as the intermediary between IT and the various business units.

Within many of our consulting clients, we're starting to see the emergence of just such an organizational function. These companies have created a new organizational unit, the Project Management Office (PMO), tasked with "translating" between the business units and IT and helping to ensure that technology meets the needs of the business. In many organizations, the business analysts or project managers who staff the PMO are also responsible for driving IT projects from start to finish.

In this article, Doculabs takes a close look at this new organizational entity, and why it makes sense—particularly for organizations in the insurance industry.

Fulfilling a Clear Need

The reasons behind the emergence of the PMO are fairly straightforward. As technologies grow ever more sophisticated, enabling the automation of more business processes, it becomes critical that IT have a clear understanding of those business processes, as well as a thorough understanding of the roles of the functional entities with which those processes must interface. The PMO can serve as the translator between the business units and IT, providing IT with information concerning the workflows, the handoffs, and helping identify the critical points of system interface. In the insurance industry, these interfaces increasingly involve external entities. Straight-through processing (STP) initiatives, for example, require a thorough knowledge of a carrier's business processes and those of its partners—knowledge that the business analysts/ project managers of a PMO can provide.

This business-process knowledge is particularly crucial for organizations undergoing mergers and acquisitions, a trend that continues unabated within the insurance industry. As organizations grow larger through mergers and acquisitions, it's important that IT understand the roles of the business units of the respective organizations, as a prerequisite to integrating the IT infrastructure of the merger partners. In the face of the reorganization and rationalization that comes with any merger, there is a clear need for a group that is knowledgeable about the implications and can help identify the potential impacts of the reorganization. The PMO is the place to house that knowledge.

Also consider the fact that carriers are now offering more products, and more product lines, as a result of the convergence of the insurance and financial services sectors. The result is that business requirements for any new technologies are likely to be more numerous and more diverse; it helps to have dedicated people whose job it is to keep up to speed on new product offerings, as well as on the technologies that will be required to support them. And it also helps to have liaisons to the people most knowledgeable of the implications of regulatory changes, the better to use technology to facilitate compliance.

Managing Multiple Projects

The role of business/IT intermediary also makes sense for organizations with multiple lines of business—a characteristic of most insurance carriers. A related issue is that most organizations tend to have multiple IT projects in progress simultaneously, projects that likely address the needs of multiple business units. The business analyst/project manager offers a valuable perspective, one that looks across business units and technology initiatives, identifying commonalities and emerging needs and helping to define both the business and the technology priorities within the organization's broader business strategy. A carrier seeking to roll out multiple technologies for customer relationship management, for instance, probably needs to set some priorities, a process that should take into consideration both business priorities and technology priorities and interdependencies, in order to better prioritize resources, financial and human.

Among the most critical considerations for organizations in the insurance industry is the increasing need for standards, both internal and cross-industry. Continued deregulation and the consolidation of the insurance and financial services industries have given impetus toward the adoption of cross-industry standards, a movement in which ACORD has played a major role, providing industry direction and promoting standards that ensure benefits throughout the industry. Increasingly, standards are the prerequisite to many business initiatives; they are the heart of the systems interoperability that makes STP work, for instance. Carriers that have internal PMOs to mediate between the business units and IT stand a better chance of making the case for adoption of these emerging standards—a case that in certain instances may need to be made to both the business and the IT sides of the organization.

Finally, there is a need for measurement and follow-up as organizations seek to ensure that their technology initiatives achieve their intended objectives. The business analyst/project manager can apply multiple checkpoints in the rollout of an initiative to monitor progress, and seek input from both business and IT personnel to measure the success of the initiative. The PMO is accountable to both the business units and IT, which helps to ensure that the technology that's deployed truly furthers the organization's strategic goals.

No question—the biggest challenge to putting a PMO in place in any organization is the complexity of the skill set required for the business analyst/project manager role. We've narrowed it down to four key areas: technical knowledge, business process knowledge, project management skills, and, for lack of a better term, organizational savvy.

- -Technical Knowledge: In his/her capacity as a professional go-between, the business analyst/project manager needs to have a fundamental degree of technical knowledge and to be conversant in the key concepts important to the IT function. This person might also be a specialist in some key technology area (such as business process management, enterprise content management, or integration), but also have an understanding of how the specific technology fits into the company's overall technology strategy.

It helps, for instance, for an ECM or integration specialist to have a high-level understanding of a concept such as XML, in order to articulate the business advantages of its use to the rank and file of the business units, while also establishing credibility with the IT staff. It is also important for this person to understand architectural concepts and considerations such as performance, capacity, scalability, and reliability.

The people who staff a PMO should also have at least some familiarity with their IT department's capabilities and resources. Knowing that the IT staff is spread rather thin on existing projects, for instance, or that Java programmers are in particularly short supply within their IT organization, can help a business analyst/project manager determine that the budget for a proposed initiative should include a line item for temporary technical staff.

-- Business Process Knowledge: The business analyst/project manager should have knowledge of the organization's business processes—preferably across several business units and functions, in order to have an understanding of the interrelationships of business processes across multiple business units and of their interfaces with external entities (customers, agents, and brokers, among others). These processes include standard industry processes such as new business application processing, claims processing, and underwriting, as well as brokerage investment and settlement, for those carriers moving into financial services. A good candidate for this position is a technology-savvy individual whose business knowledge has been gained through prior work in the functional areas.

-- Project Management Skills: Some organizations empower the business analyst/project manager to manage IT projects from start to finish. In most companies, this role is likely to require concurrent management of multiple large projects or programs, as well as specific skills such as time management and prioritization skills and the ability to minimize delays through proactive measures. Project planning skills and the ability to help solve problems and facilitate rapid issue resolution within projects are also valuable skills for the business analyst/project manager, as is the ability to manage internal project team members, contractors, and consultants when necessary.

-- Organizational Savvy: The position of business analyst/project manager is no job for neophytes, and the PMO should not be regarded as a training ground for new hires, or as a backwater for individuals who, for whatever reason, don't seem to fit elsewhere in the organization. In Doculabs' experience, the ideal candidate for this position is a seasoned person: someone who not only has the technical and business knowledge, but who is also politically connected. It's someone with the savvy and the ability to navigate the organization, who knows the landscape and the dynamics of the organization—and who knows the political "hot buttons," too.

Why is this so important? The reason is that knowledge of the specific intricacies about the internal workings of the organization is what allows members of the PMO to maneuver around the company and know whom to go to in order to get things done quickly. It takes a person who knows the ropes within an organization to see a project through the obstacles and inadvertent roadblocks that inevitably arise—someone who knows which individual within the company has the authority to take the action necessary to keep a project on track.

As attractive as the idea may be in the abstract, there are some potential pitfalls when an organization seeks to put this additional layer in place, as well as some implications, both internal and external to the company.

One of the principal challenges a company can face is the problem of getting IT to release certain of its responsibilities to the PMO. To many IT personnel, the very need to establish a separate group with a liaison function is tantamount to an admission of deficiency within the IT function; an admission that the technical staff cannot communicate well with the business units. Organizations should thus anticipate potential resistance from IT. The business groups, in contrast, are likely to be quite amenable to the idea of having an official intermediary to IT.

Respect for Authority?

Another potential issue is the question of whether the PMO has the authority to succeed. The PMO's business analysts/project managers need to be connected to authority if they are to succeed in getting the necessary people to buy in. We've seen some projects in which deadlines slipped and timely decisions were not made, all because the project manager in question did not have sign-off authority. In other instances, we've seen projects that progressed smoothly because both IT and the business units understood that the project manager had the ear of someone in authority.

And, of course, in the current economic environment, many organizations seeking to establish a PMO come up against the ultimate challenge: how to fund such a group. After all, this is a time when the pressure is on to make the organization leaner, not to pile on additional layers. Taking a look at the number of recent projects that suffered delays and/or cost overruns for lack of effective project management can help justify the cost of putting a PMO in place.

The trend toward PMOs has implications outside the organization, as well. Consultants, for example, may find companies have less need for their services, as the PMO better equips those companies to perform much of the work in-house. Again, the PMO can represent itself as a more nimble and more responsive group, with considerable expertise. And presenting the PMO in this light provides another good argument for allocating the dollars to fund this new layer of organization.

This organizational entity has consequences for the software vendor community, too. Most vendors have become accustomed to a one- or two-pronged selling approach—appealing to the business units or to the IT department of a prospective customer. With the addition of the PMO to the process, these same vendors will now have to sell to a three-headed monster. The process will require more legwork on the part of the vendor; in addition, this organizational model opens up the question of who has the authority within the organization to sign off on a deal. The result, from the vendor's standpoint, is potentially slower decision-making and a sales process that can be more complex.

More organizations are recognizing the need to establish a project management function. The advantages are clear: Companies with a PMO in place have an internal group with the necessary business knowledge to define requirements and assess the business need for their technology initiatives, and the technical knowledge to communicate with IT to ensure that all technical requirements are met. Where the technology procurement and implementation process is concerned, the PMO represents an internal organizational entity that can be potentially more responsive than either traditional IT technical resources or business resources.

To reiterate, it's all about business and IT alignment, and the PMO function is one way to ensure that your business strategy aligns with your technology. Organizations in highly competitive industries such as insurance need the assurance that the technology they acquire will help them implement their business strategy, and the PMO approach is a step in the right direction.

The authors are analysts with Doculabs, a Chicago-based research and consulting firm that helps organizations plan for, select, and optimize technology for their business strategies.