Risk management is a general and widely popular topic in project management practices and you should apply it for every project of your organization. Risk management practices quoted in this article are validated by the Masters in Project Management body PM.MBA. https://pm.mba
Contingency of risk
The organization may decide not to take any action before the risk occurs, but instead to plan an action to be taken once the risk occurs, or if it becomes more certain that the risk will occur. For example, it is very difficult to think of many practical ways of eliminating the possibility of key staff becoming ill at a critical point in the project. Contingency planning might identify staff who could cover the role of a staff member made unavailable in such circumstances. This action differs from other actions as generally it only incurs costs if the risk materializes. As with all auctions, there will be costs associated with managing the risk (see Section 7.5). There may also be costs associated with creating the conditions that would allow the contingency action to take place, as is the case when back-ups of files have to be taken to allow the contingency action of restoring files if they are corrupted.
Explain the risk management actions – practice
Explain the risk management actions that could be taken to reduce the risks to the Water Holiday Company integration project scenario that were noted as a result of Activity 7.2.
When selecting the risk management actions to be taken, it may well be that some actions are appropriate not just for one particular risk, but for several. For example, there is a risk that a delivered software function might not perform at the outset to the satisfaction of users, so that time is wasted in re-work. Two risk management actions are identified: to have a walkthrough of the interface design with users to ensure their requirements are met, and to have a peer review of the code to reduce faults in it. It happens that the peer review of code also identifies changes that reduce the risks of the code being difficult to maintain in the future.
The action chosen will have an impact on plans. In the above example, two new review activities need to be inserted into the project schedule. It is important to ensure that the benefits of these actions outweigh the benefits of inaction. Two extra reviews might take up two days, say, so the reduction in testing and correction would need to be more than this for it to be worthwhile.
Key decisions in risk management are how many risk management actions to approve and in relation to which risks. The initial focus is likely to be on the show-stoppers – risks that would prevent the completion of the project.
Where a quantitative approach has been adopted, the risk exposure figures for individual risks could be summed to get an overall project risk exposure. If necessary, a number of actions could be planned to reduce the risk exposure of the project to an acceptable level. As we saw in Section 7.5 with the discussion of risk reduction leverage, these actions would incur costs.
With the qualitative approach, a risk tolerance line has been shown on the probability impact grid in Figure 7.2. Read The Qualitative Approach to Project risk assessment. https://agileprogramming.org/qualitative-approach-to-project-risk-assessment/
The organization will not approve a project with risks that occur above this line; therefore, action would be taken to ensure a new position on the grid for these risks by reducing their probability or impact, or both. Familiarize yourself with the Quality control and assurance practices by reading the Quality control and quality assurance in Project Management and Agile practices article on ScrumTime.org. Reference: https://scrumtime.org/quality-control-and-quality-assurance-project-management-agile-practices/
PLANNING, MONITORING, AND CONTROL
The risk identification, risk assessment, and the selection of risk management actions occur primarily during project planning, but the processes described above will also continue throughout the life of the project as new risks are identified.
There may also be secondary risks that result from actions to reduce initial risks. For example, outsourcing software development to a software house because of the inexperience of in-house developers will itself generate new risks relating to the reliability of the external suppliers.
The monitoring of risks should be part of the project control cycle (see Chapter 3). The monitoring process is usually a mixture of periodic reviews – say once a month – and reviews after milestones, such as the end of a project stage.
It is important to have a structured project risk plan to document the planning and to facilitate the monitoring and control process. This will consist of a risk register, also known as a risk log, which lists all the risks identified with the project (see Figure 7.3), and the individual risk records (see Figure 7.4). Typical headings are shown in the figures, but others could be added – for example, a risk category or the earliest date that the risk could occur.
Initially, only the risk description and owner need to be recorded. The post-risk management values and plan number are entered after the appropriate actions have been approved and the risk plans formulated.
Risk register – 7.3
Risk record – 7.4
Figures 7.3 and 7.4 refer to a risk owner. The risk owner is responsible for ensuring adequate management of the risk, including how and at what intervals a risk will be monitored. If the nature of risk changes during this process, it may be necessary to revise earlier risk management action plans.
Managing risk is a continuous process
Managing risk is a continuous process. It involves identifying the risks and analyzing them to establish their probability, impact, proximity, exposure, and priority. Remedial actions need to be determined and plans produced to implement these actions, followed by scheduled monitoring and appropriate control. The whole risk management process needs to be made visible by adopting sound communication mechanisms.
Most of the risks that you will experience will already have happened on a previous project. A key aspect of risk management is learning from past projects. This is the main reason for the writing of lessons learned reports at the end of a project, as mentioned before.
Sample Questions for defining project risk
1. Which of the following best defines a contingency action?
a. An activity that is planned to take place if a risk materializes
b. An action was taken at the start of a project that reduces the potential damage if a certain risk does materialize
c. An agreement that the users accept a particular risk
d. An activity that prevents a risk from materializing
2. What is the maintenance of a risk log designed to do?
a. eliminate risk
b. save money
c. control risk
d. prevent system development failure
3. Which of the lists below best identifies what is examined when risk is assessed?
a. Probability, proximity, owner
b. Impact, probability, team experience
c. Cost, benefit, business case
d. Probability, proximity, impact
4. Which of the following is NOT an action that would reduce a risk?
a. accept it
b. prevent it
c. reduce it
d. transfer it
POINTERS FOR ACTIVITIES
Among the facts that could lead to difficulties in the Water Holiday Company integration project are:
Two sets of employees, some of which are at a high managerial level, are to be merged. There could be conflicts between the two.
Two different holiday booking systems are to be merged. There will almost certainly be different detailed requirements relating to the different types of boating holidays.
More specifically, there could be incompatibilities between database structures of the systems to be merged.
Some staff will need to be made redundant in order to gain the cost benefits of the merger. Some staff may leave of their own accord if they do not approve of changes. They may take their skills and expertise to competitors. In any case, specialist skills and knowledge could be lost.
IT aspects of integration depend on physical prerequisites such as the completion of the new merged service center.
Technical issues when the integrated system is launched may lead to the system going off-line or having reduced availability. This could lose potential business.
There is a danger of the previous customers of Canal Dreams and Minotaurs not being aware of the new Water Holiday Company identity.
Possible changes in international trading relationships could affect cross-border businesses such as Minotaurs.
Note that these are issues of concern at the point where the first plans are being made. They might feature as ‘risks’ in the business case document. Some of the concerns will be eliminated at the planning stage through the choice of project activities that address them.
Activity – identify risk
The following risks might be identified. Other risks can certainly be added. Read the Risk management in project management article on Brighton’s website if you need additional help with this. https://brightonbot.com/risk-management-in-project-management-practices/
Activity – Suggest risk actions
Note that the actions below are just suggestions. You may be able to find other, perhaps more effective, risk management actions.
| Risk | Possible risk management actions, https://www.policymatters.net/assessing-risk-in-project-management-quantitative-approaches/ |
| 1. Differences in views on new system functionality lead to delays in reaching an agreement | Escalation process established that allows relatively impartial jurisdiction on disputes |
| 2. Failure to identify the requirements of both sets of system users leads to an incomplete set of functions | Separate business analysis of both businesses
Production/comparison of cross-referenced functional requirements for both organizations |
| 3. Failure to take account of data needs of both sets of system users leads to shortcomings in merged organizational database | Separate data analysis of both businesses
Production/comparison of cross-referenced data models for both organizations |
| 4. Lack of access to knowledgeable system users lead to incorrect/incomplete assumptions about requirements | Incentives to key subject experts in both organizations with reassurances about continued employment |
| 5. Knowledgeable system users not available for acceptance testing, and other tasks associated with transfer to operational use | |
| 6. Delayed access to new premises means an installation of new IT infrastructure delayed | Existing premises are acquired and re-purposed |
| 7. Technical issues when the integrated system is initiated | Exhaustive system and acceptance testing |
| 8. Lack of availability of new system affects bookings |
‘Soft’ start-up of the new system in the off-season for bookings Automated parallel-running of old and new systems with possible fall back to old systems Phased transfer to the new system |
| 9. Lack of links from websites for old businesses to new leads to lost customers | Retain old websites with links to new ones Mailing campaigns to previous customers |