risk management in software project management

A risk is an uncertain event or loss that may or not probably happen but if it happens then it will have serious consequences

To understand risk let me explain to you a simple example, have you ever traveled on a flight, if you did, then you would have notice flight safety demonstration by air hostess to the people on the board

1. Fasten your seat belts during flight takeoff
2. Oxygen mask and safety jackets will drop automatically in case of emergency
3. There are six emergency exit (two-doors at the rear of the cabin, two in middle, and two doors at the front of the cabin)
4. Two window exit
5. In case of any emergency, the lights will illuminate to exit
6. It is illegal to smoke on a flight

What do you think?

Why the air hostess demonstrated safety instructions on board? because the flight will probably crash with 100% accuracy

No!

She did it because to put you on the safe side, and to avoid the risk of an accident

Another example: if you are a web developer or a blogger you probably know that whenever you update your WordPress site to the latest version

You probably back up the files first then you would update the site because if something wrong happens by mistake then all your years of hard work will be gone in a second that cannot be retrieved

The risk of losing the data of a site within a second is an important issue that needs to be considered

Why should we do risk management?

There are two types of attitude towards risk

1. Reactive
2. Proactive

Reactive means you initiate the project without fully understanding the risk involved by assuming that if something happens, then you will defeat the risk by your heroic action but in reality, it won’t happen like that

Proactive: means before the project begins you, first: you will understand and identify the risks involved in the project

Second: all the risk are ranked by their probability and impact on the project

Third: develop a plan with teammates to manage it and

The benefit of having a proactive attitude is that you can avoid risks before it becomes reality

 The reason, why we do risk management is to make the project reliable and to improve the quality of the project also to reduce the loss of time, cost, energy

Consider a simple quote made by Sun Tzu a Chinese commander to understand the importance of identifying  the risks

“If you know the enemy and know yourself, you need not fear the result of a hundred battles”( Sun Tzu)

Now! You will ask who is the enemy?

For a software project manager, the enemy will be a risk

A software project manager needs to identify all the obvious risks related to a project

Risks brainstorming

Suppose you are doing an audio plugin software project and to complete the project you have a software engineers team

To build the software from scratch, you called the group meeting to discuss the project, at this instance, you started the  conversation by asking a question(where we can go wrong?)

Next, you have shown some categories where things can go wrong and ask the team members to make a list of risk that should be analyzed no matter, how weird it might be

So, all the team members wrote their list. at this instance, you gathered all the lists of team member and wrote them on a whiteboard and they identified 60 risks

Now! How to manage 60 huge risks!

First: ranked all the risks by a percentage of probability of occurrence and the impact (range the impact value from 1 to 5)

Second: reduce the identified 60 risks by using the Pareto 20/80 rule

Third: develop a plan to avoid risks

Do you know, what is a Pareto 20/80 rule?

According to the 80/20 rule: 80% of the results come from 20% of the causes

In 1906, an economist called Vilfredo Pareto observe 80% of the land in Italy was owned by only 20% of the population

So, we can focus on 20% of the causes to get 80% of the result

The same principle is not only applicable to economic but to all walk of life, consequently, we can also use this principle to reduce the risk list to 20%

Understanding risks and analyzing them will take significant time, effort but the effort is worth it

Reference

• Software engineering a practitioner’s approach by Roger’s Pressman