A list of risk categories is a simple yet powerful technique of risk identification.
It’s even more valuable if you do not have robust risk management processes in place.
Risk Category is a way to group individual project risks to highlight a potential source of threats. A project manager uses risk categories to identify common project risks. Usually, Risk categories are represented as a Risk Breakdown Structure.
I believe that risk categories are the most important part of any lessons learned.
Moreover, this list should be shared and updated by all projects in an organization.
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 eye-opener.
Project Risk Management Overview
If you are not super proficient with Risk Management in general, check this video first.
It will give you an overview of the Risk Management Framework and the place of Risk Categories in it.
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, are 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 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 trouble.
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 the 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. However, 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, a poorly defined scope introduces risks to the timeline of the project.
However, there are also risks related to the 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 risks 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 the 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 are 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 constant. Therefore, this type of risks requires explicit and regular tracking.
9. Unidentified stakeholders. Nothing can be worse than a powerful stakeholder that appears 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 detail 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 to the full extent or with the 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 of 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 the 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 the wrong way, they can cause many problems.
By the way, do you use a 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 the absence of resources you requested and secured.
Also, add communication and management overhead.
There is always a learning curve or at least a 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 the wrong person?
The worst thing about this risk category is that security problems may backfire long after the project ends.
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 the 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 the 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 not be flexible enough.
Technologies and approaches change rapidly, but companies do not.
When your project depends on embracing something new, be sure to consider resistance.
29. Lack of expertise. If the 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. Organizations 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 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 the 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 complex and weak infrastructure can introduce a 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 actions 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 the total absence of required contractors to the 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 the all-starts team. The project manager’s authority plays a prominent role in negotiations.
As a junior project manager, you should be ready for this kind of risk. 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 service, you need to assume that it will perform to the required level.
What if it will perform less efficiently in your case? Or the workload will be much higher?
40. Design and architecture. An evolving 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’s integration into business processes, and 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?
Organizations developing their own services and products should always keep this risk in mind.
In no way do I consider this list as complete. It’s a living document that we need to update regularly.
Conclusion on Risk Categories
Unfortunately, this article was just one piece of a complex project risk management framework: Many other processes happen before and after this one.
If one part doesn’t work, the whole system breaks.
My Risk Management Plan Template connects all processes and tools into one cohesive system. It also provides access to other articles and videos on risk management.
Don’t put your projects and reputation at risk. Ensure you know how risk management works in the real world.
All successful project managers know it’s better to learn from someone else’s experience (aka lessons learned). Tap into my 12 years of practical IT experience and get the Risk Management Plan Template.