Eight to Late

Sensemaking and Analytics for Organizations

Archive for November 2009

Reasons and rationales for not managing risks on IT projects – a paper review

with 7 comments


Anticipating and dealing with risks is an important part of managing projects. So much so that most frameworks and methodologies devote a fair bit of attention to risk management:  for example, the PMI framework considers risk management to be one of the nine “knowledge areas” of project management.  Now, frameworks and methodologies are normative– that is. they us how risks should be managed – but they don’t say anything about how are risks actually handled on projects.   It is perhaps too much  expect that all projects are run with  the full machinery of  formal risk management, but it is reasonable to  expect that most project managers deal with risks in some more or less systematic way.  However, project management lore is rife with stories of projects on which risks were managed inadequately, or not managed at all (see this post for some pertinent case studies).  This begs the question:  are there rational reasons for not managing risks on projects?    A paper by Elmar Kutsch and Mark Hall entitled, The Rational Choice of Not Applying Project Risk Management in Information Technology Projects,  addresses this question.   This post is a summary and review of the paper.


The paper begins with a brief overview of risk management as prescribed by various standards. Risk management is about making decisions in the face of uncertainty. To make the right decisions, project managers need to figure out which risks are the most significant. Consequently, most methodologies offer techniques to rank risks based on various criteria.  These techniques are based on many (rather strong) assumptions, which the authors summarise as follows:

  1. An unambiguous identification of the problem (or risk) including its cause
  2. Perfect information about all relevant variables that affect the risk.
  3. A model of the risk that incorporates the aforementioned variables.
  4. A complete list of possible approaches to tackle the risks.
  5. An unambiguous, quantitative and internally consistent measure for the outcomes of each approach.
  6. Perfect knowledge of the consequences of each approach.
  7. Availability of resources for the successful implementation of the chosen solution.
  8. The presence of rational decision-makers (i.e. folks free from cognitive bias for example)

Most formal methodologies assume the above to be “self-evidently correct” (note that some of them aren’t correct, see my  posts on cognitive biases as project meta-risks and the limitations of scoring methods in risk analysis for more). Anyway, regardless of the validity of the assumptions,  it is clear that achieving all the above would require a great deal of commitment, effort and money.    This, according to the authors,  provides a hint as to why many projects are run without formal risk management. In their words:

…despite the existence of a self-evidently correct process to manage  project risk, some evidence suggests that project managers feel restricted in applying such an “optimal” process to manage risks. For example, Lyons and Skitmore (2004) investigated factors limiting the implementation of risk management in Australian construction projects. Similar findings about the barriers of using risk management in three Hong Kong industries were found in a further prominent study by Tummala, Leung, Burchett, and Leung (1997). The most dominant factors for constraining the use of project risk management are the lack of time, the problem of justifying the effort into project risk management, and the lack of information required to quantify/qualify risk estimates.

The authors review the research literature to find other factors that could reduce the likelihood of risk management being applied in projects. Based on their findings, they suggest the following as reasons  that project managers often offer as  justifications (or rationales)  for not managing risks:

  1. The problem of hindsight: Most risk management methodologies rely on historical data to calculate probabilities of risk eventuation. However, many managers feel they cannot rely on such data for their specific (unique) project.
  2. The problem of ownership: Risks are often thought of as “someone else’s problem”. There is often a reluctance to take ownership of a risk because of the fear of blame in case the risk response fails to address the risk.
  3. The problem of cost justification: From the premises listed above it is clear that proper risk management is a time-consuming, effort-laden and expensive process. Many IT projects are run on tight budgets, and risk management is an area that’s perceived as being an unnecessary expense.
  4. Lack of expertise: Project managers might be unaware of risk management technique.  I find this hard to believe, given that practically all textbooks and methodologies yammer on,  at great length, about the importance of managing risks. Besides, it is a pretty weak justification!
  5. The problem of anxiety:  By definition, risk management implies that one is considering things that can go wrong.  Sometimes, when informed about risks, stakeholders may decide not to go ahead with a project. Consequently, project managers may limit their risk identification efforts in an attempt to avoid making stakeholders nervous.

When justifying the decision not to manage risks, the above factors are often presented as barriers or problems which prevent the project manager from using risk management. As an illustration of (5) above, a project manager might say, “I can’t talk about risks on my project because the sponsor will freak out and throw me out of his office.”

Research Method

The authors started with an exploratory study aimed at developing an understanding of the problem from the perspective of IT project managers – i.e. how project managers actually experience the application of risk management on their projects. This study was done through face-to-face interviews. Based on patterns that emerged from this study, the authors developed a web-based survey that was administered to a wider group of project managers. The exploratory phase involved eighteen project managers whereas the in-depth survey was completed by just over a hundred  project managers all of whom were members of the PMI Risk Management Special Interest Group. Although the paper doesn’t say so, I assume that project managers were asked questions in reference to a specific project they were involved in (perhaps the most recent one?).

I won’t dwell any more on the research methodology;  the paper has all the  details.

Results and interpretation

Four of the eighteen project managers interviewed in the exploratory study did not apply risk management processes on their projects. The reasons given were interpreted by the authors as cost justification, hindsight and anxiety. I’ve italicized the word “interpreted” in the previous sentence because I believe the responses given by the project managers could just as easily be interpreted another way. I’ve presented their arguments below so that readers can judge for themselves.

One interviewee mentioned that, “At the beginning, we had so much to do that no one gave a thought to tackling risks. It  simply did not happen.” The authors conclude that the rationale for not managing risks in this case is one of cost justification, the chain of logic being that due to the lack of time, investment of resources in managing risks was not justified. To me this seems to read too much into the response. From the response it appears to me that the real reason is exactly what the interviewee states –  “no one thought of managing risks” – i.e. risks were  overlooked.

Another interviewee stated, “It would have been nice to do it differently, but because we were quite vulnerable in terms of software development, and because most of that was driven by the States, we were never in a position to be proactive. The Americans would say “We got an update to that system and we just released it to you,” rather than telling us a week in advance that something was happening. We were never ahead enough to be able to plan.” The authors interpret the lack of risk management in the this case as being due to the problem of hindsight – i.e.  because the risk that an update poses to other parts of the system could not have been anticipated, no risk management was possible. To me this interpretation seems a little thin – surely, most project managers understand the risks that arbitrary updates pose. From the response it appears that the real reason was that the project manager was not able to plan ahead because he/she had no advance warning of updates. This seems more a problem of a broken project management process rather than anything to do with risk management or hindsight. My point: the uncertainty here was known (high probability of regular updates),  so something could (and should) have been done about it whilst planning the project.

I’ve dwelt on these examples because it appears that the authors may have occasionally fallen into the trap of pigeon holing interviewee responses into their predefined rationales (the ones discussed in the previous section)  instead of listening to what was actually being said.  Of course, my impression is based on a reading of the paper and the data presented therein. The authors may well have other (unpublished) information to support their classification of interviewee responses. However, if that is the case, they should have presented the data in the paper  because the reliability of the second survey  depends on the set of predefined rationales being comprehensive  and correct.

The authors present a short discussion of the second phase of their study. They find that no formal risk management processes were used in about one third of the 102 cases studied. As the authors point out, that in itself is an interesting statistic, especially considering the money at stake in typical IT projects. In cases where no risk management was applied, respondents were asked to provide reasons why this was so. The reasons given were extremely varied but, once again, the authors pigeon-holed these into their predefined categories. I present some of the original responses and interpretations below so that readers can judge for themselves.

Consider the following reasons that were offered (by respondents) for not applying risk management:

  1. We haven’t got time left.”
  2. No executive call for risk measurements.”
  3. Company doesn’t see the value in adding the additional cycles to a project.” (?)
  4. Upper management did not think it required it.”
  5. Ignorance that such a thing was necessary.”
  6. An initial risk analysis was done, but the PM did not bother to follow up.”
  7. A single risk identification workshop was held early in the project before my arrival. Reason for not following the process was most probably the attitude of the members of the team.”

Interestingly, the authors interpret all the above responses (and a few more ) as being attributable to the cost justification rationale. However, it seems to me that there could be several other (more likely) interpretations.  For example: 2, 3, 4, 5 could be attributed to a lack of knowledge about the value of managing risks whereas 1, 6, 7 sound more like simple (and unfortunately, rather common!)  buck-passing.


Towards the end of the paper   the authors make an excellent point about the  rationality of a decision not to apply risk management. From the perspective of formal methodoologies such a decision is irrational. However, rationality (or the lack of it) isn’t so cut and dried. Here’s what the authors say:

…a decision by an IT project manager not to apply project risk management may be described as irrational, at least if one accepts the premise that the project manager chose not to apply a “self-evidently” correct process to optimally reduce the impact of risk on the project outcome. On the other hand, … a person who focuses only on the statistical probability of threats and their impacts and ignores any other information would be truly irrational. Hence, a project manager would act sensibly by, for example, not applying project risk management because he or she rates the utility of not using project risk management as higher than the utility of confronting stakeholders with discomforting information….”

…or spending money to address issues that may not eventuate, for that matter. The point being  that people don’t make decisions based on prescribed processes and procedures alone; there are other considerations.

The authors then go on to say,

PMI and APM claim that through the systematic identification, analysis, and response to risk, project managers can achieve the planned project outcome. However, the findings show that in more than one-third of all projects, the effectiveness of project risk management is virtually nonexistent because no formal project risk management process was applied due to the problem of cost justification.

Now, although it is undeniable that many projects are run with no risk management whatsoever,  I’m not sure I agree with the last statement in the quote. From the data presented in the paper, it seems more likely that a lack of knowledge  and “buck-passing”  are the prime reasons  for risk management being given short shrift on the projects surveyed. Even if cost justification was  offered as a rationale by some  interviewees,  their quotes suggest that the real reasons were quite different. This isn’t surprising: it is but natural  to attribute to unacceptable costs that which should be attributed to oversight or failure.  I think this may be the case in a large number of projects on which risks aren’t managed. However,  as the authors mention, it is impossible to make any generalisations based on small samples .  So, although it is incontrovertible that there are a significant number of projects on which risks aren’t managed, why this is so remains an open question.

Written by K

November 25, 2009 at 11:07 pm

The user who wasn’t there: on the role of the imagined user in design discourse

with one comment


Users should be the centre of focus on projects as they are the ultimate beneficiaries (or sufferers) of the end-product. Given this, there should be frequent dialogue between the designers/creators of a product and those who will use it. Most project managers would accept the foregoing as an uncontroversial, even obvious, statement of the way things should be done. However, there is a potentially a gap between this and reality. In a fascinating case-study-based paper entitled, The imagined user in projects: Articulating competing discourses of space and knowledge work, Chris Ivory and Neil Alderman look at how, in project work, knowledge about users is often constructed without direct user input – i.e. is inferred, or even attributed without justification. This post is an annotated summary of their paper.

The paper is based on a case-study of a project that was aimed at redesigning office space for employees in a higher education environment. The contentious choice here – as one might imagine – is the one between an open-plan and cellular (individual office-based) design. In the paper Ivory and Alderman discuss how the notion of the imagined user is used (by designers, or even by management) to justify particular design choices.  To quote:

The paper builds a case for the role of the imagined user as a rhetorical device in the expression and enactment of discourses within projects. Our position stems from observations that, despite the rise and rise of user-centered and participative design, the user is most notable for his or her physical absence from the design process and that interaction with users is not one of simple knowledge-transfer, but one in which knowledge about users is constructed both with and without input from users. The creation and referencing of ‘imagined users’ is part of a persuasive process – imagined users are simplified caricatures that conveniently fit (or do not fit) the sorts of design solutions (in this case particular configurations of space) under discussion. This suggests the need to go beyond knowledge-transfer accounts of the role of the user in the design and project process and to acknowledge the social construction of imagined users in project interactions.

Users and the problem of knowledge transfer

Project management theory and practice emphasise the importance of users in projects. Users typically have a dual role: firstly, they provide input into design (through requirements) and improve the quality of design decisions; second, they test the product and validate that the project objectives have been met. It is the former process that Ivory and Alderman focus on:

Interest in user input as a corrective to poor design has led to a research focus on how best to expedite the interaction between users and designers; what might be termed a ‘knowledge transfer’ focus. This emphasises finding better ways of getting to know users’ contexts and encouraging users to maximise their understanding of what is technically and financially possible. Mechanisms identified for doing this include: user groups, usability trials, user surveys, direct user observation and, latterly, various web-based forums.

The authors contend that there are two problems with this “knowledge transfer based” approach:

  1. Those involved in seeking user input may view certain suggestions as being unnecessary or even undesirable. This could happen for a variety of reasons ranging from expediency to politics.
  2. The difficulty of capturing what the user really means is often underestimated.  In particular,  the difficulty of translating experience to words and the possibility of misinterpretation implies that it is difficult, if not impossible, to capture user requirements in a complete and objective manner. This is particularly true of implicit knowledge, and hence the vast literature on the problem of knowledge capture.

As a consequence, it is often easier for designers to make decisions based on their own knowledge and their perceptions of user needs. Ergo, the imagined user…

Imagined users

To understand the concept of the imagined user, let’s begin by looking at what the authors’ have to say:

The imagined user is a discursive construct, depending for its existence on the dialogue of those involved in the design process. Imagined users are conjured up in the form of vignettes and anecdotes based on personal and second-hand experience, assumptions and more or less reliable research data. The key role of the imagined user in design dialogue is to give substance and rhetorical force to competing discourses relevant to the design issues in question. Creating and drawing on imagined users effectively translates broader discourses into persuasive context-specific accounts of users and use. The design process is not just an exercise in trying to ‘get it right’; it is a forum for the expression of potentially conflicting cultural, economic, political, ideological and professional preferences.

The word ‘discursive’ refers to the idea that the imagined user emerges as a consequence of the dialogue between designers and users and designers and others. Through the course of the design discussions, a certain view of what was said  (or intended to be said) by users  is built-up by designers and managers,  regardless of whether or not it was actually said or intended. This view is the imagined user.

In introducing the idea of the imagined user, the authors highlight the role of discourse (dialogue, discussion and conversation) in shaping the direction that a project takes. In this connection it is important to note that discourse is often used as a means to exercise power – which could be hard power (as by management decree) or soft power  (as by convincing or persuading others through logic and/or rhetoric).

The role of politics

Project management research generally tends to disregard the activities and work  that occurs before “a project becomes a project.”  In contrast, Ivory and Alderman focus on :

“…interactions that occurred in the early planning and design phases of the project studied; the period when there was a commitment within the organisation to begin a capital project, but no firm or detailed decisions as to the precise form the project should take.”

Their point is that decisions made in these early stages can have a crucial effect on determining the subsequent course of the project. Many of these decisions are driven by politics rather than “real user” requirements. So one could even say that:

…the outcomes of projects reflect political processes and power struggles between stakeholders as much as the physical design decisions and actions of project manager.

This, I think, is a very insightful observation that may chime with the experience of project managers who have worked in politically charged environments.

The case study

The case study is based on interviews with senior management in a university department that was engaged in renovating office space for its staff. The contentious aspect of the design was the choice between an open-plan and cellular model. The initial idea was to go with an open-plan – justified on the basis of open communication being important in an academic environment – but this was later modified in the course of discussions with users. In the interviews, the authors elicited information on why the open-plan model was chosen first and then subsequently modified.

The authors analysed the interviews by grouping the points made for and against a particular design choice, and then linking these to the broader social and organisational context.

The history of the project is a bit involved so, to ensure that I get it right, I’ll quote directly from the paper:

The history of the project was long and convoluted, but centred around the perceived need to bring a split site department onto a single site, whilst improving the facilities for the teaching of its students. At an early stage, a key objective imposed by senior management of the University was for a substantial amount of open plan space to form the core of the design. Negative reaction and lobbying by user groups within the department led to an agreement for a limited number of cellular offices to be included, but nowhere near enough to guarantee each academic their own office.

The initial project proposal failed on planning grounds and the project was reconstituted through a proposal to lease commercial office space, with some re-configuration to suit educational use. This was attractive to senior management in that it enabled the project to be funded primarily out of fee revenue rather than appearing on the balance sheet as a capital expenditure.

The project sponsor drove the choice of a commercial lease and insisted on increasing the use of open plan space. He was supported by other members of the senior management team and the Estates department, which viewed the high cost of existing space as a major problem for the University. These actors had positive views of previous projects to create open plan working spaces, both for administrative functions and for research units. The case study project was the first to propose the same solution for a conventional teaching department.

The solution being pursued by the project sponsor was not universally supported amongst senior management and neither was their insistence on an open plan design. When they left the institution, just prior to the signing of contracts, the new project sponsor successfully sought additional funding to allow for an increase in the provision of cellular offices. The to-ing and fro-ing of the project process and the shifts in power within the project form the backdrop to our investigation of the discourses about academics as space users and knowledge workers.

With the description of the case study done, I now move on to the authors’ analysis of the competing positions based on their interviews.

Analysis of arguments

The arguments for open-plan

The arguments for an open-plan design can be summarised as follows:

  1. The rational economic choice: This argument was based on minimising cost and optimising space usage.  The interesting thing about this argument is that it is framed solely in terms of an organisational view –  user input, being considered irrelevant, is simply not solicited . As the authors put it:  “This discourse frames the issue of space solely in organisational terms. In effect the organisation assumes a priority over, and becomes a proxy for, all users. Consequently, any need for further discussion about the user is negated – the user effectively disappears (is unimagined)..”
  2. The inevitability of progress argument: This argument hinges on the premise that change is inevitable.  Managers who advocated this position drew upon other examples where open-plan offices were implemented, and were (presumably) successful.  Such arguments deem any concerns regarding the change as irrelevant, even pointless (after all, progress is good; change is inevitable).  In this case too, users are dealt with indirectly, by appealing to users in other environment who have, presumably, accepted the inevitability of progress.
  3. Constructing a fit between users and space: This argument focuses on presenting actual examples of situations where having an open plan was a benefit. For example, one user articulated his experience thus: “You could talk to people and my PA was sitting next to me more or less. And for the first time I could see there was an incredibly efficient way of getting things done. You can see people, you can walk over, you can get access to people, you get a lot more  communication…” Typically, though, most of these descriptions referred to administrative rather than academic work. The authors suggest that such “blurring of categories of work”  is sometimes used by designers to ignore input by real users – creating imagined users in the bargain.  Another project sponsor mentioned how an open plan would break academic silos and encourage people to talk to each other. Again, we see a recourse to an imagined user  who conforms to the stereotypical, uncommunicative academic.

Of course, real users who might disagree, present problems to those who wish to impose their own design choices. The authors discuss ways in which designers and managers seek to neutralise the opinions of such users. Some of the arguments presented included

  1. Resistant users lack self-knowledge: these arguments were based on the premise that users actually didn’t actually understand that open-plan offered a better working environment, and that once they did they would be fine with it.
  2. Resistant users are wrong: this needs no explanation!
  3. Resistant users are falsely claiming that they have unique requirements: This is best explained through an example. Academics might justify their claim to cellular offices because they need to concentrate on their work. Management could counter this claim by arguing that everyone, including office staff, need to concentrate, so there’s nothing special about academics.
  4. Resistant users are self-interested: These arguments were based on the logic that universities are there to serve students, not teacher; ergo, unreasonable demands (such as those for cellular offices) are immoral.
  5. Cellular offices are not used anyway! This argument was based on the observation that offices are unoccupied for 70% of the workday (presumably whilst they were teaching). So their claims to individual offices were unjustified

Basically, if one is going to take recourse to an imagined user, one has to be able to dismiss the opinions of real users!

The arguments against open-plan

The arguments against an open plan design included:

  1. Dismissing the claims of open-plan advocates: These hinged on arguments that advocates of open plan had weak arguments (such as “My mother used to work in an open-plan environment and she loved it”) or had personal agendas.
  2. Creating alternative views of how academic work is done:   One such view might be that academic work is different from administrative work;  it needs the peace and quiet afforded by a cellular office. Strangely, this  counter-argument was not offered by any of the stakeholders.  Instead, tenured academics (higher up in the hierarchy) offered the argument that contract researchers and administrators could go into open-plan because their work was “non-core”   (a euphemism for “not important”). Again we see an imagined user – one engaged in “unimportant” activities.
  3. “People are the organisation”: This is the converse of the rational view presented in the previous section. This argument centred on the premise that the academic staff are the organisation, and that a move to open-plan would destroy employee morale, thereby destroying the organisation in the bargain.  Here too there’s an implicit appeal to an imagined user – the exemplary, indispensable (tenured) academic who would be demoralised by the loss of his office and who may thus be forced to quit. Note that in this argument, other users – contract academics and support staff are imagined as being dispensable.

The authors note that the third argument won out in the end, as they state:

The idea that morale would be damaged in an organisation dependent upon academic support made the appropriateness of open plan or cellular offices irrelevant – the organisation would cease to function effectively if its staff withdrew their support. In this way we see how resistance to the perceived threat of open plan office accommodation on the part of academic staff was manifested through the threat ‘to take their bat home’. The possibility of staff choosing to work at home, rather than occupy the new open plan space, represented too much of a risk for the project in the eyes of some senior managers…

Wrapping up

So what can we take away from this paper?

The case study highlights the use of imagined users to justify specific design views and/or decisions in a specific project.  Both sides of the argument appealed to such users – stereotypes that seem plausible but might not actually exist. This strategy isn’t new,  soccer moms and Howard’s battlers being two examples from political discourse.

The authors find it surprising that none of the arguments offered (by either party) invoked the example of an academic engaged in research – an imagined user who might actually need the peace and quiet offered by a cellular office! They surmise that this may be because in the present day work is considered as (primarily) interactive and social. Ultimately the case against open plan was made by not talking about academic work, but by “selling out” other staff – i.e. simple politics.

Imagined users are often generalisations or composites based on real users, but can also be convenient fictions. However, as the authors note, “Discourses that imagine the user may well fly in the face of empirical evidence or be based largely on hearsay or anecdote, rather than the results of rigorous research, but are no less effective for all that.”   Those who run projects  need to be aware of the power and possibility of the user who wasn’t there, because arguments that invoke imaginary users can be effective rhetorical devices to get  projects moving in  specific  (but not always desirable!)   directions.

Written by K

November 15, 2009 at 10:13 pm

Project management in the post-bureaucratic organisation

with 17 comments


Over the last two decades or so, it has been recognized that creativity and innovation tend to thrive in organisations  where employees have a say in decisions that affect their work.  This has lead to the notion of a post-bureaucratic organisation –  an organisation in which decisions are made collectively through dialogue and consensus, and where  the hierarchy is flat.  Although a number of workgroups within large organizations function this way (and with some success too),  a post-bureaucratic organisation is generally seen as a utopian and academic ideal; one that is  unlikely to work in the real world. Those who manage  organizations, departments or workgroups  are generally uncomfortable with employees working autonomously,  even though this might lead to the generation of novel ideas and products.  This is understandable: it is ultimately the responsibility of managers to ensure that  organisational or departmental goals are achieved. How else to do this but through the time-tested command and control approach to management?

In response to the question posed above, project management is often touted as a means to manage creative and innovative efforts in organisations (see some of the articles in this issue of PM Network, for example).  The claim seems a reasonable one: project management (by definition) provides a means to manage  collective, goal oriented endeavours. Further, many projects – especially those involving  new product or software development – have a creative/innovative component. In practice, though, project management tends to be a bureaucratic affair;  involving plans that must be followed, schedules that must be adhered to and regular progress reports that must be made. Even so (or perhaps, because this is so) many organizations see project management as a means to manage all creative work in a post-bureaucratic setting.  Implicit in this view is the assumption that the implementation of project management processes will  enable managers to control and direct creative work without any adverse side-effects.  An article by Damian Hodgson entitled Project Work: The Legacy of Bureaucratic Control in the Post-Bureaucratic Organisation, explores the tensions and contradictions presented by this notion. Although the article was written a while ago (in 2003), I believe the ideas explored in it are ever more relevant today, particularly in view of the increasing projectisation of organisations and the work carried out within them.  Hence my motivation to  summarise and review  the paper.

Background – setting the stage

To be fair, many organizations recognise that a “light hand on the rudder” is needed in order to encourage creativity and innovation.  In these organisations, project management is often seen as a means to achieve this.  But  how well does it work in practice? Hodgson’s paper aims to provide some insight into this question via a case study of an organization in which a project-based form of management was implemented as a means to balance the  requirements of creativity and control. In his words:

In response to the challenges of the post-bureaucratic form, project management has  been put forward by many as a ‘tried-and-tested’ package of techniques able to cope with discontinuous work, expert labour and continuous and unpredictable change while delivering the levels of reliability and control of the traditional bureaucracy. In this article I explore some of the contradictions and tensions within a department where such a ‘hybrid’ mode of control is implemented, embodying both bureaucratic and post-bureaucratic logics. In particular, I focus upon the discursive tactics employed to sell ‘rebureaucratization’ as ‘debureaucratization’, and the complex employee responses to this initiative. I argue that the tensions evident here cast significant doubt on the feasibility of a seamless integration of bureaucracy and the post-bureaucratic [organization].

The “discursive tactics” that Hodgson mentions to are (seemingly reasonable and rational) arguments that an organization might use to “sell” the idea that the methods and approaches of project management are consistent with the ideals of a post-bureaucratic organization. An example of such an argument goes as follows: project management is routinely used to manage new product development projects, so it is eminently suited to managing creative work (Incidentally,  this isn’t quite right – see this paper review for more on why)

Post bureaucracy vs. bureaucracy

Before moving on, it is worth comparing the characteristics of bureaucratic and post-bureaucratic organizations. Hodgson provides the following comparison, based on the work of Charles Hekscher:

Bureacracy Post-bureaucracy
Consensus through Acquiescence to Authority Consensus through Institutionalized Dialogue
Influence based on Formal Position Influence through Persuasion/PersonalQualities
Internal Trust Immaterial High Need for Internal Trust
Emphasis on Rules and Regulations Emphasis on Organizational Mission
Information Monopolised at Top of Hierarchy Strategic Information shared in Organization
Focus on Rules for Conduct Focus on Principles Guiding Action
Fixed (and Clear) Decision Making Processes Fluid/Flexible Decision Making Processes
Network of Specialized FunctionalRelationships Communal Spirit/Friendship Groupings
Hierarchical Appraisal Open and Visible Peer Review Processes
Definite and Impermeable Boundaries Open and Permeable Boundaries
Objective Rules to ensure Equity of Treatment Broad Public Standards of Performance
Expectation of Constancy Expectation of Change

The aim of the case study is to highlight some of the inconsistencies and contradictions that result from applying a bureaucratic mechanism (project management) to manage the work of a group that was very good at doing creative work, but was used to a more free-wheeling, hands-off management style (i.e. a group which approximates the idealised post-bureaucratic environment described above).

Why project management?

Project management has its roots in classical management (ala Taylor and Fayol), so it is perhaps  surprising that it is considered as a means to manage work in a post-bureaucratic setting. In Hodgson’s words:

I would argue that what distinguishes project management as of particular relevance to 21stcentury organizations is its rediscovery of a very 19th-century preoccupation with comprehensive planning, linked to a belief in the necessity of tight managerial discipline.

Project management tools and techniques support managerial discipline by providing means to decompose the project into manageable bits – by using a WBS say – and then assigning these bits to individuals (or small teams). The work assigned can then be tracked and controlled tightly – which is a good thing.  If the matter rested there it wouldn’t be too bad, but very often management also prescibes how the work should be done. This level of control results in a loss of autonomy (and motivation)  for team members whose job it is to do the work. The loss of motivation can have negative effects, especially in projects with a large creative component.  To counter this criticism, in recent years project management has started to focus on the creative aspects of projects – what’s needed to motivate teams, how to foster creativity (in new product development work, say) etc. As Hodgson puts it,

The linking of project management and change management has increased project management’s influence across industries, such that now the largest professional organization in project management includes special interest groups in areas as diverse as healthcare, retail, media, marketing, and hospitality. As a consequence the last decade has been a time of particularly rapid expansion for project management, as issues of change, knowledge management, and constant innovation emerged as central themes in popular management discourse.

So, project management offers two (seemingly contradictory) benefits: the ability to maintain tight control of work and the ability to foster innovation and creativity:

…project management can be seen as an essentially bureaucratic system of control, based on the principles of visibility, predictability and accountability, and operationalized through the adherence to formalized procedure and constant written reporting mechanisms. At the same time, however, project management draws upon the rhetoric of empowerment, autonomy and self-reliance central… In principle, then, project management offers a system which attempts to integrate bureaucratic control and a form of responsible autonomy more in keeping with the interdisciplinary, knowledge-intensive nature of much project work in teams.

Seen in this light, it is perhaps not so surprising that project management is viewed as a means to manage creative work.

The case study

With the above background done, I now move on to a discussion of the case study.  In Hodgson’s words, the study:

…focused upon  a telephone bank in northern England which I have referred to under the pseudonym Buzzbank. In the late 1980s, Buzzbank had been set up by a major UK bank, which I will call TN Banking, and represented one of several success stories in the retail banking sector over this period. Through reduced overheads and the extensive use of new technology in the form of sophisticated marketing techniques and call-centre technology, Buzzbank had expanded rapidly in terms of market share and turnover, developing into a key component of TN Banking’s global operations. My interest in particular centred on Buzzbank senior management’s identification of project management as the prime ‘critical success factor’ for the organization; the development of project management expertise throughout the organization was seen as a key priority to maintain performance into the next decade. To an extent, the project teams researched could scarcely be more ‘cutting edge’, representing highly-trained ‘knowledge workers’ developing innovative high technology applications and solutions in a new sector of an enormously profitable industry

Hodgson conducted interviews and observed operations within the IT department of Buzzbank over a period of two years. During this period, the organization was implementing a “strategic plan” aimed at formalizing innovation and creative work using project management processes. The idea, in the words of a couple of senior IT managers was to “bring a level of discipline” and “bring an idea of professional structuring” to the work of the highly successful unit. The structuring and discipline was to be achieved by implementing project management processes.

The main rationale used to sell project management to the Buzzbank IT team is a familiar one: the need to ensure predictability and repeatability of work done whilst ensuring that innovation and creativity would not be impeded. Another justification offered by management was that the size of the organization (which had grown considerably in the years prior to the implementation of the strategic plan) meant that  the existing “ad-hoc” work culture would no longer be successful. That is,  the size of the organization necessitated a degree of formalization,  ergo bureaucratic procedures had to be put in place. This was rationalised  (by senior management) as a natural and inevitable consequence of growth:

…The organization was therefore portrayed by senior management in IT as approaching its ‘next stage of evolution’. The immediate benefit of such a metaphor for those members of senior management charged with rebureaucratizing the organization is that it carries a very strong sense of inevitability. As such, it casts opposition to such changes as irrational and futile, standing in the way of natural ‘evolution’.

Further, managers in the organization dubbed any employee resistance as “natural growing pains” – like those of an adolescent, say. Cast in this light, dissenting viewpoints were portrayed as natural and unavoidable – and possibly even necessary – but ultimately without any validity.

Another interesting aspect that Hodgson highlights is the way in which old practices (the successful but “bad” ones) were subsumed in the new (formal) framework. For example, in the old world, employees were given the freedom to experiment, and many considered this as a strength not a weakness. In the new world, however, such a practice was seen as a threat; it was considered more important to capture how to do things correctly so that things became repeatable (ala best practice) and experimentation would not be necessary. As one manager put it:

If we capture how we do things right, at least it makes things repeatable, and we can record the improvement required when things don’t go right, which doesn’t happen in a rapidly-expanding, gung-ho environment.

Hodgson notes that the terms rapidly-expanding and gung-ho, which are used in a negative sense, could just as well be cast in positive terms such as  flexible, proactive etc. The point being that management framed the existing situation in terms that made the implementation of the new procedures seem like a logical and reasonable next step. The processes were touted as a means to achieve change (i.e. be flexible), but in a controlled way. So, management went to great lengths to avoid use of terms that would be perceived as being negative – for example, the term “structure” was used instead of “bureaucracy” or “formalization.” In this way, management attempted to assimilate the existing values of Buzzbank into the strategic plan.

So, how well did it work? Here’s what Hodgson says about the end result:

The impression given [by senior management] was that of an organizational change which was inevitable, which gave rise to some understandable but irrational resistance, and which had now been effectively completed, for the good of the organization as a whole.

On the other hand, the impression Hodgson got from speaking to lower level employees was very different:

However, in the time spent by myself in the organization, the tone and target of much of the humour, as well as much stronger reactions, appeared to throw doubt on the extent to which this discourse had permeated among the general employees, particularly within the IT department. Humour was commonplace in the everyday banter both within teams and between teams in the IT division at Buzzbank, and the increasing levels of bureaucratization was the butt of most of the humour, particularly at the lower levels of the hierarchy. The main experience of project management as reported by many  Buzzbank employees was one of intensified bureaucratic surveillance

A key example is the reaction of employees to managerial jargon that was used in company circulars and literature intended to promote the strategic plan.

Typically, comments were provoked by the circulation of literature on the strategic plan, and again, excerpts of the document were read out by members of staff, adding ironic comments to underline the gap between the document and their experience of life and work in the department.

Hodgson notes that employees often appeared to comply with the new regulations, but not in the way intended by management:

At other times, the employees appeared to comply with the formal requirements of the new system, in terms of filling in the necessary forms, reporting in at given times, completing the necessary work-logs and so on. Even here, despite the relative sophistication of senior management’s re-articulation of key discourses, compliance on the part of Buzzbank employees in many cases bore all the hallmarks of instrumental behaviour, accompanied by insubordinate statements and humour ranging from the cynical to the confrontational. At other times, assurances were given to senior management and immediately contravened, fictionalized accounts of project activities were submitted late, or else procedures were observed meticulously to the detriment of deadlines and other constraints. The emergent organizational order was a precarious negotiation between alienated compliance and an autonomous disregard for bureaucratic demands…

In short: there was a clear gap between the perceptions of management and employees as to the success of the newly implemented processes.

It is clear that Buzzbank managers saw  project management as  a means to control and direct creative / innovative work in a way that would have no negative effect on employee morale and motivation.   The challenge, of course, lay in achieving employee buy-in.  Management used many creative (!) tactics to “sell” project management to staff. These included:

  1. References to a “natural process of evolution” and the consequent “growing pains” that the organization would experience. This made the pain of the change natural and inevitable, but necessary in the interest of future gain.
  2. Manipulation of terminology to make the changes seem more palatable – e.g. using the word “structure” instead of “formalization” or “bureaucracy”.
  3. Co-opting terminology of post-bureaucratic organizations into literature designed to promote the new structure. For example, claiming that project management processes would enable the organization to be even more responsive to change (i.e. flexible), through change management processes.

From employees’ perspective, such techniques were plainly seen for what they were: methods to “sell the unsellable”. The negative reactions of employees were manifested through sarcastic humour and (often minor) acts of insubordination. The case study thus highlights the difficulties in using project management as a means to control work in a post-bureaucratic work environment.

Wrapping-up: reflections and summary

Hodgson sees the case study as exemplifying the problem of control vs. autonomy in emerging post-bureaucratic organizations:  managers view project management as a means to address the risks inherent in post-bureaucratic work, whereas employees view it as a unnecessary and unjustified imposition. Management was looking for the “best of both worlds”, a hybrid model that incorporated the best elements of a post bureaucratic model and a traditional command and control approach. The case study casts doubt on whether such a hybrid is possible solely through the implementation standard project management techniques and processes. It does so by exposing some of the tensions and differences in perceptions that can occur when such a model is implemented.

So where does this leave managers? Is there a way to manage creative work without destroying employee morale and motivation?

Looking over the complaints of the Buzzbank employees, it is clear that most of the problems arose from the loss of autonomy that they had enjoyed prior to the implementation of the new processes. This being the case, any measure to increase autonomy should improve the situation. A couple of possibilities come to mind – both of which I have discussed in earlier pieces. These are:

  1. Empower employees to make decisions that affect their work. This means allowing them the freedom to decide the best approach to solving problems (within limits specified by organisational and resource constraints).
  2. In situations where (1) isn’t possible, one could use collaborative techniques such as dialogue mapping to achieve employee buy-in. Of course, management has to be prepared to engage in true dialogue, and be willing to act upon (reasonable) suggestions made by employees.

The key message is simple and obvious: the more of say employees have in making work-related decisions, the more engaged and motivated they’ll be. This is not just a warm and fuzzy notion, but one that is backed up by research on motivation (see this paper review, for example). Yes, this does mean letting go of the “reins of control” to an extent but it is clear, as highlighted by Hodgson’s work, that holding the reins tightly might cause more problems that it solves. What’s called for, above all, is a degree of flexibility:  use project management processes by all means, but be open to employee input as to what’s working well and what’s not.

To sum up:  Hodgson’s case study suggests that inflexible project management based approaches to managing creative work  may not work as well as advertised by purveyors of frameworks and methodologies. As an alternative,  it might be worth taking a step towards the utopian ideal of a post-bureaucratic organisation  by using techniques that encourage employee input in organisational decision making.

Written by K

November 6, 2009 at 10:06 pm

%d bloggers like this: