Risk Management Examples: 9 Behind the Scenes Stories

It is hard to imagine what you can do with a project risk.

Yes. Avoid, mitigate, transfer, and so on.

But what does it mean?

What specific actions can you take to avoid something? What can you, as a project manager, do to mitigate a risk?

Adding some risk reserves and removing requirements from the scope are not the only options.

I want to share some stories of risk management with you.

Some come from my experience. Some I heard from other PMs.

These risk management examples will help you to broaden the understanding.

It is not an exhaustive list of possible actions.

Nevertheless, your mind will start working in new directions.

But keep this in mind:

Your risk management efforts are as good as your plan. That’s why I’m also sharing my Risk Management Plan Template:

List of Risk Management Examples in This Article

I recommend you to read the whole article. If it’s too big for you – choose a story from the list:

• Fixed Deadline Risk Management Example
• Huge Uncertainty in Project Scope
• Example of Risk Management with Inefficient Quality
• Risk of Losing an Important Team Member
• Risk Example of Incorrect Requirements
• Risk of a Vendor not Fulfilling Commitments
• Project Risk Management Examples with Sick Leaves
• Risk of Unclear requirements
• Risk of Destructive Stakeholders

Fixed Deadline Risk Management Example

You will face a lot of such cases:

Clients come with a fixed deadline to release a product or service.

They have a particular scope in mind. In the beginning, they think that all their points are Must-Haves.

The budget is fixed as well.

The first impulse is to get as many people and resources as possible. Do as much of the scope. Pray that you will fit in.

That’s bad planning.

Risk Response

This risk management example shows an integrated approach to mitigating threats. It means it works throughout all your project management efforts.

In many cases, adding more people doesn’t increase productivity proportionately.

Moreover, putting people into too much stress over a long period of time doesn’t work well.

They disengage the moment they feel it is impossible to achieve the project’s goal. There is no benefit of working hard for the next few months. And then fail in any case.

There is a better approach:

Usually, your team and some internal subject matter experts have crucial expertise.

(Better than clients have.)

Use their knowledge and authority to break down the scope into three groups:

1. Must have
2. Should have
3. Nice to have

Don’t agree to put everything into the first bucket. It is never the case unless you are doing an MVP.

Identify the scope of work that is crucial for the (first) delivery.

Additionally, promise to deliver as much of “should have’s.”

Notice the difference:

You don’t suggest to de-scope the project, remove features or capabilities.

You promise to deliver what’s critical for project success. Plus, you add everything that fits into the deadline.

Entirely possible you will be able to deliver everything in the end.

However, if not – you have an acceptable contingency plan.

Huge Uncertainty in Project Scope

In this case, the risk impacted the scope of the project. However, it might as well be a technological or integration risk management example.

We had a significant and complex enterprise piece of software.

Without going into details, we had to add new functionality.

From the beginning, it was clear it is a big piece of work.

As usual, there is a question. Should we do it or buy it?

Even if we buy it, there might be efforts to integrate and customize the solution.

So, it may go from plug the module. It works as-is.

Or it might be:

Buy the module, spend a lot of efforts to customize it if it is at all possible. In the end, it will appear that it is not a cost-efficient decision.

How did we manage risk in this example?

Risk Response Plan

In fact, we introduced an additional phase to the project.

We decided to make a proof of concept.

We found available solutions that can be used with our product. Then, we negotiated a free trial where we tried a quick and dirty integration.

Now, we are able to identify the costs and additional work.

The idea here is simple:

We didn’t start a project with significant uncertainty in scope and budget.

Instead, we did just a bit of research beforehand and eliminated the guesswork.

So, we did it even before we started planning. It means we started risk management right at the start of a project.

It is not something you do on a daily basis in Project Management.

However, it is a risk management example that shows an extra mile you can take.

Do keep in mind that your risk response should be adequate to the impact of a risk.

Example of Risk Management with Inefficient Quality

This risk management example shows that you can change processes to overcome risks.

So, I had a relatively inexperienced team.

In general, they had all the expertise to do the work.

However, due to the complexity of a product, there were lots of defects.

With changes in different areas defects stacked up and multiplied.

They impacted the schedule greatly.

We tried simply adding Risk Reserves. However, it was guesswork without consistent accuracy.

Moreover, there was a complication.

The time it takes to find, fix, and deliver a corrected version of the application grow with its complexity.

So, I went for a profound solution.

Risk Response

The initial workflow looks as follows:

Analyze requirements -> Implement the requirement -> Test your work -> Create and hand-off deliverable to Quality Assurance Engineer.

Then, the QA Engineer tests the deliverable. Logs defects and returns the deliverable back to the developer for rework.

Even on a small project, it is a time-consuming process.

So, I introduced a quality checkpoint.

It happens at the moment when the developer has tested his work and is ready to hand-off the deliverable to QA Engineer.

A QA Engineer has to do a quick review of the work before it gets into a deliverable.

Usually, it takes 5 to 15 minutes. In comparison, the testing to get a sign-off on the requirements may take anywhere from several hours to several days.

It was a quick win.

The number of defects reduced almost in half. Moreover, the severity of those defects was lower as well.

However, there is a catch.

It is not a perfect solution:

First, it takes additional efforts. Second, it introduces distractions for the QA team. Third, it reduces the ownership for the quality by developers.

I had to work with these side effects (residual risks) additionally.

Risk of Losing an Important Team Member

You have planned your project. Your plan looks realistic. Clients love it.

Check this out:

Look at your schedule. Do you have one person who is involved in all activities on a Critical Path?

Look into your RACI matrix. Is the same person responsible for the majority of deliverables?

Look into his or her assignments. Is this a person who has unique knowledge and experience?

What will happen if he or she leaves in the middle of the project?

That is a typical case. Every project has such “hard to replace” people.

Risk Responses

Here you should apply a whole set of preventive actions. You need to mitigate the probability of such a risk.

It is something you must do anyway:

Talk one-on-one with this person. Identify concerns she has related to working environment, her happiness, satisfaction with the impact she makes, etc. (Mitigate the probability of risk)

However, the main question stays the same:

What am I going to do if this person leaves?

You may have a suitable candidate to move up the ladder. It might not be a perfect solution. But the impact will be lower. (Mitigate risk impact)

You may try to find someone outside of the company urgently. (Actively accept the risk)

You may be transparent with clients and agree to take on the impact. Make changes to the plan. Soak up the effect. (Passively accept the risk)

There are many options. You need to pick one. It should be adequate to the amount of the impact.

Risk Example of Incorrect Requirements

Below you will also find another example of risk management in case of unclear requirements. This one is about assumptions and incorrect requirements.

This one is different.

Here we made a critical assumption.

We assumed that we clearly understand the need of our end users.

The problem is our end users are people with special needs and severe problems of fine motor movements.

We developed a solution that helps such people interact with phones and tablets.

For sure, there are several approaches to implement it. However, we didn’t want to make a bet of one of them.

It would mean that we would spend lots of time on development and getting this capability to the market.

It would take even more time to collect actual feedback from end-users.

In the end, there was a significant risk (about 30% probability) that we made a wrong assumption.

So, what did we do?

Risk Response Plan

We decided to create a prototype. It took us less than a week.

During this week clients were able to organize a workshop with users.

They demonstrated a prototype and let the user try out the approach.

In general, it proved our approach valid.

However, there was a catch:

We discovered that all users use the same approach to use the device. But they all had different speed of reactions.

This way we identified a new requirement for customization for this feature.

Risk of a Vendor not Fulfilling Commitments

There is an empiric rule here:

Multiply by three all interactions with third parties.

The worst case is when several vendors work for one client and on one product.

If you depend on any deliverables from others, you can never rely solely on your schedule.

Delays happen all the way.

They finish their work later. Then, it appears that the deliverable is not functioning at all. Someone goes on vacation and can’t fix it.

Then, you find a defect during integration. They must fix it, and all your efforts are wasted. You have to do it all again.

Add here communications overhead, thin responsibility, no integration with another project, etc.

Even if you worked with the vendor before, do not rely on previous experience. Review the lessons learned but treat them with caution.

Risk Response

In many cases, you don’t have much leverage over third parties. Moreover, if you don’t contact them directly.

So, the best approach here is to allocate risk reserves of time to mitigate possible delays and rework.

You do it in your schedule.

However, if you have authority, you can try to force the update of a typical contract.

At the very least you can add a clause for them to provide weekly reports and attend some meetings.

Lately, I have also seen a case when a company enforces a change in the overall project management approach.

Each and every vendor had to comply with this approach to fit into the delivery strategy of the whole enterprise.

Updating contracts on the go is hard.

However, you can provide your ideas to the procurement department for all the future contracts with vendors.

You can suggest doing the same to your client. They can adjust the work of other third parties you need to interact with.

Project Risk Management Examples with Sick Leaves

This case is so typical that it should be handled by default on any project.

This risk management example also shows there should be a lot of common sense in the process. Risk management is not always about expert knowledge or project management tricks.

We had a critical project at hand.

It had a strict deadline.

Therefore, we had to triage the scope and still be ready for release with everything we could finish.

And it was early Autumn.

The weather was changing dramatically. Traditionally it is a season of sick leaves in the organization.

That is something I had to take into account.

How does a project manager usually think?

If a person catches the flu, he is out for about two weeks. Moreover, if a critical person is out for that much, the project will be delayed for two weeks. If more than one person is out – then, it will be even more.

Usually, stakeholders do not accept time reserves for sick leaves. Especially that large. I should say they are correct in doing so.

(Though that is what makes people come to the office when they are ill. I don’t support such an approach.)

That is an example of lame risk management. So what is my approach here?

Response Plan

First of all, we work with people. Most of the time people get sick because they get reckless a bit.

I had to engage a mommy mode. Therefore, I do tell them to dress up to the weather. I also say to take care, sleep well, and think about their health.

They must share responsibility. It is a crucial project for the company. They committed to do it. Therefore, they should try not to fall ill.

Second, I prohibit visiting the office if someone caught a cold and felt sick.

Third, I arrange a possibility of working from home from the beginning.

That was all common sense, wasn’t it?

Now, to the project management aspects. How much time reserves do I need?

If you cannot measure it, you cannot manage it. Or something like that.

So, I got the statistics of sick leaves for the past two years in the HR department.

(I’m sure you can find such statistics as well.)

It appeared that the numbers are dramatically lower. On average for a team, it was like 10–15 man-days during Fall.

Fear has big eyes.

Therefore, I do not plan for epidemics lately. I know, it may differ for your project and organization. However, the main point here is to use statistics.

So, what’s left?

We need to mitigate the risk of one critical person to fall ill.

Avoid tasks that can be done only by one person in the team. You can do it during planning.

If I have critical persons on critical path activities, I take more time for preparation. I try to ensure that someone else can take the task. At least with reduced performance.

Therefore, we document and communicate the selected approach and technologies. The goal is to find the substitution.

Sometimes I have to look for the substitution outside the project team. The main idea is to do it beforehand. That person is not sitting idle. His or her manager should plan to share his resources if it is possible.

In the end, for three months of work, I reserve only about a week for sick leave for a team of ten.

A bigger team may require more substantial reserves. On the other hand, they have a better ability to cover up losses.

Risk of Unclear Requirements

From the start, there was one significant unclear requirement.

In fact, it was just a vision. However, it got into scope statement just like that. Customers promised to deliver detailed specification soon.

Of course, it got to the Risk Register at once. I first put it as a high-level risk.

Such risks usually can have different impacts.

The promised specification can be delayed. It can be of poor quality. I mean, it may not cover all aspects of the requirements. Or even worse. It can be both.

Moreover, poorly defined requirements mean poor quality.

We scheduled the delivery of this requirement close to the project end. We wanted to give time to the customer.

Nevertheless, we monitored this risk closely all the time. We set deadlines and made time and costs reserves. There was a date by which we were to receive the specification.

After it, we will have to kick in and clarify requirements on our own. Therefore, it was our trigger to use reserves.

I felt it was a big thing.

So, I did not stop on that. I used some slack in the schedule to brainstorm the problem.

The feature had many dependencies with other functionality of our service. There were hundreds of use cases. It was clear that we will never get a full spec.

We decided not to wait for the deadline and acted proactively.

We created a change request. It explained that we need to act upon the risk now. Moreover, we need to use the reserves.

So what was our response plan?

Response Plan

We analyzed the complexity of the requirement:

It turned out it did not require much technical skill. It was more about fundamental business analysis.

We evaluated that a junior level quality assurance engineer should handle it.

Then, we acquired one for a week.

I asked him to get familiar with our product and focus on one specific functionality. His primary task was to draft out all use cases for our new feature.

He did the job in about seven days. However, we had much time until we get to the implementation yet.

So, the main team reviewed the draft and elaborated the specification. In the long run, they define an algorithm that covered all the cases.

By the way, we did not work overtime. We always plan the slack into the schedule. So, in-between activities we managed to mitigate the impact on our deadlines.

That is one of the hallmark risk management examples I have.

We implemented the feature flawlessly. Without any serious defects. I doubt we could do it better under other circumstances.

Moreover, I believe we even saved a lot of resources in the long run. However, there is no way I can prove it.

Risk management is all about prevention of the problems in the first place.

And it is its bane.

It is so hard to demonstrate that you saved money, time, and efforts.

Risk of Destructive Stakeholders

Specifically, in this case, I describe destructive stakeholders with good and valuable intentions.

They are destructive towards your responsibilities as a project manager.

However, keep in mind there will be intentional destructive stakeholders. However, risk response will be almost the same.

This example is on the fringe of ethics for a project manager.

From one side you need to find a way to work with all key stakeholders. You need to create mutually beneficial relationships.

From another side, you need to finish a project successfully.

Moreover, there are two more sides to the problem:

A good project manager also has to help clients develop their business.

You may also need to help develop the business of the organization that you work in. In essence, it means to get more projects and work from the client.

All of these are in constant conflict.

Developing business means increasing the project scope. But if the budget is limited, it means increasing the risk for the current project.

You may work with internal stakeholders who are responsible for developing business with your client.

You have one goal in mind – make a client happy.

But your success criteria are different.

Once a new scope is identified, you need to ensure you ran it through a proper change management process.

Now it is your responsibility to decide whether it fits into the current project. Whether it is aligned with the project’s goal.

Risk Response

You need to ensure you have clear responsibilities between you and business development stakeholder.

You need to have clear boundaries between their promise that we can do it. And your commitment to delivering it in the current project within given constraints.

Quite often it will mean you need to dive deep into the companies internal politics.

You will need to limit their authority over your project.

And usually, there is no easy way here.

You will fight for finishing the project on-time and within budget. While they work to bring more money to your company.

The benefits of finishing projects and delivering value to the customer’s end users are hard to prove.

This risk management example is in the realm of business acumen and internal politics.

Nevertheless, it directly impacts your project management efforts.

I Recommend to Read Next

• Practical Project Management Book
• Risk Management Process Explained (+resources, templates)
• Risk Identification (What is it, techniques and examples)