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 | Trainer

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. 


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 

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) 


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.

Leave a Reply

Your email address will not be published. Required fields are marked *