More than just talk: rational dialogue in project environments

Prologue

The meeting had been going on for a while but it was going nowhere.  Finally John came out and said it,  “There is no way I can do this in 2 days,” he said. “It will take me at least a week.”

There it was, the point of contention between the developer and his manager. Now that it was out in the open, the real work of meeting could begin; the two could start talking about a realistic delivery date.

The manager, let’s call him Jack, was not pleased, “Don’t tell me a simple two-page web app – which you have done several times before I should add – will take  you a week to do. ”

“OK, let me walk you through the details,” said John.

….and so it went for another half hour or so, Jack and John arguing about what would be a reasonable timeframe for completing the requested work.

Dialogue, rationality and action

Most developers, designers  and indeed most “doers” on project teams– would have had several conversations similar to the one above. These folks spend a fair bit of time  discussing matters relating to the projects they work on. In such discussions, the aim is to come to a shared understanding of the issue under discussion and  a shared commitment on future action.  In the remainder of this post I’ll take a look at project discussions from a somewhat  philosophical perspective, with a view to understanding some of the obstacles to open dialogue and how they can be addressed.

When we participate in discussions we want our views to be taken seriously. Consequently, we present our views through statements that we hope others will see as being rational – i.e. based on sound premises and logical thought.  One presumes that John – when he made his claim about the delivery date being unrealistic – was willing to present arguments that would convince Jack that this was indeed so. The point is that John is judged (by Jack and others in the meeting) based on the validity of the statements he (John) makes. When Jack’s  validity claims are contested, debate ensues with the aim of  getting to some kind of agreement.

The philosophy underlying such a process of discourse (which is simply another word for “debate” or “dialogue”)  is described in the theory of communicative rationality proposed by the German philosopher Jurgen Habermas.  The  basic premise of communicative rationality is that rationality (or reason) is tied to social interactions and dialogue. In other words, the exercise of reason can  occur only through dialogue.  Such communication, or mutual deliberation,  ought to result in a general agreement about the issues under discussion.  Only once such agreement is achieved can there be a consensus on actions that need to be taken.  Habermas refers to the  latter  as communicative action,  i.e.  action resulting from collective deliberation.

[Note: Just to be clear:  I have not read Habermas’ books, so my discussion is based entirely on secondary sources: papers by authors who have studied Habermas in detail. Incidentally, the Wikipedia article on the topic is  quite good, and well worth a read.]

Validity Claims

Since the objective in project discussions is to achieve shared understanding of issues and shared commitment on future action, one could say that such discussions are aimed at achieving communicative action.  The medium through which mutual understanding is achieved is speech – i.e.  through  statements that a speaker makes based on his or her perceptions of reality.  Others involved in the dialogue do the same,  conveying their perceptions (which may or may not match the speaker’s).

Now, statements made in discussions  have implicit or explicit validity claims – i.e. they express a speaker’s belief that something is true or valid, at least in the context of the dialogue.  Participants who disagree with a speaker are essentially contesting claims.  According to the theory of communicative action, every utterance makes the following validity claims:

1. It makes a claim about objective (or external) reality. John’s statement about the deadline being impossible refers to the timing of an objective event – the delivery of working software. Habermas refers to this as the truth claim.
2. It says something about social reality – that is, it expresses something about the relationship between the speaker and listener(s). The relationship is typically defined by social or workplace norms,  for example – the relationship between a manager and employee as in the case of John and Jack. John’s statement is an expression of disagreement with his manager.  Of course, he believes his position is justified – that it ought to take about a week to deliver the software. Habermas refers to this as the rightness claim.
3. It expresses something about subjective reality – that is, the speaker’s personal viewpoint. John believes, based on his experience, intutition etc., that the deadline is impossible. For communication to happen, Jack must work on the assumption that John is being honest – i.e. that John truly believes the deadline is impossible, even though Jack may not agree. Habermas refers to this as the truthfulness claim.

The validity claims and their relation to rationality are nicely summed up in the Wikipedia article on communicative rationality, and I quote:

By earnestly offering a speech act to another in communication, a speaker claims not only that what they say is true but also that it is normatively right and honest . Moreover, the speaker implicitly offers to justify these claims if challenged and justify them with reasons. Thus, if a speaker, when challenged, can offer no acceptable reasons for the normative framework they implied through the offering of a given speech act, that speech act would be unacceptable because it is irrational.

When John says that the task is going to take him a week, he implies that he can justify the statement (if required) in three ways:  it will take him a week (objective), that it ought to take him a week (normative – based on rightness)  and that he truly believes it will take him a week (subjective).

In all dialogues validity claims are implied, but rarely tested;  we usually take what people say at face value, we don’t ask them to justify their claims. Nevertheless, it is assumed that they can offer justifications should we ask them to. Naturally, we will do so only when we have reason to doubt the validity of what they say.  It is at that point that discourse begins. As Wener Ulrich puts it in this paper:

In everyday communication, the validity basis of speech is often treated as unproblematic. The purpose consists in exchanging information rather than in examining validity claims. None of the three validity claims is then made an explicit subject of discussion. It is sufficient for the partners to assume (or anticipate, as Habermas  likes to say) that speakers are prepared to substantiate their claims if asked to do so, and that it is at all times possible for the participants to switch to a different mode of communication in which one or several validity claims are actually tested. Only when validity claims do indeed become problematic, as one of the participants feels compelled to dispute either the speaker’s sincerity or the empirical and/or normative content of his statements, ordinary communication breaks down and discourse begins.

Progress in project discussions actually depends on such breakdown in “ordinary communication” – good project decisions emerge from open deliberation about the pros and cons of competing approaches. Only once this is done can one move to action.

Conditions for ideal discourse

All this sounds somewhat idealistic, and it is. Habermas noted five prerequisites for open debate. They are:

1. Inclusion: all affected parties should be included in the dialogue.
2. Autonomy: all participants should be able to present and criticise validity claims independently.
3. Empathy: participants must be willing to listen to and understand claims made by others.
4. Power neutrality: power differences (levels of authority) between participants should not affect the discussion.
5. Transparency: participants must not indulge in strategic actions (i.e. lying!).

In this paper Bent Flyvbjerg adds a sixth point:  that the group should be able to take as long as it needs to achieve consensus – Flyvbjerg calls this the requirement of unlimited time.

From this list it is clear that open discourse (or communicative rationality)  is an ideal that is difficult to achieve in practice.  Nevertheless, because  it is always possible to improve the quality of dialogue on projects, it behooves us as project professionals to strive towards the ideal. In the next section I’ll look at one practical way to do this.

Boundary judgements

Most times in discussions we jump straight to the point, without bothering to explain the assumptions that underpin our statements.  By glossing over assumptions, however, we leave ourselves open to being  misunderstood because  others have no means to assess the validity of our statements. Consequently it becomes difficult for them to empathise with us. For example, when John says that it is impossible to finish the work in less than a week, he ought to support his claim by stating the assumptions he makes and how these bear on his argument.  He may be assuming that he has to do the work in addition to all the other stuff he has on his plate.  On the other hand, he may be assuming too much because his manager may be willing to reassign the other stuff to someone else.   Unless this assumption is  brought out in the open, the two will continue to argue without reaching agreement.

Werner Ulrich pointed out that the  issue of tacit assumptions and unstated frameworks is essentially one of defining the boundaries within which one’s claims hold. He coined the term boundary judgement to describe  facts and norms that a speaker deems relevant to his or her statements. A boundary judgement determines the context within which a  statement holds and  also determines the range of validity of the statement.  For example, John is talking about the deadline being impossible in the context of his current work situation;  if the situation changed, so might his estimate.  Ulrich invented the notion of boundary critique to address this point. In essence, boundary critique is a way to uncover boundary judgements by asking the right questions. According to Ulrich, such boundary questions probe the assumptions made by various stakeholders. He classifies boundary questions into four categories. These are:

• Motivation: this includes questions such as:
  • Why are we doing this project?
  • Who are we doing it for?
  • How will we measure the benefits of the project once it is done?
• Power: this includes questions such as:
  • Who is the key decision-maker regarding scope?
  • What resources are controlled by the decision-maker?
  • What are the resources that cannot be controlled by the decision-maker (i.e. what are the relevant environmental factors)?
• Knowledge:  This includes:
  • What knowledge is needed to do this work?
  • Who (i.e which professionals) have this knowledge?
  • What are the key success factors – e.g. stakeholder consensus, management support, technical soundness etc?
• Legitimation: This includes:
  • Who are the stakeholders (including those that are indirectly affected by the project)?
  • How do we ensure that the interests of all stakeholders are taken into account?
  • How can  conflicting views of project objectives be reconciled?

The questions above are drawn from a paper by Ulrich.  I have paraphrased them in a way that makes sense in project environments.

Many of these questions are difficult to address openly, especially those relating to power and  legitimation. Answers to these often bump up against organisational politics or power. The point, however, is that once these questions are asked, such constraints become evident to all. Only after this happens can discourse proceed in the full knowledge of what is possible and what isn’t.

Before closing this section I’ll note that there are  other techniques that do essentially the same thing¹, but I won’t discuss them here as I’ve already exceeded a reasonable word count.

Conclusion

Someone recently mentioned to me that the problem in project meetings (and indeed any conversation) is that participants  see their own positions  as being rational, even when they are not.  Consequently, they stick to their views, even when faced with evidence to the contrary. According to the theory of communicative rationality, however, such folks aren’t being rational because they do not subject their positions and views to “trial by  argumentation”.  Rationality lies in  dialogue, not in individual statements or positions. A productive discussion is one in which validity claims are continually challenged until they converge on an optimal decision.  The best (or most rational) position  is  one that  emerges from such collective deliberation.

In closing, a caveat is in order – a complete discussion of dialogue in projects (or organisations) would take an entire book and more. My discussion here has merely highlighted a few issues (and a technique)  that I daresay are rarely touched upon in management texts or courses. There are many more tools and techniques that can help improve the quality of discourse within organisations.  Paul Culmsee and I discuss some of these in our book, The Heretic’s Guide to Best Practices.

Footnotes:

¹ Those familiar with soft systems methodology (SSM) will recognise the parallels between Ulrich’s approach and the CATWOE checklist of SSM. CATWOE is essentially a means of exposing boundary judgements.

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:

1. The assumption of objectivity leads to a false sense of security.
2. 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:

1. It is impossible, in principle, to compile authoritative lists of all possible risks.
2. Risks should be studied in the context of a particular project and its environment. This includes technical, social and organizational aspects of the environment.
3. 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.