Quantitative Risk Analysis: Process Overview
Categories:
risk
Categories: risk
|
This article is the ninth part of my look into project risk management, and today the topic is quantitative risk analysis. What is quantitative risk analysis?Well, it’s difficult to spell, that’s what! And often confused with qualitative risk analysis. Simply put, it’s the next step after you’ve identified the likelihood, probability and any other risk metrics that you consider important. It’s the process of getting a number from those risk assessments and seeing what the financial, resource and time impact would be should the risks happen. On large projects it’s a way of providing greater levels of confidence and management oversight by reviewing substantive risks in a very structured way, allowing the team to work out what the best course of action is to manage the risk. InputsThe inputs to this process are:
What documents should you review?Most of your project documents could be considered fodder for this process, but beyond the risk register and risk report here are the most important ones: Assumption log – review any assumptions and constraints that affect risk. Basis of estimates – this will tell you how estimates were created and the less scientific ways of developing estimates will represent a higher risk to the project. Cost and resource estimates – use these as a starting point to work out the cost or resourcing variability for any given risk. Duration estimates – use these as a starting point to work out variability in the schedule. Cost forecasts – these are helpful if you are calculating confidence levels because you can compare the quantitative cost risk analysis to your forecast and see how on track you are likely to be. Schedule forecasts and milestone list – ditto for confidence levels related to scheduling. Tools and TechniquesThere are also quite a lot of tools and techniques that will be helpful in carrying out this step of your risk management process:
The expert judgement input you need here is going to be quite a specialised skill, so if you have risk certified professionals on the team, use them to support you. Data analysis can be undertaken in a variety of ways and you can select which is going to be the most appropriate for the type of risk you are assessing. Simulations like Monte Carlo analysis which simulators the combined effects of individual risks to see what their impact would be on successfully completing the project. Sensitivity analysis helps you understand which individual risks are most likely to affect the projects outcomes. You’ll typically see these represented in a tornado diagram. Decision tree analysis is a way of visually representing several different options for dealing with risk and reviewing what the impact of each of those options would be. It helps you choose the best risk management approach, and it typically focuses on working out the cost of different choices. Influence diagrams show the interconnections within the project, highlighting what relationships influence particular outcomes. In itself it isn’t going to share many insights about the impact of risk, but it is a good starting point for seeing how different stakeholders or tasks connect and influence each other. OutputsThere is only one output from this process and that’s the risk report. Update the report with the formal outcome of the analysis. If you have only used this process for some risks, those are the ones you want to update – it’s fine if you don’t have the same level of detail for every risk, because you are prioritising effort and time on the risks that are going to have the impact for your project. Do you always have to do quantitative risk analysis?No, you don’t. It is a good technique to use if you’ve got good data. If your risk data is skimpy and your baselines are more guesswork than expert judgement, all you are doing is building an analysis on shaky foundations. This is an appropriate process for large, complex, strategic projects or where there is a requirement to do it because a contract or stakeholder says so. However, if you choose not to go ahead and quantitatively analyse risk, then be aware that it’s really the only reliable way to aggregate and review the overall risk exposure for your project and onwards up into the rest of the portfolio. So if you need that data, you’ll have to do it. Next time I’ll be looking at how to plan risk responses. In case you missed them, and to save you a job digging through the archives, here are the quick links back to the previous instalments: Read part 1 here: An introduction to risk management Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A) Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B) Read part 4 here: Tailoring Risk Management Read part 5 here: Planning Risk Management Read part 6 here: The Risk Management Plan Read part 7 here: Identify Risks Process Read part 8 here: Qualitative Risk Analysis Pin for later reading
|
The Benefits Management Process [Video]
Categories:
benefits
Categories: benefits
|
In this video I explain the six steps for managing the benefits realisation process on your project. They are:
There’s more detail on each of those steps in the video, but if you prefer to read the highlights, you can find a text overview here: Pin for later reading
|
Archiving Project Data
Categories:
project data
Categories: project data
|
Over the last couple of months I’ve looked at some of the tech trends affecting us as project delivery professionals working in an online world. One of the technical challenges I haven’t talked about yet of using collaboration tools is how you archive the data effectively. Archiving tools are available, but they are yet another system to integrate within your technology landscape. There’s nothing to say that their development will keep up with the constant evolution of the SaaS marketplace; in fact, I think it’s fair to say that they aren’t. Forrester reports that only 15% of businesses actively capture and archive data from collaboration sites (Hayes & McKinnon, 2015). The old approaches to data management and records compliance just don’t cut it with new communication channels, even where interoperability makes it possible. This problem is going to get worse before it gets better. Regulatory bodies will catch up with the increase in data being stored across collaboration tools and online and will demand that companies manage their archives more effectively. Organizations will be forced to adopt more robust methods of managing archives with the associated cost of data management that comes with this. Archiving strategies need to be built in conjunction with the adoption of online tools and with flexibility in mind. All the trends I’ve talked about – like AI, robotic processing automation and interoperability - bode well for both the manufacturers of project management software, and (one would hope) the people using them. Better data, better collaboration, and better end-to-end systems should increase the likelihood of success on projects because it all contributes to better decision making. And I believe collaboration tools are already improving the results of teams where they are being used – I certainly see that in the conversations I have with my mentoring clients and the project managers I work with every day. However, the great results we expect from tech will only come about if the tools being applied meet a genuine business need. You can’t layer tools into a broken, uncommunicative team and expect them to suddenly work together, just like that. The team culture has to be ready and open to change, the infrastructure has to be there, the management desire to want virtual and online working to succeed has to be there – and people have to see the benefit. The business need that drives all of that is likely to overlap the areas of technology, collaboration, and culture. The way people work online—both in and outside the project environment—is not perfect, and we can expect to see more evolutions and innovations in the years to come, both in terms of tools and the way in which interactivity is encouraged and fostered. I hope that we will eventually look back and realize that this was the time that organizations made the shift to the collaborative project environment. While the societal change may feel fast, in organizational terms, it is infiltrating slowly. Project leaders are essential in supporting innovation and effective collaboration in all its forms.
|
This article includes a few points that were made in my PMI book: Collaboration Tools for Project Managers. Given what we’ve been going through and seeing so far this year, it felt appropriate to try to pick out some comments on tech for teams and where that might be taking us – because it seems to me that virtual working is here to stay.
Key Achievements for Project Cost Management [Infographic]
Categories:
cost management
Categories: cost management
| I’m often asked about ‘the minimum’ for any given project management process – as if the rest of the process is somehow superfluous and anyone who does those extra bits is wasting effort. I think most project management processes are implemented with ‘the minimum’ in mind – or at least they should be. However, project cost management is a big topic and it got me thinking about the kinds of things I would consider ‘winning’ at managing the project’s financials. What would the minimum be? Ultimately, if stakeholders are happy and the work is progressing and under control, then I’m winning! I’ve put what I think the key achievements for project cost management should be in the infographic below. I’m not sure that ‘achievements’ is quite the right term because this is our job we’re talking about, not some kind of badge-collecting exercise. But I couldn’t think of anything better! Leave a comment below if you’ve got a different term I should be using. These are the things that I consider to be the basics for myself doing cost management on a project. Your ‘minimum’ list might be different. And if it is, let us know in the comments!
|
The key things are:
Qualitative Risk Analysis: Process Overview
Categories:
risk
Categories: risk
|
This article is part eight of my look into project risk management, and today the topic is qualitative risk analysis. I did not expect this to turn into so many parts, but risk management is an in-depth topic and there’s a lot to cover! In case you missed them, and to save you a job digging through the archives, here are the quick links back to the previous instalments: Read part 1 here: An introduction to risk management Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A) Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B) Read part 4 here: Tailoring Risk Management Read part 5 here: Planning Risk Management Read part 6 here: The Risk Management Plan Read part 7 here: Identify Risks Process What is qualitative risk analysis?What is it, apart from being a word that lots of people (myself included) stumble over and get confused with quantitative risk analysis (more on that next time). Qualitative risk analysis is simply the process of prioritising the risk based on probability of occurrence and impact, as well as some other characteristics if they are relevant. It’s what most of us would recognise as an important step in project risk management – the part where we decide which are the risks we are going to focus on because we don’t have time to spend effort on all of them. Perform Qualitative Risk Analysis is the third process in the Knowledge Area of Project Risk Management. The point of doing it is to prioritise individual risks by looking at how likely they are to happen (probability of occurrence) and how bad they would be for the project if they did happen (impact). When you look at those two data points, you can prioritise all the project risks. As with risk identification, it has to happen throughout the project because risks come and go and also change in severity. Something that has a low probability of occurrence today could have a dramatically different likelihood of occurring tomorrow if something else happens to make it so. The process doesn’t talk much about risk proximity although it is mentioned in a ‘other factors you can consider’ list in the PMBOK® Guide. I find proximity another useful measure for prioritising risks. That looks at how soon the risk is likely to happen if it happens at all. Risks that are likely to occur far in the future can be postponed for a bit while the team focuses on risks that have a likelihood of occurrence for next week. In the process we review the risks we identified and prioritise them based on our subjective opinions and those of the team. Therefore it’s only useful if we also understand the risk assumptions and attitudes being brought to the table by the people doing the assessing. It’s important to note that the assessment of risk is relative – you compare the risks on this project to each other, and come up with a relative priority. If you compared them to the risks on another project, you’d probably get a different result. InputsThe inputs to this process are:
The stakeholder register is important because it gives you input as to who should be involved – and because assessing risk is generally subjective, even if you do try to use data-based categories for the assessment, it’s helpful to know what their risk tolerances and appetite are. If you use a neutral (professional) facilitator, they can help uncover some of the bias in the team and assess the risks more objectively. You’d hope, anyway. Tools and TechniquesThere are also quite a lot of tools and techniques, many of them centering on interpersonal skills and professional knowledge. The tools and techniques you’re likely to use include all of these (there are quite a few to choose from, you won’t necessarily use them all on the same risk – pick and choose what makes sense to help the analysis of the particular risk you are looking at):
There are quite a few ways you can do data analysis. Risk data quality assessments: This is where you look at how reliable the data is that you are using for your assessment. If the data scores low, you will want to get some better data on which to base your next steps and action plan. Risk probability and impact assessment: This is what most people think of when they think of risk analysis. It’s the table you will find in your risk management plan that tells you how a risk will score based on how likely it is to happen and the impact to the project or business if it does. Other factors: You can consider pretty much anything you like when you make your judgements about risk. The PMBOK® Guide lists a few including proximity (as we saw above), controllability, urgency, connectivity and strategic impact. Use as many criteria as you can do reliably and repeatably so you’ve got lots of data to go on when you make your risk assessments. I tend to find that organisations stick to probability and impact, and some go as far as adding in proximity (how soon the risk is going to happen, if it happens). However, there are others, like how easy the risk would be to manage, how easy it is to detect and control, strategic impact and how connected it is to other risks – because that would influence a wider section of our risk pool The challenge with doing the assessment is identifying unconscious bias in both the individuals involved in the process and the process itself. You’ll need to be aware of the risk appetite of the organisation and just challenge everything. Do your best! OutputsThe outputs of the process are updates to the project documents, specifically:
The end result of this process is that you have a bunch of documents to update. At the end of the process you get a list of risks (from the process to do risk identification) with a weighting or score of how risky they are. That feeds into a future process which is to look at what you are going to do about those risks. You’ll want to make sure your assumptions log, risk log, issue log and risk report are all up to date. These are all living documents so in case you hadn’t realised by now, this process is something that repeats during the life of the project. You’ll be doing risk prioritisation pretty much in every team meeting, or I’d recommend at least on a monthly basis. Share the documents with whomever needs to see them so the whole team has access to the latest information. In my experience, as you talk about the riskiness of risks, you also formulate ideas for what you might do to mitigate them. So the processes happen in parallel, often within the same risk workshop. It’s helpful to understand them as separate activities, but don’t worry if you end up planning risk responses at the same time as having a conversation about how troublesome the risk is likely to be. Next time I’ll be looking at quantitative risk analysis. Pin for later reading
|
