Archive for the ‘People Management’ Category
Groupthink in project environments
Introduction
Groupthink refers to the tendency of members of a group to think alike because of peer pressure and insulation from external opinions. The term was coined by the psychologist Irving Janis in 1972. In a recent paper entitled, Groupthink in Temporary Organizations, Markus Hallgren looks at how groupthink manifests itself in temporary organisations and what can be done to minimize it. This post, which is based on Hallgren’s paper and some of the references therein, discusses the following aspects of groupthink:
- Characteristics of groups prone to groupthink.
- Symptoms of groupthink.
- Ways to address it.
As we’ll see, Hallgren’s discussion of groupthink is particularly relevant for those who work in project environments.
Background
Hallgren uses a fascinating case study to illustrate how groupthink contributes to poor decision-making in temporary organisations: he analyses events that occurred in the ill-fated 1996 Everest Expedition. The expedition has been extensively analysed by a number of authors and, as Hallgren puts it:
Together, the survivors’ descriptions and the academic analysis have provided a unique setting for studying a temporary organization. Examining expeditions is useful to our understanding of temporary organizations because it represents the outer boundary of what is possible. Among the features claimed to be a part of the 1996 tragedy’s explanation are the group dynamics and organizational structure of the expeditions. These have been examined across various parameters including leadership, goal setting, and learning. They all seem to point back to the group processes and the fact that no one interfered with the soon-to-be fatal process which can result from groupthink.
Mountaineering expeditions are temporary organisations: they are time-bound activities which are directed towards achieving a well-defined objective using pre-specified resources. As such, they are planned as projects are, and although the tools used in “executing” the work of climbing are different from those used in most projects, essential similarities remain. For example, both require effective teamwork and communication for successful execution. One aspect of this is the need for team members to be able to speak up about potential problems or take unpopular positions without fear of being ostracized by the group.
Some characteristics of groups that are prone to groupthink are:
- A tightly knit group.
- Insulation from external input.
- Leaders who promote their own preferred solutions (what’s sometimes called promotional leadership)
- Lack of clear decision-making process
- Homogenous composition of group.
Additional, external factors that can contribute to groupthink are:
- Presence of an external threat.
- Members (and particularly, influential members) have low self-esteem because of previous failures in similar situations.
Next we’ll take a brief look at how groups involved in the expedition displayed the above characteristics and how these are also relevant to project teams.
Groupthink in the 1996 Everest Expedition and its relevance to project teams
Much has been written about the ill-fated expedition, the most well-known account being Jon Krakauer’s best-selling book, Into Thin Air. As Hallgren points out, the downside of having a popular exposition is that analyses tend to focus on the account presented in it, to the exclusion of others. Most of these accounts, however, focus on the events themselves rather than the context and organizational structure in which they occur. In contrast, Hallgren’s interest is in the latter – the context, hierarchy and the role played by these in supporting groupthink. Below I outline the connections he makes between organizational features and groupthink characteristics as they manifested themselves on the expedition. Following Hallgren, I also point out how these are relevant to project environments.
Highly cohesive group
The members of the expedition were keen on getting to the summit because of the time and money they had individually invested in it. This shared goal lead to a fair degree of cohesion within the group, and possibly caused warnings signs to be ignored and assumptions rationalized. Similarly, project team members have a fair degree of cohesion because of their shared (project) goals.
Insulation from external input
The climbing teams were isolated from each other. As a result there was little communication between them. This was exacerbated by the fact that only team leaders were equipped with communication devices. A similar situation occurs on projects where there is little input from people external to the project, other teams working on similar projects or even “lessons learned” documents from prior projects. Often the project manager takes on the responsibility for communication, further insulating team members from external input.
Promotional leadership
Group leaders on the expedition had a commercial interest in getting as many clients as possible to the summit. This may have caused them to downplay risks and push clients harder than they should have. This is similar to situations in projects which are seen as the “making of project managers.” The pressure to succeed can cause project managers to display promotional leadership.
Lack of clear decision making process
All decisions on the expedition were made by group leaders. Although this may have been necessary because group members lacked mountaineering expertise, decisions were not communicated in a timely manner (this is related to the point about insulation of groups) and there was no clear advice to groups about when they should turn back. This situation is similar to projects in which decisions are made on an ad-hoc basis, without adequate consultation or discussion with those who have the relevant expertise. Ideally, decision-making should be a collaborative process, involving all those who have a stake in its outcome.
Homogeneous composition of group
Expedition members came from similar backgrounds – folks who had the wherewithal to pay for an opportunity to get to the summit. Consequently, they were all highly motivated to succeed (related to the point about cohesion). Similarly, project teams are often composed of highly motivated individuals (albeit, drawn from different disciplines). The shared motivation to succeed can lead to difficulties being glossed over and risks ignored.
External threat
The expedition was one of many commercial expeditions on the mountain at that time. This caused an “us versus them” mentality, which lead to risky decisions being made. In much the similar way, pressure from competitors (or even project sponsors) can cloud a project manager’s judgement, leading to poor decisions regarding project scope and timing.
Low self esteem
Expedition leaders were keen to prove themselves because of previous failures in getting clients to the summit. This may have lead to a single-minded pursuit of succeeding this time. A similar situation can occur in projects where managers use the project as a means to build their credibility and self-esteem.
Symptoms and solutions
The above illustrates how project teams can exhibit characteristics of groups prone to groupthink. Hallgren’s case study highlights that temporary organisations – be they mountaineering expeditions or projects – can unwittingly encourage groupthink because of their time-bound, goal-focused nature.
Given this, it is useful for those involved in projects to be aware of some of the warning signs to watch for. Janis identified the following symptoms of groupthink:
- Group members feel that they are invulnerable
- Warnings that challenge the groups assumptions are rationalized or ignored.
- Unquestioned belief in the group’s mission..
- Negative stereotyping of those outside the group.
- Pressure on group members to conform.
- Group members self-censor thoughts that contradict the group’s core beliefs.
- There is an illusion of unanimity because no dissenting opinions are articulated.
- Group leaders take on the role of “mind-guards” – i.e. they “shield” the group from dissenting ideas and opinions.
Regardless of the different contexts in which groupthink can occur, there are some stock-standard ways of avoiding it. These are:
- Brainstorm all alternatives.
- Play the devil’s advocate – consider scenarios contrary to those popular within the group.
- Avoid prejudicing team members’ opinions. For example, do not let managers express their opinions first.
- Bring in external experts.
- Discuss ideas independently with people outside the group.
Though this advice (also due to Janis) has been around for a while, and is well-known, groupthink remains alive and well in project environments; see my post on the role of cognitive biases in project failure for examples of high-profile projects that fell victim to it.
Conclusion
Hallgren’s case study is an excellent account of the genesis and consequences of groupthink in a temporary organisation. Although his example is extreme, the generalizations he makes from it hold lessons for all project managers and leaders. Like the Everest expedition, projects are invariably run under tight time and budgetary constraints. This can give rise to conditions that breed groupthink. The best way to avoid groupthink is to keep an open mind and encourage dissenting opinions – easier said than done, but the consequences of not doing so can be extreme.
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.
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 