Working with Offshore Partners Requires CIO Oversight

The first time Farrell Delman outsourced application development to an IT services company in India, the relationship was far from the mutually beneficial partnership he had hoped for. As president and CIO of the Tobacco Merchants Association (TMA), an information aggregator and distributor for the tobacco industry, Delman needed an outsourcer to develop a content management system to handle the organization’s ever-growing library of electronic information. So in 2000, he signed a contract with a large IT services provider in India that said it could complete the project for just $256,000, instead of the $1.65 million it would cost TMA to do the work in-house.

A CISR-CIO Study

This is Part 2 of a three-part series about outsourcing strategies and success models, defined in original research by MIT’s Center for Information Systems Research and CIO magazine.

Part 1: Simple Successful Outsourcing

Part 3: Big Deals, Big Savings and Big Problems  

Unfortunately, the outsourcer had little experience with content management systems, Delman says, and developers spent much of their time learning on the job on TMA’s dime. The outsourcer had underestimated the amount of work it would take to develop the application and, therefore, had underbid, he says. “A lot of what they considered their ’design’ of the application amounted to attempting to fit round pegs into square holes in order to save time and money,” recalls Delman. The size of the vendor was also an issue. It had several big customers, but TMA wasn’t one of them. Despite frequent trips to India, Delman felt ignored. What attention was paid to TMA was focused solely on coding, he says. “The people assigned to the project were very skilled in IT, but they didn’t spend a lot of time getting to know our business model,” says Delman. And given that TMA’s business depended on this content management system, that was a problem.

Ultimately, the project came in on budget. But that was the only bit of good news to be had. The project took seven months longer than expected to complete. The content management system was not aligned with the business needs of TMA and lacked the flexibility Delman was seeking, he says. And ongoing maintenance for the application proved difficult and expensive.

Delman’s experience is not unique. He was attempting to pull off what Jeanne W. Ross, principal research scientist at MIT’s Center for Information Systems Research (CISR), calls a “co-sourcing alliance,” in which client and vendor jointly manage projects—usually application development or maintenance work that goes offshore. Unlike outsourcing deals in which a CIO hands off a discrete piece of commoditized or repeatable work to a vendor—what Ross terms a transaction relationship—co-sourcing alliances rely on a symbiotic relationship between client and vendor. (To learn how CIOs should approach transaction relationships, see Simple and Successful Outsourcing.)

Co-sourcing works out for the client 63 percent of the time, according to a recent study by CISR and CIO. Transaction relationships, by comparison, have a 90 percent success rate. (A third type of outsourcing identified in the CISR-CIO study, strategic partnerships, works out half the time but goes sour in the other half of cases.)

The mistake that CIOs such as Delman make with co-sourced projects is failing to set them up as partnerships in the truest sense of the word. Co-sourcing, which draws on both the vendor’s specialized technical knowledge and the client’s deep business knowledge, succeeds only when both parties have strong capabilities and the relationship is set up so that those capabilities can mesh for the greater good.

Co-sourcing that is treated like anything but a team sport is bound to fail, says Ross. Delman says his vendor did not bring the right technical skills and brushed aside the client’s knowledge of the business. The project was a bust.

Despite less than stellar success rates, CIO interest in co-sourcing alliances remains high. And why not? Done right, you can gain access to a vendor’s highly trained technologists and project managers when you need them, while actually saving money and retaining a level of management control. The trick lies in setting yourself up for success. CIOs who want to make co-sourcing work must first ensure that both they and the vendor have the right capabilities, then set expectations and governance processes for a mutually beneficial alliance, and finally revisit those expectations and management rules to sustain value throughout the relationship. It may not be easy, says Ross, but “it’s totally achievable.”

Getting to Know You

After the missteps with his first attempt at a co-sourcing alliance, Delman took some time to make sure he had his footing the second time around. As maintenance on his content management system grew more onerous, he once again sought out an outsourcer. His ultimate goal was to create a new, more flexible application to manage content, which approached 3GB in 2003. But he didn’t jump into another development project with a vendor. Rather, he hired Cordiant to maintain the application that the previous outsourcer had developed. Cordiant, based in Kochi, India, spent more than a year doing maintenance on the system before even considering the development of a new system.

That’s how Delman avoided the snags he had had with the previous co-sourced development project. “By doing maintenance, [Cordiant] learned what the system was about in terms of content, and they were able to see how it could be streamlined,” he says. “The maintenance period also gave them time to smooth out potential problems. “It was a good way to find out what the communication levels were. You find out if when you say blue, they see the same blue. A lot of learning happened in that maintenance phase.”

When it was time to start development on a new system in June 2004, both client and vendor were in agreement about what would work best for TMA. Cordiant began work on an open-source content management system. Within seven months, Cordiant completed the system for $300,000; Delman estimates it would have cost $2 million to do in-house. But more importantly, the company delivered a system that met TMA’s needs for a dynamic content management system in full. And that’s saying a lot for Delman, who by his own admission is “a little obsessed about [the] applications” on which TMA’s business model hinges. “If they don’t work,” he says, “we don’t sell.”

Delman expects to renew the contract with the outsourcer in 2007. “What I have with Cordiant is the relationship I would have with my own internal systems department,” he says. “In fact, I view them as my own internal systems department.”

TMA’s second attempt at co-sourcing worked well because Delman chose the right partner and allowed time for the two companies to learn one another’s capabilities and needs. Ross explains that “if you start small and take the time to learn how to do it, co-sourcing can be a natural to help CIOs access IT talent at lower offshore rates while making better use of their internal staff.”

At State Street, the seeds of a successful co-sourcing alliance go back a quarter century. Jerry Cristoforo, State Street’s CTO and executive VP of enterprise information and global markets technology services, formed a relationship with Zhijun He, the founder of the computer science program at China’s Zhejiang University, way back in 1980. Fast-forward 25 years and State Street has developed a co-sourcing alliance with UniverseSoft Technology, an outsourcing company spun out of the university that is dedicated to application development and maintenance for the Boston-based financial services company. State Street owns 81 percent of the company, the university 19 percent.

Before the company was formed in 2003, State Street used the university’s PhD candidates for R&D work. Although his relationship with He had been close for years, Cristoforo knew he had to take some time to develop the alliance between State Street’s IT staff and business users and the student-developers in China. In 2001, three Zhejiang professors spent nine months in Boston working with State Street’s development managers, getting to know the business and taking on several long-term technical projects as project managers. Development was done back in China.

Soon after, State Street ran into a problem with its trade-execution software. The company had acquired the system in 1997 in anticipation that the transition management business (which has to do with high-volume asset reallocation) would take off. It didn’t, and the employees who knew the system’s inner workings ultimately left the company. In 2002, transition management activity suddenly went through the roof, but the software supporting it was no longer current. It went from crashing once a year to several times an hour, and there was no one around with the knowledge to fix it.

Cristoforo realized he had a solution at hand: the developers at Zhejiang. There was no doubt they were talented. The only question was whether they could fix the problem fast enough, since they’d previously worked only in R&D mode. But the combination of the technical minds in China and the business knowledge in Boston, linked by the project managers in both locations, resulted in success. “In 10 months, we were in production with the new system,” Cristoforo says.

Zhejiang was a great resource for State Street, but not a permanent one. “When we did that project, all of a sudden we had all this core development knowledge at the university,” Cristoforo says. “But what happens when one of those wonderful students graduates?” So he worked with the university to establish a company that could offer long-term employment to Zhejiang graduates to work on State Street application development and maintenance. UniverseSoft Technology has gone on to help State Street deal with a whole host of legacy application issues—from high-end development to grunt work—in record time and at low costs.

Cristoforo refuses to call the relationship with Zhejiang “outsourcing.” “When you’re dealing with an outsourcing model, what you’re doing tends to be more in the tactical interest of the company. When you’re co-sourcing, it’s more of a long-term relationship and it’s in the strategic interest of a company,” he says.

All for One and One for All

Like any outsourcing model, co-sourcing will work only if the client and vendor both get something out of the relationship, says CISR’s Ross. The vendor gets the benefit of developing industry- and application-specific skills by working on the client’s project, while the client reaps the vendor’s technology expertise at low costs. But a real co-sourcing alliance goes a step further, sharing project risk as well.

Guy de Poerck, CIO of the International Finance Corp. (IFC), an arm of the World Bank that promotes private-sector investment, views that concept of shared risk as critical to the application development and maintenance work it sends to its partners in India. IFC has been using Satyam Computer Systems for application development work for just 18 months, but it has quickly moved from paying for the work on a cost-and-materials basis to a fixed-cost model. Client and vendor decide ahead of time how much money will be spent on all application-related work.

To do so, de Poerck must be completely open with Satyam. He shares IFC’s IT and business plans so that the outsourcer can determine what resources will be required to support IFC’s ongoing projects. And Satyam must stick to the initial budget (unless the scope of a project changes) if it wants to profit from the relationship. “It’s a true sharing of risk,” says de Poerck. “You can’t approach this like you’re buying a commodity and saying, ’Here are my operations—do a survey and make me a deal.’ With co-sourcing you have to engage with each other at a really detailed level.”

But it wasn’t easy for IFC to get to that point. De Poerck began working with Satyam in early 2004 on a pilot project, paying for time and materials. But to truly share risk and management, de Poerck realized that his department would have to gain a better understanding of its processes than it had at the outset. “You need to know exactly what all your processes are and what your service levels are and have that documentation ready,” says de Poerck. “Very often you will find that you don’t. But co-sourcing is a fantastic way to force yourself to do that and raise the [service] level of your own IT department.”

Another important ingredient in the co-sourcing equation is the level of trust and openness required. IFC insists on having “100 percent visibility” into who Satyam puts on its projects, says IFC’s information officer and offshore manager, Zafar Azhar, who reports to de Poerck. One reason is that IFC has opened its network to Satyam. “We treat the development center at Satyam in Chennai the same way that we treat all of IFC’s other 105 country offices around the world,” says Azhar. “We do the same checks on [the employees] and ask for their passports, which starts a process to do background checks.”

A major risk with co-sourcing alliances, according to Ross, is an imbalance of inputs between client and vendor. If a CIO relies too much on the outsourcer’s technical prowess, his staff may lack the knowledge to use the applications effectively. Conversely, if a vendor spends too much effort imparting its software development or project knowledge to the client, it could, in essence, share itself right out of a contract.

That Side’s Yours and This Side’s Mine

The mechanism for co-sourcing success—a true sense of partnership—can also be its downfall. Boundaries between the two sides can become blurred. It’s often difficult to tell exactly what the client is contributing and what the vendor is providing, says Ross, and that can lead to problems. CIOs who succeed at these relationships seek to define the separate contributions of client and vendor—even down to individual responsibilities—without detracting from the collaborative nature of co-sourcing.

Omgeo, a software provider for the securities trading industry, began co-sourcing with Indian company Patni last year. The arrangement has worked so well that Omgeo Managing Director Michael Agnew refers to Patni as “the development, QA and testing unit” of Omgeo. Yet he has been careful to specify who does what. “It’s part of our project charter process to set and write up all roles and responsibilities up front,” says Agnew. “We understand what all the accountabilities are by function, by project and by individual.” But simply saying who’s responsible for what isn’t enough. “The lesson I’ve learned with any partner is that being very formal in the communication process and setting expectations clearly up front is paramount to success,” says Agnew. “All throughout the project lifecycle, it should be clear who’s handling what.”

At the highest level, there’s an Omgeo global sourcing director who oversees all outsourcing and monitors all metrics from cost to performance to headcount. There are also Omgeo project managers who direct development teams and work with the vendor’s project manager. Three Omgeo managers are responsible for working with Patni’s quality assurance team in Mumbai. And most importantly, there’s the Omgeo program manager for Patni who deals directly with Patni’s equally important relationship manager for Omgeo.

Mary Lacity, professor of information systems at the University of Missouri, says having the right people in the relationship management roles is a make-or-break proposition for a co-sourcing alliance. “If you get the two primary point people right—the alliance managers for customer and supplier—you’ll be fine,” she says. “It’s hard to find the right people. But if those two people can be completely frank, be completely honest about the people in their own organization rather than necessarily protect them, and even share financial information—’This is what my margins are, and this is what I can do’—then it works.”

How to Measure Success and Sustain Value

Certainly, a successful co-sourcing project is one that comes in on time and on budget and works well. But evaluating a co-sourcing relationship goes deeper than that.

For State Street’s Cristoforo, project milestones are just the tip of the iceberg; a bigger issue is whether his co-sourcing arrangement can be sustained over the long haul. If specific issues arise during a project—say, problems with coding or processes—that’s a signal to Cristoforo that a deeper problem could be lying underneath. “It really doesn’t matter if you’re making deliverables if you don’t have sustainability,” he says. For Cristoforo, success in this kind of partnership can be measured only over a long period of time: “We’ve been working with Zhejiang close to five years. We’ve been with them as they’ve grown from 15 people supporting us to 300 people. They’ve proven they can handle all kinds of work, from high fidelity to low fidelity. We have many different development communities at State Street, and Zhejiang is now integrated with most of them.” These are all mounting signs of success for Cristoforo.

Back at TMA, Delman compares his co-sourcing alliance with Cordiant to another solid relationship he has. “I view it as a marriage. When something’s really wrong, it’s obvious. But when things are going well, you don’t usually notice it. Sure, some days it’s my birthday. And some days my daughter brings home a C to us. But normally things are pretty much like they were the day before,” Delman says. “It’s the same way with my co-sourcing relationship. Sometimes I’m delightfully surprised. Sometimes I’m a little annoyed because I don’t understand why some things take so long when others happen faster. But there’s a certain rhythm to the relationship that I’m used to that tells me things are moving along.”