A Psychological Contract Perspective on Project Networks

A Psychological Contract Perspective on Project Networks

The theoretical starting point for this article is to conceptualize project networks as psychological contracts (Conway & Briner, 2005; George, 2009; Rousseau, 1995, 1998). First, psychological contract theory is presented, followed by a discussion about project networks as psychological contracts.

Originally, psychological contracts were used to investigate employee–employer relationships (i.e., individual–organizational relationships); however, the concept has since been applied to team dynamics (Lacoursiere, 1980), team charters (Svendrup & Schei, 2015), as well as to interorganizational settings (i.e., organization–organization relationships), and then specifically to client–supplier relationships (Herriot, Manning, & Kidd, 1997; Koh, Ang, & Straub, 2004). The classical concept of psychological contract, originally developed by human resource management scholars (e.g., Argyris, 1960; Conway & Briner, 2005; George, 2009; Rousseau, 1989, 1995; Schein, 1965), describes mutual obligations between employers and employees in organizations. In its original context, it was mainly related to social exchange theory. When the concept was later further operationalized, it mainly became a concept used to describe employment relationships (Cullinane & Dundon, 2006). Rousseau (1989, 1995) provides a common definition of psychological contracts as the employee’s beliefs regarding the promises of the reciprocal exchange agreement between the employee and the organization.

In psychological contract theory, critical incidents play a central role. Critical incidents may manifest in violations and/or breaches of the contract. Herriot et al.’s (1997) seminal investigation is an example of a study that aims to define the content of a psychological contract by focusing on critical incidents. Using data collected from critical incidents, and assuming the hypothesis that there exists a general agreement between employees and the organization concerning their obligations, they investigated both employees’ and managers’ perceptions of these obligations within the organization. Findings showed that there was a considerable level of agreement between employees and the organization and ideas of what exists in the contract, which seemed to indicate there is indeed a psychological contract.

In a later study, Koh et al. (2004) examined client–supplier relationships in IT outsourcing processes using the same approach. In their study, through a multi-method approach, they have identified (psychological) mutual obligations between the client and the suppliers in a business relationship, not in an employer–employee relationship, something that indicates that the concept of psychological contract is transferable also to inquiries of business relationships. Consequently, given Koh et al.’s (2004) study of business relationships, it seems possible to likewise apply the concept of the psychological contract to network relations such as project networks.

Moreover, past research has suggested that psychological contracts can take a variety of forms; the most commonly used distinction is that between transactional and relational contracts (George, 2009; Majchrzak, Jarvanpaa, & Bagherzahdeh, 2015; Rousseau, 1989). Within interorganizational relationship literature, transactional contracts are typically defined as the formal agreement and the relational as the informal agreement (Majchrzak et al., 2015). In psychological contract theory, however, both types refer to psychological contracts (i.e., informal contracts in interorganizational relationship literature). In psychological contract literature, transactional psychological contracts typically refer to limited involvement, short-term obligations, monetary compensations, and a relationship in which the identities of the parties are irrelevant. Conversely, relational psychological contracts emphasize deeper long-term involvement: loyalty as well as an interest in the other party. Accordingly, by utilizing the same approaches used in psychological contract research, it is likewise considered logical to examine the latent informal and tacit expectations between actors in a project network as well as characterize a project network as being either transactional or relational to its nature.

Methodology

To address the questions posed, a retrospective longitudinal case study was used. Case studies are typically used for answering how and why questions (Yin, 2009), for investigating contemporary difficulties in demarcating phenomena (Yin, 2009), for conducting process studies (Åhlström & Karlsson, 2009), as well as for inductive theory building (Eisenhardt, 1989) and theory elaboration (Ketokivi & Choi, 2014). The present study is theory elaborative (Ketokivi & Choi, 2014), examining the evolution (i.e., the process) of a partnership between two companies during the initiation and execution of a project to codevelop a new product. This relationship can be viewed as a focused analysis of a strong tie in a project network. Such a relationship (i.e., a tie) is embedded both in terms of formal and informal organizational arrangements, and the evolution of a relationship is determined by the respective actors’ business goals, practices, and cultures.

Findings: Evolution and Outcome of the Collaboration

Following is a description of the evolution of the collaboration between the lead company and the research company. The presentation is divided into two sections: the process and the outcome.

Process

The two companies had been aware of each other years before the partnership started. The research company had been especially interested in getting the lead company as a client for a long time. One manager at the research company put it this way: “We have been interested in collaborating with the lead company for a long time as they are a leader in their industry and everyone looks at what they do.” In a similar vein, although not with the same intensity, the lead company was very aware of the competence that existed in the research company and that there was a large potential for collaborating with the research company. Discussions took place between the companies over several months and, in the final stage of the negotiation (immediately before a contract was signed), the actual decision to start a joint project was made in an atmosphere of “close the deal and fix the details later.” (In later interviews, the respondents highlighted this fact as an explanatory factor for why things fell apart later in the process.) From the lead company’s perspective, the motivation for engaging in the alliance was to be able to outsource hardware development and production while the company focused its resources on software. From the research company’s perspective, the project fit very well with its business strategy of offering complete solutions within optics and mechatronics. These areas included development, production, and product management.

A contract containing the following main issues was created: (1) Both the pre-study and the development phases should be delivered at fixed prices, and (2) the cost of development should be divided in accordance with the unit price set on each product by the research company. This was a solution that suited both the research company’s business concept and the lead company’s R&D strategy, where the latter partner saw it as a risk reduction strategy.

A pre-study aimed at refining the initial cost estimates and planning a full project was initiated. The focus of this phase was to establish a specification for the product to be developed: the fifth generation of the system. The first critical incident, observed by both partners, occurred during the later stages of this pre-study.

Critical Incident 1: Once the pre-study had been completed, a conclusion was that the initial estimations of the cost of the development project should be revisited. The cost of development would be higher than earlier estimations.

The project leader of the research company summarized the situation as follows: “We were caught in the typical expectation trap; it should be as the existing product, but better and cost less.” Both companies, however, decided to continue the project. A meeting with engineers from both organizations was held to discuss how to find ways to reduce project costs. Later, when the project was finished, the head of R&D at the lead company reflected on the situation and said: “We should have stopped the project at this point until we had solved the commercial issues, but at that time there was a strong will from both parties that we should finish the project in time.” Nevertheless, the outcome was a decision to divide responsibilities so that the research company would be responsible for hardware development, and software development would be the lead company’s responsibility.

As time-to-market was crucial for the lead company, the development phase of the project was initiated and work proceeded as planned during the succeeding development period. During this period, the research company worked primarily on its own, largely guided by a specification developed during the pre-study (as earlier decided).

Interactions between the research company and the lead company were limited to progress meetings with little knowledge transfer, apart from what was included in the specification. The relationship between the two partners’ engineers was good; however, the following critical incidents radically changed the relationship between the two companies:

Critical Incident 2: After 3 months, a hardware prototype entered a test phase to test the functionality of the hardware and software integration, and the lead company had developed specific software for this test procedure. During the testing, the research company discovered that it could not guarantee full hardware functionality since the software only tested parts of this functionality. The lead company, in turn, argued that the research company was responsible for the hardware regardless of the software, which was meant to be used as a tool for testing the hardware, and not to be used as a contract disclaimer for the research company.

It had been decided that there should be a clear division of responsibilities. The lead company should have the responsibility for the software and the research company for the hardware. The weakness of this decision was now seen. For an outsider, this issue may not seem vital, but for both of the participants it was a manifestation of a lack of competence. The project leader in the research company was frustrated because the test software could “only verify 20% of the functionality, and with such a test we could not guarantee the functionality we were responsible for.” On the other hand, engineers at the lead company stated: “The research company claimed that we should be ready with the software at this point in time, however, this had not been clear in the planning” (engineer, lead company). This situation resulted in a blame game in which new functionality was specified and extra hours added to the project, with no change to the time plan or cost estimate.

As a consequence, the relationship between the partners became toxic. An extra steering committee meeting was held, and strategies for continuing the work were discussed. No immediate decision was made and this discussion lagged on for another 6 months without any definitive solution. The result was that the project was delayed by 8 weeks, which led to increased project costs. Still, the formal contract was not renegotiated.

Critical Incident 3: A technical problem was found at prototype delivery: the sound level of the hardware was too high. The lead company was of the opinion that the research company had missed a requirement or hidden the obvious difference in the sound level from the previous version. In contrast, the research company argued there was no specification of sound levels in the formal specification.

Sound was something that everybody in the lead company understood and the sound level of the prototype was high. The position from the lead company was clear: “You are engineers! The product cannot be worse than before! You have to redesign.” The research company admitted that it had delivered a substandard product but argued that the formal specification was ambiguous. The research company continued to argue that if the software had been able to test the full functionality of the hardware, then this problem would have been detected at an earlier stage. One engineer in the research company presented it this way: “Take a product that has been working for 10 years and change some parts; the product has been optimized for four generations so of course there will be secondary failures.” At this point in the project, there were no additional resources for improving the product. Nevertheless, the project continued, but the lead company was disappointed with both the lack of communication with the research company and the incidents during the development process. The research company in turn had not succeeded in making changes in the formal contract although their project was responsible for an overrun in the development budget.

Step by step, the engagement of the engineering work reached a very low level.

At this point, an organizational consultant was engaged to shed some new light on the collaboration. The consultant’s task was to provide a “second opinion” on the alliance and how it developed. He reported that “from a strategic point of view the alliance seemed to be an optimal fit between the two partners’ competencies in order to create the product.” However, the consultant suggested several improvements related to how the project was run: to increase the cooperation between the parties (i.e., make explicit all dependencies between each party in the project); to change the compensation model to include major change requests; and to form a stronger steering committee. None of these recommendations was implemented. The project continued to slide.

Critical Incident 4: The project was put on hold and all engineering work stopped. The CEOs of the respective companies now joined the discussion and a process of renegotiation started; this concerned scope, business terms, and engineering tasks.

The research company stopped working because they were not prepared to take more of the financial risk. The project leader at the research company formulated it as “Should we solve this together or should legal step in?” Instead of engaging the legal experts, the CEOs of both companies got engaged in the project. The renegotiation led to a major shift in how work had been done. The project name was changed, and the research company introduced a new project manager in order to get a new start. The formal contract was radically changed, with the major change including a new compensation model based on an open account rather than a fixed price. Based on these changes, development was restarted, and far greater emphasis was given to communication between the two companies. In the renegotiated contract, the new compensation model stated that the research company would only charge hourly engineering costs (with no margins). The consequence of this arrangement was that the research company’s engineers were locked into the alliance project until it finished; the research company covered its costs but could not engage in other more profitable projects. The engineers of the lead company now worked closely with the engineers at the research company, and co-learning about the technical system ensued. Table 1 presents an overview of the changes made in both the formal contract and in the psychological one.

OPEN IN VIEWER

Table 1.

The Character of the Psychological Contract Before and After Critical Incident 4.

	Before Critical Incident 4	After Critical Incident 4
Formal contract	Fixed price Initial division of risk	“Discounted charge by hour” Risk sharing
Psychological contract	• Individual, coordinated tasks • Handovers • Fulfillment of specification • Little interaction	• Teamwork • Cooperative learning • Adaption

This was a critical incident, which followed other incidents, thereby fostering escalating distrust. The renegotiation (Critical Incident #4) described here is just the consequence of the previous critical incidents. The renegotiation, therefore, became a natural step for the lead company to restructure the project. In a similar vein, the renegotiation incident also became an opportunity for the research company to renegotiate the contract, something they had wanted to do for a long time. Previous reasons for rescheduling the time plan of the project had existed (e.g., when the test software was not ready); however, nothing had been formally done until this halt.

Discussion and Conclusion

In contrast to classical project management research, which aims to understand the solitary organizational unit of a project, new units of analysis such as program, portfolio, project-based organizations, and project networks have emerged in the project management research (Gemünden, 2016). This interest in other units of analysis manifests in an ambition to capture the inherent complexity faced by today’s project leaders. Managing a single well-demarcated project is simply not enough. Although not a new concept, but currently driven by globalization and new means for virtual communication, scholars have recently shown a renewed interest in project networks (Bakker et al., 2016; DeFillippi & Sydow, 2016; Manning, 2010; Oliveira & Lumineau, 2017; Ruuska, Ahola, Karlos, Locatelli, & Mancini, 2011). Accordingly, a current challenge for project network scholars is to explain “how history matters”; in other words, how past experiences of collaboration between actors in a project network is transformed into an informal organizational format that is replicable in future collaboration—something referred to as the “temporal paradox” (DeFillippi & Sydow, 2016). However, a question that has yet to be addressed in project network research is as follows: How are project networks formed in the first place?

Based on an investigation of the formation of a collaboration between two parties, which later was developed into a project engagement template, this article has investigated two questions: (1) Could the (informal) organizational format of a project network be conceptualized as a psychological contract? (2) Given question 1, could a psychological contract perspective shed light on how project networks are created in the first place?

The first contribution from this study, which addresses this question, is that a psychological contract perspective could be used to describe project networks. In parallel to the formal organization (i.e., the contract), the psychological contract theory highlights the informal structure in terms of expectations. In this current case, the focus rested on mismatches in expectations shown in a series of critical incidents. These critical incidents could be interpreted as repeated violations of the psychological contract between the parties, something that was needed in order to trigger a situation in which the formal contract was changed. Expectation related to different aspects of the other partner’s competence dominated the incidents. Accordingly, a preliminary finding is that the psychological contract in a project network is, to a large extent, formed by expectations related to an understanding of the other party’s competence. A process of mutual adjustment of expectations could be interpreted as a process where relationships are formed; therefore, by introducing psychological contracts as a new unit of analysis, future studies could examine in more detail how critical incidents shape the (reshaped) project network.

Findings from the study also suggest that project networks are formed both by the formation of a formal agreement (i.e., a contract) that specifies roles and responsibilities and by the formation of a psychological contract that specifies expectations. In the present case study, a major breach of the psychological contract was made. It could be argued that this breach manifested in a transition from a transactional-based to a relational-based psychological contract. This indicates that the character of the interaction process (characterized as a transactional or relational psychological contract) between the partners is related to the successful outcome of the cooperation. The hypothesis from this study is that a relational character of the process is linked to success.

A number of managerial implications could be drawn from this study. One managerial implication is that an articulate psychological contract, in parallel to the legal contract, could be a useful management tool for governing the alliance. By defining the content of such a contract early on, a new mediating object can be introduced to support team discussion within, as well as between, the parties. Accordingly, the crafting, as well as the maintenance, of this psychological contract will be a key issue for managers in a project network. A second managerial implication is linked to the governance structure of project network nodes. Since the contractual issue is often the responsibility of upper management, there is a need for an articulated shared leadership model where the division of responsibilities between the managerial and the engineering levels (i.e., the business and the technical level) is clear. Business issues (related to cost, priorities, and initial conditions) need to be managed on a (top) managerial level, whereas issues related to engineering and technical development could be the responsibilities of the technical project leaders.

This study does, however, have several limitations. First, it is a single case study, from which it is difficult to generalize. However, as the goal has been to illustrate the application of a theoretical approach, it can be argued that the findings are valid to knowledge-intensive, contractually based project networks, such as R&D project networks. Second, another weakness is that the case presented does not include repetitive replications of the project network. However, it shed light upon the transformation of one strong tie in a project network; accordingly, further research is needed. One potentially fruitful approach for future research would be additional case studies, including the analysis of critical incidents as indicators of project deviations/psychological contract breaches This should be done in the whole project network, not only on a dyadic relationship. Another fruitful approach would be to describe the perception of psychological contracts as those done by Herriot et al. (1997) and Koh et al. (2004), where the interesting topic would be to map on the one hand the formal contracts, including the division of work (i.e., roles and responsibilities), and on the other hand the content (or perception of) the psychological contract between the actors (i.e., the routines and relationships).

A further interesting question for future research is if project networks can be formed on formal contracts only (i.e., transactional contracts only) or if a relational component is needed. The content of the psychological contract has not specifically been the focus of this study; however, future studies should also employ the same methodology as Koh et al. (2004) and investigate the content of the psychological contract as applied in different types of project networks. Yet another interesting topic with both theoretical and practical implications is to investigate how critical incidents are managed and the pace at which they are resolved; how this “coping process” influences the character of the relationship between the parties would be another area. This last topic could be framed as a leadership challenge, an issue touched upon by past research (Sydow, Lerch, Huxham, & Hibbert, 2011; Thorkildsson, Kaulio, & Ekman, 2015). Increased knowledge on these crucial issues would be beneficial for both streams of project network governance research as well as practicing managers.