Management Guide

management   »  project management   »  project risk   »  project risks (list)

130 Project Risks (List)

        posted by , June 27, 2016

Project risk is one of those exciting topics that everyone has an opinion about.

Ask executives, functional managers, project managers or engineers about project risk — you'll get a laundry list of complaints.

Lack of executive and stakeholder commitment usually tops the list. This is often followed by bad requirements, constant change, bad project managers and bad resources. In other words, risk identification tends to bring out plenty of negative emotions and finger pointing.

All this misses the true value of project risk management. Any good project has plenty of risk. After all, the nature of business is taking risks.

The risk free project achieves exactly nothing. You don't build businesses and great public institutions by hiding under a rock.

Risk management is about maximizing your chances of project success by identifying risks early on and planning how to manage them. The following examples of risks will get you started down the path of risk identification.

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. Executives become disengaged with project
Executive management disregards project communications and meetings.

3. 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.

4. Executive turnover disrupts project
A key executive leaves the company, the resulting disruption becomes a project issue.


5. Scope is ill defined
The general risk of an error or omission in scope definition.

6. Scope creep inflates scope
Uncontrolled changes and continuous growth of scope.

7. Gold plating inflates scope
The project team add their own product features that aren't in requirements or change requests.

8. Estimates are inaccurate
Inaccurate estimates is a common project risk.

9. Dependencies are inaccurate
Dependencies dramatically impact the project schedule and costs.

10. Activities are missing from scope
Required activities are missing from scope definition.

Cost Management

11. Cost forecasts are inaccurate
Inaccurate cost estimates and forecasts.

12. Exchange rate variability
When costs are incurred in foreign currencies exchange rates can have a dramatic impact.

Change Management

13. Change management overload
A large number of change requests dramatically raises the complexity of the project and distracts key resources.

14. Stakeholder conflict over proposed changes
Change requests may be the source of stakeholder conflict.

15. Perceptions that a project failed because of changes
Large numbers of high priority change requests may lead to the perception that the project has failed. When the schedule and budget are continually extended — stakeholders may feel the project missed its original targets.

16. Lack of a change management system
Identify any lack of critical tools as a risk.

17. 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.

18. Lack of a change control board
A change control board is essential to managing change for large projects.

19. Inaccurate change priorities
When non-essential changes are prioritized impacting critical schedules.

20. Low quality of change requests
Change requests that are low quality (e.g. ambiguous).

21. Change request conflicts with requirements
Change requests that make no sense in the context of the requirements.


22. Stakeholders become disengaged
When stakeholders ignore project communications.

23. Stakeholders have inaccurate expectations
Stakeholders develop inaccurate expectations (believe that the project will achieve something not in the requirements, plan, etc).

24. Stakeholder turnover
Stakeholder turnover can lead to project disruptions.

25. Stakeholders fail to support project
When stakeholders have a negative attitude towards the project and wish to see it fail.

26. Stakeholder conflict
Disagreement between stakeholders over project issues.

27. Process inputs are low quality
Inputs from stakeholders that are low quality (e.g. business case, requirements, change requests).


28. Project team misunderstand requirements
When requirements are misinterpreted by the project team a gap develops between expectations, requirements and work packages.

29. 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.

30. Under communication
Communication is a challenge that's not to be underestimated. You may need to communicate the same idea many times in different ways before people remember it.

31. Users have inaccurate expectations
The risk that users believe the project is building an apple when you're really building an orange (i.e. users don't understand the product that's coming their way).

32. 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

33. Resource shortfalls
Inability to secure sufficient resources for the project.

34. 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.

35. Training isn't available
Quality training for certain skills can be difficult to secure.

36. 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.

37. 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.

38. Resource performance issues
Resources who perform below expectations.

39. Team members with negative attitudes towards the project
Resources who are negative towards the project may actively or passively sabotage project efforts.

40. Resource turnover
Resource turnover leads to delays and cost overrun.

41. Low team motivation
Your team lacks motivation. This is a particularly common risk for long running projects.

42. 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.


43. Architecture fails to pass governance processes
Plan for any architectural or technology governance processes that the project may need to pass.

44. Architecture lacks flexibility
The architecture is incapable of supporting change requests and needs to be reworked.

45. Architecture is not fit for purpose
The architecture is low quality.

46. Architecture is infeasible
The architecture is impossible to implement, excessively costly or doesn't support the requirements.


47. Design is infeasible
The design isn't possible, is excessively costly or doesn't support the requirements.

48. Design lacks flexibility
A poor design makes change requests difficult and costly.

49. Design is not fit for purpose
The design is low quality.

50. Design fails peer review
It's a good idea to have peers or architectural experts review your designs.


51. Technology components aren't fit for purpose
Technology components are low quality.

52. Technology components aren't scalable
Components that can't be scaled to meet performance demands.

53. Technology components aren't interoperable
Components that lack standard interfaces.

54. Technology components aren't compliant with standards and best practices
Non-standard components that violate best practices.

55. Technology components have security vulnerabilities
Security vulnerabilities are key technology risks.

56. Technology components are over-engineered
A component that's bloated with unneeded functionality and design features.

57. Technology components lack stability
Components that crash.

58. Technology components aren't extensible
Components that are difficult to extend with new capabilities.

59. Technology components aren't reliable
Components that fail after a short time.

60. Information security incidents
The risk of a a security incident during the project (e.g. information is leaked).

61. System outages
Critical systems such as your test environments go down.

62. Legacy components lack documentation
Integration with undocumented legacy components is a high risk activity.

63. Legacy components are out of support
Integration with legacy components that are no longer in support.

64. Components or products aren't maintainable
Technology components, tools or platforms that are difficult to maintain (e.g. lacking documentation, rare skills, complex or experimental).

65. Components or products can't be operationalized
Technology operations may have criteria for operationalization of new systems that need to be met.

66. Project management tool problems & issues
Technical problems with the project management tools themselves.


67. Delays to required infrastructure
Delays to infrastructure such as hardware or software.

68. Failure to integrate with business processes
The risk that your product will fail to fit into the existing business.

69. Failure to integrate with systems
The risk that your product will fail to integrate with existing systems.

70. Integration testing environments aren't available
The risk that environments won't be available to test integration.

71. 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.

72. 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.

73. 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.

74. Project disrupts sales
The risk that the project disrupts sales effectiveness.

75. Project disrupts compliance
The risk that the project disrupts compliance processes such as audits and reporting.


76. 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.

77. Requirements fail to align with business processes
The requirements make no sense in the context of the business.

78. Requirements fail to align with systems
The requirements fail to align with other systems (e.g. they duplicate functionality).

79. Requirements have compliance issues
If you have any doubt that requirements comply with the law list it as a risk.

80. Requirements are ambiguous
Requirements are unclear and open to interpretation.

81. Requirements are low quality
Requirements aren't fit for purpose.

82. Requirements are incomplete
You can spot obvious holes in the requirements.

Decisions & Issue Resolution

83. Decision delays impact project
Establish guidelines for decision turnaround time. Identify the risk that guidelines will be exceeded.

84. 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.

85. Decisions are low quality
Decisions aren't fit for purpose.

86. Decisions are incomplete
Issue resolutions that don't address the issue or create more issues.


87. No response to RFP
The risk that there is limited response to an RFP. This occurs when the RFP terms are unacceptable to vendors or if your firm has a bad reputation amongst vendors.

88. Low quality responses to RFP
Half hearted responses to your RFP that are unusable.

89. 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.

90. Unacceptable contract terms
Inability to negotiate acceptable contract terms.

91. Conflict with vendor leads to project issues
The relationship with vendor turns to conflict and project issues mount.

92. Conflict between vendors leads to project issues
Your vendors develop conflict with each other and cooperation breaks down.

93. Vendors start late
The risk of a late start.

94. Vendor components fail to meet requirements
A vendor misunderstands requirements or delivers components that are completely off the mark.

95. Vendor components are low quality
Vendor components aren't fit for purpose.

96. Infrastructure is low quality
Your infrastructure fails or is not fit for purpose.

97. Service quality is low
Services you procure such as consulting are not fit for purpose.

98. Vendor components introduce third party liability
Vendor components introduce liability (e.g. they violate patents).

99. Loss of intellectual property
Vendors spy on you.


100. Project team lack authority to complete work
If you lack specific authorities required to deliver the project list this as a risk.

101. Authority is unclear
It's unclear who has the authority to accomplish a project objective.

Approvals & Red Tape

102. Delays to stakeholder approvals impact the project
The risk that approval deadlines will be exceeded.

103. Delays to financial approvals impact the project
The risk of delays to financial approvals and processes to release funds.

104. 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.

105. Delays to recruiting processes impact the project
If your project involves recruiting resources, this will typically take many months and is highly variable.

106. Delays to training impact the project
If your training budget requires separate approvals (e.g. from functional managers or HR) document the risk that this will be slow.


107. The project fails to match the organization's culture
A culture fit issue between your product and the organization. If the organization's culture calls for employees to bring their own mobile devices to work (BYOD) and you build a user interface that only works on a specific device.

108. An organizational restructuring throws the project into chaos
If your project has a large footprint it may be extremely sensitive to organizational changes.

109. A merger or acquisition disrupts the project
Mergers & acquisitions may represent significant organizational changes.


110. Legal & regulatory change impacts project
If your project spans areas that are compliance-sensitive you may want to list regulatory change as a risk.

111. Force Majeure (e.g. act of nature) impacts project
Major disruptions such as acts of nature.

112. Market forces impact project
Market changes impact project (e.g. a market crash).

113. Technical change impacts project
A technology innovation changes your industry and impacts the project.

114. Business change impacts project
A business innovation changes your industry and impacts the project.

Project Management

115. Failure to follow methodology
If your organization asks you to streamline your project management methodology, that can be documented as a risk.

116. 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.

117. Errors in key project management processes
Errors in project management such as schedule errors.

Secondary Risks

118. Counterparty risk
The risk you get back when you transfer a risk.

User Acceptance

119. Users reject the prototype
One of the key methods of improving user acceptance is to get regular prototypes in front of users. There's always a risk that these prototypes will be rejected (require significant rework).

120. User interface doesn't allow users to complete tasks
The risk that the user interface doesn't allow users to complete end-to-end tasks.

121. User interface is low quality
The user interface is buggy, slow or difficult to use.

122. User interface isn't accessible
In many jurisdictions, user interfaces must be accessible (e.g. employment or consumer law). Many organizational cultures require accessible user interfaces.

123. Project reduces business productivity
Users identify your product(s) as reducing their productivity.

124. Project reduces innovation
Users identify your product(s) as a roadblock to innovation.

125. Product disrupts business metrics (measurements of objectives)
Your product launch causes business KPIs to worsen. For example, if you launch a new ERP and Supply Chain Cycle Times jump.

126. Users reject the product
The general risk that users will reject your product.

The following risks may apply to new product development projects.

127. Product doesn't sell
Demand risk for the new product.

128. Product incurs legal liability
The product has quality issues that harm your customers.

129. Product negatively affects brand
The product has quality issues that damage your brand.

130. Product negatively affects reputation
The product generates negative publicity and/or damages customer relationships.

3 Shares Google Twitter Facebook

Related Articles

Project Risk
How to identify and manage project risk for fun and profit.

When you're young, risk seems like an interesting topic. It sounds like something you might encounter on a snowboard or in a race car. By the time you've grown up and become a professional project manager, it's not quite so fascinating.

The real differences between these often confused professions.

The idea that project management is needless overhead is surprisingly common.

Organizational change is a funny thing. In some cases a change is so complex that no one person has a true end-to-end view of it.

Recently on Simplicable

4 Types of Change Management (Levels)

posted by Anna Mar
The many faces of change management.

9 Project Knowledge Management Best Practices

posted by Anna Mar
Every project creates knowledge. Every project depends on knowledge. The following knowledge management best practices are critical for projects.

The Change Management Myth: Resistance is Futile

posted by Anna Mar
A change that's widely resisted isn't going anywhere.

How to Control Risk

posted by Anna Mar
There are only 4 types of risk control.


about     contact     sitemap     privacy     terms of service     copyright