Eight to Late

Sensemaking and Analytics for Organizations

Archive for the ‘Organizational Culture’ Category

Metaphors we argue by

with 11 comments

Introduction

In our professional lives we often come across people who have opinions  that differ from ours. If our views matter to us, we may attempt to influence such people by presenting reasons why we think our positions are better than theirs.  In response they will do the same, and so we have an argument: a debate or a discussion involving differing points of view.  The point of disagreement could be just about anything –a design, a business decision or even a company dinner menu.  In this post I  explore the idea that the dictionary meanings of the word “argument” do  not tell the whole story about what an argument actually is. In their classic work on conceptual metaphors, George Lakoff and Mark Johnson show how metaphors  influence the way we view and understand human experiences (such as arguments).  Below, I look at a few metaphors for argument and discuss how they influence our attitudes  to the act of arguing.

Argument as war

In the very first chapter of their book, Lakoff and Johnson use the metaphor argument is war to illustrate how arguments are often viewed, practiced and experienced. Consider the following statements:

  1. He attacked my idea.
  2. I defended my position.
  3. He countered my argument.
  4. I won the argument.

These statements – and others similar to them – are often used to describe the experience of arguing. They highlight the essentially adversarial nature of debate in our society. Lakoff and Johnson suggest that this metaphor colours the way we think about and approach arguments. This makes sense – just think about the negative emotions and confrontational attitudes that people bring to meetings in which contentious matters are discussed.

However,  it doesn’t have to be that way. Consider the following metaphor…

Argument as art

In a  post on collaborative knowledge creation, I discussed how a specific kind of argument – design discussion – can be seen as a act of collaborative knowledge creation. Al Selvin uses the term knowledge art to refer to this form of argument.  As he sees it, knowledge art is a marriage of the two forms of discourse that make up the term. On the one hand, we have knowledge which, “… in an organizational setting, can be thought of as what is needed to perform work; the tacit and explicit concepts, relationships, and rules that allow us to know how to do what we do.” On the other, we have art which “… is concerned with heightened expression, metaphor, crafting, emotion, nuance, creativity, meaning, purpose, beauty, rhythm, timbre, tone, immediacy, and connection.”

Design discussions can be no less contentious than other arguments – in fact often they are even more so.   Nevertheless, if participants view the process as one of creation, then their emphasis is on working together to craft an aesthetically pleasing and functional design. They would then be less concerned about being right (or proving the other wrong) than about contributing what they know to make the design better. Of course, the right environment has to be in place for people to be able to work together (and that is another story in itself!), but the important point here is that there are non-adversarial metaphors for arguments, which can lead to productive rather than point-scoring debates.

Note that this metaphor does not just apply to design discussions.  Consider the following statements, which could be used in the context of any kind of argument:

  1. His words were well crafted.
  2. His ideas gave us a new perspective.
  3. He expressed his views clearly.

Among other things these statements emphasise that arguments can be conducted in a respectful and non-confrontational manner.

Argument as cooperation

One of the features of productive arguments is the way in which participants work together to make contributions that make a coherent whole. Consider the following statements:

  1. His contribution was important.
  2. His ideas complemented mine.
  3. The discussion helped us reach a shared understanding of the issue.
  4. The discussion helped us achieve a consensus.

Although this metaphor is almost the opposite of the “argument as war,” it is not hard to see that, given the right conditions and environment, arguments can actually work this way. But even if the conditions are not right, use of words that allude to cooperation can itself have a positive effect on how the argument is viewed by participants. In this sense the metaphor we use to describe the act of arguing actually influences the way we argue.

Argument as journey

This metaphor, also from Lakoff and Johnson, draws on the similarities between a journey and a debate. Consider the following statements:

  1. He outlined his arguments step-by-step.
  2. I didn’t know where he was going with that idea.
  3. We are going around in circles.

Use of the “argument as journey” metaphor, sets the tone for gradual elaboration / understanding of issues as the argument unfolds. The emphasis here is on progress, as in a journey. Note that this metaphor complements the “argument as art” and “argument as cooperation” metaphors – creating a work of art can be likened to a journey and cooperation can be viewed as a collective journey. These are examples of what Lakoff and Johnson call coherent metaphors.

Argument as quest

In my view, the “argument as quest” metaphor is perhaps a particularly useful one, especially for collaborative design discussions. Consider the following statements:

  1. We explored our options.
  2. We looked for the best approach.
  3. We examined our assumptions.

This metaphor, together with the  one that views argument as as a cooperative process, capture the essence of what collaborative design should be.

In summary

The most common metaphor for argument is the first one – argument as war. It is no surprise, then, that arguments are generally viewed in a negative way. To see that this is so, one only has to look up synonyms for the word – some of these are: disagreement, bickering, fighting, altercation etc. Positive synonyms are harder to come by – exchange was the best I could find, but even that has a negative connotation in this context (an exchange of words rather than ideas).

In their book, Lakoff and Johnson speculate what the metaphor argument as dance might entail. Here’s what they have to say:

Imagine a culture where argument is viewed as a dance, the participants are seen as performers, and the goal is to perform in a balanced and aesthetically pleasing way. In such a culture, people would view arguments differently, experience them differently, carry them out differently and talk about them differently.

They conclude that we may not even see what they are doing as “arguing.” They would simply have a different mode of discourse from our  adversarial one.

Lakoff and Johnson tell us that metaphors influence the way we conceptualise and structure our experiences, attitudes and actions.  In this post I have discussed how different metaphors for the term argument lead to different views of and attitudes toward the act of arguing.  Now, I’m no philosopher nor am I a linguist, but it seems reasonable to me that the metaphors people use when talking about the act of arguing tell us quite a bit about the attitudes will assume in deliberations.

In short: the metaphors we argue by matter because they influence the way we argue.

Written by K

March 22, 2011 at 10:17 pm

Posted in Argumentation, Communication, Design Rationale, Knowledge Management, Organizational Culture

Tagged with

More than just talk: rational dialogue in project environments

with 20 comments

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 thing1, 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:

1 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.

Written by K

December 16, 2010 at 10:24 pm

Posted in Communication, Organizational Culture, Project Management

Tagged with , ,

A social constructionist perspective on software development projects

leave a comment »

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:

  1. Product development was organized according to a process that evolved over time rather than a best practice template.
  2. 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.
  3. The interviewees emphasized that they had well defined but narrow roles.

In addition, from other interviews it emerged that:

  1. 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.
  2. 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

« Older Entries
Newer Entries »