Once upon a time, several blind sages groped an elephant in order to understand how it looks like. But everyone studied only the part of the animal that was closest to him. One said the elephant was like a snake, holding it by its trunk. Another held its leg and insisted that it looked like a tree. The third held a tail and said the elephant looked like liana. In the end, the wise men could not agree and understand how the elephant looks like.
An interesting fact is that each of them was right in his own way; each simply saw the situation only from his own side and refused to accept information from his peers. If they had put together their observations, then, most likely, they could compile complete information and see the whole picture.
This tale demonstrates well that one person cannot be an expert in everything – that is why a team of people is needed to get most of the jobs done. Each person has their own world outlook, certain life experience and a set of beliefs, through which they look at the world. Everyone assesses the situation from their own point of view, and when different ideas are put together, the chance is higher that the right decision will be made eventually.
Anyway, the more opinions are involved, the higher the risks that some of the opinions will clash and things will go wrong. In this article, I’ll explore what tools and approaches are required for effective risk management in software development projects.
In classic project management, everything starts with a risk management plan and strategy, which defines how exactly different risks will be managed in the project down the road. Also, at this stage, we can identify specific methodologies and tools, roles of participants, risk categories and other details that help define a proper approach to risk management. A risk management plan is a very useful document that will help you answer many questions in the course of your project development, but it may take a long time to prepare it, especially if you have not paid enough attention to this issue before.
In practice, there are two documents that can help you with your risk management strategy: a risk map (aka risk heat map) and a risk register.
Risk register
Risk registry is a regular spreadsheet comprised of 3-4 to a few dozens of columns, depending on a degree of risks processing required. For example, you can maintain it in Excel, create a doc on your company’s SharePoint portal, or even use your Project Server, if it offers such a feature. In practice, any format will do as long as this document is used on a regular basis.
Take a look at a small example from one of 8allocate’s real-life client projects below:
For convenience, you can also add columns indicating the date of risk identification, assignees, risk response strategy (accept, avoid, etc), risk type (threat/opportunity), possible cost of impact, and other attributes that you want to keep track of and control on a regular basis.
In project management, a risk register must be created from the very beginning.
At 8allocate, we make sure we build a transparent relationship with each client from day one, and in order to avoid missing some risks which can become critical to our client’s project success and development budget, we convince each prospective client to have an extended discovery workshop with us, where we can identify all of the possible risks and create a proper roadmap for handling them.
Examples of risks at the project planning stage
Once the project start has been agreed, the planning phase begins. Here, a good project manager begins the most intensive work: you need to assemble a project team, designate a list of activities, correctly identify the links between them (first draw, then make up) determine how to manage the project, prepare a work schedule, etc, etc.
At this stage, a significant number of project management artifacts should be created,which will help detect many risks that seem to be “underwater”. Examples of such artifacts can be a work schedule, plans (or strategies) for managing risk, communication, quality, a list of project requirements, resource requirements, a project product description, and so on.
Now let’s take a look at an example of what risks can be identified given you have certain time limitations. Let’s say we only have one month to deliver a project. We’ve allocated resources, created links, defined assignees and set priorities – everything seems to be topnotch. However, you forgot about one tiny detail – one of your team members has an approved vacation in the middle of the month and there’s no way you talk him out of this vacation or convince to postpone it. Such situation usually happens at the client’s end in case of a distributed or extended software development team. When there’s an interdependency between remote (subcon) and in-house teams and the client forgets to inform you in advance that one of their in-house team members will be off for 10 days when he’s most needed on the project – that’s already 2 big risks of the delayed delivery.
Risk 1
Risk description: the client’s team member will be on vacation during project execution.
Impact: Due to the fact that the deadline is in 30 days and an average vacation lasts 7-10 days, the absence of a key developer in the client’s team will have a high impact on the timing of delivery.
Probability: high
Status: Since we’ve just identified the risk, let’s mark it as “New”.
Comment: We need to request information from the client’s PM/tech lead about in-house staff availability for the period of project execution.
Risk 2
Risk description: The project acceptance will be delayed due to the absence of a customer representative. This may have an impact on the deadlines for the project.
Impact: If we delay the deadline, then this is certainly bad. However, the delay will clearly be due to the customer (who lets their key people leave the project when it’s halfway) so we can expect that the penalties will not be applied due to the delay. I would mark the impact as medium.
Probability: To begin with, I would mark the “Low” probability of this risk, since the customer approached us and therefore has clear intention to complete the project. As such, we can expect their involvement and participation.
Status: New.
Comment: Talk to the client, explain the issue and continue to work on the rest of the project.
Many other risks are possible, too. Your best software developer can get sick, the client may impose penalties for the late delivery, or the code you deliver can be poorly written and hard-to-maintain. To avoid as many risks as possible, you need to consider all of the options and work out strategies to address them.
Risk maps
Sometimes your risk registry may not enough. Has your risks log already exceeded several tens or hundreds, and you have no time to control everything? You may need a riskmap to better visualize all of your register entries as charts. Such maps allow us to quickly identify items that deserve your attention, and set priorities for them.
Below is an example of a risk map from another custom project delivered by 8allocate:
On the abscissa axis we have the Impact, the further to the right – the stronger the impact on the entire project. The ordinate axis is the Probability of the risk occurrence. R1 … Rn are the numbers of risks from the register, which are used as a signature.
The tricolor background is green, yellow, red and is designed so that it is clear when we should pay particular attention to specific risks. As we can see on the map below, the risks of R9 and R13 are in the danger zone, so these two risks should receive increased attention and control.
The first three columns are links to another tab so that values are automatically substituted. Columns D and E represent the numerical values of the risk so that the diagram is plotted correctly. In columns G and H, as you can see, I have an intermediate, technical compliance table so that VLOOKUP can correctly substitute values.
I usually build a diagram in a separate tab in the same file where I have a risk register.
I removed the formula in cells D4 and E4, since the risk has been worked out and closed and it makes no sense to display it on the diagram anymore.
Having built a diagram once, you can continue to update it in a couple of minutes and use it for weekly reporting on the project status, for instance.
To conclude, the ability to manage risks at the level of PMI-RMP (Risk Management Professional) cannot provide a 100% risk protection. There will always be situations that are simply impossible to control. There will always be problems and force majeure situations that could have been prevented thanks to proper risk management.
While you can rely on your theoretical knowledge gained from such PM methodologies as PMBOK or PRINCE2, you can only master your risk management skills after going through dozens of risky situations and finding non-trivial and outside-the-box ways of managing them. Do you agree?
