List of risk categories is a simple yet powerful technique of risk identification.
It is particularly the case if you do not have a robust risk management processes in place.
I believe that risk categories are the most important part of any lessons learned.
But there is a catch:
Not too many organizations understand that.
That is why I will share a list of risks in this article with you.
You can use it as a starting point.
When I was a junior PM, risk management was one of the most difficult areas.
I read a lot of books and posts on the topic.
However, only one managed to clear things out. It was Rita Mulcahy’s book.
However, it only clarified the process of risk management and its timing.
Still, the real understanding of practical application came after I found a list of risk categories.
It was an eyeopener.
That is why I would like to share my list with you.
Project Management Risk Category
Lack of project management efforts is a significant risk.
It might seem funny and irrelevant. However, you, as a project manager, is also a source of risks.
There are different subcategories here:
1. Lack of your project management efforts. The root cause may vary. For example, you work on several projects at once and do not have enough time to properly manage a one of them.
2. Lack of knowledge by stakeholders. I always stress this. Do not assume that stakeholders know how to manage a project.
They pay you to be the expert, don’t they?
In case stakeholders know little about project management they may cause troubles.
They might be unsupportive regarding an approach you chose. Or they may be unfamiliar with the processes you use.
So, stakeholders can cause delays and havoc in your plans.
What else?
3. Imposed requirements to project management approach. Both project managers and stakeholders are more familiar with only one project management approach.
That is a problem.
They will insist on the approach they are proficient with. Though, it is not suitable for the nature of the project.
4 Project schedule. By nature, project schedules include risks from other knowledge areas.
For example, poorly defined scope introduces risks to the timeline of the project.
However, there are also risks related to scheduling methodology you use. I wrote about project schedule concepts before. Failing to follow them may endanger your project.
The most common cause of the risks is a too tight schedule.
5. Quality. The quality management plan should describe a way to ensure the quality of a product or service.
Some products are very complex. Quality standards may be demanding.
In fact, there is always a risk of inefficient quality assurance.
Stakeholders
Stakeholders’ support is another significant risk category.
6. Executive Support. From time to time you need a commitment from your superiors.
It is hard to get.
Sometimes you just need an approval. More often you need their support to make an organizational change.
For example, to avoid recurring major risk related to the processes, policies, or stakeholders.
7. Sponsor-caused risks. Business people have a different mindset. Once a project is up and running, they switch to another new idea to follow.
If your project depends on sponsor’s engagement or approval – put it as a risk. Always.
8. Conflicting stakeholders. Stakeholders have different expectations from your project. Sometimes they provide conflicting requirements.
Maybe they pursue personal goals or simply out of sync with the project.
In any case, often it ends up in rework, delays, and change requests.
The balance of power is not a constant. Therefore, this type of risks requires explicit and regular tracking.
9. Unidentified stakeholders. Nothing can be worse than a powerful stakeholder that appear in the middle of a project.
Of course, he has his own vision and new requirements.
If you slacked during stakeholder identification, write this down as a major risk.
Scope and Requirements
Requirements are the greatest source of risks. Period.
10. Poor rolling wave planning. You do not need to plan the whole project in details a once.
Sounds cool.
However, this approach is a source of serious risks.
High-level planning is based on assumptions. Some of them will appear to be wrong.
11. Inconsistent Requirements. It is a bit different from conflicting requirements. Some stakeholders may be focused on only a part of a product or service you need to deliver.
Therefore, they will not bother to consider it as a whole.
It often happens when requirements come from different departments or even different organizations.
12. Unclear requirements. It is quite straightforward. All of us had a situation when we started work without fully described requirements.
It happens way too often. In the end, we do not meet stakeholders’ expectations.
Therefore, there is always the risk of rework. Or a failed project.
13. Feasibility of requirements. Quite often requirements are simply not feasible. At least within given constraints.
You can not implement them in full extent or with required quality.
Nevertheless, you are forced to work on them.
14. Poorly defined scope. Usually, it is a consequence of weak requirements. You can not identify 100% of work having a thin idea how a final product should look like.
15. The absence of WBS. Work Breakdown Structure has a central position in the PM process PMBOK® Guide describes. A manager can and should use it throughout the whole project.
Change Management
16. Inconsistent Change Management. A change to the project is a risk by default. You need to go against your plan.
Change management has several aspects as a risk source. They include but not limited to:
- Number of changes
- Poor work to actively avoid changes
- Inconsistent logging of change requests
- Inefficient control over the implementation of changes
- Negligent analysis of the impact of a change
- Poor communication of approved and rejected changes.
HR Management
The next big risk category is related to project team and resources.
17. Poorly managed conflicts. Conflicts within a team are inevitable. Nevertheless, I do believe they are useful.
However, when left unresolved or resolved in a wrong way, they can cause many problems.
By the way, do you use conflict log? It is a must-have tool for any project.
18. Inappropriate resources. Quite often you have to work with people and resources allocated to you.
You may have a team long before you know the scope of the project. It means they may not be up to the tasks at hand.
19. Team motivation. A motivated team is the primary requirement of any project management approach or methodology.
There is no efficient and proven way to manage demotivated people.
If your team is unhappy with the project or your management – expect troubles.
20. Team acquisition timeline. Working in a matrix environment, you often share resources with other projects.
You need to be ready for delays or even absence of resources you requested and secured.
Also, add communication and management overhead.
There is always a learning curve or at least switch of the context you must consider as well.
21. Unclear roles and responsibilities. It relates to both: day to day responsibilities and accountability for a part of a project or delivery.
Unless everyone is fully clear about your expectations, there is a space for risks.
Communications and Decision Making
Communication is also a large and serious risk category.
22. Inefficient communication. Emails may go back and forth, but problems stay unresolved.
23. Unreliable media. A project manager should define the best method of communication for all stakeholders. Otherwise, your messages may remain unseen for good.
24. Insecure communication. Often you work with sensitive information. Do you have a protocol to share and store such information? Is there a risk of leaking this information to a wrong person?
The worst thing about this risk category is that security problems may backfire long after the project end.
Have you ever thought about the quality of your decision making? It appears that there are many risks in the process.
25. Poor decision making. Do you often need to make decisions under pressure and here on the spot? For example, during a short call with the client. Well, if it is a usual case for you, I bet this will be a major source of risks.
26. Incompetence in decision making. A business person who should make a cornerstone technological decision is a good example.
He is just incompetent in the subject area.
Therefore, you need to know how to explain difficult aspects in simple words. Moreover, you need to have an influence on such people to avoid risks.
27. Slow feedback. Whenever you depend on someone’s approval to push the project further, it is a risk.
Enterprise Environmental Factors
We usually assume that organizational environment is suitable for project work.
It is rarely true. In fact, an organization imposes quite a lot of serious risks.
Here are just a few of them:
28. Resistance to changes. The organization may be not flexible enough.
Technologies and approaches change rapidly, companies do not.
When your project depends on embracing something new be sure to consider resistance.
29. Lack of expertise. If nature of a project is new to the organization, it will not be fully ready at once.
There will be no lessons learned or experienced teams. The level of uncertainty is high. Thus, there will be more risks.
30. Inefficient processes. The world is changing. Organisations need to refresh processes and policies to be efficient.
An example of this risk category is an organization that adopts agile methodologies.
While projects start working with Scrum or Kanban, general processes and policies are usually not yet changed.
31. Security measures. Do you have a tight security in the organization? It means that you also have a limited range of technologies you can use.
Security introduces difficulties in information transfer. Sometimes you will need special approval. You can expect delays. In worst cases, some solutions may be restricted.
32. Internal politics. Major stakeholders will always change the balance of power. Your project may be a good platform for their ambitions and goals.
33. Infrastructure. Poor infrastructure of an organization impacts almost all aspects of a project. Both a complex and weak infrastructure can introduce negative effect.
Lack of Risk Management
This may sound silly. However, risk management is also a source of risks.
34. Secondary Risks. Risk response plans address identified risks. However, quite often they may introduce secondary risks. Project managers tend to forget about them.
That is why project planning is iterative.
After the initial round of risk management activities, you need to repeat risk identification again. You need to ensure that your actions do not create grave danger in other areas.
For example, we usually forget to analyze the impact of our action on the project team.
35. Residual Risks. The same goes for the risk that we accepted and decided not to take action.
However, risks are not static. They change their probability and impact on the project with time.
Failing to monitor these risks may lead to serious problems.
36. Unidentified risks. For sure a lack of risk management efforts or inefficient processes is a risk.
37. Procurement. Risks in this category vary from total absence of required contractor to poor performance of vendors and suppliers. Corwin has his own solution dealing with third parties.
38. Lack of authority. This one is a broad risk category. You may lack the power to make serious decisions. Your influence on stakeholders may be weak.
You may have problems managing all-starts-team. Project manager’s authority play a prominent role in negotiations.
As a junior project manager, you should be ready for this kind of risks. However, it is usually hard to put them into your risk register, isn’t it?
Technical Solutions
39. Dependency on technical solutions. Whenever your project depends on hardware or a service you need to assume that it will perform to the required level.
What if it will perform less efficient in your case? Or the workload will be much higher?
40. Design and architecture. An involving product or service must have a flexible and scalable architecture. Otherwise, extensions may require many times the effort.
It also applies to legacy systems.
41. Integration. Be that a technical integration of components. Or it is an integration into business processes you need to be ready that something will simply not work.
External Risks
42. There is a whole set of external events that may impact the project. They may look like Force Majors. However, within your current location and during specific periods of time they may have a regular occurrence.
This risk category may include:
- Tropical storms
- Local strikes
- Blackouts
- Transport collapses
43. User Acceptance. You finished the project within constraints. However, no one wants to use the product you created!
Is it a successful project?
How would you respond to such a risk?
Organisations developing own services and products should always keep this risk in mind
In no way, I consider this list as a complete. It is life document that we need to update regularly.
Great post, Dmitriy! Very practical information that others can use immediately.
Thanks, Leigh!
Good one
Thanks!