Winning with Brains & Brawn

For a boxer preparing for competition, it's not just a matter of being at the right weight, but making sure the bulk you have is working for you to the maximum extent. Trimming the fat is important, but it's only the beginning. To take on the toughest competitors, you need to know what your strengths are and condition yourself to make the most of them.

Similarly, the disciplines of IT asset management and project portfolio management go a certain distance toward tracking an insurance company's resources and managing them toward business goals. But in order for IT organizations to be as effective as possible, knowing what they are is a big part of knowing what they've got.

Know Thyself

The proper way to catalog the assets in an organization is to plot the intersection of systems, products and business functions, according to Paul McDonnell, managing director and insurance segment leader, BearingPoint (McLean, VA). "We recommend that companies formally create an inventory of all the systems they have in place, and the projects they have underway," he says.

To execute what McDonnell calls a "functional decomposition of the business," companies should look at three dimensions: business functions that systems support, products that those systems support, and the systems themselves.

The concept of assets in an organization has traditionally been of hardware and software in the computer room and on the shelves. Accordingly, one of the most elusive categories to inventory is the intellectual content that an IT organization creates and utilizes. "One of the major problems insurance companies have is how much of what is running the business today is not documented," McDonnell asserts. "That's something companies need to do because it's very difficult for them to leverage their assets if they're not properly documented."

Inadequate documentation of how systems support the business-and how the systems relate to each other-drives up maintenance costs and hampers problem resolution, according to McDonnell. "Every time you do a new project you have to go out and re-analyze what you're actually dealing with," he says. "Without a strong discipline and understanding of the assets you have in place, you run the risk of creating duplicate system functionality," and cutting off the opportunity that those wasted resources represent.

Insurance and related industries are only beginning to understand and capture ideas, in the opinion of John Bader, vice president, enterprise technology, Allstate (Northbrook, IL, $118 billion in assets). Allstate, Bader relates, "is beginning to understand that an idea can be a competitive advantage, and is working to capture and protect those ideas as corporate assets." Allstate has accumulated in-house-built tools that govern capital allocation and project portfolio issues, drawing from a lower tier of homemade project management and financial management tools. On top of those evolving capabilities, according to Bader, "we're in the early stages to build-out a knowledge management capability" to handle intellectual assets, along with "an education process within the organization on both a legal and a business level."

Allstate is moving toward a world in which such ideas are considered patentable, Bader believes, "and in that ball game, there is competitive advantage that you own," he foresees.

Tacit Knowledge

The benefits are more immediate on the operational side, relates Bader's colleague, Robin Richmond, assistant vice president, technical delivery services. "If I'm able to capture the tacit knowledge that people have by spending years working on an application, I'm able to move them around more frequently. If I can't, I tend to leave them in the same job because I need that captive knowledge," she says.

Simplifying asset management presents a particular challenge to a firm the size of Allstate. "The number of applications in my area number around 2,500, and there are about 1,500 people that work on them," Richmond relates. "As I look across the organization and all the applications trying to find out how we get through the project life cycle, I've found that we're getting through it in various and sundry ways."

In order to to standardize those "various and sundry ways" and to achieve greater speed-to-market and nimbleness in technology in general, Richmond is working to apply the Capability Maturity Model (CMM) at Allstate. CMM identifies five ranks of software development-related performance-initial, repeatable, defined, managed and optimizing-which are usually referred to ordinally as levels one through five. Level five is characteristic of industries such as aerospace and pharmaceuticals, according to Richmond. An assessment of Allstate's technology organization showed some examples of levels two and three, but the predominant level was one. "Level one is where you get the job done through heroic deeds-you stay the night and meet your dates," Richmond explains. "Level two starts introducing consistency in the processes that govern your project life cycle."

Allstate hopes to achieve level two this year, but is aiming for level three over the longer term, according to Richmond. To help get there, she has overseen the introduction of a training program and a tool called PAL (project asset library), which stores the carrier's standard operating procedures. Richmond's team has rolled out the PAL to two key process areas: configuration management for documents and configuration management for code. As an example of PAL's utility to the organization, Richmond says, "in some applications I have upwards of 20,000 source code modules in an application, so it's important to version that correctly."

Process improvements often fall victim to backsliding in technology organizations, owing to the pressure to deliver quickly, according to Allstate's Bader. But with the consistent application of procedure, as through CMM, "you start to change the culture of the organization and backsliding becomes harder to do," he says. Part of that culture change must be an appreciation of the consequences of failure, adds Richmond. "What we try to put in front of our employees is that when we fail to deliver, we fail our internal customers, our claims folks, our agents and our end customers," she says. "There's a lot of failing going on if we fail."

There would be a lot less failure in technology organizations if they re-thought how they apply theirhuman assets, according to John Kellington, chief technology officer, Ohio Casualty Group (OCG, Fairfield, OH, $3.5 billion in assets). Traditionally those organizations have worked in a very silo-specific fashion, where "they know their own system, their own documentation techniques, their own disaster recovery techniques," he says. While keeping-the-lights-on upkeep is an essential part of a technology organization's work, "the large projects are normally software development projects, so the question is, 'How do you become the best-of-breed in software development?'" he adds.

One way, according to Kellington, is to implement what he calls role-based software development techniques. Rather than have the suite of technology skills confined in disparate silos, important project roles can be located in individuals who have mobility around the organization. "There are four key roles that make a project successful: project manager, architect, programming specialist, and a subject-matter specialist," Kellington says. The latter role provides the necessary area or line-of-business expertise, while the former three are competent for any project. With such an approach, "I can move high skills from one area of the organization to another, and they can engage because they understand what role they do have to play-and what roles they don't-and can be effective," Kellington elaborates. "By doing this, you build a more fluid organization."

Driving Reuse

Roles can also play a part in maximizing reuse of software assets, according to Kellington, who relates that Ohio Casualty is moving toward building systems around components. In the past, programmers supporting a business system would report to the manager responsible for that business system. "Although Ohio Casualty isn't organized this way because of our size, some companies are moving toward organizing around components as opposed to systems," he says. "For example, a location, party and product component may be reused in many systems, and as companies organize staff around those components, they promote reuse." Kellington adds, "The staff supports the components and their services, and they enhance the components when they receive new requirements from the business systems. By organizing around a component structure, the software becomes more reusable."

Reuse efforts centered around software asset libraries have tended to fail because of the discretion accorded to those using them. "Every architect who goes to a 'reuse library' essentially says, 'Oh, man, that's horrible, I can do it much better," and ends up building their own stuff," Kellington says. "By not having an organization structure to prevent that, it could make it difficult to get reuse." He continues, "with our size, we've been able to promote reuse with key resources and a ton of communication."

Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio