These risk management examples will show how to solve several problems. I want to stress that problems are solved long before the team encounters them. No stress, no panic, no firefighting. That is how risk management should work.
Managing risks is a mature level of project management. When a piece of work is well defined it will be done smoothly. So you can focus your project management approach around solving problems. You remove impediments that disrupt the normal working process.
Moreover, you think ahead of time. You try to predict and avoid events with negative impact
These risk management examples are from Corwin’s experience. So, I will tell the stories on his behalf.
Risk Management Example #1: Requirements Analysis
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 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 till 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 Management Example #2: Sick Leaves
This case is so common 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.
That is an example of lame risk management. So what is my approach here?
You will never see this on my projects. I never allow working at the office when you are sick.
Response Plan
First of all, I 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 tell to take care, sleep well, and to 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 office if someone caught a cold and felt sick.
Third, I arrange a possibility of working from home.
That was all common sense, wasn’t it? Now, to the project management. 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 past two years in HR department. It appeared that the numbers are dramatically lower. On average for a team, it was like 10-15 man-days during Autumn.
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 is 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. The Bigger team may require larger reserves. On the other hand, they have a better ability to cover up losses.
Risk Management Example #3: Third Party Dependancies
This one is short. 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, etc.
Even if you worked with the vendor before, do not rely on previous experience. Review the lessons learned but treat them with caution.
Response Plan
That is not an academic approach. However, multiply by three.
Takeaways
These risk management examples show that it is not about theoretical knowledge. Quite often only the general framework is common. The approach to identifying and responding to different risks differ. Quite often it is as simple as adding a tasks or reserves. Sometimes it is just common sense that you need to apply explicitly. Some cases will require a lot of planning, negotiation, and analysis.
Share your exceptional cases of risk management below in comments.