Really easy, import your plan, fill out the risk register, add uncertainty to the desired estimated duration, then run the montecarlo analyzer to create and impacted risk plan.
Serveral reports are created automatically including tornado charts of the most critical activities, most probable finish dates, activity variances etc, scatter graphs.
It is also easy to model LDs using activities attached to the KPIs.
I don’t use Pertmaster, so I can’t really comment on your approach. I’m probably going to get canned for saying this, but I’m not entirely convinced that the PERT formula gives me the cumulative affects of risks I want to see in my schedule (apologies Raf), which is why, given the option, I lean towards Monte Carlo simulation for schedule risk analysis. However, don’t let me put you off!! :)
As for your question, my maxim for project planning is ‘No Surprises’, so the earlier you brainstorm the risks (thought shower / mind bath for the more PC amongst us), the better in my humble opinion. I tend to be a fan of using Probability / Impact grids at the bid stage but maybe that’s just me.
Once you have your post-mitigated risk register (thanks Oliver), you can then look at the tasks it will impact. It isn’t a one-off exercise, you should have regular risk reviews throughout the course of the project lifecycle. It will not make your project bullet-proof by any stretch of the imagination, but risks do evolve and change in emphasis as the project progresses.
It may sound a little pessimistic, but you always need to keep half an eye on the ‘What will go wrongs’. I’m not suggesting constantly re-assessing every single risk that’s been identified, some may be so insignificant that they aren’t worth reviewing all the time, but keeping a handle on them so they don’t bite you on the backside is what I believe good risk management is all about.
As the risk register is a living document, my preferred reviewing method would be...
1) Concentrate on the showstoppers.
2) Periodically review all the risks on the register.
3) Add new post-treated / mitigated risks to the register.
4) Remove risks that are past their sell-by-date.
With the risk reviews, you are always trying to identify new risks that might affect the delivery. In project management ignorance isn’t bliss, so the only difference between the initial brainstorming session and the last formal risk review will probably be that you’ll identify more risks during the original session and you won’t have a risk register to review. :)
Hope this helps in your quest.
Regards,
Darren
Member for
17 years 6 months
Member for17 years6 months
Submitted by David Appelfeld on Wed, 2008-06-11 10:24
Thank you very much for your comprehensive reply. I like your point that I should mention just the most significant risks. I am doing the schedule and risk assessment by Pertmaster and I will try to found most critical risks with the highest sensitivity on influencing the project. Is it right method? After reading your replay I have got other question for you but also for others. When is the right time to do risk assessment? Is is just during the early phases like tendering or does it have also meaning do it during later phases? What is then the different between this two assessments?
Regards,
David
Member for
18 years 6 months
Member for18 years6 months
Submitted by Oliver Melling on Wed, 2008-06-11 10:00
’I do not want overload my schedule by huge number of the risks which will not have impact on the plan’
If they do not impact the plan, then they are not potential risks. If you have a massive list of risks, they should form your pre-mitigated risk register. Then you should try to eliminate, remove or isolate as many as possible to reduce your list.
This final list is your post-mitigated risk register and contains the risks that should impact your plan.
All risks, or opportunities for that matter, aren’t necessarily always shown in the schedule. Depending on the likelihood or impact of the risk, you would probably only need to show the top ten risks, the showstoppers that would be the biggest barriers to successful project delivery.
Every risk has the potential to have an adverse affect, it’s the nature of the beast. To reduce the uncertainty in your project, you therefore need to systematically identify each risk and represent it’s severity through probabilistic risk assessment.
There aren’t any hard and fast rules to gauge how many risks you will identify on your project, but there are a number of things you have to consider:
1) The nature of the project – have there been similar projects in the past or is it totally unique and never undertaken before.
2) The experience of the project team – will they have the competence to identify, assess and evaluate the risks.
3) The project definition – is there enough understanding of the requirements to deliver the project.
4) The project breakdown – has the work been decomposed with sufficient granularity to aide risk identification.
The last proviso also enables me to approach risk identification from a consistent starting point. Depending on whether your schedule is product or work based, you start at the lowest level of the PBS / WBS, reviewing each product / work package in isolation, categorising each risk as Rav suggests and build up a picture of the project risks as you work from the bottom up.
After you’ve assessed your exposure and determined how you can / will address each risk, you can then collate and document all these factors in a risk register. This way you can always ensure, through regular risk review, they will stay on your radar as risks rather than mysteriously morph into issues. As an added bonus you get to keep your schedule (relatively) clutter free as well. :)
In BlueScope Steel (My previous employer) we have 16 sets of risk categories, Like
- Contractual Risk,
- Technology Risk
- Financial Risk
- Cash flow risk
& SO ON...........
Under these 16 categories, we used to analyse different aspects of the project and then rate them on a scale of 10 and then develop a contingency plan for those risks.
Sometime, we used to have 20 major risks, while even on small projects we used to have more than 20 major risks.
Instead of size of projects, what matters is complexity of project. 1000 activties will not determine the number of risks, but depends upto what levels you have developed the program.
Member for
20 years 11 monthsRE: Number of risks in the project
Darren
You can get a free Pertmaster evaluation at http://www.primavera.com/products/Pertmaster/pertmasterevaluation.asp. Also might be worth looking at the Pertmaster user group at http://tech.groups.yahoo.com/group/pertmaster/ for what users have to say.
Member for
17 years 8 monthsRE: Number of risks in the project
Excellent... I may even be able to finagle a licence transfer if there is one going spare here.
Member for
18 years 6 monthsRE: Number of risks in the project
Really easy, import your plan, fill out the risk register, add uncertainty to the desired estimated duration, then run the montecarlo analyzer to create and impacted risk plan.
Serveral reports are created automatically including tornado charts of the most critical activities, most probable finish dates, activity variances etc, scatter graphs.
It is also easy to model LDs using activities attached to the KPIs.
Member for
17 years 8 monthsRE: Number of risks in the project
It may be worth examining a trial version then. How user friendly is it Oliver?
Member for
18 years 6 monthsRE: Number of risks in the project
I have used Pertmaster risk expert on a few bids and it does use monte carlo analysis amongst other things to impact the plan.
Member for
17 years 8 monthsRE: Number of risks in the project
David,
I don’t use Pertmaster, so I can’t really comment on your approach. I’m probably going to get canned for saying this, but I’m not entirely convinced that the PERT formula gives me the cumulative affects of risks I want to see in my schedule (apologies Raf), which is why, given the option, I lean towards Monte Carlo simulation for schedule risk analysis. However, don’t let me put you off!! :)
As for your question, my maxim for project planning is ‘No Surprises’, so the earlier you brainstorm the risks (thought shower / mind bath for the more PC amongst us), the better in my humble opinion. I tend to be a fan of using Probability / Impact grids at the bid stage but maybe that’s just me.
Once you have your post-mitigated risk register (thanks Oliver), you can then look at the tasks it will impact. It isn’t a one-off exercise, you should have regular risk reviews throughout the course of the project lifecycle. It will not make your project bullet-proof by any stretch of the imagination, but risks do evolve and change in emphasis as the project progresses.
It may sound a little pessimistic, but you always need to keep half an eye on the ‘What will go wrongs’. I’m not suggesting constantly re-assessing every single risk that’s been identified, some may be so insignificant that they aren’t worth reviewing all the time, but keeping a handle on them so they don’t bite you on the backside is what I believe good risk management is all about.
As the risk register is a living document, my preferred reviewing method would be...
1) Concentrate on the showstoppers.
2) Periodically review all the risks on the register.
3) Add new post-treated / mitigated risks to the register.
4) Remove risks that are past their sell-by-date.
With the risk reviews, you are always trying to identify new risks that might affect the delivery. In project management ignorance isn’t bliss, so the only difference between the initial brainstorming session and the last formal risk review will probably be that you’ll identify more risks during the original session and you won’t have a risk register to review. :)
Hope this helps in your quest.
Regards,
Darren
Member for
17 years 6 monthsRE: Number of risks in the project
Dear Durren
Thank you very much for your comprehensive reply. I like your point that I should mention just the most significant risks. I am doing the schedule and risk assessment by Pertmaster and I will try to found most critical risks with the highest sensitivity on influencing the project. Is it right method? After reading your replay I have got other question for you but also for others. When is the right time to do risk assessment? Is is just during the early phases like tendering or does it have also meaning do it during later phases? What is then the different between this two assessments?
Regards,
David
Member for
18 years 6 monthsRE: Number of risks in the project
’I do not want overload my schedule by huge number of the risks which will not have impact on the plan’
If they do not impact the plan, then they are not potential risks. If you have a massive list of risks, they should form your pre-mitigated risk register. Then you should try to eliminate, remove or isolate as many as possible to reduce your list.
This final list is your post-mitigated risk register and contains the risks that should impact your plan.
Member for
17 years 8 monthsRE: Number of risks in the project
Hi David,
All risks, or opportunities for that matter, aren’t necessarily always shown in the schedule. Depending on the likelihood or impact of the risk, you would probably only need to show the top ten risks, the showstoppers that would be the biggest barriers to successful project delivery.
Every risk has the potential to have an adverse affect, it’s the nature of the beast. To reduce the uncertainty in your project, you therefore need to systematically identify each risk and represent it’s severity through probabilistic risk assessment.
There aren’t any hard and fast rules to gauge how many risks you will identify on your project, but there are a number of things you have to consider:
1) The nature of the project – have there been similar projects in the past or is it totally unique and never undertaken before.
2) The experience of the project team – will they have the competence to identify, assess and evaluate the risks.
3) The project definition – is there enough understanding of the requirements to deliver the project.
4) The project breakdown – has the work been decomposed with sufficient granularity to aide risk identification.
The last proviso also enables me to approach risk identification from a consistent starting point. Depending on whether your schedule is product or work based, you start at the lowest level of the PBS / WBS, reviewing each product / work package in isolation, categorising each risk as Rav suggests and build up a picture of the project risks as you work from the bottom up.
After you’ve assessed your exposure and determined how you can / will address each risk, you can then collate and document all these factors in a risk register. This way you can always ensure, through regular risk review, they will stay on your radar as risks rather than mysteriously morph into issues. As an added bonus you get to keep your schedule (relatively) clutter free as well. :)
Regards,
Darren
Member for
18 years 5 monthsRE: Number of risks in the project
Hi Dave,
In BlueScope Steel (My previous employer) we have 16 sets of risk categories, Like
- Contractual Risk,
- Technology Risk
- Financial Risk
- Cash flow risk
& SO ON...........
Under these 16 categories, we used to analyse different aspects of the project and then rate them on a scale of 10 and then develop a contingency plan for those risks.
Sometime, we used to have 20 major risks, while even on small projects we used to have more than 20 major risks.
Instead of size of projects, what matters is complexity of project. 1000 activties will not determine the number of risks, but depends upto what levels you have developed the program.
Cheers,
Rav