Communications of the ACM

Communications of the ACM

The Role of Trust in Outsourced IS Development Projects

By Rajiv Sabherwal
Communications of the ACM, February 1999, Vol. 42 No. 2, Pages 80-86
10.1145/293411.293485
Comments

Katherine M. Hudson, the former Kodak executive well known for outsourcing Kodak's IS activities to EDS a decade ago, once said, "You can't write a contract on spirit and culture." Other outsourcing cases support her emphasis on the social aspects of outsourced IS development, or OISD. Looking back at the 1988 Xerox-EDS contract, the "spirit" of the contract, a "high degree of cooperation," and an "environment of trust" were all critical [2].

Here, I focus on the key social factor of trust in OISD projects. Trust is an important aspect of interpersonal [1], as well as interorganizational [4, 11], relationships. One view of trust emphasizes each party's perception of the motives of the other party. For example, trust can be defined as "a state involving confident positive expectations about another's motives with respect to oneself in situations entailing risk" [1]. A broader view incorporates motives, along with behavior. For example, trust can be defined as "confidence that the behavior of another will conform to one's expectations and in the goodwill of another" [4]. Taking this broader view, I examine the role of trust in OISD, the complementary relationship between trust and structure, and the virtuous and vicious cycles involving trust, structure, and performance. My conclusions are based on 18 primary OISD projects (see Table 1 and the sidebar, How the Study Was Conducted).

Participants in OISD projects represent at least two different organizations—the client and the vendor. Trust should be viewed differently from its role in internal IS development where participants know each other already and are aware their future personal relationships will reach beyond the current project. But in OISD, participants from both sides often lack prior relationships with one another and may take a short-term, project-centered view. Moreover, trust can be difficult to develop in OISD projects, which are often governed through structural mechanisms, including deliverables, penalty clauses, and reporting arrangements. Inhouse development rarely uses detailed, explicit structures, relying more on trust among participants.

While recognizing the greater difficulty in developing trust in OISD projects, I still want to emphasize the need for trust in these projects, which frequently require the cooperation of strangers in tough, high-stress situations. Each organization—client and vendor—pursues its own goals while being concerned about its own lack of complete project control and wary of opportunistic behavior by its partner [3, 7]. These problems may be reduced somewhat through cautious vendor selection and appropriate structures [10], but they also require development of trust among the participants.

Not surprisingly, the cases I studied revealed that distrust hurts performance, whereas trust improves performance. Distrust can lead to finger pointing, as each organization focuses on its own interests, seeking to identify how the other organization may have hurt the project. For example, in one project, vendor executives blamed the client for numerous problems. However, I also found that most of the problems were caused by lack of direct contact between vendor and client; combined with a lack of appropriate structures, these problems yielded a relationship characterized by distrust and conflict.

In contrast, trust characterized successful projects. Trust in one another leads participants to work together rather than seek ways to deflect blame. One vendor executive described a large, successful project (Project A), saying, "If you have 20 people, you won't get everyone to get along with everyone else. The important thing is that most people actually do get along. That's what made it work."

Most interorganizational relationships, including OISD projects, involve a psychological contract, as well as a formal, written contract. The written contract is generally understood, unlike the psychological contract, which consists of unwritten and largely unspoken sets of congruent expectations held by the transacting parties about each other's prerogatives and obligations. These expectations of what each party gives and receives from the relationship vary in their explicitness; the parties are often only barely aware of the nature of these expectations [11]. Managing OISD projects requires resolving issues concerning both types of contracts. Compliance with the written contract is generally addressed through structural controls, whereas trust supports the psychological contract (see Figure 1). Moreover, both structural controls and trust help address unexpected problems in OISD projects.

Straightforward noncritical projects may succeed despite participants ignoring the written contract and structural controls, relying exclusively on the psychological contract and trust. In Project B, although the cost to the client (a $100,000 budget) was set at the beginning, there was no written contract or structural controls. The two organizations had a friendly, long-term relationship; when they disagreed, the client trusted the vendor; the client deferred to the vendor's expertise even when the vendor declined the client's request for more functionality. Said one client executive, "We were lucky we shared a mutual benefit from continuing to work together. As the system developed, we wanted to add things, and the vendor sometimes argued us out of our add-ons. In most cases, the vendor's consulting expertise gave it the credibility to convince us we didn't need what we said we wanted. And most of the time, the vendor was right."

---

Each organization pursues its own goals while being concerned about its own lack of complete project control.

---

Trust limits the need for structure by reducing the perceived need to guard against opportunistic behavior [9], but exclusive reliance on trust is dangerous. Even though the parties may be confident in each other's trustworthiness, they also may be uncertain whether to rely on it exclusively [11]. Most projects require a balance of trust and structural controls. While highlighting the importance of trust, the cases I studied indicated that some structural controls are still essential. These controls address the vendor's concern over the users' ignorance or of new requirements and make the client confident in the project's outcome. Said one vendor executive, "The client might feel it may be losing control, growing fearful at not being physically present during the development process. That's why we go out of our way to address this feeling by specifically talking about reporting mechanisms."

All successful projects I studied (unlike Project B) combined trust and structural controls. In one successful project, a formal contract was prepared and the relationship was excellent. The client's IS manager was happy with the vendor but still said, "The contract should have been more stringent, not that we would have used it as leverage to get something done, just to have it there and know that, okay, we have something we can deal with contractually."

Numerous problems were associated with projects that lacked balanced structure and trust. For example, excessive structural controls can hurt performance due to the time spent reporting progress rather than developing software. A client IS manager complained about excessive controls, saying, "An inordinate amount of time went to telling us what we were doing. Anybody could wander in, and we'd have to tell them what we were doing, just like you did half an hour ago with someone else. That was disconcerting for the programmers and the testers and probably not real productive."

Similarly, excessive trust, while ignoring structural controls, can hurt projects. In a few cases, the two organizations began the project with such confidence in their own (and their partner's) abilities that neither established any structures or identified potential obstacles. They were surprised later when problems arose. Lack of structure created performance problems and reduced trust. For example, in Project C, the vendor's project manager described how the unstructured use of faxes made his team feel they were not trusted enough. He said, "Sometimes the fax didn't reach its intended desk, but the sender assumed the fax had reached its target and was waiting for a response. The sender then sent the next fax, beginning with, 'As I said in the previous fax . . .' The recipient receiving this fax might miss a fax, though he received an earlier fax. So he refers to the earlier fax, because he's unaware of the just-sent fax. There can be total miscommunication. This kind of thing over thousands of miles, believe me, can be so irritating. And these people in software development are sensitive people; they ask, 'Why is the customer writing to me like that, using such a strong tone? You can't really seem to work for the next few days."

Back to Top

Characterizing Trust

The cases I studied revealed four types of trust: calculus-based, knowledge-based, identification-based, and performance-based. They build on another, earlier classification of trust into three types [8], adding performance-based.

Calculus-based trust is rooted in the rewards and punishments associated with a particular project. Client executives trust and cooperate with the vendor, expecting structural controls and penalty clauses to minimize opportunistic behavior. Establishing structures (such as reporting mechanisms and frequencies, change-management procedures, and client-involvement plans) early in a project inspires confidence about the project's outcome. A vendor executive said, "At least the first time something goes offshore, the client may feel it may be losing control; the fear of not being physically present during development is a factor. We go out of our way to address this feeling by, for example, talking about reporting mechanisms. The communication setup also seems to be a critical factor in terms of a client's comfort about communicating with us."

Calculus-based trust is also facilitated through the client's recognition of the vendor's desire to contract future projects. In Project A, the vendor's executives' diligence was due partly to a hoped-for long-term relationship with the client, as well as in the project's value in helping win contracts with other clients. In another project, anticipating future contracts with its large client, the vendor added several changes as requested by the client, but when the next few projects were contracted out to other vendors, its performance on behalf of the first client deteriorated quickly.

Knowledge-based trust depends on the two parties knowing each other well. The most common source of knowledge-based trust I encountered in my case studies was shared experience between the client and vendor on other projects. In some cases, the vendor developed other systems for the client, and, in several other cases, the client asked the vendor (and maybe other vendors) to demonstrate its ability by developing a small system first.

Knowledge could also derive from key participants from the two organizations knowing one another. Said one vendor executive, "We first had to gain credibility with the client. The best way was to have some of our people work with the client, so the client could see them in operation. Then, when the client's delegation visited us, they already had a positive view about our abilities."

Finally, knowledge-based trust may be facilitated through a "courtship" [8], whereby the participants seek to know each other well before starting the project. In the outsourcing arrangement between General Dynamics and Computer Sciences Corp., begun in 1991, knowledge-based trust was facilitated by an initial meeting between several senior executives, including General Dynamics' vice chairman Harvey Kapnick and Computer Science's chairman Bill Hoover. One General Dynamics executive [12] said, "It was a very positive meeting. Harvey and Bill hit it off very well. There was an immediate fit. This was a critical chemistry test. Had that meeting not gone so well, the whole idea may have gone straight to the filing cabinet. After dinner, Harvey said, 'These are good guys; I could work with them.' That was our go-ahead."

Identification-based trust follows from the two parties identifying with each other's goals. Strong identification-based trust implies "the parties effectively understand and appreciate the other's wants; this mutual understanding is developed to the point that each can effectively act for the other" [8]. About the Xerox-EDS relationship, a senior Xerox executive said, "Today, in any meeting, you cannot tell who is from Xerox and who is from EDS. And it doesn't matter who leads the meeting, because the objective is a common objective" [2].

Identification-based trust in OISD projects may be developed through the shared goal (system success) and through early team-building efforts. A vendor executive emphasized the importance of the shared goal, saying "I think both of us saw the need to yield on some items, and we continued to yield on them as needed. We both had a purpose, and that purpose was to develop the system."

By bringing together key project participants and emphasizing shared goals, the project managers helped participants identify with the overall OISD group. One client vice president of IS said, "Spanish was the Colombian vendor's native language; so I recruited a project manager who spoke Spanish. He met the team, and we wanted the team to come here to meet with our people and understand some of our culture."

In the Xerox-EDS relationship, key participants met at the start of the project and shared their personal and corporate objectives. A senior Xerox executive said, "Each side made two lists. We wrote down our company's objectives; then we wrote down what we thought were the other company's objectives. These objectives were all put on flip charts, allowing us to quickly identify disconnects. The two of us leading the team also wrote our personal objectives, right down to what would get us promoted and fired. That session brought us extremely close to one another" [2].

Finally, performance-based trust depends on a project's early successes. Accomplishing project goals seemed to improve cooperation and trust, whereas performance problems can cause conflict and distrust. In some projects, jointly celebrating completion of interim deliverables through, say, a party or a cruise improved the participants' trust for one another. Demonstrating the completed portion of the system also helps. A senior vendor executive described a successful pilot, saying, "Instead of just saying 'trust me,' we wanted to have something tangible to show. Not only did it buy us some management time, it helped some of our own people who had been feeling demoralized."

Several vendors recognized the importance of ensuring successful performance, especially through meticulous quality assessments. One vendor executive said, "Each interim deliverable you submit has to reflect the organization's ability to deliver. So before you deliver, it's always good to solicit feedback within the development organization. If there are basic flaws, some input can be taken from people with experience in similar areas and can be continuously incorporated into the project."

Performance-based trust in OISD projects is especially important when the client and the vendor are not located near one another; the client's inability to observe the vendor's behavior points up the timeliness and quality of deliverables. One vendor project manager said, "The client can't see how people work and how much time we spend on each activity. Problems happen when delivery is delayed."

Back to Top

Virtuous and Vicious Cycles

OISD projects proceed through virtuous and vicious cycles involving trust, structure, and performance (see Figure 2). The virtuous cycle involves positive trust, appropriate structuring, and good performance [5]; it results from complementary trust and structural controls. Balanced trust and structure is essential for project success, which in turn improves trust, especially the performance-based kind.

In contrast, the vicious cycle involves distrust, inappropriate structuring, and poor performance. Lack of balance between trust and structure adversely affects performance, hurting trust. In one project I studied, the client had a high level of trust in the vendor following their earlier mutual experience and therefore did not establish a structure for the relationship. Lack of structure caused problems later when the vendor changed project personnel without notifying the client. Another common reason for projects getting into the vicious cycle is the lack of involvement of key people. In some cases, the client's IS personnel or important users were not involved during requirements analysis, while in a few cases the vendor was not involved in the requirements analysis. Such lack of involvement can lead to inadequate structural controls for a project and inhibit participants from developing personal relationships. Lack of involvement adversely affects trust, as well as structure.

I also observed shifts among virtuous and vicious cycles. Some projects started well but got into trouble later. One reason for getting into trouble was a change in client or vendor personnel, causing performance problems through reduced trust, as well as lost system knowledge. Another reason was the ineffective handling of performance problems (sometimes despite balanced structure and trust), further diminishing trust. Finally, in some cases, the participants started well, establishing structures and exercising due caution. But, upon achieving initial success, they became complacent and relaxed. Structural controls were either ignored or discarded altogether, and minor problems associated with bigger issues were inadequately attended. The problems inevitably escalated, significantly hurting the project's chances for success.

Some projects experienced a shift from the vicious to the virtuous cycle. And four general tactics seemed to help get a project and its associated client-vendor relationship out of trouble. One was adding or reducing structures. For example, in Project C, the problems caused by missed faxes were addressed through a simple structure—a numbering scheme for faxes.

A second tactic involved emphasizing identity-enhancing events and de-emphasizing identity-threatening events [6]. For example, in Project A, the monthly meetings between the vendor and the client, attended by a number of people from both sides, involved considerable disagreement and criticism. Recognizing that these meetings were well attended, the vendor's project manager proposed that the negative issues be discussed in a smaller group the night before the main meeting. This allowed the general meeting to be much more friendly. Moreover, the disagreements, which were now aired in a small group of senior executives, did not adversely affect the trust of even these executives. Thus, the harmful effect of an identity-threatening event was significantly reduced.

A third tactic was to change the project manager. A vendor executive said, "Strong project management early on would have removed the fear and doubt the client seemed to have about our commitment to the project. After one of our people convinced the client that we were in fact working on its behalf, the mutual attitude improved steadily for several months until both sides were comfortable about the system's chances."

A fourth tactic involved the focused use of top-management pressure. Although too much top-management involvement can cause demoralization, selective involvement of a client's top management gets vendor's attention. In one project, realizing that the client was doing an excellent job of testing the software, the vendor stopped its own testing. When the client's vice president of IS went directly to the client's president, the issue was addressed quickly.

Back to Top

Conclusion

The popularity of OISD makes good management imperative, but these projects continue to be problematic, often yielding disappointing results. Trust in OISD relationships is critical. While recognizing the value of a formal, well-prepared contract and appropriate structural controls, the partners in an OISD organization have to trust each other. Balance between trust and structure furthers performance, whereas excessive focus on either structure or trust, ignoring the other, hurts performance. OISD projects usually focus on structure, but some projects also point up the risk of excessive focus on trust, that is, a high level of trust can lead to inadequate attention on structural controls.

The four kinds of trust defined here and the nine tactics for building them (see Table 2) should be useful in improving the relationship between OISD partners, increasing the likelihood of project success.

Finally, the cases I surveyed and studied indicated that projects go through virtuous and vicious cycles, along with some of the actions that can lead projects into these cycles.

I was somewhat limited because my conclusions were based on 18 cases, of which 13 were observed only from the vendor's viewpoint. Further research is needed to validate my findings. Nevertheless, the lessons I learned so far can facilitate greater success in OISD while making participants' personal experience more positive, helping address a key concern, as expressed by a senior client executive, "I look back at vendor management. There was a better way to do it. The project's targets were more than the vendor was really capable of. Yet we were angry and tried to make the vendor do it. I would sometimes think, 'We are killing these people.' But the vendor's people weren't bad guys, refusing to do the work. The vendor was doing the best it could."

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 1999 ACM, Inc.

---

No entries found