Posts Tagged ‘Social Constructionism’
On the social construction of IS project risks
Introduction
Most approaches to project risk management prescribe a structured approach to managing risks involving steps such as identification, analysis and response planning (see the PMBOK Guide, for example). Implicit in this approach is the assumption that risks exist “out there” and can be identified via systematic investigation. Among other things, this leads to a view that it is possible – and indeed, desirable – to identify all possible risks on a project, and then manage these through the lifecycle of a project. Of course, new risks may emerge, but the underlying belief is that these too can be identified and managed using a structured approach. In short, the fundamental assumption is that risks have an objective existence and can therefore be identified by an examination of the project and its environment.
In a paper entitled, The Limits of Risk Management – A Social Construction Approach, Bernd Stahl and co-authors argue that the traditional view of risk management is limited because:
- The assumption of objectivity leads to a false sense of security.
- It (often) ignores (or understates) risks that may be specific to certain organisations or situations.
Consequently, they suggest that it may be more fruitful to view risks as social constructs – perceptions of reality that are products of social interactions between stakeholders. In this post I explore this somewhat unusual view of risk. I’ll first illustrate the general idea of risk as social construct and then describe how some common IS project risks can be seen as social constructs. I’ll end with a brief look at the implications of this for project risk management.
Project risks as social constructs
The first step in classical (or standard) risk analysis is to identify all possible events that may affect the project. However this, in principle, is impossible because there is no general method to do so. Consequently, risk managers usually compile lists of potential risks (based on prior experience, research literature, textbooks, brainstorming etc.) and use these as starting points for analysis. The point is, all these methods are ad-hoc and, despite claims to the contrary, cannot guarantee a comprehensive coverage of all risks. This point is made very clearly in a paper by Lyytinen et. al. which examines four techniques of software project risk analysis and concludes that there are substantial differences between them. Quoting from the conclusion to the Lyytinen paper:
…practitioners should be cautious with regard to the expected miracles of any risk management approach. Risk management approaches are neither complete nor risk-proof (my italics). Their value in the context of managing complex socio-technical change is that they put high premium on shaping management attention through learning new organizing schemes that help make sense of the development situations in new ways…
According to Stahl, the conclusions of the Lyytinnen (and a few other researchers) support the idea that risk s is a social construct that comes about as a result of interactions and agreements between those involved in the project (and individual perceptions of these):
We believe that [the] objective concept of risk is flawed and threatens the success of the entire enterprise. A concept of objective risk raises the expectation that risks can be completely controlled. Also, it suggests that once the comprehensive list of risks is compiled, the end of the theoretical work is reached and managerial practice can take over. These factors can combine to create a false sense of security that will dull managers’ attention and can thereby create even bigger risks. We hold risk to be a social construction depending on social agreements and on individual perceptions. It must be ascribed to become real.
In my opinion there’s a big leap of logic in the above paragraph: I do not see how ”the expectation that risk can be completely controlled” and the “false sense of security this creates” implies that risk is a construct that depends on “social agreements and individual perceptions.” Nevertheless, I do believe that the social constructionist view of risk is useful because most project risks have a social dimension. I’ll elaborate on this point via examples in the next section.
IS project risk as a social construct – some examples
Most of the research literature on social construction tends to be hard to read and devoid of examples that professional project managers can relate to. This is a shame because much of this work casts a critical eye on the implicit assumptions that underlie project management practice. So, instead of quoting from and paraphrasing hard-to-read papers, I’ll illustrate how some common project risks have a social dimension.
The risks I consider are drawn from a paper entitled, Early warning signs of IT project failure: the dominant dozen, by Leon Kappelman and his co workers. The paper presents the top twelve early-stage project risks based on an analysis of data gathered from project professionals and a survey of research literature. I’ll discuss how four risks from Kappelman’s dominant dozen have social origins.
Lack of top management support
According to Kappelman et. al. this is the number one risk in IS projects. The point is that this risk most often arises because of (dysfunctional) politicking between managers. As Kappelman et. al. state :
In many cases, IT projects get caught up in enterprise politics where there are fundamental disagreements about overall enterprise priorities. In these cases the resources and enterprise-wide commitment required for success are lacking. Middle managers do not see the project as being important to the enterprise or to their performance evaluations and therefore redirect resources and attention to activities that top management does support.
The point is: this risk is often a consequence of corporate politics, which is very much a social construct.
Lack of stakeholder involvement and/or participation
The following passage from the paper highlights the socially constructed nature of this risk:
If key project stakeholders do not participate in major review meetings, it signals they are not engaged in the project and therefore the project is not a high priority for them. Other stakeholders soon begin to disengage too. The project manager then finds it harder to get the participation and resources necessary for project success, especially from those who are not full-time members of the project team. Often such project team members get reassigned to other projects that are perceived to be more important.
The point is – key stakeholders, through their influence in the organisation, can cause a project to go awry.
Another common situation is one in which stakeholders lose interest in a project because they do not see the benefits of being involved. This point is well-recognised in traditional risk management which highlights the importance of getting stakeholder buy-in. The point here is that this risk is a consequence of individual perceptions, not of objective reality. In other words, it is a social construct.
Lack of documented requirements and/or success criteria
This risk is an old classic, discussed and analysed by several well-known writers. As Robert Glass mentions in his book on the facts and fallacies of software engineering:
This problem is caused by the fact that the customers and users for the software solution are not really sure of what problem they need to have solved. They may think they know at the outset, only to discover as the project proceeds that the problem they wanted to solve is too simplistic or unrealistic or something else they weren’t expecting. Or they may really not know anything at the outset and are simply exploring solutions to a vague problem they know needs to be solved….
Regardless of the causes or the outcome, the point is that Ill defined scope means that different stakeholders have different interpretations of what’s to be delivered. Consequently, project objectives become a matter of interpretation and opinion. This shows how even something as basic as project objectives are actually social constructs – they depend on individual stakeholder perceptions. Seen in this light it isn’t a stretch to say that there can be as many objectives as there are stakeholders!
Communication breakdown among stakeholders
This risk is perhaps the most obvious social construct – communication is not only the lifeblood of a project, it is also the basis on which professional and social relationships are built. Communication becomes all the more important on projects environments where diverse stakeholders and ongoing change are the norm. As Kappelman et. al. state:
Any significant project has multiple stakeholders and requires an ongoing choreography of various tasks and resources. Change over the life of the project is inevitable — business environment, competitor strategic and tactical moves, laws and regulations, management team, staff turnover, resource availability, and cost — to name just a few possibilities. If all stakeholders do not communicate and work together on an ongoing basis, the project team will be pulled in multiple directions…
Communication breakdowns can occur for a variety reasons, but most of these arise because of conflicting viewpoints of those involved. As I have written in a post on project communication, “A shared world-view – which includes a common understanding of tools, terminology, culture, politics etc. – is what enables effective communication within a group.”
Implications
The above examples show how common project risks have a social dimension, even if they are not entirely social constructs. The social aspects of risk are often ignored because they are hard to handle – it is much easier to follow a process than to deal with stakeholders who are (or might get) upset. Consequently risks such as communication breakdown or lack of management support are not broached because of the high cost of speaking up. I contend that many project risks remain unaddressed because of this.
The implications of a social constructionist view of risk can be summed up as follows:
- It is impossible, in principle, to compile authoritative lists of all possible risks.
- Risks should be studied in the context of a particular project and its environment. This includes technical, social and organizational aspects of the environment.
- Particular emphasis should be given to relationships between stakeholders as these may present barriers to an honest assessment of risks.
These implications suggest that a participatory approach involving open deliberation is mandatory for successful risk management. As Stahl et. al. put it:
Indeed, a checklist of risks is just a starting point for an ongoing debate on risk. Management should identify the stakeholder of risky decisions and engage in a free discourse about the nature and the evaluation of risks. The stakeholder discourse could be used to define responsibilities . The stakeholders as parties interested in the process are presumably best suited to identify risk factors. Ideally this process would lead to a consensus concerning the risks. Similar approaches have been suggested in the literature, however, we wish to emphasise that only when managers understand that risk is a social construct will the complex and costly process of stakeholder discourses as a way of dealing with risk make sense (my italics).
Summing up
The mathematical and analytical machinery of risk management can obscure the fact that managing risks is as much an art as a science, calling for skills in dealing with people as well as probabilities. Organisational politics, individual perceptions and interactions between different stakeholder groups play a role in creating risks. In other words, risks are not objective entities, they have a social dimension.
Written by K
December 2, 2010 at 5:33 am
Posted in Corporate IT, IT Management, Paper Review, Project Management, Risk analysis
Tagged with Social Constructionism
A social constructionist perspective on software development projects
Introduction
Many new product development (NPD) projects are subject to unpredictable effects which can be hard to control. Examples of these include: requirements changes, changes in personnel, shifting business needs etc. Moreover, in the early stages of projects, there is often a great deal of uncertainty as to what exactly needs to be done. Many project management methodologies tend to conceptualise NPD projects as well defined efforts that can be decomposed into discrete tasks which can then be planned and directed (see this paper review, for example). This conceptualization – or more correctly, assumption – accords software development projects a solidity and certainty that they do not have. In a paper entitled, Towards a (more) critical and social constructionist approach to new product development projects, Beata Segercrantz looks into how NPD projects – specifically, software development projects – can be viewed usefully as entities that emerge from relationships and interactions between various project stakeholders. This post is a review of the paper.
Segercrantz views NPD projects as constructed by discourse – i.e. through dialogue and interactions between all stakeholders. In sociology this is termed as a constructionist view, one in which knowledge of an entity (in this case, a project) and the identities of those involved in or with it (the stakeholders) is seen as being produced through conversations and interactions between those involved in creating the entity. This approach necessarily results in multiple views, reflecting the that reality no two stakeholders will have the same conception of the project. In such a view, voices that are marginalized by the traditional project-as-well-defined-entity view are given equal air time. This is useful because it can unearth viewpoints and insights that would otherwise be missed.
Background
The best known NPD methodology is the Stage-Gate approach, which views the product development process as moving through Scoping, Build Business Case, Development, Testing and Validation and Launch. The stages of discovery and post-launch review are considered to be outside the traditional stage-gate model. Although recent references on the methodology emphasise its flexibility and customizability (see this paper, for instance), it remains at heart a process-based approach to NPD. Segercrantz draws attention to research which suggests that the stage-gate approach, with its early lock-in of product definition, may be too constraining for technology projects, which tend to take place in highly changeable environments (see this paper, for example). More flexible approaches involving overlapping stages which, in effect, allow changes to product definition at later stages are necessary. But these dilute the benefits of the stage-gate approach, the main loss being certainty of commitments and the costs that go with it.
The problem with mainstream NPD methodologies is that they are too prescriptive (whilst claiming to be flexible). Further, in areas where flexibility is claimed, they actually end up delegating much of the management detail to other, unspecified project management processes. This gives the illusion of flexibility. Further – and more important, in my opinion – is that they do not address the process of discovery. They only address what comes after. This, of course, would be a problem for any process because it is impossible to prescribe a method that would lead to useful discoveries. However, this is a shortcoming that isn’t entirely clear in accounts that describe popular NPD methodologies.
Mainstream NPD methodologies focus on reducing product development costs and time to market, whilst ensuring product quality. Their preoccupations, quite naturally, are all about specifying the processes that will enable organisations to achieve these goals. Their approach is, also quite naturally, rational. However, such an approach, which focuses on best practice and standardization ignores the human element. To quote from the paper,
…much mainstream NPD literature presupposes that improved models of NPD processes and projects are likely to lead to progress. Through increased empirical knowledge about different characteristics of NPD, it is assumed that structures of the world, including NPD, can be found; structures that leave little space for margins or deviation from rules of reason. Only increased precise predictions are assumed to produce effective NPD projects and formulating the predictions requires ‘finding’ a single best account or sometimes a limited number of related accounts. The prescriptive accounts in mainstream NPD models, however, pay little attention to various consequences of the models on individuals… Complex ways in which individuals respond to dominant discourses of organizations seem to be under-explored…
Segercrantz’s research is aimed at exploring some of the human elements of NPD projects, specifically how certain voices are shut out of the decision making process thus precluding some outcomes that could otherwise have occurred.
Projects – from being to becoming
In the traditional view, a project is seen as a well-defined organizational entity that has an existence independent of the people who work on it. Real-world interactions between people (the real organisation, if you will) are considered to be secondary. This view is cart-before-horse because, in reality, the project is a consequence of organizing (by the people who comprise the project). So, projects do not have an independent existence, they are brought into being by a process of organizing – i.e. they are socially constructed.
To understand how relationships and interactions create projects, one has to move beyond the traditional view. As Segercrantz puts it,
…our attention shifts towards complex social processes that software product development experts engage in; the interactions and relational processes that take place between them. Through these processes, projects are socially constructed and come into existence as they are attributed with specific meanings. How the product development processes interactively unfold and construct certain shared understanding of NPD and not others are emphasized. These actions are continuous and thus meanings attributed to projects are more or less constantly modified as the actors participate in NPD. Meanings are therefore always in a state of becoming, never fixed, and should be understood as primarily culturally and historically specific. In sum, by engaging in certain process, actors seek to construct stabilized meanings of NPD but, simultaneously, as they participate in these projects various meanings are modified…
To develop a social constructionist view, one has to rely on discourse analysis, which essentially entails understanding what people actually say and do, rather than what they ought to be saying and doing. The point is, what people actually say and do on a specific project to a large extent defines what the project is and how it is to work on it. Further, it is also important to note that certain discursive possibilities are excluded because not everyone on the project is equal – some voices are marginalized because of their subordinate position in the project and/or organisational hierarchy.
So, where do traditional NPD methodologies fit in the discursive scheme of things? Segercrantz suggests that NPD processes and procedures should be seen as discursive templates which can be used as starting points from which one can develop new ways of understanding and running specific projects. This is the reality anyway, because best practices are almost always hacked up to suit specific organizational and project needs. Moreover, the changes needed are most often decided via social interactions – i.e. discourse.
The method
Best practices and methodologies presume there is a right way to do things. Consequently, studies that focus on these tend to give more weight to opinions that support the practice/methodology whilst ignoring contrary views. One of the key benefits of discourse analysis is that it can expose some of these hidden views. In the best case, this can offer up new possibilities for how NPD projects can be run. In Segercrantz’s words:
By unmasking the becoming of certain effects, we can produce new alternatives for the future. This objective sharply contrast to much mainstream NPD literature, which typically aims at formulating one or limited prescriptive options for the future to produce preferred effects.
Segercrantz mentions the difference between critical and analytical approaches to discourse analysis: the former views interactions through the lens of political/social power relationships (i.e. they assume certain stakeholders are more powerful than others) whereas the latter make no such assumptions. The approaches are not mutually exclusive, both can and should be used in discursive studies. Segercrantz uses both approaches: the former to make inferences from the data she gathers and the latter to interpret data in terms of power relationships.
The raw data for the study consisted of over 80 interviews with professionals working in Finnish software companies. In the paper, Segercrantz provides illustrative examples of data drawn from interviews with 6 development professionals within a single company. She notes that when analyzing the data, she initially made no assumptions about relationships (i.e. she used an analytical approach) and made inferences about different organizing patterns based on the data alone. After that, she examined power relations using a critical approach.
The case study
The software company studied was continually engaged in NPD projects. Segercrantz sought the views of development professionals within the organisations. Here’s what one of them had to say:
The process, according to my view, began as the person who is pulling the strings, the major guru, who sort of leads the product development, he has a long history, he has seen many products, he has even seen many versions of this product [under development], that is, of financial portfolio systems. He has seen many financial portfolio system products and systems related to them. Based on this experience he has probably during the years developed a vision and he also happens to be, let’s say quite an intelligent person. Somehow he can keep all these things in his head, it helps. And then he probably got a green light from someone to begin developing his idea. In my view, it has been lead from one head. … Each [team member] has had a very narrow scope in it [the NPD project]. One hasn’t let them intervene in everything. Instead they have been, well, let’s say that their scope has been kept narrow with dictatorial means. It is maybe doubtful in a social sense, but on the other hand it has given good results. That is, a product has been created. And if you would start messing a lot outside your own scope, then you would suffocate very soon. It has worked in this case. Perhaps everyone has respected it. There has been a leadership style that is efficient in my opinion.
Several interesting points emerge from the above:
- Product development was organized according to a process that evolved over time rather than a best practice template.
- The project leader was in a position of power, and was portrayed as (or constructed as) a “major guru ” hence legitimizing his right to decree how things should be done and who should do them. Implicitly, the others were portrayed as having less experience and knowledge, and their opinions could thus be ignored.
- The interviewees emphasized that they had well defined but narrow roles.
In addition, from other interviews it emerged that:
- The interviewees were in positions where they had to comply with rules set from those higher up in the hierarchy, but they also had to set direction and delegate to those who were below them.
- The delegation process had a political aspect to it: delegating work to others also involved convincing them to do it in a prescribed way, following certain rules. This wasn’t a straightforward process. This was the cause of a fair bit of stress.
Segercrantz makes the point that the NPD model shaped and used by the leader served as a discursive template via which others in the project interpreted their experiences and roles. This can be seen as an exercise of positional power. In contrast, the others took up “narrowly defined subject positions offered in discourse and were ‘locked’ into a structure of rights (and obligations) that addressed them as ‘communicators’ and instruction-followers.” However, although the project was run “dictatorially”, the others were able to (had to!) modify (customize) the template in order to get the job done. Some of them also made sense of (or rationalized) their positions within the project and firm via the template , even though they felt disempowered. As Segercrantz states:
The interviewee cited in the beginning of this section seems to dis-identify with the subject positions offered through the seemingly institutionalized ‘dictatorial’ ways of organizing projects. However, he still performed his obligations and even defended the practices by claiming ‘it has given good results’ and ‘there has been a leadership style that is efficient’, thus legitimizing the relations of power. In contrast, another interviewee explicitly seemed to identify, at least in certain local conditions, with the subject positions offered; working under time pressure functioned as an important means through which he was constructed as ‘a person who is needed by the company
Conclusion
The paper puts forward a very interesting perspective on how projects can be viewed as socially constructed. Seen in this light, projects don’t have an existence independent of the people and relationships that comprise them. This questions the universality of popular approaches to project management, all of which assume that the project is an organisational entity that can be managed via standardised processes that pay scant attention to human relationships. That said, I found the case study very disappointing because it is too limited, and does not make a convincing case for the validity of the theoretical framework proposed. Thus, in my opinion, the value of the study lies in the questions it raises, not those that it answers.
Written by K
November 11, 2010 at 10:40 pm
Posted in Communication, Corporate IT, Organizational Culture, Paper Review, Project Management
Tagged with Social Constructionism
Eight to Late 