Over the past decades the concept of risk management receives a high volume of recognition. All managers should tackling their risks effectively.
"Bad news" should never arrive out of the blue.
Should the possibility be analysed and identified? Contingency actions put in place?
We must do the necessary research, analysis and risk management process for a project to improve its chances of success. We need to collect all the necessary information from all relevant sources.
“Let’s not worry too much about this now – it almost certainly won’t happen anyway". That's what we often hear. The danger of such optimism is fairly obvious.
Project might adopt different approach to risk management. In some highly regulated industries, i.e health, safety or legal it is a serious topic. In others, like IT projects it suffer generally due to requirements misalignment and end user resistance.
The right model for a project will need to answer some fundamental questions:
- which risks are involved in the plans?
- have these been analysed and weighted?
- are there plans to mitigate them?
- how do we execute and track those mitigation plans?
- are these plans effective?
- any lessons learned from previous projects?
Heagney (2011) suggests that risk management is a systematic process to identifying, analysing, and responding to project risks.
A formal and comprehensive project risk plan allows project managers to be proactive and add discipline to a project.
The project risk management begins early in the project life cycle. Typical examples include: loss of key team members, weather emergencies, technical failures and poor supplier performance.
Many project managers wait too long to access risk factors, because they assume that there are too many unknowns. Most desirably, during the early brainstorming sessions.
The Six step process
The process of risk management generally involves a great detail of research and it is generally conducted in following steps:
Make a list. Here we brainstorm on a formal session where all risks are captured. It is important, that the entire team gets together to make the list. Project manager completing risk assessment on its own is a really bad idea. Even if any of the team members are left out, there is a likelihood that some risks might not be captured. Certain level of research is necessary. This includes phone calls, e-mails, visits etc. We initiate a dialog of what could go wrong. Department managers can be very helpful with this tasks. The approach should be holistic.
When analysing risks, there is a possibility of missing objectives, changes from stakeholders, technological problems or staffing changes. There are some particular aspects to consider:
- Time. The critical path needs to be analysed to look for uncertainties.
- Cost. The estimates have uncertainty attached to them, Are these fairly accurate?
- Quality. Do we have assurance in the processes or is the key part of the project outside of control?
- Health and safety. What are the risks to people?
- Legal. The level of legal risks to organisation.
- Organisational environment. Wider risks affecting the organisation.
-Risks after the project is completed
Often checklists might be used to determine relevant risks. Those, should be carefully assessed with the stakeholders. Some questions may include:
Do the objectives of the project fit into the client’s overall business strategy?
Is there any risk of this strategy changing over the lifetime of the project?
What is the volatility of the business environment for the project?
Could any unforeseen changes impact the viability of the project and its deliverables?
Are there any climactic, geological, meteorological or other environmental factors that could impact the execution or deliverables of the project?
How many sites will the project deliverables be implemented in?
Are there any geo-political, economic or social risks that might impact the project?
When are the project deliverables required; how precisely was the date determined?
What would be the risks of late delivery?
Is the project dependent on other projects or external resources outside its control?
Are other projects dependent on this project?
What was the financial business case (cost/benefit analysis) for the project?
What are the implications if the budget is exceeded?
How clearly are the project objectives and deliverables defined?
Are the technical specifications crystal clear and do the project staff know exactly what is required?
Can the test ‘fit-for-purpose’ be carried out?
What would be the implications of delivering products that are of a lower quality than defined?
How risky is the project with regard to the technical deliverables?
To what extent is it based on new, and possibly unproven, technologies?
Is the project dependent on external suppliers to any extent?
Has the project been planned effectively?
Are too many tasks in the project plan inter-dependent and/or running in parallel?
Have all the necessary resources been estimated and scheduled?
Are there any significant risks with regard to obtaining and retaining all the specialist resources (particularly staff) required to execute the project?
Does the experience of the project manager cover this business application?
Have they managed similar sized projects successfully in the past?
Is the personality of the project manager suited to such an endeavour?
What is the calibre and experience of the senior staff?
Where will the project team be located?
What are the implications for communication and co-ordination if split across sites?
Where will members of the project team be located in relation to the client user community?
Will the project be managed using formal project and, for IT projects, development methodologies?
How well do the project team understand the chosen methodology?
What is the commitment level of the user community towards the project?
Management and workforce?
Are there any implications for cultural and organisational changes outside the control of the project?
Will user training be required to engender commitment?
2. Determine the Probability and impact. This allows for prioritising risks and helps to define how much effort, resource and staff and money should be spent to prevent the worse to happen. This should also be accomplished with the team members. It is sufficient to use HIGH-MEDIUM-LOW scale and apply it to risks. The next question we need to ask is what would be the impact of the project? - the Impact. Given the assessment of Probability and Impact we should focus our efforts on those with highest scores.
3. Mitigate the risk. Some risks can be prevented and others mitigated. Some procedures might be required here for this step. Risk of not finishing major activities might be reduced by adding some buffer at the end of stricter controls. Some organisations are not willing to accept risks, but outsource it through insurance. Trials might also reduce risks.
This step in risk management is essential. There is no point in identifying and prioritising the risks if we cannot develop relevant responses to the risks.
The risk can be:
- Accepted - we do nothing and accept the risk with any further provision. It should only be appropriate when the probability is truly negligible or there is no logical or cost-related responses possible. This decision should be followed by a full and frank discussion. This type of response should be monitored rather closely. Should the probability or impact increased it needs to be re-evaluated again.
- Prevention - taking measures to prevent from happening. Sometimes low cost solutions can be readily devised so cost-benefit analysis is desirable so that the project does not "swallow" significant amounts of money to prevent the risk.
- Reduction - it may apply to the probabilities or the impact of the risks. Again, a professional cost-benefit analysis could be well utilised here.
- Transfer - contractual transfer to another party. It can be an insurance company or contractor (supplier). Such transfer should especially be considered when the impacts are significant.
4. Consider contingencies. Contingencies are the actions that we take when risk occurs. These are directly lined to the priorities. If the risks are of high priority, we might want to identify more contingencies. If the risk falls in the middle, at least one contingency should be considered. Lower level risks might be assessed as negligible.
5. Establish trigger points. This could be the most important element of the project risk plan. It is when the risk become close to reality so we need to trigger the contingency. The trigger should be at specific point of time or defined range of time.
Contingencies should be considered in case prevention, reduction and transference is not available to any cost-effective basis. This will require development of coherent plans to deal with the situation once it happens including financial resources. The plans should be documented and tested.
Establishing reserves allows leverage the plan to its fullest potential. The contingency reserves are additional time and/or budget to account for risks. These can be created for known risks and unknown risks. Sometimes we don't know what we don't know. Perhaps 10% would be efficient.
Multiproject Risks
When we run multiple projects we face complex issues. Here, we require specific perspectives. Firstly, we must focus on individual projects and individual project risks. Then, we should assess the entire portfolio and determine the nature of the relationships. We must identify where the projects overlap and determine what might go wrong in this areas. It specifically applies to the transition from one project to another. The areas where projects touch are called coordination points. So, in reality, we manage individual project risks and put the focus towards the coordination points.
Risk management tools
We can use risk matrix or risk log when managing risks. The risk register is the last ingredient of a project risk plan. It is a dynamic tool that can help to track risk status as the project matures. As project progresses risks are added to risk registers. This methods can provide a useful tool for decision making.
Sensitivity Analysis
With this analysis an expected value for the main inputs ( for example cost) to a project is put into calculations of an outcome. It can be optimistic ( +n%) or pessimistic (-n%) value. (Value of 10 is often 10).
The price of materials and labour for the project is likely to fluctuate. As the contract price needs to be fixed in advance the project manager needs to see the effects of fluctuations on bottom-line performance. The materials are the major contributions and overheads are calculated on a basis 175% of direct labour.
For example:
Materials - £0.60m
Direct labour - £0.20m
Contribution to overheads - £0.35m
Revenue - fixed at £1.2m
The formula is:
Revenue
- materials costs
- combined labour and overhead costs
-----------------------------------------------------
= profit
The analysis shows that should materials increase 10% the project will make a loss.
Expected value
The expected value of an event is the possible outcome times the probability of its occurrence. For example, if a project has 50% chance of profit of £10.000. The expected value is 0.5 X £10.000 = £5.000. The per cent change can be estimated using Monte Carlo analysis.
Monte Carlo Simulation is available on most popular spreadsheets (for example MS Excel)
In the example shown above. The revenue is between £750,000 and £1,150.000 if the outcome is good. The material income is less certain £250,000 is most likely, but there is a risk it will be more. It is unlikely that it will be less than £250,000. The profit (revenue-material-labour) is £150,000.
If we add the uncertainties together the result will be another distribution. The project has only 15% chance it will make £150,000 profit.
PERT Analysis
Program evaluation and review technique (PERT) os a model used when planning projects. It intends to deal with the likelihood that a single value given as an estimated time for completion of activities is going to have a degree of error. Therefore, instead of calculating single time we estimated 3:
- optimistic time - ideal conditions
- most probable time - normal conditions
- pessimistic time - conditions where things go wrong
The analysis applied can be very simple or go into complex calculations. Below we use a simple calculation.
The activity arrows have now got 3 figures - optimistic, most likely and pessimistic. Activity A - Optimistic - 3, most likely - 5, pessimistic - 7.
We need to calculate the expected time for the activity.
o - optimistic
m - most likely
p - pessimistic
expected time = [o + 4m + p]/6
For activity A, the expected time would be: [3 + (4 X 5) +7]/6 = 5. And so on.
In order to save drawing the distribution each time it is possible to compare activities in terms of variance measure.
variance of activity time = [ ( p - o ) / 6 ]2
PERT provides a certain level of risk assessment as it has 3 values for time estimates. The objective of risk analysis is to allow the project manager to apply contingencies to minimise it.
The PERT technique remains popular among very large projects.
We can calculate variance for each activity time.
And then calculate the probabilities of completion.
A basic analysis of a chance of success through PERT may demonstrate that with the level of resources demonstrated we might have very little chance of success. Communicating this level of risk and requiring of senior management to accept this type of risk may result in an opportunity in re-scoping your projects and much higher chances of success that is acceptable to both the project manager and the firm.
Exploitation of opportunities
We must not forget about project opportunities. There are many approaches for assessing them.
Negative to positive - where a risk does not materialise there is a benefit and can be capitalised. For example technology might prove to do more than originally thought, the contingency allocated would do less and could be developed further for other applications. Similarly when a task takes less than expected, there should be an opportunity to use that early benefit and move the rest of the project faster.
Opportunities of response - when a risk deem too high and mitigated, this itself presents opportunities. For example, using an existing supplier to mitigate the risk of unknown suppliers being involved in the project presents an opportunity for further learning.
Random good fortune - be alert for opportunities by breakthrough that could have been expected.
The opportunities can be put through similar to risk management process through Sensitivity analysis and probability analysis.
Summary
The issue of risk is central to project management. There are always risks and the way we manage them contributes to the success of failure. It is therefore helpful to use the identification, analysis and evaluation techniques.
However, the risk and opportunities management is only half of the story. It is important how we respond to it.
Bibliography:
Heagney, J., (2012), "Fundamentals of Project Management", 4th edition, American Management Assotiation
Lock, D., (2013), "Project Management", 10th edition, Farnham
Maylor H., (2010), "Project Management", 4th edition, Harlow
Comments