Archive for the ‘Organizational Culture’ Category
A new perspective on risk analysis in projects
Introduction
Projects are, by definition, unique endeavours. Hence it is important that project risks be analysed and managed in a systematic manner. Traditionally, risk analysis in projects – or any other area – focuses on external events. In a recent paper entitled, The Pathogen Construct in Risk Analysis, published in the September 2008 issue of the Project Management Journal, Jerry Busby and Hongliang Zhang articulate a fresh perspective on risk analysis in projects. They argue that the analysis of external threats should be complemented by an understanding of how internal decisions and organisational structures affect risks. What’s really novel, though, is their use of metaphor: they characterise these internal sources of risk as pathogens. Below I explore their arguments via an annotated summary of their paper.
What’s a risk pathogen?
“Risk,” the authors state, “is a statistical concept of events that happen to someone or something.” Traditional risk analysis concerns itself with identifying risks, determining the probability of their occurrence, and finding ways of dealing with them. Risks are typically considered to be events that are external to an organisation. This approach has its limitations because it does not explicitly take into account the deficiencies and strengths of the organisation. For example, a project may be subject to risk due to the use of an unproven technology. When the risk becomes obvious, one has to ask why that particular technology was chosen. There could be several reasons for this, each obviously flawed only in hindsight. Some reasons may be: a faulty technology selection process, over optimism, decision makers’ fascination with new technology or some other internal predisposition. Whatever the case, the “onditions that lead to the choice of technology existed prior to the event that triggered the failure. The authors label such preexisting conditions pathogens. In the authors’ words, “At certain times, external circumstances combine with ‘resident pathogens’ to overcome a system’s defences and bring about its breakdown. The defining aspect of these metaphorical pathogens is that they predate the conditions that trigger the breakdown, and are generally more stable and observable.”
It should be noted that the pathogen tag is subjective – that is, one party might view a certain organisational predisposition as pathogenic whereas another might view it as protective. To illustrate using the above example – management might view a technology as unproven, whereas developers might view it as offering the company a head start in a new area. Perceptions determine how a “risk” is viewed: different groups will select particular risks for attention, depending on the cultural affiliations, background, experience and training. Seen in this light, the subjectivity of the pathogen label is reasonable, if not obvious. In the paper, the authors examine risk pathogens in projectised organisations, with particular focus on the subjectivity of the label (i.e. different perceptions of what is pathogenic). Why is this important? The authors note that in their studies, “the most insidious kind of risk to a project – the least well understood and potentially the most difficult to manage if materialised – was the kind that involved contradictory interpretations.” These contradictory interpretations must be recognised and addressed by risk analysis; else they will come in the way of dealing with risks that become reality.
The authors use a case study based approach, using a mix of projects drawn from UK and China. In order to accentuate the differences between pathogenic and protective perspectives of “pathogens”, the selected projects had both public and private sector involvement. In each of the projects, the following criteria were used to identify pathogens. A pathogen
- Is the cause of an identifiable adverse organisational effect.
- Is created by social actors – it should not be an intrinsic vulnerability such as a contract or practice.
- Exists prior to the problem – i.e. it predates the triggering event.
- Becomes a problem (or is identified as a problem) only after the triggering event.
The authors claim that in all cases studied, the pathogen was easily identifiable. Further it was also easy to identify contradictory interpretations (protective behaviour) made by other parties. As an example, in a government benefits card project, the formulation of requirements was done only at a high-level (pathogen). The project could not be planned properly as a consequence (triggering event). This lead to poor developer performance and time/cost overruns (effect). The ostensible reason for doing requirements only at a high-level was to save time and cost in the bidding process (protective interpretation). Another protective interpretation was that detailed requirements would strait-jacket the development team and preclude innovation. Note that the adaptive (or protective) interpretation refers to a risk other than the one that actually occurred. This is true of all the examples listed by the authors – in all cases the alternate interpretation refers to a risk other than the one that occurred, implying that the risk that actually occurred was somehow overlooked or ignored in the original risk analysis. It is interesting to explore why this happens, so I’ll jump straight to the analysis and discussion, referring the reader to the paper for further details on the case studies.
Analysis and Discussion
From an analysis of their data, the authors suggest three reasons why a practice that is seen as adaptive, might actually end up being pathogenic:
- Risks change with time, and managing risk at one time cannot be separated from managing it at another. For example, a limited-scale pilot project may be done on a shoestring budget (to save cost). A successful pilot may be seen as protective in the sense that it increases confidence that the project is feasible. However, because of the limited scope of the pilot, it may overlook certain risks that are triggered much later in the project.
- Risks are often interdependent – i.e. how one risk is addressed may affect another risk in an adverse manner (e.g. increase the probability of its occurrence)
- The stakeholders in a project do not have unrestricted choices on how they can address risks. There are always constraints (procedural or financial, for example) which restrict options on how risks can be handled. These constraints may lead to decisions that affect other risks negatively.
I would add another point to this list:
- Stakeholders do not always have all the information they need to make informed decisions on risks. As a consequence, they may not foresee the pathogenic effect of their decisions. The authors allude to this in the paper, but do not state it as an explicit point. In their words, “Being engaged in a particular stage of a project selects certain risks for a project manager’s attention, and the priority becomes dealing with these risks rather than worrying about how widely the way of dealing with them will ramify into other stages of the project.”
The authors then discuss the origins of subjectivity on whether something is pathogenic or adaptive. Their data suggests the following factors play an important role in how a stakeholder might view a particular construct:
- Identity: This refers to the roles people play on projects. For example, a sponsor might view a quick requirements gathering phase as protective, in that it saves time and money; whereas a project manager or developer may view it as pathogenic, as it could lead to problems later.
- Expectations of blame: It seems reasonable that stakeholders would view factors that cause outcomes that they may be blamed for as pathogenic. As the authors state, “Blameworthy events become highly specific risks to an individual and the origin of these events – whether practices, artefacts or decisions – become relevant pathogens.” The authors also point out that the expectation of blame plays a larger role in projectised organisations – where project managers are given considerable autonomy – compared to functional organisations where blame may be harder to apportion.
Traditional risk analysis, according to the authors, focus on face-value risks – i.e. on external threats – rather than the subjective interpretations of these risks by different stakeholders. To quote, “…problematic events become especially intractable because of actors’ interpretation of risk are contradictory.” These contradictory interpretations are easy to understand in the light of the discussion above. This then begs the question: how does one deal with this subjectivity of risk perception? The authors offer the following advice, combining elements of traditional risk analysis with some novel suggestions:
- Get the main actors (or stakeholders) to identify the risks (as they perceive them), analyse them and come up with mitigation strategies.
- Get the stakeholders to analyse each others analyses, looking for contradictory interpretations of factors.
- Get the stakeholders together, to explore the differences in interpretations particularly from the perspective of whether:
- These differences will interfere with management of risks as they arise.
- There are ways of managing risks that avoid creating problems for other risks.
They suggest that it is important to avoid seeking consensus, because consensus invariably results in compromises that are sub-optimal from the point of view of managing multiple risks
I end this section with a particularly apposite quote from the paper, “At some point the actors need to agree on how to get on with the concrete business of the project, but they should be clear not only about the risks this will create for them, but also the risks it creates for others – and the risks that will come from others trying to manage their risks.” That, in a nutshell, is the message of the paper.
Conclusion
The authors use the metaphor of a pathogen to describe inherent organisational characteristics or factors that become “harmful” or “pathogenic” when certain risks are triggered. The interpretations of these factors subjective in that one person’s “pathogen” may be another person’s “protection”. Further, a factor that offers protection at one stage of a project may in fact become pathogenic at a later stage. Such contradictory views must be discussed in an open manner in order to manage risks effectively.
Although the work is based on relatively few data points, it offers a novel perspective on the perception of risks in projects. In my opinion the paper is well written, interesting and well worth a read for academics, consultants and project managers.
References:
Busby, Jerry. & Zhang, Hongliang., The Pathogen Construct in Risk Analysis, Project Management Journal, 39 (3), 86-96. (2008).
Assumptions of competence
In a recent post, I wrote: “…most folks don’t really need to be managed because they’re competent at what they do, and go about doing their jobs in a generally diligent manner.”
On reading this an old friend wrote to me saying, “I am sincerely of the opinion that most people are not competent at their jobs…” And a bit later in the same message, “If you are looking for quality and excellence, don’t expect to find it in business and corporate culture.”
Incidentally, he is an independent consultant with over fifteen years experience, much of it gained in large corporations . His observations regarding the general lack of competence and quality in the business world must, therefore, be taken seriously. Nevertheless, I reckon he’s at least partly off the mark: I believe it behooves managers to begin with the assumption that people are competent, and that they want to do high-quality work.
Let me start my case with three stories which may sound familiar:
Jim is a developer at the regional office of a large multinational. He is overloaded with work, typically working on at least two (often three) major projects concurrently. As a consequence he cannot do justice to any of them. It is clear that Jim will not meet the deadlines on any of the projects. Though it is clear that his situation has been caused by poor management, he’ll be the one carrying the can.
Tracy is an experienced database programmer working on a large project. She has worked on similar projects before, and is arguably the best person to provide technical input regarding the design and implementation of database program modules for the product. Yet, her manager insists that every suggestion she makes be approved by him prior to presentation to the team, often adding his two-cents to her designs. Of late the team has noticed that Tracy has been unusually quiet during project meetings.
Sanjay has been working as an ERP adminstrator for a while. He has the job well under control, and is looking to pick up some new skills. The company he works for has just purchased a large number of licenses for a major business intelligence platform, so there’s going to be plenty of work building new reports. Sanjay knows this area is under-resourced: there’s only one person working on the new platform, right from metadata design to creating reports. Clearly, this person could use some help, and it’s a perfect opportunity for Sanjay to pick up new skills. Sanjay approaches his manager for permission to get involved, but the manager refuses outright.
Sooner or later…
Jim’s blamed for the failure of his project(s).
Tracy has lost interest in her job.
Sanjay’s administering his ERP system competently enough, but spends his (considerable) free time surfing the Net. He’s bored, and makes no effort to hide it.
To a casual onlooker it may appear that Jim, Tracy and Sanjay “are not competent at their jobs”, but that is a superficial observation. The real problem is that they are no longer motivated by their work. The basic reason for their demotivation is bad management. More specifically:
Jim’s expected to achieve the unreasonable or impossible.
Tracy isn’t empowered to make decisions that affect her work.
Sanjay isn’t given the opportunity to learn new skills.
Fact of the matter is, these folks want to succeed at their jobs and even go beyond their job description, but they aren’t given the support, opportunity and / or the means to do so.
I did say my friend’s partially right, and he is: with a demotivated team, quality and excellence and all those wonderful things we’re supposed to strive for in the workplace aren’t going to happen. The question is, who is responsible? As Deming mentions in his management / quality classic, Out of The Crisis, the fault lies largely with management. I agree, but many don’t. I’d be interested in hearing what you think. Do let me know through your comments.
A new model of motivation and its relevance for project managers
Many managers struggle with the question of how to motivate their team members effectively. A recent Harvard Business Review article entitled, Employee Motivation: A Powerful New Model, by Nitin Nohria, Boris Groysberg and Linda Eling-Lee describes a new model that provides concrete steps which organisations and individual managers can take towards improving team motivation. The model is based on analysis of data gathered from a large number of employees across many organisations. Projects are temporary organisational structures so the model is of potential interest to project managers: hence this annotated summary of the article.
The authors start with the premise that people’s choices are guided by four basic human drives which were described in a book written by Nohria and Lawrence in 2002 (see a review of the book here). In brief, these are the drives to:
- Acquire: To obtain tangible items (things such as a car, house etc.) and intangibles (such as respect, status etc.) .
- Bond: To seek membership in groups (e.g. work teams) and form connections with individuals (e.g. friendships)
- Comprehend: To understand the world and thus develop a personally meaningful and coherent view of one’s social and work environment.
- Defend: Protect what is important (to the individual) and ensure fairness (to those who form a part of one’s world)
The authors make the point that these drives are independent, and that one must address all of them in order to motivate employees fully. This is interesting because it implies, for instance, that people cannot be motivated by money alone. This point may be obvious to some, but I know some managers who believe that financial rewards alone are enough to motivate employees and team members.
The authors suggest some organisational levers that may be used to fulfil each of the aforementioned drives. These are:
- Reward System: A well-designed reward system that includes equitable remuneration and transparent, performance-related bonuses can be used to address the drive to acquire.
- Corporate/Team Culture: A collegial work environment. which encourages openness, camaraderie, and team work will foster a sense of belonging in employees / team members. This can fulfil the drive to bond.
- Job Design: The drive to comprehend, or understand one’s place in the world can be fulfilled by engagement in a job that is interesting, challenging and meaningful. The employee or team member should clearly understand the importance of his or her job, and where it fits in the big scheme of things.
- Performance management and resource allocation: Any system that includes performance-related rewards must be accompanied by an transparent and trustworthy processes to assess performance. Further, any resource allocation (for projects or other corporate initiatives) must be done in a way that is based on the merits of the endeavour, completely free of bias. Performance assessment, through its effect on individual and team rewards impacts the employees drive to acquire and bond; whereas the resource allocation, through its effect on projects impacts the drive to comprehend (i.e. people’s jobs). Hence these two offer employees ways to defend things that are important to them (or things that fulfil other drives).
Granted, project managers do not always have control over all (or even any!) of the organisational levers listed above. However, the authors’ research indicates that employees more often than not understand the limited influence that their direct managers have on these levers. Hence, most employees only expect their managers to do their best to fulfil all four motivational drives within the organisational constraints that are imposed from above. That is, employees are pretty realistic about what their managers can and can’t do. This is good news for project managers because it means that team members generally do not expect miracles from them! Examples of specific things a project manager might do include:
- Offer more autonomy and learning opportunities to team members.
- Promote team bonding through joint activities.
- Foster relationships based on trust within the team.
- Recognise achievement through public acknowledgement and other non-financial means (for example, by informing the senior management)
- Raise the profile of the team in the larger organisation.
…and so on. There are ways to tweak organisational levers, even if one doesn’t quite have the muscle to yank them.
To summarise: the article outlines a model of motivation that is built on research in biology and psychology. The model is based on the need to address four basic human drives – i.e. the drives to acquire, bond, comprehend and defend. Managers need to understand that all four drives must be fulfilled in order to motivate employees fully. Employees generally recognise that their direct managers have limited control over organisational culture and reward systems. However, they expect their managers to do their best to motivate teams within these constraints. In my opinion the article is worth a read (regardless of the validity of the model) because it emphasises that motivation involves more than financial reward and, even more importantly, it encourages front-line managers to take an active role in motivating their teams.

