CHAPTER 7: RISK

This is what Agile says

Agile acknowledges risk but doesn’t really tackle it. It reflects the fact that Agile-ers are reluctant to consider anything that might get in the way of getting on with development.

Let me quote two statements about Agile and risk management:

•Traditional Risk Management is done up front and tries to envision what could go wrong all the way to the end of the project.¹¹

•Agile Risk Management is done more by practices than envisioning. Many Agile practices look to identify and mitigate risk throughout the project.¹²

•Agile exposes and provides the opportunity to recognize and mitigate risk early. Risk mitigation is achieved through: cross-functional teams, sustainable and predictable delivery pace, continuous feedback, and good engineering practices. Transparency at all levels of an enterprise is also key.¹³

These to me are cosy, warm statements, but show two weaknesses:

1.PM4A and other waterfall methods such as PRINCE2, do not simply consider risk ‘up front’, but include risk assessment as part of every planning event and monitor risks as an ongoing activity.

2.PM4A offers a comprehensive procedure for the examination of risks and the management of them, Agile does not.

This is what PM4A says

PM4A is very strong on risk management, not only when it should be done, but it also t offers a technique to analyse and manage risks.

The difference matters because …

Risk is inevitable in changing circumstances and projects are all about creating change, so we need to have a firm hold on how and when to look at risks (and opportunities). Agile doesn’t provide this, but PM4A does.

Here is what APM should do

Nothing. We should adopt the PM4A approach to risk assessment and management.

7.1 Philosophy

A risk is an event or combination of events that may or may not occur, but if they do, they will have an effect on achievement of the project’s objectives. This means that risk management is a prerequisite to our principle of continued project justification.

•A risk may be a threat or an opportunity.

•Every project is subject to constant change in its business and wider environment. The risk environment is constantly changing too. The project’s priorities and relative importance of risks will shift and change. Assumptions about risk must be regularly revisited and reconsidered, for example, at each end phase review.

•The purpose of the risk approach is to identify, assess and control any uncertainties in order to improve the project’s chances of success.

•Risk management should be proactive and systematic.

7.2 Risk management strategy

Risks can arise at any time, but there are also defined moments when the risk situation should be examined. A risk management strategy describes the procedures to be used to identify, record, analyse and control risks.

7.2.1 Risk tolerance

Another name for this is ‘risk appetite’. An important piece of information is how much risk the client is willing to take in the project. For example, a project to build a new chemical factory would have a very low ‘risk appetite’, whereas in wartime a project to capture a strategic bridge may have a very high ‘risk appetite’.

Risk tolerance can be related to other tolerance parameters; risk to achieving product quality and project scope, and risks to achieving the benefits defined in the project justification.

The organisation’s overall tolerance of exposure to risk must also be considered as well as a view of individual risks.

7.2.2 Action log

A project should record risk details in an action log. In APM, the emphasis is on constant visibility of all project information, so the action log should appear as part of the information radiator, possibly with risks grouped as ‘high’, ‘medium’ or ‘low’.

(Details of the suggested contents of an action log can be found in appendix A.1.)

7.2.3 Risk management times

APM suggests that you:

•Carry out risk assessments at the start of a project – make proposals on what should be done about the risks. Get agreement on whether to start the project or not. Risk assessment is done during the Propose phase (risks in the project proposal, the project mandate, etc.).

•Appoint an owner for every risk – build into the project plan the moments when the owners should be monitoring the risks. Check with the owners that they are doing their job and keeping the risk status up to date.

•Review every issue for its impact on existing risks or the creation of a new risk – build the time and cost of any risk avoidance or reduction, for example, into your recommendation on the action to be taken.

•Review the risks at the end of every phase – this includes existing risks that might have changed, and new risks caused by the next stage plan (if the project is big enough to use these).

•Inspect the risks at the end of the project for any that might affect the product in its operational life – if there are any, make sure that you notify those charged with looking after the product. (Use the follow-on actions section of the project closure report for this.)

7.2.4 Risk responsibilities

The team has joint responsibility for ensuring that risks are identified, recorded and regularly reviewed. The client has two responsibilities:

1.Notify the team of any external risk exposure to the project; and

2.Make decisions on the team’s recommended reactions to risk.

A risk owner should be identified. This is the person best placed to observe and monitor the risk. It might be a member of the team or a member of client management.

7.2.5 Early warning indicators

These are thresholds or levels of items that can be monitored to give advance warning that a risk situation might be developing. Examples are:

•The number of issues being raised;

•The number of quality review errors;

•The amount behind schedule; and

•The amount overspent.

7.3 The risk management procedure

Figure 7.1: Risk procedure

The risk procedure has six steps:

1.Identify.

2.Evaluate.

3.Identify suitable responses.

4.Select.

5.Plan and resource.

6.Monitor and report.

7.3.1 Identify

This step identifies the potential risks (or opportunities) facing the project. It is important not to judge the likelihood of a risk at this early stage but to:

•Identify critical parts of the project;

•Note potential sources of risk for these parts;

•Prepare early warning indicators for these;

•Identify risks and record them in the action log; and

•Review captured risks with stakeholders.

7.3.2 Evaluate

Risk evaluation is concerned with the probability, proximity and impact of individual risks, considering any interdependencies or other factors outside the immediate scope under investigation.

Probability

The likelihood of a particular outcome actually happening (including a consideration of the frequency with which the outcome may arise).

Proximity

When considering a risk’s probability, another aspect is when the risk might occur. Some risks will be further away in time than others, so attention can be focused on the more immediate ones. This prediction is called the risk’s proximity. The proximity of each risk should be included in the action log.

Impact

The effect or result of a particular outcome actually happening. For example, occasional personal computer system failure is fairly likely to happen but would not usually have a major impact on the business. Conversely, loss of power to a building is relatively unlikely to happen but would have an enormous impact on business continuity.

7.3.3 Identify suitable responses

The responses to a risk can be broken down into nine types,

These risk responses can be divided into two categories:

1.Threat

2.Opportunity

Table 7.1: Types of Risk Responses

Avoid (threat)	Terminate the risk – by doing things differently and thus removing the risk, where it is feasible to do so. Countermeasures are put in place that either stop the threat or problem from occurring, or prevent it having any impact on the project or business.
Reduce (threat)	Treat the risk – take action to control it in some way, where the actions either reduce the likelihood of the risk developing or limit the impact on the project to acceptable levels.
Transfer (threat)	This is a specialist form of risk reduction where the financial impact of the risk is passed to a third party via, for example, an insurance policy or penalty clause.
Accept (threat)	Tolerate the risk – perhaps because nothing can be done at a reasonable cost to mitigate it, or the likelihood and impact of the risk occurring is at an acceptable level.
Fallback (threat)	These are actions planned and organised to come into force as and when the risk occurs.
Share (threat or opportunity)	Both parties agree on the likely costs and share any savings or extra costs on either side of this figure.
Exploit (opportunity)	Take action to ensure the opportunity occurs and the positive impact is achieved.
Enhance (opportunity)	Work to improve the chances of the opportunity arising and to enhance the benefits gained from its occurrence.
Reject (opportunity)	A decision not to take the opportunity (at this time) because of other considerations.

If the project is part of a programme, project risks should be examined for any impact on the programme (and vice versa). Where any cross-impact is found, the risk should be added to the other action log.

7.3.4 Select

This involves selection of a risk response from the suitable responses. For each possible action, it is a question of balancing the cost of taking that action against the likelihood and impact of allowing the risk to occur.

The consideration must be done in light of the risk tolerances provided by the client.

It can be useful to look at previous projects’ lesson reports to see what risks were considered, what responses were selected and whether the responses were effective.

Figure 7.2: Risk action selection

7.3.5 Plan and resource

Having made the selection, implementation will need planning and resourcing, and is likely to include plan changes, new or modified work packages.

A risk ‘owner’ should be appointed for each risk that requires action. This should be the person with a vested interest in the state of that risk and/or closest to the risk to observe any change to its status.

Results of risk planning are documented in the action log.

7.3.6 Monitor and report

There must be mechanisms in place for monitoring and reporting on the risk actions:

•Some of the actions may only be to monitor the identified risk for signs of a change in their status.

•Risks owned should be reported on the information radiator. Every effort should be made to provide access to all parties. The progress report also summarises the risk status.

•Where a risk actually occurs, an issue should be raised to trigger the necessary actions. There may also be open risks at the end of a project that should be passed to those operating and maintaining the product. This forms part of the follow-on actions, and part of the end project report.

Consider if there are any risks and corresponding actions that must be noted in the lessons log or the next retrospective meeting.

Table 7.2: Case Study Risk Example

Risk cause	Changes to the legislation.
Event	May occur very late in its passage into law.
Effect	Giving insufficient time to include the changes in the training.
Probability	High.
Proximity	Shortly before the government’s announced target date.
Impact	Potentially high.

Table 7.3: What Action Could Be Taken?

Avoid	No – we have no control over when changes may be made or the number of changes.
Reduce	Yes – we should plan to delay printing until the last minute and be ready to lay on extra courses if changes affect staff who we believed were not to be affected. The whole plan should be geared to being ready as early as possible with spare time for late changes.
Transfer	No – We can’t just transfer the problem to the hospital trust.
Accept	No – The hospital trust would not be happy if we just accept that our training might not reflect late changes.
Fallback	Yes – This joins with the reduce option in terms of ‘if it happens’. As the project will be using APM, it is already geared to accepting changes during development.
Share	No – We don’t want to share any costs here.

¹¹ www.agilealliance.org/wp-content/uploads/2016/01/Agile-Risk-Management-Agile-2012.pdf.

¹² Ibid.

¹³ www.leadingagile.com/2015/03/agile-is-risk-mitigation.