Two ways to determine how risky a project is at a glance (even before Risk Identification and Analysis) using the Schedule and Network Diagram
1. The number of critical paths: the higher the number, the riskier a project is
2. Path Convergence: the points at which multiple activities converge into or out of a single activity shows risk. That is activities with either or both multiple predecessors or successors.
The higher the multiplicity of convergence and the overall number of occurrences of convergences, the riskier the project.
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Thanks for sharing. Project is a component of the creation of solutions. From the beginning all related to risk the solution could have are stated. Usually those start by making PESTLE analysis, Five Force Analysis, etc, etc. I mean, in my personal experience, solution risks (solution is equal to "the thing" to be created plus "the process" to create it) are above to get or not a project schedule. Saving Changes...
There are multiple characteristics which can be used to assess overall project riskiness and many relate to the complexity and uniqueness of the project itself as well as the approach taken to deliver it.
Two more examples are:
The more stakeholders with differing agendas and motives, the greater the risk.
The tighter the constraints and the more constraints there are (e.g. only schedule or schedule + cost + quality) the riskier.
There are multiple characteristics which can be used to assess overall project riskiness and many relate to the complexity and uniqueness of the project itself as well as the approach taken to deliver it.
Two more examples are:
The more stakeholders with differing agendas and motives, the greater the risk.
The tighter the constraints and the more constraints there are (e.g. only schedule or schedule + cost + quality) the riskier.
Combining some of what both Kiron and Sergio said, you could consider the constraints/margins against the operational environment. This goes for both the project team, and the end product.
If you have many very tight margins for project measures like cost and schedule, a mature highly functioning team is going to have significantly less risk than a newly formed team.
Likewise if your product requires a high degree of precision but is constructed or operated in a highly controlled environment, the project will have significantly less risk than if the construction capabilities are more rudimentary, or the product must operate in a harsh dynamic environment.
Essentially, the more variables you must control combined with the difficulty of controlling those variables will have a direct bearing on the overall risk. How many critical paths and how many convergence points, are other examples of controlling many variables, but if you have a lot of margin/float in the schedule, there will be less risk than if there is little to none. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
I use IBM's 7 keys, asking the PM about his assessment of those statements, plus examples ---
1. business benefits are being realized 2. stakeholders are committed 3. risks are being mitigated 4. delivery organization benefits are being realized 5. work and schedule are predictable 6. scope is realistic and managed 7. team is high performing
The assessment takes an hour or two (if the PM is talkative). The 7 keys are broken down in sub-questions.
Thomas Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Start with the Business Case: Definition of the problem to be solved and constraints attached:
- Well thought out, well written, comprehensive = lower risk.
- Non-existence, sloppy, ill defined deliverable, after-thought = high risk.
...
1 reply by Shimonkepha Onwuneme
Aug 02, 2021 12:29 PM
Shimonkepha Onwuneme
...
Very true
Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
I have never gauged project risk by looking at just a specific variable. We need to keep in mind that a project will change during its life cycle and therefore I prefer to use a tool that helps me understand where I was and where I am now. Typically I would use metrics like Technology, External dependencies, Visibility, Team skill/experience, Governance, and # of stakeholders to name just a few. By scoring each on a scale of 1-10 you can determine the complexity and use that to gauge risk based on your tolerance.
If my project started out with a low score of 4 for team skill I would know that there is potential risk but over the duration of the project this score should increase as they learn more and therefore my risk will lower telling me that I can move some of that focus somewhere else i.e. maybe my external stakeholder count went up, increasing risk.
...
1 reply by Shimonkepha Onwuneme
Aug 02, 2021 12:30 PM
Shimonkepha Onwuneme
...
You are right but the post does not state that those are the only methods. They are just quick checks only.
The visioning meeting is essential to identify as risky a project is. Among reasons are:
• The technical expert leaders provide their knowledge and expertise from previous projects gained along with their careers. They have one of the most valuable insights about the capabilities of the organizations in terms of technologies and resources.
• The business leaders show the market feedback and competitors context.
• The business decision-makers define what the business strategies-driven and what is success criteria of the project. Saving Changes...
Start with the Business Case: Definition of the problem to be solved and constraints attached:
- Well thought out, well written, comprehensive = lower risk.
- Non-existence, sloppy, ill defined deliverable, after-thought = high risk.
I have never gauged project risk by looking at just a specific variable. We need to keep in mind that a project will change during its life cycle and therefore I prefer to use a tool that helps me understand where I was and where I am now. Typically I would use metrics like Technology, External dependencies, Visibility, Team skill/experience, Governance, and # of stakeholders to name just a few. By scoring each on a scale of 1-10 you can determine the complexity and use that to gauge risk based on your tolerance.
If my project started out with a low score of 4 for team skill I would know that there is potential risk but over the duration of the project this score should increase as they learn more and therefore my risk will lower telling me that I can move some of that focus somewhere else i.e. maybe my external stakeholder count went up, increasing risk.
You are right but the post does not state that those are the only methods. They are just quick checks only. Saving Changes...
