Remember that game of "telephone" you played when you were akid? You whispered a message to someone, who passed it to anotherperson, who passed it to another, and so on? Finally, the player atthe end of the line called out your message, and invariably it wascompletely different from how it had started because ofmisinterpretation and miscommunication.

Effectively communicating and confirming requirements in legacysystem rehabilitation and replacement projects can bear anunfortunate resemblance to that game. Business throws itsrequirements over the transom. IT translates those requirementsinto a technical design. Business comments on that design based onits interpretation of IT's documents.

Too often, the message is lost in translation and–unlike thegame of telephone–miscommunications in legacy replacement projectshave real-world consequences.

"Projects get stuck. There may be some activity that ishappening but not significant progress because of communicationproblems," says Dave Packer, senior principal and enterprisearchitect at X by 2, a consultancy that specializes in applicationand enterprise architecture. Delivered systems may not meetbusiness needs, or projects may fail completely.

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 manyorganizations, IT is told what to do by the business, and if IT hasfeedback, it's not considered wanted. It's a one-directional (vs. abi-directional) communication process," says KimberlyHarris-Ferrante, vice president and distinguished analyst atGartner.

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

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

Likewise, insurers' IT departments traditionally have lacked adeep understanding of the business side. "It's only the companieswith a more futuristic outlook where IT departments actually areengaging actively with the business, working to understand thebusiness side, and pushing their business counterparts to identifywhat their needs will be so that they can be proactive," saysHarris-Ferrante.

PEOPLE AND PROCESS

Solving communication breakdowns and creating requirementsdocuments everyone understands and agrees on begins with involvingthe right people. However, identifying those people is somethingwith which companies continue to struggle.

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

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

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

"It sounds simple, but it can be difficult to ask peoplequestions and then just be quiet and let them answer," saysAmerisure CIO Frank Petersmark. "In a meeting, people often willnod their head knowingly, but later we would find out that in noway meant they all agreed. You have to get the users to respondactively, and keep asking questions until you reach anunderstanding and consensus."

Amerisure determined it needed not only to listen better butalso change its development methodology after experiencing whatPetersmark calls a "false start" with a legacy systemrehabilitation project in the past.

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

As the insurer migrated from a mainframe/COBOL environment toOracle/Microsoft, it also picked up on IBM's Rational UnifiedProcess (RUP) development framework. Gradually, Amerisure replacedits previous waterfall development process with the iterativemethodology of RUP. The method not only required a change from ITbut also from business.

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

Amerisure also made some interesting discoveries through thecollaborative development process.

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

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

Petersmark illustrates how the RUP process impacted a recentpolicy administration initiative, which involved consolidatingseveral legacy mainframe-based and client-server systems into asingle, Web-based policy platform called the Amerisure PolicySystem (APS).

"In the past, we might have gone out as an IT department intothe market assuming we understood what our users wanted and vettedand bought a system. Then we would have implemented it andcustomized it, or the business side would have changed itsprocesses to fit the processes of that system," Petersmarksays.

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

To achieve that objective, the insurer took the unusual step ofbuying a minority share of Taliant Software, gradually expandingthat to a majority share and acquiring the vendor's policyadministration technology and resources in the process. Amerisureset about modifying the system to align with its businessprocesses. The move also coincided with the development of aproject management office (PMO) within Amerisure.

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

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

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

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

Those people initially served as liaisons and translatorsbetween business and IT. Many of them were "adopted" over time intoa more permanent project management role. "We were lucky enough tofind people within our organization who could bridge communicationand perspective gaps," says Petersmark.

Amerisure recently completed rolling out the APS system toworkers' compensation and commercial auto and plans to completeremaining lines in 2009.

SYSTEMS AND STRUCTURE

To avoid or resolve communication challenges and createrequirements documents everyone understands, talented people needto be supported by effective organizational structure andsystems.

"If you go into some large insurers in particular and ask howmuch time business and IT spend together, you'll find they don'tknow 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 aspecific business unit; someone who can attend business meetings sothat when claims talks about claims or underwriting talks aboutunderwriting, that person is the IT voice that is part of thatprocess," she notes.

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

"We found over time you really can't do these projects instructural silos. So, we don't keep people in their functionalareas; 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 relationshipfor those in it. It's been a real evolution for us and helped ussharpen our business focus in our IT projects over the past fiveyears."

That focus is essential because of the number of ongoing andupcoming legacy system projects at Genworth. Formed in 2004 as aspinoff from General Electric, Genworth has a history of companyacquisition and chooses to convert acquired business to itspreferred administration platform, which for its annuities businessis AdminServer.

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

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

"We don't have this notion of delineated teams where a projectis scoped and framed, then developed and delivered. Instead, we putpeople in the same room and have them collaborate coming up withrequirements," he says. "Our methodology today also is veryiterative, where we prototype and get buy-in along the way, ratherthan deliver and then hope to get business to accept it."

Delivering prototypes and intermittent functionality and waitingfor 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 getus to a better answer in the end. Speed is not the most importantmeasure of project success, and we have achieved much betteralignment between business and IT around legacy conversion andoverall systems development," he adds.

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

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

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

Outside development resources also can bring a fresh perspectivethat can help bridge the communication gap between business and ITand solve problems.

"Most of the problems an insurer will have with a legacy systemproject have been solved before, but companies don't recognize thatbecause they lack a view of the big picture," Packer says. "ITbecomes overwhelmed with problems, the team tends to thrash andstruggle, and alignment between business and IT suffers. That'swhere the use of outsourcing and outside resources to solveproblems can come into play."

That strategy has paid off for Farm Bureau Financial Servicesproperty/casualty companies. The insurer needed to upgrade itshome-grown, legacy commercial lines processing system to a platformthat could scale to meet business growth and support better processautomation.

Normally, the company would have handled development in-house,but since commercial lines accounted for less than 15 percent ofits business, it looked for an off-the-shelf solution. "We wantedto grow our commercial lines, but we didn't want a massive internalproject because we focus our internal IT resources on personallines, where the bulk of our business is," says Dan Pitcher, vicepresident of Farm Bureau Financial Services' property/casualtycompanies.

The insurer elected to migrate its commercial lines policyadministration environment to CSC's Web-based POINT IN andAgencyLink systems, both of which are hosted for Farm BureauFinancial Services by CSC. The systems were deployed in 2007, andthe insurer completed rolling over commercial lines business in thesummer of 2008.

"CSC was able to bring people to the project who had gonethrough it before," Pitcher says. Bringing in an outsidedevelopment resource also helped business gain a betterunderstanding of the IT requirements of a typical developmentproject.

"Simply by virtue of seeing that changing requirements wouldcarry a hard-dollar cost [from CSC] and not just an internal delayhelped the business prioritize requirements on a needs-basedbasis," Pitcher explains.

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

"A lot of vendor implementations fail because they turn intosystem enhancement projects rather than implementations," heasserts.

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

"We have a formal project management process, including weeklysteering group meetings between all the key players on theproject," Pitcher says. "But in the case of this system, CSC is ourIT, and a lot of that project communication was going on inmeetings by phone, e-mail, or visits. When you're used to havingeverybody in the building, around the table, that was anadjustment."

MAKING IT WORK

Ultimately, creating requirements documents business understandsand establishing effective communication between business and ITisn't dependent on any single development methodology. Anyframework can be effective as long as a company measures progress,not the process.

"One of the biggest problems is there actually is anover-communication and over-documentation of details and anunder-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 documentand say they're doing something. But people can't look at a400-page document and say whether or not something is correct."

It's not that this level of detail is unnecessary; rather, it isnot needed at all times and by all stakeholders in the project.Companies need to combine a big-picture vision that guides documentdetail and system development with information and componentsdelivered 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 aconstruction site, they don't walk around with a 400-page document.They walk around with a blueprint of a dozen pages, and each pageis relevant to specific people–the electrician, the plumber, theroofer, and so on."

The good news is companies are making progress toward clearingthe communications fog around legacy system projects, and thealignment gap between business and IT continues to shrink, howeverslowly.

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

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