Archive for the ‘Paper Review’ Category
Fostering cross-project learning and continuous improvement in projectised environments.
Introduction
There’s much angst and hand-wringing about how difficult it is to engender a learning environment in projectised organisations. In an earlier post I made a case for an emphasis on learning rather than efficiency in project execution. That discussion focussed on challenges around learning within a project. These challenges are magnified in the case of learning across projects. In most organisations, the responsibility for cross-project learning typically rests with the project management office (PMO) or its equivalent – whether or not it exists as a formal entity. In a paper entitled, How Project Management Office Leaders Foster Cross-Project Learning and Continuous Improvement, published in the Project Management Journal, Jerry Julian investigates how project management office leaders facilitate cross-project learning. Based on his findings, he also presents some recommendations for improving cross-project learning and foster continuous improvement. I summarise and discuss the paper below.
The paper begins with the observation that, “…project teams often start solving problems anew rather than learning from previous projects within the same organisation. This often means that the end of a project is the end of collective learning…” As they are the focal point for all project work within the organisation, PMOs are best placed to foster cross-project learning. Further, since they serve as a repository for project documentation, they are also well placed to identify potential improvements and implement these after due consideration. The paper explores how PMO leaders perceive their role in fostering learning and continuous improvement. The specific questions addressed are:
- What do PMO leaders see as their responsibilities in fostering learning and continuous improvement?
- How do they foster cross-project learning?
- What are the enablers and barriers (as perceived by them) to cross project learning and continuous improvement.
The author attempts to answer these based on data gathered from surveys and subsequently validated through focus groups. Regardless of the validity of the author’s methodology, the paper serves to inform PMO leaders about what their peers are doing to foster cross-project learning. It therefore merits attention from PMO or program/portfolio managers.
Background
One of the most common activities associated with cross-project learning is the practice of conducting project post-mortems aimed at finding out what went well and what didn’t. From his review of the literature, the author finds that although the value of such “lessons learned” sessions is widely acknowledged, many organisations fail to conduct them in practice (see this paper by Maximilian von Zedtwitz, for example). Amongst those that do, there is general dissatisfaction with the process. As Anne Keegan and Rodney Turner state in this paper, “…Project team members frequently do not have the time for meetings, or for sessions to review lessons learned. Often project team members are immediately reassigned to new projects before they have had time for lessons learned sessions or after action reviews. In no single company did respondents express satisfaction with this process, and all claimed that time pressures exert enormous pressure, and reduce the effectiveness of these learning practices.”
However, the problem is deeper than time pressures. As Jacky Swan and coworkers point out in this paper, the assumption that knowledge can be captured and transferred in textual form is itself questionable, basically because it ignores that knowledge is often embedded in practice, and hence cannot be understood independently of that practice. If this is true – and most experienced project managers would recognise that it is – then the traditional lessons learned document is less useful than it is thought to be. What might be more useful is in knowledge is transferred in other ways, such as narration and joint work. In essence, many lessons can only be learned by doing – furthermore, doing in the right context. This isn’t new: it is central to the idea of reflective practice articulated by Donald Schon in his 1983 classic entitled The Reflective Practitioner . It is also central to Jean Lave and Etienne Wengers ‘ ideas on communities of practice. Accordingly, the author uses these concepts in developing a framework to study the role of PMO leaders in cross-project learning.
Framework and Methodology
Following, Wenger the author views (cross-functional) project teams as being made up of people from multiple communities of practice, and a PMO as being embedded in a “constellation of practices” through which knowledge about past projects must be negotiated and shared. In this framework a PMO leader can be seen as a broker between various communities of practice – which may include senior management, project teams and the PMO itself. A PMO leader would do things that promote communication between various communities of practice. Specifics of what those “things” might be include: alignment (ensure everyone’s “on the same page”), translation (for instance, between IT and business-speak), coordination (ensure people’s efforts are directed to the same end) etc. The PMO leader, being at the boundary between multiple communities of practice, has a particular responsibility in managing boundaries between these communities. A PMO leader manages these boundaries by:
- Promoting boundary encounters (single or discrete encounters that provide connections across practices)
- Developing effective boundary practices (practices that sustain connections across boundaries)
- Creating / archiving useful boundary objects (artefacts – documents, stories etc.- that organise interconnections across communities).
In addition to managing boundaries, the PMO leader should reflect on the knowledge gained in boundary encounters. Such reflection could be at the level of
- Content: review how ideas have been applied to solving problems.
- Process: review the problem solving process.
- Premise: review the assumptions underlying the process.
Ideally reflection should occur at all three levels. In this view, the PMO leader is not just the custodian of project-related processes, but also a driver of process improvement. The author uses the aforementioned concepts of communities of practice (and the boundaries between them) and reflection (or reflective learning) to frame his research methodology and subsequent analysis. To gather data, the author interviewed several PMO leaders drawn from various industries. Prospective interviewees were identified through 20 initial contacts and then using a snowball sampling strategy whereby initial contacts and others were asked to provide referrals to individuals who met the author’s selection criteria. Data collection was done through a pre-interview questionnaire followed by an in-depth interview. The paper has a fairly detailed description of the methodology, so I’ll leave it at that and proceed on to the findings which are likely to be of greater interest to my readers.
Findings
The author’s results are best discussed in the context of the research questions posed in the introduction:
Perceptions of PMO leader responsibilities relating to cross-project learning
- 75% of participants said that their primary responsibility was to ensure that projects were delivered on time and within budget and expectations.
- 60% required project teams to identify lessons learned.
- 45% said that continuous improvement of project performance was an important part of their job.
- 45% felt that they were responsible for consistent adoption of project management practices across the organisation.
- 20% said that their responsibilities included providing a learning and development environment for project managers.
How PMO leaders foster cross-project learning
Unsurprisingly, every interviewee claimed that they facilitated cross-project learning by brokering connections between senior management, project teams and other communities. They do this through a variety of boundary practices, objects and encounters. Specific boundary practices include:
- Lessons learned practices (85%)
- Status and project reports to senior management and other governance processes (85%)
- Common project management practices (80%)
- Knowledge sharing forums (40%)
Boundary objects used to foster connections across projects include:
- Tools and templates (85%)
- Systems (65%)
- Documents (40%)
Boundary encounters included meetings to
- Intervene when projects were going off-track
- Transfer project management knowledge to project teams
- Improve processes used on projects.
In addition it was found that about half the interviewed PMO leaders engaged in content and process reflection to diagnose project-related problems and to help project staff and other stakeholders learn from prior projects.
Enablers of cross-project learning
The following were the major findings relating to enablers of cross-project learning:
- 60% of those interviewed believed that a network of strong relationships is important to enabling cross-project learning.
- 6% thought that senior management support is important.
- 30% believed that organizational culture plays an important role.
- 25% believed that it is important to have a neutral facilitator
- 25% emphasised the importance of professional development of project managers via training, apprenticeships etc.
- 10% believed that reflection throughout the course of the project (rather than just at the end) is critical.
Barriers to cross-project learning
The following were the author’s findings relating to barriers to cross-project learning:
- 55% identified the lack of direct authority over project managers as a major barrier.
- 45% thought that time pressures were an important factor.45% reckoned that frequent staff rotation hindered cross project learning.
- 35% felt that fear of reprisals prevented staff from airing or owning up to mistakes.
- 20% thought that lack of senior management support played a role.
- 20% identified the deferral of learning to the end of the project – i.e. lack of continuous reflection and improvement – reduced the effectiveness of learning.
Analysis and discussion
On analysing his data, the author finds that PMO leaders broker learning through a variety of activities, including:
- Project intervention – 35%
- Status reporting and governance – 17%
- Lessons learned practices -16%
- Process improvement -12 %
- Transfer of standards and practices -12 %
- Knowledge sharing fora – 7%
The author acknowledges that the large percentage associated with the first item might be due to a framing effect – the questions asked in the interview specifically solicited critical incidents in which intervention was required. He also suggests that the relative importance of the reporting/governance item is due to the fact that most PMO leaders consider project performance to be their primary responsibility. Since PMO leaders are often judged on project performance, it is common for them to dashboards to keep track of project statuses. In these, statuses are monitored through traffic light reports, wherein projects that are going well are coded green; those in potential difficulty, yellow; and those in trouble, red. Most often, projects doing well are ignored and only those in trouble are given attention. This leads to what the researcher calls “red-light learning” wherein lessons are learnt only in the context of something going wrong. Potentially useful information pertaining to “what went right” is ignored.
Based on the findings described in the previous section, the author posits that social capital is a key enabler of cross-project learning. In the present context of cross-project learning, it is important for PMO leaders to build social capital by developing connections to individuals and other social networks (project teams, expert groups etc.) both within and outside their organisations. On the other hand the findings suggest that, defensive routines are barriers to cross-project learning. The term defensive routine was coined by Chris Argyris, who defined it as, “..actions or policies that prevent individuals or teams of the organization from experiencing embarrassment or threat…” An example of this, familiar to those working in projectised environments, is the unwillingness of project team members to talk about things that didn’t go so well. Most often such defensive routines point to a deeper malaise – in the case of the example, unwillingness to discuss what went wrong may be due to a “blame culture” within the organisation.
The findings indicate that PMO leaders broker learning through a variety of boundary practices. The author classifies these into two categories: retrospective and prospective. The former includes activities aimed at generating and reviewing knowledge from past projects (e.g. lessons learned, status reporting), whereas the latter is aimed at applying knowledge gained in past projects to future ones (e.g. process improvement, knowledge forums). The author refers to these practices as “collective brokering.” In his words, “PMO leaders can be viewed as knowledge brokers who, through the establishment of retrospective and prospective brokering practices, help their organizations learn from past project experiences by embedding process knowledge into organizational routines that can be transferred to new or existing projects.” In my opinion, the reference to organizational routines is unfortunate, as routines imply rigidity. Perhaps the term “organizational practices” may be more appropriate here – implying a degree of flexibility and adaptability. See this post by Nikolai Foss for more on organizational routines versus organizational practices.
Concluding Remarks
The paper ends with some conclusions and recommendations. I list these below, along with some comments. Conclusions first:
- PMO leaders are knowledge brokers who facilitate organizational learning and continuous improvement.
- Organizational routines that incorporate knowledge gained from past projects provide a vehicle for improving an organisation’s everyday processes.
- Defensive routines can hinder organisational learning from projects.
The view of PMO leaders as knowledge brokers is a useful one: PMO leaders, by virtue of their involvement in diverse projects across the organisation, are uniquely placed to serve as catalysts for learning and improvement. The second conclusion merely states that knowledge gained from projects should, where possible, be incorporated into an organisation’s day-to-day work processes. I’m sure many project and program managers will concur with the third conclusion. I suspect it is the main reason why – so often – not much is learnt from lessons learned sessions. Finally, the author presents some recommendations for PMO leaders. These are:
- To focus on building up social capital across multiple communities (within and outside the organisation) through the development of relationships based on trust, professional development and mutual understanding.
- To focus on learning from both successful and failed projects.
- To reflect throughout the course of a project, not just at the end.
- To use neutral facilitators in order to get the most out of project retrospectives.
The recommendations range from the very general (the first one) to the very specific (the fourth one). It is all good advice, no doubt. However, I can’t help but feel that it isn’t really new: most PMO managers who understand their role in fostering cross-project learning already know this from experience.
Julian, Jerry., How project management office leaders facilitate cross-project learning and continuous improvement, Project Management Journal, 39 (3), 43-58. (2008).
The role of the project sponsor
The role of the project sponsor has not been given much attention in project management literature and lore. This is strange because most project managers will attest to the importance of having an effective project sponsor. So here’s a question: what differentiates an effective sponsor from an ineffective one? Well, obviously involvement in the project is important – an indifferent sponsor won’t be much help at all. But what kind of involvement is required? A recent paper entitled Governance and Support in the Sponsoring of Projects and Programs, by Lynn Crawford and others, explores the formal and informal aspects of the sponsorship role, with a view to defining what makes an effective sponsor. This post is an annotated summary of the paper.
In their introduction, the authors state that, “convincing evidence demonstrates that success or failure of projects is not entirely within the control of the project manager and project team. Contextual issues are crucial in influencing the progress and outcomes of a project, and a key theme that has emerged is the support of top management.” In addition to this, the authors recognise the increasing focus on corporate governance adds another dimension to the role of the sponsor – that of ensuring that the project is aligned with corporate policies and, more generally, any relevant regulatory requirements.
The paper aims to provide a comprehensive view of project sponsorship by looking at the role from the perspective of sponsors, project managers, team members and other project stakeholders. The conclusions were based on interviews with assorted stakeholders selected from 36 projects across different geographical regions. The diversity of data enabled the authors to construct a conceptual model of the sponsor role. As hinted at in the previous paragraph, the model views the role as consisting of two independent perspectives: that of the organisation (governance) and that of the project (support).
Background
In true academic fashion, the authors present a comprehensive review of the literature on project sponsorship. Broadly, the literature may be divided into two areas: standards and research papers. The authors find that project management standards provide sparse material on the role of the sponsor. Specifically, the PMBOK views the sponsor in the context of a single project – and mainly in the role of a financier. The standard makes no reference to the wider organisational context in which the project plays out. Other standards such as the OPM and Program / Portfolio Management Standards provide a limited discussion of the sponsor as project champion, but these too, completely overlook the organisational context of the role. Other standards such as those from the APM and OGC have a more rounded view of the role.
In recent years the project sponsor role has been getting increased attention from project and general management researchers, as evidenced by the increasing number of papers published on the topic. In the author’s words, “Initial understanding of the role of the project executive sponsor as the person or group responsible for approving finance has gradually been expanded to include many other key functions that appear to be directly related to project success.” Some of these include:
- Ensuring availability of resources.
- Achieving and maintaining buy-in of senior management.
- Getting political support for the project.
- Serving as a “project critic”.
The literature also identifies the following characteristics of successful project sponsors:
- Appropriate seniority and power in the organisation.
- Political skill.
- Connections and influence in the organisation.
- Ability to motivate
- Excellent communication skills
- Ability to work with people at different levels in the organisation and the project team.
Yet, despite the importance of the role, many organisations do not nominate sponsors for all their projects. From their literature review, the authors conclude that although there is an increasing recognition of the importance of the sponsorship role, it remains largely unexplored. Their paper is intended to be a step towards filling this gap.
Methodology
The authors conducted their research in two phases. In the first phase, they performed five independent studies aimed at identifying:
- Attributes contributing to effective sponsorship
- The influence of sponsorship on project success
- Competencies required of project sponsors
- The sponsorship role in the context of organisational, program and project governance
- A model of factors contributing to the effective performance of the sponsorship role
The researchers were able to identify common themes that emerged from all of the independent studies. This commonality enabled the researchers to build a conceptual model of the sponsorship role, which was then tested against data gathered in the second phase of the research. The details of the research methodology, as fascinating as they may be for professional researchers, are of little interest to the practising project manager. So, I’ll leave it there, and move on to a discussion of the model.
The Model
The project sponsor role straddles two organisational entities: the project and the sponsoring organisation. From the perspective of the project, the main function of the sponsor is to provide support (e.g. champion the project); from the organisational perspective it is to ensure appropriate governance (e.g. compliance with regulations and corporate policy). The authors therefore model the role along two complementary, yet independent, dimensions – support and governance. The dimensions complement each other in that “the act of governing the project requires that the project be looked at from the perspective of the parent organisation (governance), and the act of providing top management support requires looking at the parent organisation from the perspective of the project (support).” Although complementary, one can conceive of situations where one might exist without another – think of an overly regulated organisation, for example – so they are independent as well.
To a large extent, which dimension is emphasised depends on the situation – and a canny sponsor recognises what a particular situation demands. For example, a sponsor may need to emphasise governance if a project has regulatory implications. On the other hand, she may need to emphasise support if some aspects of the parent organisation are impeding project progress. In principle, one can describe all possible sponsor perspectives in a two dimensional plane described by the coordinates (governance, support): the former describing the interests of the parent organisation and the latter the interests of the project. The paper does not describe the framework any further, although the authors do mention that future papers will fill in more detail.
The authors then present a long discussion of the two perspectives, discussing specific situations in which they may be appropriate. In essence, from a governance perspective the sponsor needs to ensure that the interests of the parent organisation are served by the project, whereas from a support perspective he or she needs to champion the project within the larger organisation. Specific examples of each are easy to find, and are left as an exercise for the reader.
It is interesting that the model presented is akin to some existing theories of management and leadership. A well-known example is the managerial grid model proposed by Blake and Mouton in 1964. In the grid model, the two dimensions are (the welfare of) People and (the maximisation of) Production, and an effective leader displays concern for both. Recent research, however, provides only limited support for the hypothesis that high-people and high-production leaders are more effective than others. In fact, Yukl suggests that people-related factors such as interpersonal relationships and teamwork are more important. A good leader should be able to “guide and facilitate” by fostering relationships and teamwork within the organisation. The congruence between the grid model (and others of its ilk) and the present sponsor model is false, and managerial effectiveness should be seen as a third dimension (in addition to Support and Governance).
So what are the attributes of a good “guide and facilitator” as it pertains to project sponsorship? The authors identify the following from their data:
- Good communication skills.
- Commitment to the project.
- Position and influence in the parent organisation.
- Is available when needed
In terms of practical help, the most important of these attributes is availability. In the words of one of the survey respondents, “The sponsor must be accessible. It doesn’t help if you have a sponsor who kind of reports to God and you never get to see them…” I’m sure many project managers will be able to relate to this.
Conclusion
The paper presents a conceptual model of the project sponsorship role, based on an analysis of existing project and general management literature, and data gathered from diverse project environments. The model views the role as being made up of two independent functions: support and governance. These functions represent the perspective of the temporary organisation (the project) and the permanent one (the parent organisation) respectively. It is also interesting that the two functions can, at times (or should I say, often?), lead to conflicting demands on a sponsor. The authors end the paper stating that analysis of data and work on the model continue. I look forward to seeing a further elaboration of their model in the future.
To end, a few quick words about relevance of the paper to practising project managers. From the practitioner’s perspective, the paper is worth a read because it spells out the full range of responsibilities of a project sponsor in very clear terms. In short, after reading this paper you’ll know what to say when a sponsor of your project wanders over and asks, “What do you need from me?”
References:
Crawford, Lynn., Cooke-Davis, Terry., Hobbs, Brian., Labuschagne, Les., Remington, Kaye., Chen, Ping., Governance and Support in the Sponsoring of Projects and Programs, Project Management Journal, 39 (S1), 43-55. (2008).
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).
Eight to Late 