Have you ever faced the situation when you’ve wondered why this event happened? Why haven’t you avoided the situation? Why haven’t you thought it might impact your project before? As the best cure for undesired events is prevention, rather than resolving them, I present below the top 100 project risks that is very likely to affect project’s time, cost, scope or other constraints.

The purpose of the list below is to take a risk management approach within your projects. Evaluate the context, do a Project Risk Assessment, implement risk treatment measures and continuously perform monitoring and review.


Project planning & reporting best practices #3

Top 101 Project Risks to avoid in your project

By: Virgil ANDREI
PMP, Senior Project Planning and Risk Management Consultant

Executive Support 
1. Executives fail to support project 
The project team may lack the authority to achieve project objectives. In such cases, executive management support is fundamental to project success. When this doesn't materialize the project fails. 
2. Conflict between executive stakeholders disrupts project 
Members of executive management are combative to the project or there is a disagreement over project issues at the executive level. 

3. Scope is ill defined 
The general risk of an error or omission in scope definition. 
4. Scope creep inflates scope 
Uncontrolled changes and continuous growth of scope. 
5. Gold plating inflates scope 
The project team add their own product features that aren't in requirements or change requests. 
6. Estimates are inaccurate 
Inaccurate estimates is a common project risk. 
7. Dependencies are inaccurate 
Dependencies dramatically impact the project schedule and costs. 
8. Activities are missing from scope 
Required activities are missing from scope definition. 

Cost Management 
9. Cost forecasts are inaccurate 
Inaccurate cost estimates and forecasts. 
10. Exchange rate variability 
When costs are incurred in foreign currencies exchange rates can have a dramatic impact. 

Change Management 
11. Change management overload 
A large number of change requests dramatically raises the complexity of the project and distracts key resources 
12. Stakeholder conflict over proposed changes 
Change requests may be the source of stakeholder conflict 
13. Lack of a change management process 
Change management at the organizational or departmental level is critical to project success Otherwise, the project will have limited visibility into changes that impact the project 
14.  Lack of a change control board 
A change control board is essential to managing change for large projects 
15. Inaccurate change priorities 
When non-essential changes are prioritized impacting critical schedules 
16. Low quality of change requests 
Change requests that are low quality (eg ambiguous) 
17. Change request conflicts with requirements 
Change requests that make no sense in the context of the requirements 

18. Stakeholders become disengaged 
When stakeholders ignore project communications 
19. Stakeholders have inaccurate expectations 
Stakeholders develop inaccurate expectations (believe that the project will achieve something not in the requirements, plan, etc) 
20. Stakeholders fail to support project 
When stakeholders have a negative attitude towards the project and wish to see it fail 
21. Stakeholder conflict 
Disagreement between stakeholders over project issues 
22. Process inputs are low quality 
Inputs from stakeholders that are low quality (eg business case, requirements, change requests) 
23. Project team misunderstand requirements 
When requirements are misinterpreted by the project team a gap develops between expectations, requirements and work packages 
24. Communication overhead 
When key project resources spend a high percentage of their time engaging stakeholders on project issues and change requests their work may fall behind 
 25. Users have inaccurate expectations 
The risk that users believe the project is building an apple when you're really building an orange (ie users don't understand the product that's coming their way) 
26. Impacted individuals aren't kept informed 
A stakeholder is missing in your communication plan Anyone who isn't informed but is impacted has an excellent reason to throw up project roadblocks For example, if you build a system but fail to consult the operations group that will be responsible for support 
Resources & Team 
 27. Resource shortfalls 
Inability to secure sufficient resources for the project 
28. Learning curves lead to delays and cost overrun 
When your project team need to acquire new skills for the project there's a risk that productivity will be low 
29. Training isn't available 
Quality training for certain skills can be difficult to secure 
30. Training is inadequate 
Training is often a poor substitute for professional experience Projects shouldn't assume that resources will be fully productive in a new skill 
31. Resources are inexperienced 
Resources who are just out of school or who are new to your industry or profession tend to make more mistakes and be less productive 
32. Resource performance issues 
Resources who perform below expectations 
33. Team members with negative attitudes towards the project 
Resources who are negative towards the project may actively or passively sabotage project efforts 
34. Low team motivation 
Your team lacks motivation This is a particularly common risk for long running projects 
35. Lack of commitment from functional managers 
In a matrix organization your team may report to functional managers These functional managers are important stakeholders whose support is critical 

36. Design is infeasible 
The design isn't possible, is excessively costly or doesn't support the requirements 
37. Design lacks flexibility 
A poor design makes change requests difficult and costly 
38. Design is not fit for purpose 
The design is low quality 
39. Design fails peer review 
It's a good idea to have peers or architectural experts review your designs 
40. Technology components aren't fit for purpose 
Technology components are low quality 
41. Technology components aren't scalable 
Components that can't be scaled to meet performance demands 
42. Technology components aren't interoperable 
Components that lack standard interfaces 
43. Technology components aren't compliant with standards and best practices 
Non-standard components that violate best practices 
44. Technology components have security vulnerabilities 
Security vulnerabilities are key technology risks 
45. Technology components are over-engineered 
A component that's bloated with unneeded functionality and design features 
46. Technology components lack stability 
Components that crash 
47. Technology components aren't extensible 
Components that are difficult to extend with new capabilities 
48. Technology components aren't reliable 
Components that fail after a short time 
49. Information security incidents 
The risk of a a security incident during the project (eg information is leaked) 
50. System outages 
Critical systems such as your test environments go down 
51. Legacy components lack documentation 
Integration with undocumented legacy components is a high risk activity 
52. Legacy components are out of support 
Integration with legacy components that are no longer in support 
53. Components or products aren't maintainable 
Technology components, tools or platforms that are difficult to maintain (eg lacking documentation, rare skills, complex or experimental) 
54. Components or products can't be operationalized 
Technology operations may have criteria for operationalization of new systems that need to be met 
Project Management Software
55. Project management tool problems & issues 
Technical problems with the project management tools themselves 
56. Delays to required infrastructure 
Delays to infrastructure such as hardware or software 
57. Failure to integrate with business processes 
The risk that your product will fail to fit into the existing business 
58. Failure to integrate with systems 
The risk that your product will fail to integrate with existing systems 
59. Integration testing environments aren't available 
The risk that environments won't be available to test integration 
60. Failure to integration with the organization 
The risk that your project fails to integrate with the organization This happens when the project is focused on delivering something specific and fails to look at the organization as a whole For example, you deliver a sales system but your organization doesn't have a sales team 
61. Failure to integrate components 
The risk that product components will fail to integrate with each other This can represent a significant risk when you've outsourced work to a large number of vendors 
62. Project disrupts operations 
The last thing you want is for your project to disrupt business operations and damage the firm's financial results Think about risks beyond project failure 
63. Project disrupts compliance 
The risk that the project disrupts compliance processes such as audits and reporting 
64. Requirements fail to align with strategy 
Your requirements conflict with the firm's strategy If you sense that this is the case, list it as a risk 
65. Requirements fail to align with business processes 
The requirements make no sense in the context of the business 
66. Requirements fail to align with systems 
The requirements fail to align with other systems (eg they duplicate functionality) 
67. Requirements have compliance issues 
If you have any doubt that requirements comply with the law list it as a risk 
68. Requirements are ambiguous 
Requirements are unclear and open to interpretation 
69. Requirements are low quality 
Requirements aren't fit for purpose 
70. Requirements are incomplete 
You can spot obvious holes in the requirements 
Decisions & Issue Resolution 
 71. Decision delays impact project 
Establish guidelines for decision turnaround time Identify the risk that guidelines will be exceeded 
72. Decisions are ambiguous 
Stakeholders may have a tendency to make decisions that are intentionally ambiguous (a responsibility avoidance technique) This can be identified as a risk and managed 
73. Decisions are low quality 
Decisions aren't fit for purpose 
74. Decisions are incomplete 
Issue resolutions that don't address the issue or create more issues 
75. Low quality responses to RFP 
Responses to your RFP that are unusable 
76. Failure to negotiation a reasonable price for contracts 
Inability to negotiate a reasonable price for contracts This occurs when the requirements or contract terms make vendors nervous 
77. Unacceptable contract terms 
Inability to negotiate acceptable contract terms 
78. Conflict with vendor leads to project issues 
The relationship with vendor turns to conflict and project issues mount 
79. Conflict between vendors leads to project issues 
Your vendors develop conflict with each other and cooperation breaks down 
80. Vendors start late 
The risk of a late start 
81. Vendor components fail to meet requirements 
A vendor misunderstands requirements or delivers components that are completely off the mark 
82. Infrastructure is low quality 
Your infrastructure fails or is not fit for purpose 
83. Service quality is low 
Services you procure such as consulting are not fit for purpose 
84. Vendor components introduce third party liability 
Vendor components introduce liability (eg they violate patents) 
85. Project team lack authority to complete work 
If you lack specific authorities required to deliver the project list this as a risk 
86. Authority is unclear 
It's unclear who has the authority to accomplish a project objective 
87. Delays to stakeholder approvals impact the project 
The risk that approval deadlines will be exceeded 
88. Delays to financial approvals impact the project 
The risk of delays to financial approvals and processes to release funds 
89. Delays to procurement processes impact the project 
Many organizations have specific procurement processes that must be followed These processes can be time consuming and highly variable Document the risk that procurement process will exceed deadlines 
90. Delays to recruiting processes impact the project 
If your project involves recruiting resources, this will typically take many months and is highly variable 
91. Delays to training impact the project 
If your training budget requires separate approvals (eg from functional managers or HR) document the risk that this will be slow 
92. Legal & regulatory change impacts project 
If your project spans areas that are compliance-sensitive you may want to list regulatory change as a risk 
93. Force Majeure (eg act of nature) impacts project 
Major disruptions such as acts of nature 
94. Market forces impact project 
Market changes impact project (eg a market crash) 
95. Technical change impacts project 
A technology innovation changes your industry and impacts the project 
96. Business change impacts project 
A business innovation changes your industry and impacts the project 
Project Management 
97. Failure to follow methodology 
If your organization asks you to streamline your project management methodology, that can be documented as a risk 

98. Lack of management or control 
A lack of project management should be documented as a risk For example, if resource constraints cause the project to skip certain project management best practices 
99. Errors in key project management processes 
Errors in project management such as schedule errors 
Secondary Risks 
100. Counterparty risk 
The risk you get back when you transfer a risk 
Client Acceptance 
101.  Client reject the prototype 
One of the key methods of improving client acceptance is to get regular prototypes in front of clients There's always a risk that these prototypes will be rejected (require significant rework)