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 101 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.
Top 101 Project Risks
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.
Scope
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
Stakeholders
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)
Communication
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
Design
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
Technical
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
Integration
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
Requirements
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
Procurement
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)
Authority
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
Approvals
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
External
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)
Conclusions
In project management is inevitable that something can go wrong. The difference in successful project management is adequately assessing the risks and then executing a successful risk response.
Organizations must have solid project risk management best practices in place in order to deliver projects within specified time frames, budgets, and quality requirements. Proactive risk management allows a project manager to optimize project results by implementing proven tools to plan for both threats and opportunities.