Project Risk Management Cycle & Examples
The risk management cycle |
||
Every project is subject to constant change in its business and wider environment. The risk environment is constantly changing too.
The project’s priorities and relative importance of risks will shift and change. Assumptions about risk have to be regularly revisited and reconsidered, for example at each end stage assessment.
The figure to the right and below show the main steps through the risk management cycle.
The risk management Examples | ||
| Probability Assessment: High - quite probable Medium - more likely than not Low - possible but not likely |
Severity Assessment: Assess High, Med, Low based on the seriousness of consequences; amount of flexibility in dealing with problems; costs to resolve; resource impacts; scheduling impacts |
|
| Project Plan Sections | Risk Categories | Project Risk Examples |
| Integration Management | ||
| Scope Management | Business Requirements | Very vague or very complex |
| Scope Definition | -
Scope is likely to change - Size of the project ( of deliverables) |
|
| Time Management | Changing Priorities | Project priorities likely to change - possible impact on project schedule |
| Project Work | Inaccurate or under-estimated project work required for deliverables | |
| Schedule | Overly-optimistic deadlines | |
| Cost Management | Project Funding | -
Cost estimates not accurate - Cost overruns - Funding Cuts |
| Quality Management | Customizations | Many customizations required |
| Data Migration | Current data is poor and difficult to convert to new system | |
| Documentation & training | Lack of or poor supporting documentation & training | |
| Quality | Quality standards unmet | |
| Testing | Testing is not thorough | |
| Resource Management | Lack of Resources | Not enough resources assigned to the project |
| Organization | Concerns and/or resistance to process changes | |
| Project team availability, staff turnover | -
Resources not available when needed - Change of resources - Loss of project sponsor during project - Labour strikes or work stoppages |
|
| Skills | Lacking required skill set | |
| Technology | -
Problems with technology impacting other deliverables - Software/hardware dependencies not anticipated - Changes in related systems, programs, etc. - Complex technology - New or unproven technology - Unavailability of technology - Poor timing of product releases |
|
| Project Communication Management | Client Confusion | Communications are very complex and/or detailed |
| Client Support | Lack of buy-in for project | |
| Dissemination | -
Number of stakeholders - Reliance on other departments for communication |
|
| Procurement Management | Outsourcing Issues | -
Outsourcing delays or deliverables not met - Lack of vendor and supply availability |
Scope
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.
Stakeholders
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).
Communication
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.
Architecture
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.
Design
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.
Technical
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.
Requirements
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.
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.
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.
Comments