images

Risk management

Proactively managing uncertainty, complexity and change

images

Key points

■ A planned approach to risk management

■ Profiling the organisational risk context

■ Identifying project risks

■ Categorising risk for critical assessment

■ Risk tools and techniques

■ Performing qualitative and quantitative probability assessment

■ Performing qualitative and quantitative impact assessment

■ Prioritising scaled risk intervention

■ Planning risk-response strategies

■ Assigning risk accountability

■ Controlling project risk

In practice

No matter what we do, risk is always present. From getting out of bed, to commuting to and from work, through to executing the project plan, there is always a need to identify, assess and manage your risk exposure. There is risk in getting the local authority to approve a new sporting facility, in redesigning a restaurant, in renovating your home, in investing in retirement options, in recruiting new applicants—each of which may well be somebody’s project.

For some, risk is obvious and in your face. Examples include death, illness, changing jobs or working within a team. In other cases, risk may be more remote, if not invisible—for example, in the case of being hit by space junk or being attacked by a rogue animal. And herein lie the many challenges in working with risk—the identification of risk factors that could potentially impact the project. The key point here is the project itself. The risk lies in executing the project performance and deliverables—not post-implementation, when nobody turns up to dine in the remodelled restaurant (if the project was to remodel, not to promote and fill the seats), and not when the new emergency admission procedures fail to be followed (if the project was to investigate and report alternative emergency admission procedures).

But enough doom and gloom. Risk can also bring with it innovation, enhancements, efficiencies and continuous improvement, as new ways are found to do the work or alternate measures are put in place in response to perceived or real risk. Risk can force us to think outside the square and to move beyond the standard operating procedure (SOP) treatment responses, which might work for operational risks but may fall short in dealing with project ones.

There will always be risk throughout the project, starting with the concept stage and traversing the entire life-cycle through to finalisation. In places, it will be vague and poorly defined. At other times, it will gain clarity as more is understood about the project and communicated to everyone involved. And as with each of the other PMBOK processes, risk management never leaves the project.

Chapter overview

Clearly, one of the ‘givens’ in most types of projects (given that they produce change) is the notion of risk in some shape or form. The other ‘given’ is that risk is not a static or fixed concept. In fact, risk is one of the most fluid forces the project organisation will need to manage throughout the life of the project.

PMBOK (2013) defines risk management as ‘the processes of conducting risk management planning, identification, analysis, response planning and controlling risk on a project’. It should be apparent that the goal of risk management is to ensure that a suitable risk-response mechanism is put into place to reduce the probability of trauma (or increase the probability of the opportunity) in the project, and to reduce the resulting negative consequences (or increase the positive consequences)—that is, to proactively manage the risk.

Following a six-step model, risk management involves agreeing how the risk-management activities will be planned and conducted, identifying the risks, qualifying and quantifying these risks, and developing targeted responses, along with monitoring and evaluating the effectiveness of the risk processes. Regardless of the number of steps, the challenge facing most project organisations in this regard is to ensure that these processes become an integral and seamless part of the organisation’s culture and a constant priority for the project stakeholders, project manager and team (and an agenda item at every project meeting).

Planning for risk management

A ‘reasonable’ person may define risk as a potential problem, a situation or perhaps an opportunity that will have a measured impact on a nominated outcome. The AS/NZS (31000: 2009) standard defines risk as an ‘effect of uncertainty on (project) objectives’—in other words, the exposure of an activity to an uncertain outcome.

This definition is intuitively appealing, relatively simplistic and easily understood, with no reference to difficult mathematical processes, complex formulae, impossible-to-understand algorithms or scientific processes. This is important because the objective for all stakeholders is to agree with the true meaning of project risk—its volatility, its positive and negative contribution to the project—and to appreciate the need for its proactive management throughout the project.

Many project organisations (regrettably) place heavy and singular reliance on their standard operating procedures (SOPs) when it comes to managing their project risk. To be fair, many low-level risks are well suited to being managed under this operational framework, including authorised access, work, health and safety (WHS) inductions, incident reporting, financial delegations, regulatory compliance and issue escalation pathways. But (and it is a big but) will faith in this operational practice enable and empower the proactive management of all levels of project uncertainty over the project life-cycle?

Mapping inherent strategic risk

Obviously, explicit, thorough and documented risk-management planning activities will work towards not only evaluating and controlling project risks, but (and equally importantly) also delivering a successful project. However, many organisations undertaking a major project will face strategic (high-level) risk exposure. In launching a new product, not only could the launch fail, but the reputation and profitability of the organisation could be seriously damaged. Equally, the new mining project may not produce the expected tonnage, or the construction of the new tunnel (to alleviate inner-city congestion) may fail to get the predicted traffic flow. In all these cases, the risk is strategic, as it belies the over-arching success (however measured—for example, profitability, competitiveness, survival) of the business itself and not just the project’s internal risk of not being completed on time, on budget and as scoped (to narrowly focus on just three aspects for now).

Not only is this overall strategic project context important; the project stakeholders’ risk appetite and tolerance is equally important (PMBOK, 2013). It follows that different people (and organisations, for that matter) will have different levels of acceptance of (or tolerance for dealing with) risk. These risk ‘attitudes’ will play an incredibly constructive (or destructive) role in how well risk-management planning activities are supported, and can be classified under three broad perspectives:

1 risk averse (low tolerance), where the intent is avoidance with the focus on refraining from perceived risk activities

2 risk neutral (neutral tolerance), where the intent is caution, with the focus on remaining impartial to perceived risk activities

3 risk seeking (high tolerance), where the intent is acceptance with the focus on engaging in risk activities.

The process of planning the risk-management activities begins with clearly understanding and agreeing exactly how the risk-management activities for the project will be carried out. This will also require an equal acceptance that project risk never comes gift-wrapped in a universal and convenient one-size-fits-all format. These activities will need to continually balance the degree, type and visibility of what risk management involves with the scale of the risk itself, the project planning and delivery, and, of course, the importance of the project to the organisation itself.

Nor should these activities be the sole domain of the project manager. All stakeholders need to be actively present in these (and other) activities from the concept stage onwards, in demonstrating their agreement and active support, and in ensuring that the risk-management processes are actioned effectively throughout the project. This support should never be marginalised in subsequent project life-cycle stages, when ‘new’ risk suddenly appears that had not previously been documented. No project has a crystal ball, so common sense would dictate that risk will continue to change and challenge the project, from start to finish—and the last thing you want is some stakeholder feigning surprise (or worse, ignorance) and then putting the blame on the project manager and the project team. Risk management will always be a shared and transparent responsibility—perhaps a novel idea for some.

As with any other project planning processes (scope, time, cost, quality, etc.), the risk-management plan needs to convey how the risk-management activities will be structured and performed, and may include the following information and activities (adapted from PMBOK, 2013):

■ the methodology (approach, tools and data sources) to be used

■ roles and responsibilities for stakeholders, project manager and team members

■ estimates of, and access to, additional funding to cover contingency and management reserves

■ scheduling the frequency of risk-management activities throughout the life-cycle

■ a format for analysing examples of risk activities

■ reference to mandatory (and associated) documentation relying on updated risk information (e.g. the project plan)

■ categorising potential causes of risk through a project-specific risk breakdown structure (RBS), or adapting a categorisation framework or SOP

■ scaling both qualitative (descriptive) and quantified (numeric) definitions of risk probability and risk impact

■ specifying that risks will be prioritised using a probability and impact matrix

■ revised stakeholder tolerances

■ reporting formats nominating how risk-management activities will be documented, analysed and communicated

■ an audit trail of tracking documents showing how risk activities were recorded and responded to.

Critical reflection 10.1

With projects conceived with different degrees of uncertainty, complexity and change, it is little wonder that risk poses a constant threat and opportunity to the project’s successful completion.

■ What is your organisation’s operational attitude towards risk?

■ How well do you think risk is managed operationally?

■ What is your organisation’s attitude towards project risk?

■ How well do you think project risk is managed operationally?

Identifying the risks

With a planned approach bedded down, risk identification (as the second of six steps) will involve project stakeholders, the project manager, team members, clients, subject-matter experts (SMEs) and others anticipating and identifying those risks (and their characteristics) that may affect the project in some measured way. In fact, regardless of any specific role, all project personnel should be actively encouraged to identify potential risks (mapped back to the WBS) with a shared sense of ownership, responsibility and additional objectivity. Remember, this is not an ad hoc, reactionary plan or a last-resort process. It has structure, due process and a logical flow (like everything else in project management).

It is important to remember that when you begin to identify risk, very few risks—if any—will be absolute in their detail, as they will continue to evolve throughout the project’s life-cycle (not to mention the new ones that will make themselves known). Risk identification is an iterative process governed by any situational context in which the project is located—risk identification in the planning stage will not be as accurate (or timely) as the risk identification carried out in the execution stage. However, the more comprehensive the identification aims to be, the less chance there is of any risk not identified at this early stage being automatically excluded from any further analysis (and possible response strategy) once the project has commenced.

Risk events are often described in terms of the ‘known unknowns’—knowing something could or will happen, but not when it will occur or to what degree. Examples include knowing it might rain, the supplier might go broke or the electronic part might fail. And there are also the ‘unknown unknowns’—not knowing anything about what might possibly happen. In these cases, the project stakeholders have no history, general knowledge and/or experience in the type of project they are working on (or what risk may be relevant). Anything and everything that happens from a risk perspective would take them by surprise. In this type of project, it is pretty much impossible to predict the risks that could impact.

Categories of risk

As covered in the risk-management plan, part of dealing with uncertainty in anticipating and identifying risks is the process of categorising risk under meaningful headings to enable further, and more concrete, analysis. Two initial categories could be as simple as:

1 internal risk, which is controlled and/or influenced by the project organisation, stakeholders, project manager and team

2 external risk, which sits outside the direct control and/or influence of the project organisation, stakeholders, project manager and team.

Once you can separate internal from external risk categories, it is easier to begin populating potential and more tangible sources of risk, as identified in Table 10.1.

Irrespective of where the risk comes from (whether inside or outside of the project parent organisation), the project manager and team must remain vigilant throughout every stage of the project as different risks are identified.

Table 10.1 Internal and external categories of risk

Internal risk (controllable) External risk (uncontrollable)
Ambiguous project charter Market deregulation and changes
Inaccurate estimates Technology innovation
Fast-tracked decision-making Political unrest, upheavals, changes
Access to management reserves Fluctuating economic cycles
Poor performance reporting Increasing global competition
Undefined quality requirements Increased compliance
Communication bottlenecks Variable contractor performance
Unauthorised changes to scope Social changes
Fluctuating commitment Legislative constraints
Limited resource availability International standards or regulations
Low-level skill sets Conflicting contractor priorities
Lack of accountability Partnering relationships
Variable stakeholder expectations Contractual obligations

For those of you who find more generic risk categories easier to work with, project risk could originate from any of the following categories:

competition activity, evidenced through merger activity, market acquisitions, plant closures, price fluctuations, the introduction of new product or service offerings, or a reduction in operating costs

political agendas, evidenced through legislation, documentation and record-keeping, inspection, and audit or compliance

economic performance, evidenced by the economic cycle, changes in exchange rates, government fiscal and monetary policy, unemployment rates or interest rates

technology impacts, evidenced by production efficiencies, mass production, increasing redundancy or e-commerce opportunities

marketing appeals, evidenced by the release of competing products or services, changes in market share, consumer response rates to advertising or accuracy of market research

legal matters, evidenced by contract administration, non-conformance, conflicts or dispute resolution

financial markets, evidenced by access to reputable sources of funds, funding contingencies, penalties/costs associated with funding or unanticipated changes to scope

organisational practices, evidenced by initiatives to outsource, re-engineer, restructure or downsize existing SOPs, policies and processes, or cultural norms and values

resource capability, evidenced by skill shortages in key areas, limited availability, conflicting operational priorities, fluctuating commitment, low morale and motivation, failure to identify training and support requirements, or a lack of direct control and supervision.

If you are still looking for another category (system) to follow, why not adopt all the PMBOK processes that make up the acknowledged project management methodology? These are shown in Table 10.2.

Critical reflection 10.2

Given the prevalence of risk, categorising the different sources of risk can be a challenging task for some.

■ What categories do you use to group different sources of risk?

■ How does this categorisation assist in both identifying and ultimately managing the risk?

The tools and techniques

To further assist you in coming up with categories to help locate sources of risk, a number of useful approaches, tools or techniques can be applied in this stage, and throughout the entire risk-management process, including:

Table 10.2 PMBOK process risk categories

Project management processes Examples of potential risk
Integration

■ Inadequate methodology

■ Poorly defined life-cycle

■ Lack of approvals and signoffs

■ No authorised change-control process

Scope

■ Poor definition of expectations

■ Lack of stakeholder involvement

■ No supporting documentation

■ Lack of precise requirement details

Time

■ Scheduling conflicts

■ Deadlines agreed independently

■ Scheduling detail omitted

■ Critical tasks dominating the schedule

Cost

■ Budgets agreed independently

■ Difficulty in tracking money spent

■ Lack of control over spending

■ Limited access to contingencies

Quality

■ Failure to define quality standards

■ Monitoring and inspection costs

■ Schedule and cost implications from rework

■ Incomplete or ambiguous specification details

Human resources

■ Poor project management expertise

■ Poor skills and training

■ Problems with monitoring and reporting performance

■ Operational priorities causing over-allocation issues

Communications

■ Absence of accurate information

■ Lack of ongoing consultation with stakeholders

■ Uncontrolled documentation

■ Failing to update documentation

Procurement

■ Non-compliance with specification

■ Viability of contractors

■ Supply, logistic, reporting and management problems

■ Contractual performance compliance

Stakeholders

■ Inability to identify key stakeholders

■ Failing to control changing expectations

■ Disclosing confidential information

■ Lack of timely approval and signoff

■ risk registers

■ assumption analysis

■ lessons learned

■ checklists

■ SWOT analysis

■ simulations

■ risk specialists

■ material safety data sheets

■ trend analysis

■ industry databases

■ specification descriptions

■ project scope baseline

■ project budget baseline

■ quality requirements

■ sensitivity analysis

■ decision trees

■ project completion reports

■ process flowcharts

■ historical research

■ cause–effect diagrams

■ brainstorming

■ critical incident reports

■ strategic plans

■ interviews

■ feasibility studies

■ SMEs

■ commercial databases

■ project schedule baseline

■ issue logs

■ benchmarking

■ probability distributions

■ expert judgement.

Remember that at the completion of this stage of risk identification, every stakeholder must have reviewed, documented and agreed on a comprehensive list of risk sources.

Performing qualitative and quantitative risk analysis

Following the risk-identification stage, the next two stages require a more detailed analysis to reduce the level of uncertainty and/or impact facing the project, and to enable everyone to focus on the high-priority risks. To achieve this, attention will now turn to:

■ the probability of the risk occurring

■ the impact of the risk on the project

■ the priority (or ranking) of the risk.

As with any analysis, the pre-existing risk attitude, any assumptions made, the subjective nature of the analysis, the potential influence for bias and the time criticality of risk-related action may each magnify or diminish the importance (or not) of any risk source identified (PMBOK, 2013).

The probability of project risk

Whenever you mention the word ‘probability’, most people start to panic and think of all the reasons why they do not like statistics. Rest assured that, for our purposes, we will keep probability simple, without undermining its application to risk. After you have identified what types of risk might impact on your project, it is necessary to predict or determine the probability or likelihood of the risk happening—in other words, to try to find out whether the risk is about to happen, might happen or has little chance of happening.

Risk assessment requires that the project manager and team be able to determine the probability of a risk event occurring. Numerical values ranging from 0 to 100 may be used just as easily as descriptive generic terms like ‘high’, ‘medium’ or ‘low’. Clearly, the numbers enable more measured analysis, although the qualitative terms might also provide insight into the probability. While there is no ideal way to present probability data, Table 10.3 demonstrates how probability data could be recorded.

In Table 10.4, the probability of the (sample) risk events identified has been added. So far, we can identify what potential risk has been captured, and the likelihood of each risk occurring. Is this enough information upon which to base project decisions?

Remember that there are no right or wrong words or numbers to use, as long as the scale used (a number scale of 1 to 5 or a word scale from ‘very high’ to ‘remote’) is rigorously and consistently applied in scoring the probability (or likelihood) of the risk.

Table 10.3 Qualifying and quantifying project risk probability

Risk probability Explanation
Value Descriptor  
1 Rare A one in one hundred chance of occurring
2 Unlikely A slight possibility of occurring
3 Moderate Reasonable to consider it could occur
4 Likely Most probable that it will occur
5 Certain 100 per cent chance of happening

Table 10.4 Assigning probability to risk

Risk event Probability
Inclement weather 4
Operational priorities 3
Uncontrolled scope changes 5
Fluctuating exchange rate 1

The impact of project risk

This represents the fallout, the consequences (positive or negative) or the damage (again, let’s not forget the potential gain) arising from the risk. Impact will need to be described in as much detail as possible by the project team, because it is this impact that has the greatest influence on the team’s ability to deliver a successful project. It you cannot visualise, describe or quantify the impact, this will make it next to impossible to treat. Close attention will also need to be paid to the four stages of the project’s life-cycle, as the impacts will have different levels of severity at each stage.

Now the challenge is to isolate and record the impact resulting from each risk event. Again, as with probability, numerical values (1–5) would work just as easily as values measuring delays, costs and other value data. Of course, descriptive generic terms like ‘major’, ‘moderate’ or ‘insignificant’ would work too. Try to be as descriptive as you can to make ultimate response strategies more effective. Table 10.5 demonstrates how impact could be recorded, while Table 10.6 adds the impact score to the risk assessment.

Table 10.5 Qualifying and quantifying project risk impact

Risk impact Explanation
Value Descriptor  
1 Insignificant Impact would be inconsequential
2 Minor Some noticeable impact
3 Moderate Manageable scale of impact
4 Major Large scale of impact
5 Catastrophic Extreme, widespread impact

Table 10.6 Assigning impact to project risk

Risk event Probability Impact
Inclement weather 4 5
Operational priorities 3 4
Uncontrolled scope changes 5 5
Fluctuating exchange rate 1 4

Having formally investigated the likelihood that each identified risk will occur, then assessed the potential effect the impact may have on the project’s objectives in terms of the scope, time and cost baselines (along with quality, human resources, communication and the like), a clearer picture has emerged of both the negative effects for threats and the positive effects for opportunities for each identified risk.

PMBOK (2013) has recorded a range of meaningful impact scales for negative risk mapped against four of the key project objectives (as indicated in Table 10.7). This could easily be extended to capture all the remaining objectives, with scales relevant to different types of projects and organisational risk profiles.

The probability and impact matrix

Given that each risk event will generate a different probability and/or impact score or value, there needs to be a way to separate, rank or prioritise all the different levels of risk exposure. A practical way to do this is to simply multiply the probability score by the impact score (assuming you have quantified these) to get an overall priority score. This can then be used to separate the different levels or degrees of risk exposure, and to assist in developing appropriate response strategies.

Table 10.7 Definition of impact scales for four project objectives

Project objective Very low 0.05 Low 0.10 Moderate 0.20 High 0.40 Very high 0.80
Cost Minor cost increase <10% cost increase 10–20% cost increase 20-40% cost increase >40% cost increase
Time Minor time increase <5% time increase 5–10% time increase 10-20% time increase >20% time increase
Scope Minor reduction in scope Minor areas of scope affected Major areas of scope affected Scope reduction unacceptable to sponsor Project end item effectively useless
Quality Minor drop in quality Only very demanding applications affected Quality reduction requires sponsor approval Quality reduction unacceptable to sponsor Project end item effectively useless

Therefore, the information collected so far (the risk events, their likelihood and their impacts) can be merged into a risk matrix, which will enable the project stakeholders to analyse and begin the process of prioritising the risk. The priority is calculated by multiplying the probability value by the impact value. The higher the resulting value, the greater should be the priority, as shown in Table 10.8.

There should never be any automatic nor direct correlation between probability and impact; they are mutually exclusive and objective assessments. Something with a low probability (a tidal wave hitting a densely populated city) could result in either singular or any number of multiple impacts (loss of life, infrastructure and environment).

By completing this matrix, all stakeholders in the project can clearly see:

■ what the risk is

■ the probability of it occurring

■ the impact it will have on the project

■ what the priority status is.

Table 10.8 Calculating the priority scale

Risk event Probability Impact Priority
Inclement weather 4 Catastrophic (5) Schedule postponement 20
Operational priorities 3 Major (4) missed deadlines 12
Uncontrolled scope changes 5 Major (5) Revisions in schedule and budget 25
Fluctuating exchange rate 1 Major (4) accessing contingency funds 4

A useful graphical approach to plotting risk probability and impact is the ‘5 by 5’ grid (there are also ‘3 by 3’ or ‘10 by 10’ grids), which uses numeric values for both probability and impact, and generates values ranging from 1 through to 25. The higher the number, the greater the priority that should be given to the treatment of this risk. In many cases, this grid is also used in conjunction with SOPs to determine a suitable low-level intervention. Table 10.9 displays the ‘5 by 5’ grid with the following scaled intervention options:

Low: values from 1 to 6 will be treated by existing SOPs.

Medium: values from 8 to 12 will require direct intervention by the project manager.

High: values from 16 to 25 will require immediate escalation and intervention by senior management (project steering group and/or sponsor).

Table 10.9 ‘5 by 5’ priority grid

  Impact
Probability   1 2 3 4 5
1 1 2 3 4 5
2 2 4 6 8 10
3 3 6 9 12 15
4 4 8 12 16 20
5 5 10 15 20 25

Critical reflection 10.3

Being able to define probability and impact in either qualitative or quantitative terms (or ideally both) is fundamental to treating risk effectively.

■ Review how you define probability and impact in your risk register (or other documentation)

■ Does it provide enough ‘range’ to enable all stakeholders to fully capture the risk?

■ What improvements can you make to ensure that probability and impact descriptions and scales are effective?

Planning risk responses

With the analysis completed, it is necessary to plan the risk responses. These strategies will need to be well planned and tailored for each risk, and will need to identify who will be accountable for actioning the responses deployed throughout the project when required. In other words, a risk-management strategy or response will be assigned to, or ‘owned’ by, someone for each risk event throughout the project. All risk must be managed—and managed well. And for those who are still not convinced, perhaps an example will help. Consider that you have an investment portfolio—perhaps $10,000 worth of managed funds with a broker. Take your mind back to 11 September 2001 and the days following the terrorist attacks on the United States. As the fallout from the attacks spread around the world and through the stock market, shares began plummeting as investors feared the worst. Now consider the most common response options to this stock market collapse:

accept the risk: ignore the falling share prices and do nothing, believing that over time your portfolio will regain any lost value

mitigate the risk: increase your portfolio by buying blue chip stocks at rock bottom prices, and decrease your existing portfolio to offset the losses caused by falling prices

avoid the risk: sell down your portfolio and get out of the share market to limit your losses.

Don’t ask me to choose; it is your portfolio. However, your response may well be the best response for your given risk profile. Whichever response you choose, you are demonstrating your response—that is, your management of the risk threat (or opportunity). Figure 10.1 displays these options.

images

Figure 10.1 Risk-response matrix

Risk-response strategies for negative risks or threats

Recall that projects are all about scope, time, cost and resources. Each of these (and the other PMBOK processes) now need to be considered in light of possible risk-response strategies (regardless of where you are in the life-cycle). A number of possible choices are available, but it normally comes down to choosing one of the following four (or variations of these) strategies:

1 Acceptance: the acceptance (passive or active) of the risk and the impact it may have on the project’s outcome, if it occurs. By choosing this response, the stakeholder’s only recourse is constant monitoring and/or establishing a contingency reserve to handle the risks. Examples may include accepting that your flight might be delayed or your wedding reception rained out.

2 Mitigation: taking specific action to reduce either the probability and/or impact of the risk event. This strategy is designed to work with the risks, as they cannot effectively be avoided, and nor are the stakeholders willing to accept them outright. Examples could include informing your client in advance that the meeting might need to be changed due to an expected flight delay, or relocating the wedding indoors.

3 Avoid: this is a targeted response aimed at eliminating the threat to protect the project from the impact altogether. This may mean rescheduling, scope adjustments or isolating part of the project being affected. Examples could include organising a Skype call with your client, or postponing the wedding until the dry season.

4 Transfer: the aim is to transfer the impact of the threat, together with the ownership of the response, to a third party. Rather than eliminating the risk, its management is simply transferred to someone more capable of dealing with the threat presented (this may also include the payment of a risk premium for transferring the liability). Examples could include hiring specialist travel consultants or engaging a specialist wedding planner.

Critical reflection 10.4

With four stock-standard response strategies available, treating risk is more manageable than some project stakeholders think.

■ Review your last project’s risk register and map each of the treatments against the four generic risk responses.

■ What does this tell you about your attitude to risk: is it averse, neutral or risk-taking?

Risk-response strategies for positive risks or opportunities

In these cases, another three specific responses can be followed (in conjunction with the acceptance one cited above). They are:

1 Exploit: the focus here is on ensuring that the identified opportunity is realised by eliminating the uncertainty around it altogether so that the opportunity definitely happens. An example would be using new technology or talent resources to reduce the cost and duration required to complete the project.

2 Enhance: this strategy seeks to actively increase the probability and/or positive impacts of an opportunity. An example would be assigning additional resources to close out the project earlier.

3 Share: in many cases, project risk is shared between partnerships, consortiums and/or mergers, where each party is contracted for their particular expertise and each has a particular ownership, given that they are best able to manage the risk. An example would be a joint venture, where each party is known for a particular expertise that the other does not have.

4 Accept: this focuses in on being willing to take advantage of the opportunity should it arise, while not doing anything to actively pursue it. An example would be being open to a funding partner if the situation arose later in the project.

It must be remembered that, regardless of the negative risks or threats and the positive risks and opportunities, both probability and impact may be the drivers for response strategies. In some cases, it may be possible to develop a response to address the probability of the risk without having to develop an impact strategy. The probability of a major rain event in the wet season in the tropics would be quite high, so why not postpone the project to a drier season? In this example, there is no response strategy to limit the potential impact. In other cases (like death), probability cannot really be influenced so some people take steps to delay the inevitable (exercise, diet, medication, etc.). The key learning here is to not rush headlong into only seeking to manage just the impact every time. Always investigate both the probability and the impact.

Also avoid the temptation to include risk events that fall outside of the project. Think back to the tunnel example earlier—the project was to ‘build’ the tunnel. In this case, is there any risk to the builder if motorists do not use the tunnel? The short answer is ‘no’. Surely the more relevant risks would relate to materials, rain, access and so on. The reality is that someone (the client) wants a tunnel to ease congestion and to turn a profit—both of which fall outside the contractor’s obligations (although contractual conditions may certainly present a different picture). The lesson here is not to make yourself liable for risk that is outside the project’s boundaries.

Assigning accountability

Clearly, risk-response strategies have to be assigned to the most appropriate stakeholder available to carry out the required response. Their technical skills may be the sole selection criterion in this instance, or it may come down to their seniority or financial delegation. Obviously (one would hope), the project manager will not be held responsible, in the first instance, for each and every response strategy, as these should be ‘outsourced’ to the people who have the prerequisite authority and financial delegation, or who can actually work towards resolving them. The project manager will, however, retain overall control of the process.

Assigned ownership is a foreign concept to a lot of project stakeholders, which is both surprising and alarming. If no one is assigned responsibility, there is a very high chance that no one will take any interest in the risk or its treatment. If the responsibility is shared, everyone on the project takes an active role in not only identifying and analysing risk but also in ensuring that capable resources are actually assigned to action and monitor the response strategy. As a result, they could be responsible for any of the following key supporting activities:

■ identifying the triggering events that set the response strategy in effect

■ carrying out the response strategy

■ presenting an update at the project risk meetings

■ updating the project scope, schedule and cost baselines and management plans

■ monitoring the risk register for additional, related risks

■ conducting further quantitative risk analysis

■ evaluating the effectiveness of the response strategy.

Let’s now return to our risk assessment (Table 10.10) and update the information with what the response strategy is and who is accountable.

There is one final action (perhaps series of actions) to be taken before rushing off to try to control the project risks (as per the PMBOK model). Recall that one of the key assigned responsibilities above was to update the project scope, schedule and cost baselines, as these have probably changed given the risk analysis conducted and the development of the appropriate strategies. In fact, there are other documents to update as well, including:

■ the quality management plan, reflecting changes to processes, standards, practice or tolerance and supporting requirements documentation

■ the human resource management (HRM) plan, reflecting changes in technical skills, resource assignment and loading or professional development required

■ the communications management plan, reflecting changes in additional information needs, reporting protocols and formats

■ the procurement management plan, reflecting changes in tendering and/or contracting conditions relating to any additional work required

■ the stakeholder management plan, reflecting changes in stakeholder expectations, revised requirements and ‘handling’ strategies

■ the change request registers, reflecting changes to resources, activities, cost estimates and other items impacting the project planning and delivery

■ the technical documentation, reflecting changes in design, physical deliverables or other technical behaviour of the modified product or service

■ assumptions logs, reflecting changes in outdated assumptions and/or new ones.

Table 10.10 Project risk register

Risk event Probability Impact Priority Strategy Accountability
Inclement weather 4 Catastrophic (5) Schedule postponement 20 Seek approval for time extensions Logistics officer
Operational priorities 3 Major (4) missed deadlines 12 Identify replacement resources Production manager
Uncontrolled scope changes 5 Major (5) Revisions in schedule and budget 25 All proposed changes in writing and authorised Project manager
Fluctuating exchange rate 1 Major (4) accessing contingency funds 4 Closely monitor cash-flow reserves Project steering group

The principal document that needs updating is, of course, the project risk register. These updates will be dependent, once again, on the risk attitudes of the organisation and key stakeholders, the priority ranking and the risk responses. While some low-level risks may be assigned to an almost casual watch list, those with a medium to high priority may well require that the following information is regularly reviewed and updated (PMBOK, 2013):

■ risk owners and assigned resources

■ agreed response strategies

■ trigger conditions, or warning signs of a risk occurrence

■ contingency plans and reserves

■ residual risks remaining post response

■ secondary risks arising directly from implementing a risk response.

Controlling project risk

Risk assessment is an invaluable tool for the project organisation, stakeholders, project manager and team members in terms of ensuring that the project objectives are realised. However, identifying, assessing, analysing and responding to tentative risks at the start of the project does not mean you are free from constantly reviewing and controlling your risk assessment processes throughout the project. It simply means that you are following due process every time a project is initiated.

As you know, risk is not a static concept, nor does everyone get it right the first time, every time. The challenges of identifying the risk events to begin with, let alone the attempts to try to quantify the probability and/or impact, require a dynamic mix of science and art, to say the least. In some situations, the chosen strategies might be very effective at minimising the risk exposure, although in others they might turn out to be questionable, if not totally ineffective. Ongoing control is what is needed to ensure that the opportunities involved in managing risk are not squandered and that the many lessons presented throughout the project are, in fact, learned. Figure 10.2 highlights the dilemma faced by the project organisation regarding balancing risk.

PMBOK (2013) stresses the importance of risk control, with its acknowledgement of the process as ‘implementing risk response plans, tracking identified risks, monitoring residual risks and evaluating risk response effectiveness throughout the project’ as it continually optimises risk responses. New, changing and outdated risks need to be monitored continuously for their impact on the project. With such a direct focus, risk control involves accessing performance information to determine whether:

■ project assumptions are still valid

■ performance data are still accurate and current

■ planned results compare favourably with actual results

■ new risks have been identified, current risks reassessed and risks closed out that have been extinguished

■ adherence to the risk-management plan has been confirmed

■ contingency reserves for both schedule and cost performance are available

■ alternative strategies have been canvassed and analysed

■ corrective action has been implemented

■ the project management plan and associated documents have been revised

■ the lessons learned databases have been updated.

images

Figure 10.2 The risk-management dilemma

In the completed example in Table 10.11, the expectation that risk must be reviewed and controlled constantly throughout the project has been incorporated in the risk register. Failure to do so would leave the door open for retribution against the project manager and the team for mismanaging the project and for failing to anticipate all the changes the project incurred—many of which may be clearly outside the control of the project itself. After all, no one is allowed to blame others. Every party is walking the same road, with an acute sense of shared ownership and responsibility.

Table 10.11 The risk register

Risk event Probability Impact Priority Strategy Accountability Control
Inclement weather 4 Catastrophic (5) Schedule postponement 20 Seek approval for time extensions Logistics officer Revised priority (12)
Operational priorities 3 Major (4) missed deadlines 12 Identify replacement resources Production manager Revised priority (4)
Uncontrolled scope changes 5 Major (5) Revisions in schedule and budget 25 All proposed changes in writing and authorised Project manager Revised priority (14)
Fluctuating exchange rate 1 Major (4) accessing contingency funds 4 Closely monitor cash-flow reserves Project steering group Revised priority (4)

Critical reflection 10.5

Simply because you identify and treat risk doesn’t (sadly) mean that the risk has disappeared, nor does it block any future risks from appearing in your project.

■ Review your last project’s risk register and find examples of where the nominated treatment did not achieve the desired result.

■ Review your last project’s risk register and find examples where the residual risk (left after treatment) was monitored and reviewed and/or the register was updated to reflect this.

■ Review your last project’s risk register and find examples of where new risks were added throughout the project.

Review questions

10.1 Why is risk management crucial to project planning and delivery?

10.2 Summarise the steps involved in managing project risk and identify the role each step plays in proactive risk management.

10.3 Explain the application of the probability and impact matrix and the benefits it delivers.

10.4 What are the common risk-response strategies for both threats and opportunities throughout the project?

10.5 What are the individual actions that need to be performed under risk control?

Research activities

As with each of the PMBOK processes, the project manager or team members may be tempted to believe that they have to become qualified risk managers or experts to deal with project risk.

Let’s be clear: this isn’t necessary. However, the critical understanding and application of how project risk impacts the planning and execution of the project are required. To further develop your understanding of your organisation’s risk-management policies, procedures and practices, consider researching any of the following specialist areas and topics:

■ risk-management models

■ health, safety and workplace legislation

■ incident reports

■ material data safety sheets (MSDS)

■ probability distribution

■ sensitivity analysis

■ risk standards

■ contingency plans

■ expected monetary value analysis

■ interviewing techniques

■ risk registers

■ quantitative analysis

■ qualitative analysis

■ SWOT analysis

■ cause and effect diagrams

■ process mapping.

Case study

Migrating to the new software platform was always going to present some challenges for the business. Not only were there localised, operational issues across the state; there was also the staggering amount of ‘illegal’ software loaded on most PCs throughout the offices. Not to mention that this decision had been announced from ‘above’, with little, if any, meaningful consultation.

George, the newly ‘anointed’ third project manager in as many months, continued reading through the project mandate (written by the executive) and the project delivery plan (written by the original project manager), although he was yet to locate the project management plan itself and its component parts—notably the risk-management plan.

Categorised as a level 4 project, the mandate had provided some indication of the ‘high-level’ risks this crucial project would face, although without going into the necessary detail as to how they would be managed. With the budget approaching $1.5 million, disparate stakeholders more than likely wanting to protect their fiefdoms, political sensitivities, dated infrastructure and the obsolete XP platform, george knew he was well and truly in trouble after his first week in the role.

It wasn’t that the risks were all that hard to identify in the first place; it was the culture of the organisation that seemed to be his biggest impediment. As a recipient of recurrent government funding, the bureaucratic business had always survived by not rocking the boat and clearly by not taking too many risks. The notion of proactively managing risk through an embedded process, let alone having a resident risk champion on board, was totally foreign to everyone who worked there. George also realised that not all the potential risks to this project would in fact be negative, as the opportunities presented by this major upgrade should be identified, promoted and capitalised on.

images…regular meetings would need to be held, with risk added to the agenda. Scalable templates needed to be developed to help identify, analyse, respond, control, monitor and review risk; all project performance reporting would now incorporate risk and schedule impact updates; and…the practice of shared risk ownership would be clearly defined, allocated and communicated from now on.images

George now knew what he needed to do, and it wasn’t going to be popular with everyone. Within the hour, he had drafted out a risk-management planning document ready to send to the project’s key head office and state-wide stakeholders, contractor supervisor and their SMEs, while also informing everyone that they were now foundation members of the project’s risk-management team—and attendance would not be optional.

An integral part of the planning document was the ‘on the ground’ process george wanted followed as this migration project evolved through the different phases of development, testing and rollout, and the decision gates and required approvals that would need to be in place. This involved more than singularly filling in a risk register template, or worse still finding an example (probably with the help of google) and simply copying and pasting in the information. Ideally, george wanted a fully endorsed ICT governance standard to be adopted, but he realised that this was outside his remit on the current project.

George was proposing that regular meetings would need to be held, with risk added to the agenda. Scalable templates needed to be developed to help identify, analyse, respond, control, monitor and review risk; all project performance reporting would now incorporate risk and schedule impact updates; and, perhaps most importantly, the practice of shared risk ownership would be clearly defined, allocated and communicated from now on.

Conscious of only lip service being paid to his ideas, george further proposed a series of state-wide risk-management workshops to walk everyone through not only the process and documents, but the level of discussion, detail and analysis warranted. The last thing he wanted was risk-management discussions and registers littered with ‘lame’ risk events like legacy systems, coding errors, a lack of user input, incomplete requirements, testing failure, contractor disputes, time delays and budget blowouts. What george and his team needed to know was how the project uncertainty and the resultant impact (good or bad) would be managed proactively.

Questions

1 How will a risk-management plan change the endemic culture in both the business and the project?

2 What are ‘real’ examples of both negative and positive risks in george’s project?

3 How would you scale and prioritise these risks to enable a targeted response?

4 What existing controls and ‘new’ treatment strategies could george expect to see in the risk register?

5 Why is the notion of shared responsibility for risk so important to george?

6 Should george feel completely at ease once risk treatment has been assigned?