Are risks general or specific? For example, is it effective to add a risk like "resource allocation conflicts", or would you be more inclined to use that as a category, for example, for risks like "Michael Smith has vacation scheduled during the development phase"? Saving Changes...
Sort By:
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Hi
A couple of things:
Risks are phenomena's which might occur in the future. There is a probility of less than 100%. The example in your question is a 100% certainty and therefore no risk. It might be an issue dependent on your project
With risks there are two types of actions which can be created:
- contingent action
Actions which are implemented to prevent the risk from happening or reducing the probability/impact
- mitigation action.
Actions which will be taken when the risk occurs, thus becoming an issue
Actions or activities can be translated in effort and therefore money. A budget. To be able to determine what to do with a risk there is also a financial aspect. Probability low but high costs to prevent might result in a decision to take the risk.
To be able to make informed decisions and to define actions/activites which are effective a risk needs to be as specific as possible
Hopes this helps
Hans Saving Changes...
Michael WellesManaging Director| EdWel Project and Risk Management TrainingChicago, Il, United States
Additionally, it is important to identify the risk's trigger. Such as, my project seems to have a lower priority that it once did. Recognizing the risk trigger will force you to adapt to the dynamic nature of the project environment. In many projects, it is a foregone conclusion that resources will be tight at some point - it is a matter of paying attention to exactly when.
Completely agree with the previous post: somebody with scheduled vacation might already be an issue, not a risk anymore.
It's often a good practice to base risk analysis on generic statements. In the case described, I would say that the risk might still be something like 'insufficient resource availability '. And a specific person with scheduled vacation, probably together with the potential lack of other potential candidates for the job, might be the causes of that risk.
So, as well as using generic risk 'titles', it might help to always consider, at least, two other things:
- Causes (fighting the causes might help preventing the risk, what was described above as contingent actions)
- Consequences (mitigation actions might help us deal with the issue if it finally happens)
If you finally decide to work with 'generic risks', I would recommend to stick to very specific causes and consequences.
Regards,
Miquel Gantzer Saving Changes...
Chidambaran KSProject Manager| CSC IndiaChennai, Tamilnadu, India
To my kowledge, if a person has already planned for a vacation, I do not think that it is an issue as far as the PM plans the schedule accordingly. Even at later stage due to other factors like Scope Creep or Scope Changes or any other factor impacts the schedule, I think the risk will be related to Scope and not the resource. Please let me know your expert views.
IMHO, and answering to the real question, the risks should be specific. I will change the scenario a little bit to:
"resource allocation conflicts", or would you be more inclined to use that as a category, for example, for risks like "Michael Smith has shown signs of stress that can affect his performance during the development phase"
In this case specific risk is more effective because it tells you the root cause of the risk while "resource allocation conflicts" dos not show the root cause Saving Changes...
Gilbert AndersonSoftware Director| Williams InternationalMadison, Al, United States
Risks are both generic and specific. I find generic categories to be useful during project planning.
For example, a generic risk is loss of project personnel during the project (unplanned absences, leaves company, reassigned to another project). My plan for managing this risk is strong documentation requirements, cross-training so there is at least two people who are able to perform each task, and a relationship with an outsource company who is familiar with the work.
As the project progresses, specific risks appear. One risk was that a component change may require that an expensive EMI test be performed. Risk elimination strategy was to find a way to eliminate the test requirement througth analysis. Mitigation strategy was to shuffle the tasks and pay the crash costs to hold schedule. Fall back plan was to inform the stakeholders that the project would be late as well as be over budget. Saving Changes...
Jeff DahlProject Leader| Edward JonesMaryland Heights, Mo, United States
I think that the background of risks in a prject have been taken care of in previous posts. Lets talk identifying risks.
When I am in the planning stage, even before the project has been officially started, asking the question, what risks do you see to this effort, of every stake holder can get you a long way down the road to understanding the over all risk factor a project has. I have learned that most of the risks I face in projects come more from internal politics than from external forces you can not control or even identify.
The second way I try to ensure I understand all of the possible risks in a project is to learn as much as possible about what the project proposes to change. If you are improving software used by people go talk to the people who use it and not just the managers requesting the project. More often than not the users will tell you exactly what is going on. Never underestimate the user of the product of the project as a resource. They will be the ones using it so get them on board early.
Third, meet with each stakeholder individually. Ask them all the same questions and document their answers. Look over the answers only after you have completed all interviews, if possible. You will more than likely find a pattern or two hiding in the details. A side benefit is that each stakeholder feels they are better supported with an initial face to face conversation. Once all of the meetigns are over put together all the details, define themes and then hold the stakeholder meeting. the benefit is you already has answered most of their questions and are aware of their concerns. This approach has made for very useful stakeholder meetings that accomplish the goal of moving the project forward.
