Risk management isn't about stopping risk.

It's about understanding,

prioritizing and controlling risk. Any business that doesn't understand
andcontrol risk is bound for asset destruction, compliance issues, scandal and
financial collapse. 

Risk management adds value in several important ways: 

1. Risk Management Provides Risk Transparency

Imagine a firm that has no view of the risks that employees take with the
firm's assets and reputation. 

Risk management identifies risks and measures the impact and probability of
risk. This is essential financial transparency that's arguably as important as
revenue and cost reporting. 

2. Risk Management Provides Accountability for Risk

Accountable stakeholders may choose to accept risk. Risk management
provides accountability for risk-taking decisions. 

3. Risk Management Reduces Risk

Risk management identifies strategies and implements plans for mitigating
and transferring risks. 

4. Risk Management Aligns Risk With Strategy

Risk management allows a firm to focus risk-taking on strategic objectives. 

Typically, risks that are critical to your business strategy are accepted. Risks
that can threaten your business strategy are eliminated. In this way, risk
management helps a firm align risk to strategy. 

5. Risk Management Prepares for Risk Events

Risk is the effect of uncertainty on objectives. Risk management identifies,
assesses and controls potential events. When these events occur, you've
planned for them. 

6. Risk Management Monitors Risk

Risk management monitors and handles risk events. This allows for prompt
risk response. 

7. Risk Management Supports Sustainability

Sustainability is the capacity to endure. Risk can threaten the survival of your
firm. It can even threaten the survival of an entire system (e.g. global
economy, planet's ecosystem). 

Risk management isn't optional for any firm or system that hopes to sustain
itself. 
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 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.

 Clic
k the image (opens in new tab). Enter your email. Get access to the whole PM Basics Library.

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 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 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 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.
Stakeholders have their own requirements and expectation for you. They are not always aligned with
goals of a project. [iStock/XiXinXing]

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

Always define the correct means of communication for each stakeholder. [iStock/ktsimage]
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 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 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 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 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 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 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

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?

Organizations 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