2. • WHAT IS RISK MANAGEMENT
Project risk management is an important aspect of project management. According to the
Project Management Institutes PMBOK, Risk management is one of the ten knowledge
areas in which a project manager must be competent.
Project risk is defined by PMI as, "an uncertain event or condition that, if it occurs, has a
positive or negative effect on a project’s objectives.
Project risk management is the process of identifying, analyzing and then responding to
any risk that arises over the life cycle of a project to help the project remain on track and
meet its goal. Managing risk isn’t reactive only, it should be part of the planning process to
figure out risk that might happen in the project and how to control that risk if it in fact
occurs.
A risk is anything that could potentially impact your project’s timeline, performance or
budget. Risks are potentialities, and in a project management context, if they become
realities, they then become classified as “issues” that must be addressed. So risk
management, then, is th process of identifying, categorizing, prioritizing and planning for
risks before they become issues.
3. Risk management can mean different things on different types of projects. On large-scale
projects, risk management strategies might include extensive detailed planning for each risk
to ensure mitigation strategies are in place if issues arise. For smaller projects, risk
Management might mean a simple, prioritized list of high, medium and low priority risks.
4. Risk Management Example : 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.
5. 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.
6. 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.
7. Risk Management Example : 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.
8. 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.
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.
9. 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.
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.
