When communication breakdowns in legacy system projects happen, they generally can be traced back to one or two root causes.

o IT and business are not equal partners. "In many organizations, IT is told what to do by the business, and if IT has feedback, it's not considered wanted. It's a one-directional (vs. a bi-directional) communication process," says Kimberly Harris-Ferrante, vice president and distinguished analyst at Gartner.

"When IT is viewed as an enabler, communication problems arise. Business gives the order, IT implements. Business people give the money, and IT works for them, rather than with them," says Vivek Mehra, vice president of financial services and insurance at IT services firm Keane Inc.

o Business doesn't understand IT and vice-versa. "The communication and translation problems that lead to business and IT misalignment around legacy system projects come down to lack of information and misunderstanding of capabilities," Mehra says. "Somebody will create a business strategy and assume everyone in IT understands it and can change on a dime to make the changes it requires."

Likewise, insurers' IT departments traditionally have lacked a deep understanding of the business side. "It's only the companies with a more futuristic outlook where IT departments actually are engaging actively with the business, working to understand the business side, and pushing their business counterparts to identify what their needs will be so that they can be proactive," says Harris-Ferrante.

PEOPLE AND PROCESS

Solving communication breakdowns and creating requirements documents everyone understands and agrees on begins with involving the right people. However, identifying those people is something with which companies continue to struggle.

"The way we tend to solve these problems is by taking a group of business staff and IT staff, shoving them in a room, and telling them to work it out. However, they have only a small view of the picture because they are siloed by virtue of their role within the company," Packer observes.

What's missing in this group, Packer continues, is a leader who can articulate and enforce the vision on legacy projects, who has knowledge of both business and IT, and who has the experience to gather information about the project and problems.

"I'm not talking about Moses parting the Red Sea. I'm talking about someone who can listen to people throughout the organization and has the skill set and the authority to bring that together," Packer adds.

"It sounds simple, but it can be difficult to ask people questions and then just be quiet and let them answer," says Amerisure CIO Frank Petersmark. "In a meeting, people often will nod their head knowingly, but later we would find out that in no way meant they all agreed. You have to get the users to respond actively, and keep asking questions until you reach an understanding and consensus."

Amerisure determined it needed not only to listen better but also change its development methodology after experiencing what Petersmark calls a "false start" with a legacy system rehabilitation project in the past.

"We didn't quite match the business requirements [in that project], so we knew we wanted to be more collaborative this time around and find a methodology that enabled that collaboration," Petersmark says.

As the insurer migrated from a mainframe/COBOL environment to Oracle/Microsoft, it also picked up on IBM's Rational Unified Process (RUP) development framework. Gradually, Amerisure replaced its previous waterfall development process with the iterative methodology of RUP. The method not only required a change from IT but also from business.

"The change took a while," Petersmark says. "Our users weren't used to creating and reviewing use cases. We had to spend a lot of time making sure my peers were on board and they would commit people to projects. But as time went along, we found it became a useful, constructive, and collaborative approach to building requirements our [internal] customers would understand."

Amerisure also made some interesting discoveries through the collaborative development process.

"As we were building requirements, we found differences in what a corporate user thought was going on in the field and what was actually going on in the field. Initially, we'd base our design decisions on what corporate told us, which caught us a few times," Petersmark says.

"We also discovered, even though we had high-level and downstream steering committees, messages and decisions didn't always move all the way down the food chain," he adds. "We found we really had to 'stretch our legs' and involve a lot of people in the process, and we had to be very clear everyone understood and agreed on nomenclature that was used."

Petersmark illustrates how the RUP process impacted a recent policy administration initiative, which involved consolidating several legacy mainframe-based and client-server systems into a single, Web-based policy platform called the Amerisure Policy System (APS).

"In the past, we might have gone out as an IT department into the market assuming we understood what our users wanted and vetted and bought a system. Then we would have implemented it and customized it, or the business side would have changed its processes to fit the processes of that system," Petersmark says.

Amerisure did begin the policy administration initiative by looking at solutions in the marketplace but found there was nothing that fit to its satisfaction. Working collaboratively between business and IT, Amerisure set out to "flip the equation," Petersmark says. "We wanted to create a system that matched the way we processed our business, not the other way around."

To achieve that objective, the insurer took the unusual step of buying a minority share of Taliant Software, gradually expanding that to a majority share and acquiring the vendor's policy administration technology and resources in the process. Amerisure set about modifying the system to align with its business processes. The move also coincided with the development of a project management office (PMO) within Amerisure.

"We have a lot of our customers who interface directly with our PMO repository for project documentation and track projects, progress, and people's roles in projects. Anyone involved in a project, from the top to the bottom, can have a view of that and can know where things are, what money has been spent, and so on. That's helped open up communication," Petersmark says. "We've also gotten better at how to craft use cases that are easier to understand."

But the process Amerisure put in place was just one part of the solution. People were the other.

"One of the things we've been blessed with is we have IT people who know the business well, but it's a whole other big step to be able to talk to business users. The sort of collaboration required by RUP really was outside their comfort zone," Petersmark says.

"What we found in the policy administration build project was we had to recruit people from the business side who had an affinity for IT as well as IT people who can put a business hat on and understand things from a user's perspective," he remarks.

Those people initially served as liaisons and translators between business and IT. Many of them were "adopted" over time into a more permanent project management role. "We were lucky enough to find people within our organization who could bridge communication and perspective gaps," says Petersmark.

Amerisure recently completed rolling out the APS system to workers' compensation and commercial auto and plans to complete remaining lines in 2009.

SYSTEMS AND STRUCTURE

To avoid or resolve communication challenges and create requirements documents everyone understands, talented people need to be supported by effective organizational structure and systems.

"If you go into some large insurers in particular and ask how much time business and IT spend together, you'll find they don't know each other in a lot of cases. They are different departments," says Gartner's Harris-Ferrante.

"Companies are learning they need to dedicate an IT analyst to a specific business unit; someone who can attend business meetings so that when claims talks about claims or underwriting talks about underwriting, that person is the IT voice that is part of that process," she notes.

For Genworth Financial, the right structure includes co-locating IT staff with business to improve communication.

"We found over time you really can't do these projects in structural silos. So, we don't keep people in their functional areas; we pull them out to work as a team," says Mike Shadler, Genworth CIO.

"We almost take the view reporting structure doesn't matter; it's wherever the team needs to be," he indicates. "Cross-functional structure creates a better working relationship for those in it. It's been a real evolution for us and helped us sharpen our business focus in our IT projects over the past five years."

That focus is essential because of the number of ongoing and upcoming legacy system projects at Genworth. Formed in 2004 as a spinoff from General Electric, Genworth has a history of company acquisition and chooses to convert acquired business to its preferred administration platform, which for its annuities business is AdminServer.

"Over time we've done a lot of consolidation and replacement of legacy systems. We've gone from more than 20 down to seven, and we're on track to be down to five by the end of 2009. We have four active projects right now," Shadler explains.

One thing Shadler has learned is the traditional over-the-transom method does not work for Genworth.

"We don't have this notion of delineated teams where a project is scoped and framed, then developed and delivered. Instead, we put people in the same room and have them collaborate coming up with requirements," he says. "Our methodology today also is very iterative, where we prototype and get buy-in along the way, rather than deliver and then hope to get business to accept it."

Delivering prototypes and intermittent functionality and waiting for business input adds some time to the development process, Shadler points out, but the result is worth it.

"We may be losing development efficiency, but that's OK to get us to a better answer in the end. Speed is not the most important measure of project success, and we have achieved much better alignment between business and IT around legacy conversion and overall systems development," he adds.

Also, business and IT are equal partners at Genworth, with projects originating equally from both sides.

"As a result, we have a lot of buy-in when undertaking these projects," Shadler says. "They're not IT projects, they're business projects, designed around creating systems that are simpler for business partners to use and that result in increased productivity [for staff]. Everyone can understand that and is aligned around that goal."

The use of outsourced development resources from Patni, according to Shadler, helps keep Genworth's IT staff focused on business strategy. "Patni is our main global provider of services. We keep the control and the architecture and the plan for the projects inside Genworth, but using Patni gives us the capacity to do more work," he says. "It makes use of the global talent tool and doesn't impede communication."

Outside development resources also can bring a fresh perspective that can help bridge the communication gap between business and IT and solve problems.

"Most of the problems an insurer will have with a legacy system project have been solved before, but companies don't recognize that because they lack a view of the big picture," Packer says. "IT becomes overwhelmed with problems, the team tends to thrash and struggle, and alignment between business and IT suffers. That's where the use of outsourcing and outside resources to solve problems can come into play."

That strategy has paid off for Farm Bureau Financial Services property/casualty companies. The insurer needed to upgrade its home-grown, legacy commercial lines processing system to a platform that could scale to meet business growth and support better process automation.

Normally, the company would have handled development in-house, but since commercial lines accounted for less than 15 percent of its business, it looked for an off-the-shelf solution. "We wanted to grow our commercial lines, but we didn't want a massive internal project because we focus our internal IT resources on personal lines, where the bulk of our business is," says Dan Pitcher, vice president of Farm Bureau Financial Services' property/casualty companies.

The insurer elected to migrate its commercial lines policy administration environment to CSC's Web-based POINT IN and AgencyLink systems, both of which are hosted for Farm Bureau Financial Services by CSC. The systems were deployed in 2007, and the insurer completed rolling over commercial lines business in the summer of 2008.

"CSC was able to bring people to the project who had gone through it before," Pitcher says. Bringing in an outside development resource also helped business gain a better understanding of the IT requirements of a typical development project.

"Simply by virtue of seeing that changing requirements would carry a hard-dollar cost [from CSC] and not just an internal delay helped the business prioritize requirements on a needs-based basis," Pitcher explains.

He also attributes the success of the legacy replacement to obtaining solid executive sponsorship, and the speed of replacement to establishing a "shall not modify" rule upfront.

"A lot of vendor implementations fail because they turn into system enhancement projects rather than implementations," he asserts.

Using an outside development resource was an adjustment in communication for Farm Bureau Financial Services, he admits.

"We have a formal project management process, including weekly steering group meetings between all the key players on the project," Pitcher says. "But in the case of this system, CSC is our IT, and a lot of that project communication was going on in meetings by phone, e-mail, or visits. When you're used to having everybody in the building, around the table, that was an adjustment."

MAKING IT WORK

Ultimately, creating requirements documents business understands and establishing effective communication between business and IT isn't dependent on any single development methodology. Any framework can be effective as long as a company measures progress, not the process.

"One of the biggest problems is there actually is an over-communication and over-documentation of details and an under-communication of the big picture, whether it's the vision, the process, the architecture, or the people," says Packer.

"Some companies equate creating documents with making progress," he observes. "They create a 40-person team and a 400-page document and say they're doing something. But people can't look at a 400-page document and say whether or not something is correct."

It's not that this level of detail is unnecessary; rather, it is not needed at all times and by all stakeholders in the project. Companies need to combine a big-picture vision that guides document detail and system development with information and components delivered to the right people at the right time.

"It's like when you're building a house," Packer comments. "There's no single picture that is adequate for everyone. At a construction site, they don't walk around with a 400-page document. They walk around with a blueprint of a dozen pages, and each page is relevant to specific people–the electrician, the plumber, the roofer, and so on."

The good news is companies are making progress toward clearing the communications fog around legacy system projects, and the alignment gap between business and IT continues to shrink, however slowly.

"There is a definite trend where IT understands more about the business," states Harris-Ferrante.

"We have broken down the walls in the classic business and IT relationship. Our outcomes are based and measured on business and customer metrics, and that's a great evolution," Shadler says. "We are the business." TD