Archive for the ‘Corporate IT’ Category
Relational factors in managing outsourced projects
Introduction
More often than not the success of an offshored IT initiative is measured using financial or operational metrics – client-side managers tend to focus on cost savings and vendor-side managers on achieving service level metrics. This is fine as it goes, but is a limited view of the business arrangement. It is far more important for both parties to to focus on building trust and commitment to a long-term relationship. In a paper entitled, Evaluating the Success in International Sourcing of Information Technology Projects: The Need for a Relational Client-Vendor Approach, Peter Haried and K. Ramamurthy look into the role of relational factors in internationally sourced projects. This post is a summary and review of the paper.
Project management methodologies and standards focus on the economic, contractual and operational aspects of projects; they have very little to say about how client-vendor relationships should be managed. Perhaps as a consequence, much of the research on offshored projects is based on agency theory or transaction cost economics, both of which focus on risk and opportunistic behaviour from perspective of clients (rather than vendors). However, it is clear that vendors would generally have a different view of what constitutes risk or opportunism – a risk for a client is not necessarily one for the vendor. Further, as Haried and Ramamurthy mention in their introduction, success is in the eye of the beholder; clients and vendors will differ on what constitutes success. This suggest that a view which emphasizes relationships rather than contracts and SLAs may provide a basis for a more inclusive approach to offshored initiatives.
Recent research has begun to look at the relational aspect of offshoring (see this paper or this one, for example). According to Haried and Ramamurthy, however, little work has been done on integrating the relationship perspective with the traditional outcome-focused view. Their work is an attempt to bridge this gap.
Theoretical Background
In a post entitled, To outsource or not to outsource, I discussed how transaction cost theory can provide organisations an insight into whether or not they should outsource work. According to transaction cost theory, the cost of completing a transaction (from the client perspective) depends critically on:
- The complexity of the transaction: for example, implementing an ERP system is more complex than implementing a new contract management application.
- Whether or not it involves assets that are worth more within a relationship between two parties than outside of it: for example, custom IT services, tailored to the requirements of a specific company have more value to the two parties – provider and client – than to anyone else. This is called asset specificity in economic theory.
These factors can help determine whether or not an organisation should outsource their work, but they neglect the social-relational aspects of the outsourcing relationship. For instance, if the relationship is strong, a firm may feel confident enough to offshore highly complex, organisation-specific work. Clearly, the relational aspect needs to be factored into in any offshoring decision.
The relational view is founded on the assumption that the relationship between the client and vendor is more important for success than a purely economic view. Haried and Ramamurthy use social exchange theory as the basis for their investigation. Quoting from Wikipedia, “Social exchange theory posits that all human relationships are formed by the use of a subjective cost-benefit analysis and the comparison of alternatives.” As such, it assumes that human relationships are based on an economic analysis, albeit a subjective one.
Research Model
Based on a survey of research literature, Haried and Ramamurthy identify the following as key variables that affect offshoring relationships:
- Information Sharing: this defines the degree to which the parties agree to share relevant information with each other. This is really just another term for effective communication, one of the key success factors of any project.
- Legal bonds: these are the legally binding agreements that are set out in the offshoring contract. The authors contend that many problems in offshoring deals can be traced back to the contract between the client and vendor. It is important for both parties to realise that the contracts are necessarily incomplete, and must be interpreted in a far-sighted manner.
- Client adaptations: adaptations made by the client to fit the processes and procedures of the vendor.
- Vendor adaptations: adaptations made by the vendor to fit the processes and procedures of the client.
- Mutual obligations: beliefs that each party hold about their obligations to each other. These generally refer to items that have not been (or could not be) contractualised. Mutual obligations are a form of psychological contract.
- Intercultural competence: The ability to develop good interpersonal and working relationships with people from other cultures, and to resolve any conflicts or misunderstandings that may arise due to cultural differences. Traditionally, intercultural differences have been viewed as a major obstacle in international sourcing arrangements. However, research seems to be somewhat equivocal on this point.
In my opinion, the selection of these factors is arbitrary: the authors do not offer any justification for choosing these six factors rather than others. For example, anecdotal evidence suggests that offshoring clients often complain about the high turnover of vendor staff -the rationale being that it becomes difficult to build good working relationships when key contacts on the vendor-side change often. Given this, continuity (of relahionships) could have been considered a separate variable in much the same way as information sharing has been factored out of mutual obligations (information sharing is a mutual obligation). Although this is just an example, it begs the question as to which other important relational variables might have been omitted from the study.
Haried and Ramamurthy identify the following factors as being measures of the relational success of an offshoring arrangement. In their model these factors are assumed to be caused (or driven) by the above mentioned variables.
- Trust: In most cases the client and vendor are located in different countries, so there’s plenty of scope for (negative) opportunistic behaviour on both sides. Given this, it is important that the two parties trust each other. As such, the degree of trust developed is a good measure of the relational success of a project.
- Commitment: This refers to the effort that each side is willing to put in to maintaining the relationship. Very often this entails going beyond the contract. The ideal situation as far as commitment is concerned is when both parties have an exclusive arrangement to work with each other. Clearly, the degree of commitment is another measure of relational success. However, it isn’t clear to me that it is an independent factor because commitment depends on trust.
- Conflict: All relationships are prone to conflict, outsourcing arrangements are no exception. However, working through and resolving conflicts in a mutually acceptable manner can strengthen the relationship. Conflict can be quantified (sort of) via the overall level of disagreement between the two parties over matters such as goals, procedures, timelines etc. Clearly, the level of conflict is also a good measure of the relational success of the offshoring arrangement.
Again, these three success factors are chosen without justification, omitting other possibly significant ones. For example, longevity of the relationship might also be a good indicator of the success of the relationship. Further, the causal connection between variables and success factors is far from clear; the authors hypothesise a cause-effect relationship between the six relational dimensions and the three measures, but there is no justification offered.
Research Methodology
The authors gathered qualitative data through interviewing a number of offshoring client/vendor pairs about the relational aspects of the outsourcing arrangement. Vendors were contacted through the client – this is an important point which I’ll return to later. The clients were asked to provide information on two projects – one that had been completed recently and the other ongoing. The authors asked for permission to interview multiple stakeholders from both the client and vendor organisations. This provided diverse perspectives on the all questions that were asked. The questions asked pertained to the model discussed in the previous section, in the context of the project that the interviewees had worked on. The questions were open-ended so the interviewees had to think through their answers, not just tick a box.
The authors surveyed five US-headquartered firms from the areas of financial service and manufacturing. These were the clients. The outsourcing partners (vendors) – six in all – are all India-based outsourcing majors. The gathered data covered eight projects across the surveyed organisations.
Analysis
Below are the conclusions the authors drew from an analysis of their data. The findings are listed by each of the model variables.
Information exchange
Client Perspective
Most of the client-side interviewees indicated that communication (information exchange) was a key determinant of the success of the relationship. In many projects the vendor had a on-site team with whom client-side stakeholders could communicate directly. This was highlighted by clients as being an effective means to communicate. It placed the onus of communicating with the offshore team on the on-site vendor team.
Vendor Perspective
The vendor perspective matched that of the client. All vendors agreed that having an onsite team is critical to the success of the project. Although some of the reasons offered by vendor-side stakeholders differed in detail from that of those on the client-side, this indicates that communication is indeed a key relational success factor.
Based on the above, the authors formulate the following proposition:
Proposition 1: Intense, open, and timely information exchange is crucial for relational success for both client and vendor stakeholders.
Vendor Adaptations
Client Perspective
Clients viewed adaptations made by the vendor as critical to the success of the outsourcing relationship. Typically, the adaptations cited by clients included, working hours, processes and procedures, investments made in training staff and placing personnel on site.
Vendor Perspective
Most vendor-side interviewees agreed that the vendor needed to adapt to the client rather than the other way round. Further, many vendors recognized that this was a key to continuing the relationship. As one vendor-side analyst put it, “Up to a certain level, no matter what, we will accommodate because they know if we do not accommodate we will be out.”
The authors point out that these findings are consistent with transaction cost theory in that vendor adaptations are, in effect, a type of asset specificity. They give the vendor an advantage over other vendors who may want to compete for the client’s business because they indicate that the vendor is serious about maintaining and enhancing the relationship with the client.
Based on the above, the authors hypothesise the following:
Proposition 2. Adaptations by vendors are vital for relational sourcing success evaluations by client and vendor stakeholders. These are even more important for client stakeholders than for vendor stakeholders.
I’m not sure I agree with the statement, “[vendor adaptations are] even more important for client stakeholders than for vendor stakeholders”. I’d say they’re at least equally important to vendors because the client could walk away from the relationship if the vendor is not willing to make adaptations.
Client Adaptations
Client Perspective
The responses here were a bit mixed. Clients-side managers believed that some adaptations would have to be made, and were worthy of making too. For example, one manager stated that offshoring would entail more rigorous documentation and adherence to internal processes– which he perceived as a Good Thing. On the other hand, one of the business analyst’s interviewed thought it odd that they (the client) should be making adaptations when they were the customer in the relationship. The perception seemed to be that the vendor should make adaptations, not the client.
Vendor Perspective
Some vendor-side interviewees indicated that clients would need to make adaptations to get the most out of offshoring. Two areas singled out were: 1) adjusting to distributed teams and 2) adapting to cultural differences. That said, vendors valued whatever adaptations their clients made, and realised that these adaptations indicated the seriousness of the client about the relationship.
Based on their findings, the authors propose the following regarding client-side adaptations:
Proposition 3. Adaptations by clients are essential for relational sourcing success evaluations by client and vendor stakeholders. These are even more important for vendor stakeholders than for client stakeholders.
Legal Bonds
Client Perspective
Most client stakeholders considered the offshoring contract to be of limited importance. In most cases, clients viewed the contract as a basis for the relationship, but not a comprehensive document containing last detail of the business agreement. Client-side managers emphasized that the contract was intended to be flexible.
Vendor Perspective
The vendor, quite naturally, placed more emphasis on the contract. That said, most vendor managers noted that the contract described only the high-level goals, not how they would be achieved. Most vendors saw the contract as a means to engender trust and reduce conflict. Based on interviewee responses, the authors make the following hypothesis:
Proposition 4. Legal bonds are considered key to relational sourcing success for vendor stakeholders to a greater degree than for client stakeholders.
Although the authors claim that these findings are consistent with social exchange theory, I suspect that the respondents may have glossed over difficulties – see my post on some pitfalls of contracts for more on why.
Mutual Obligations
Client Perspective
Many clients did not acknowledge that mutual obligations played a role in the relationship. However, some client-side stakeholders acknowledged that many vendor personnel went above and beyond the call of duty (and the contract). On the other hand, some senior managers felt they weren’t getting value for the large sums money they were spending.
Vendor Perspective
Vendor stakeholders were consistent in their belief that the contract could not capture everything, and that mutual obligations were an important determinant of the success of the relationship. Many vendor-side personnel claimed that they were doing several tasks that were not in the contract.
The authors suggest that the differences in perceptions of mutual obligations may be because many client-side personnel were simply not aware of what was written in the contract. In contrast, most vendor stakeholders had a good idea of what was contracted. Based on this, the authors make the following hypothesis:
Proposition 5. Mutual obligations are viewed by vendor stakeholders as essential for relational sourcing success, but not necessarily by client stakeholders.
Intercultural Competence
Client Perspective
Clients acknowledged the importance of intercultural understanding to the success of the relationship. However, most clients displayed a good awareness of cultural differences and what needed to be done to address issues arising from them.
Vendor Perspective
Like clients, all vendors acknowledged the importance of cultural differences. Like clients, they did not believe these presented any major problems.
The authors emphasise that their findings are not consistent with previous research (see this paper for example). Based on their findings they propose the following:
Proposition 6. Intercultural competence is not a key determinant of relational sourcing success valuations by client and vendor stakeholders.
Summary results and conclusions
Based on their findings, the authors make the following points:
- Success of the relationship depends on many factors (in particular, those listed above), and any analysis must include both client and vendor perspectives. Many earlier studies included only the client perspective.
- Information exchange (communication) is acknowledged as a key factor by both clients and vendors.
- The clients expected vendors to make adaptations to the clients’ processes, but did not necessarily believe that they (the clients) needed to make any adaptations. The authors point out that this finding is inconsistent with transaction cost theory
- Clients did not always acknowledge the importance of contract, but the vendor always did. The same was true of the role of mutual obligations. The authors speculate that this may be because client stakeholders weren’t always aware of what was contracted whereas vendor stakeholders invariably were.
- Neither clients or vendors believed that cultural differences were an unmanageable issue. The authors suggest that this may be because offshoring is now a well-accepted practice and that client firms have a better understanding of the potential problems that intercultural issues can cause.
- They acknowledge the limitations of their research: sample size, location of clients and vendors. However, they do not acknowledge that clients and (especially!) vendors may not have been open in their responses. This is a particular concern because vendors were contacted through the client.
- They believe that their work may be useful to project managers who work on internationally sourced projects because it provides a set of key relationship dimensions that managers should focus on. Maybe so, but readers should be aware that there could be other key dimensions as I’ve noted earlier in the review.
To conclude: although the conceptual model presented by the authors has some shortcomings, project managers will find the paper a worthwhile read because it highlights the importance of relational factors in managing outsourced projects.
On the relationship between systems and the organisations that build them
Introduction
System design is a creative activity, but one that is subject to a variety of constraints. Many of these constraints are obvious: for example, when tasked with designing a new software product, a team might be asked to work within a budget or use a particular technology. These constraints place boundaries on the design activity; they force designers to work within parameters specified by the constraints. But there are other less obvious constraints too. In a paper entitled, How Do Committees Invent, published in 1968, Melvin Conway described a notion that is now called Conway’s Law: An organisation which designs a system will inevitably produce a design that mirrors the organisation’s communication structure. This post is a summary of the key points of the paper.
Conway begins the paper with the observation that the system design is an activity that involves specifying how a system will be built using a number of diverse parts. Many elements of the act of design are similar, regardless of the nature of the system –be it software or a shopping mall. The objective of a design team or organisation is to produce a specification or blueprint based on which the system can be built.
Much of design work is about making choices. Conway points out that these choices may be more than design decisions:
Most design activity requires continually making choices. Many of these choices may be more than design decisions; they may also be personal decisions the designer makes about his own future. As we shall see later, the incentives which exist in a conventional management environment can motivate choices which subvert the intent of the sponsor.
The paper is essentially an elaboration and justification of this claim.
Pre-design work
The preliminary stages of design work are more about organizing than design itself. First, the boundaries have to be understood so that the solution space can be defined. Second, the high-level structure of the system has to be explored so that work can be subdivided in a sensible way within the organisation that’s doing the design. This latter point is the crux of Conway’s argument:
…the very act of organizing a design team means that certain design decisions have already been made, explicitly or otherwise. Given any design team organization, there is a class of design alternatives which cannot be effectively pursued by such an organization because the necessary communication paths do not exist. Therefore, there is no such thing as a design group which is both organized and unbiased.
There are a couple of important points here:
- The act of delegating design tasks narrows the scope of design options that can be pursued.
- Once tasks are delegated to groups, coordination (via communication) between these groups is the only way that the work can be integrated.
Further, once established, it is very hard to change design idea (or a project team, for that matter).
The system mirrors the organisation
Most systems of any significance are composed of several subsystems that communicate with each other via interfaces. According to Conway, these elements (italicized in the previous sentence) have a correspondence with the organisation that designs the system. How so? Well, every subsystem is designed by a group within the organisation (call it a design group). If two subsystems are to communicate interact with each other, the two groups responsible for their design must communicate with each other (to negotiate the interface design). If subsystems don’t interact, no communication is necessary. What we see from this argument is that the communication between subsystems roughly mirrors the communication paths within the organisation.
As any system designer knows: given a set of requirements, there are a number of designs that can satisfy them. If the argument of the previous paragraph is true then the structure of the design organisation (or project team) influences the choice that is made.
Managing systems design
Conway points out that large system design efforts spin out of control more often than those for small systems. He surmises that this happens when the design becomes too complex for one person (or a small, tightly-knit group of people). A standard management reaction to such a situation is to delegate the design of component to sub-teams. Why? Well here’s what Conway says:
A manager knows that he will be vulnerable to the charge of mismanagement if he misses his schedule without having applied all his resources. This knowledge creates a strong pressure on the initial designer who might prefer to wrestle with the design rather than fragment it by delegation, but he is made to feel that the cost of risk is too high to take the chance. Therefore, he is forced to delegate in order to bring more resources to bear.
A major fallacy in this line of thinking is that more resources means that work gets done faster. It is well known that this isn’t so – at least as far as software systems development is concerned. Conway points out that politics also contributes to this effect. In most organisations, managerial status is tied to team size and project budgets. This provides an incentive to managers to expand their organisations (i.e. project teams), making design delegation almost inevitable.
Large teams have a large number of communication paths between their members. Specifically, in a team consisting of N people, there are N(N-1)/2 possible communication paths – each person can communicate with N-1 people making N(N-1), but this has to be halved because paths between every two individuals are counted twice. Organisations deal with this by restricting communication paths to hierarchical management structures. Because communication paths mirror organizational structures, it is almost inevitable that system designs will mirror them.
Conclusion
The main implication of Conway’s thesis is that a project team (or any organisation) charged with designing a system should be structured in a way that suits the communication needs of the system. For example, sub-teams involved in designing related subsystems should have many more communication channels than those that design independent components. Further, system design is inherently complex, and the first design is almost never the final one. A consequence that flows from this is that design organisations should be flexible because they’ll almost always need to be reorganized.
In the end it is less about the number of people on a team than the communication between them. As Conway mentions in the last two lines of his paper:
There is need for a philosophy of system design management which is not based on the assumption that adding manpower simply adds to productivity. The development of such a philosophy promises to unearth basic questions about value of resources and techniques of communication which will need to be answered before our system-building technology can proceed with confidence.
This is as true now as it was forty-odd years ago.
Conflicts over identity: on the relationship between software developers and project managers
Introduction
The relationship between software developers and project managers is often fraught with conflict. Yet they have to get along professionally: the success of a software project depends to a large extent on whether or not they can work together. A paper entitled Stop whining, start doing! Identity conflict in project-managed software production, published in the May 2009 issue of Ephemera, delves into this issue by looking at how the two parties view themselves in relation to each other. This post is a summary and review of the paper.
A quick word or two before diving into the paper. First, identity conflict occurs when a person or a group feels that their sense of self (i.e. their identity) is threatened or denied legitimacy and respect. Second, although the title of the paper suggests that it deals with identity conflict in project-managed software production, the authors’ focus is considerably narrower: the analysis presented in the paper is based on selected Slashdot discussion threads involving software developers and project managers. In effect, the authors draw their conclusions about identity conflict in software production based on opinions expressed online forums. It is, I think, stretch to read too much into such exchanges. I’ll have more to say about this in the final section of this post.
The authors of the paper, Peter Case and Erik Pineiro, begin their analysis by noting that although project managers are usually above programmers in the organizational hierarchy, the relationship is complicated by two factors:
- Project managers usually do not need (and often lack) the educational qualifications possessed by programmers.
- Project managers usually do not have the depth of technical knowledge that programmers have.
These two conditions often lead to the view amongst programmers that they (the programmers) have a higher organizational status (or matter more) than project managers do.
The authors end their introduction with the observation that the skills of programmers are necessary for the creation of software, but equally necessary is the need to direct software building efforts using some form of project management. This observation underlines the symbiotic relationship between developers and project managers. On the other hand the differences between the two disciplines is also a source of conflict between the two parties. The main aim of the paper is to highlight how this conflict plays out in online discussions involving developers and project managers.
Research Methodology
Case and Pineiro base their research on an analysis of contributions to online discussions on Slashdot. A large number of Slashdot contributors are programmers. The discussions cover a range of topics of interest to coders – from the merits of particular technologies, to outsourcing, aesthetics and personal philosophies of programming. The authors use two ideas (or, more accurately, lenses) to interpret the data, the data being individual contributions to discussions.
First, the authors contend that contributors to Slashdot are:
… bringing about social effects through their displays of technical bravado, expressions of aesthetic preference and espousals of dissent, resistance and subversion.
In particular, when discussing the relationship between programmer and project managers, contributors – through the discussion – are creating (or confirming) a certain view of the relationship between the two parties. In doing so, they are enacting their own identities (as members of a particular guild). They do so in opposition to the other party – i.e. by setting themselves apart by negating the skills, knowledge and work of the other.
Second, the work that programmers do has a certain value in the marketplace – i.e it is created because of its (direct or indirect) commercial value. This has two consequences:
- Programmers feel that they have to compromise on quality (or aesthetics) because of time pressures and, on the other hand, project managers feel that programmers do not understand the commercial imperative to move the project forward.
- Both sides feel that their own specialized area of knowledge – technical or managerial – is the truly important one as far as the commercial aspects of the project are concerned.
The authors use excerpts from Slashdot discussions to highlight these two dynamics at work.
Data analysis and discussion
The programmers’ perspective
In Slashdot discussions, Case and Pineiro find that programmers articulate different identities depending on the audience. In some situations they express an interest in (or agree with the importance of) meeting deadlines, getting the product to market etc. Whereas, in other situations, particularly when responding to (or comparing themselves to) project managers, they might express an interest in code aesthetics – i.e. the importance of writing good, even beautiful, code. Several examples of the latter can be found in a discussion thread on software aesthetics. Many of the contributions to the discussion assert that (good) programmers have the following traits:
- Are passionate about their work
- Care deeply about quality.
- Understand of the importance of good code.
Several contributors make these points in opposition to the work-related traits of managers. That is, they set up a stereotypical manager – who doesn’t care about code quality etc. – as a foil for their rhetorical arguments.
Technical knowledge is another important way in which programmers set themselves apart from project managers. The contention here is that managers cannot really understand what a software system is because they don’t have the required knowledge; an implication being that they are not qualified to manage its construction. Case and Pineiro mention how this issue can really raise emotions when it comes to the issue of outsourcing (see this discussion thread for example).
The project manager’s perspective
Although the Slashdot community is dominated by programmers, the authors were able to find a few contributions that gave the project managers’ viewpoint. For example, a discussion on project management for programmers, gave some project managers an opportunity to articulate their views. In the discussion, project managers tended to focus on two aspects – performance (i.e. completing the project on time) and project management knowledge – both of which (they implied) programmers do not understand. See this comment for an example of the former and this one or this one for examples of the latter.
Project managers thus set themselves apart (i.e. construct their identities) as distinct from programmers. They are concerned with driving the project to successful completion and they have specialized knowledge and training to do this; both of which programmers do not possess.
The authors’ conclusions
From their analysis of selected Slashdot discussions, Pineiro and Case conclude the following:
- Software developers and project managers tend to construct their identities in opposition to each other – i.e. by setting themselves (their skills, motivations and concerns) as being different from the other. On the other hand, business imperatives require that they collaborate, so there is a symbiotic aspect to their relationship.
- Despite project managers being marginally higher up than programmers in organizational hierarchy, there is little difference in the status of the two. The reasons for this are: 1) Project managers lack the specialized technical knowledge needed to understand programmers’ work and 2) Software project managers’ are dependent on programmers – perhaps more so than project managers in other disciplines. As a consequence, the difference in status might rankle with programmers. Thus the hierarchical proximity of the two parties might also be one of the reasons for the conflict between the two.
- Both parties generally claim to have the same goal – produce quality software in reasonable time. They differ, however, in the means to achieve the goal. Programmers believe the focus should be on producing high quality code whereas project managers tend to emphasise the optimization of resources and time, whilst meeting the system requirements.
Wrapping up
The paper isn’t an easy read because of the wide use of sociological jargon, but then it is a research paper. The central idea – that online discussions can serve to construct or reinforce programmer and project manager identities – is an intriguing one. If true, it implies that one’s self (and projected) image influences, and is influenced by, how one describes oneself to others in speech or writing. For instance, does my claim that I’m a “seasoned database architect” and “experienced project manager” reinforce my professional identity? Also interesting is the idea that developer and project manager identities are often constructed in opposition to each other. That is, both parties appear to build their identities by casting the other in a negative light.
However, as interesting as all this is, I believe it misses a crucial point: that programmers and project managers, for the most part, play out roles which are defined and enforced by the organisations they work for. If organisational rules and norms require programmers (or project managers) to behave in dysfunctional ways, then that’s exactly what most of them will do. On the other hand, if an organisation encourages behaviour that fosters good working relationships between the two parties, things would be different: those working in such environments would have more positive experiences to to relate (this comment taken from one of threads analysed by the authors is a case in point). It is surprising that the authors chose not to include such (positive) comments in their analysis.
In brief: the paper presents an interesting perspective on the relationship between programmers and project managers. Even though the authors’ focus is somewhat limited, the paper is of potential interest to researchers and practitioners interested in work relationships in project environments.
Eight to Late 