Planning for risk

In past entries I have talked about risk Hidden risks to project success and even delved deeper into specifics of developer risks and financial risks

If we take a step back and look at the concept of risk as anything that could potentially cause your project to fail. Then risks to your project are much more than I have ever covered and are nuanced to your particular situation. If you tried to cover all potential risks then you would end up spending more resources that is possibly worth.

In this entry we will be looking at the concept of a risk assessment matrix.

A risk assessment matrix is an impact vs likelihood matrix representing the various risks that are on your project. The three by three matrix helps you visualize the overrall risk profile of your project and show you where you should focus your efforts.

The matrix

You can make a bigger copy of that particular matrix or even use it a doc.

Risks are arranged with increasing impact on the y axis up. They are placed with increased chances of happening to the x axis.

You will note the measure of likelihood and impact are relative to each other.

Example of a filled out matrix below:

Mitigating the risk

Now that we have the risks listed out in a way that we can easily visualize, its now time for us to jump into action.

Level 1 risk

This should appear as an item on your next iteration.

You should do anything within your power to mitigate this risk as soon as possible.

In the example above we had feature creep. So you may want to for example have the client sign off the user stories to be built and have the agreement in writing. This action would push down the risk on the likelihood scale.

Level 2 risk

This risks don’t require urgent action. However you should dedicate some time to coming up with a mitigation strategy in case the risk does materialize.

In the example, we had developer gold plating. It may not make much sense to over invest in making sure the developers don’t gold plate. A simple practise like daily standup can help you control the risk.

Level 3 risk

Risks on this category present an avenue to exercise the mantra, what you don’t do is just as important as what you do.

Beyond basic monitoring, you need not invest much in this risks. You only need to watch out for when there level escalates.

In our example we had developer is poached. Since we take good care of our developers we know this will not happen and even if it does happen the contract with them stipulates a 30 day notice.

How do you control risks on your projects? Tell us on the comment section below or on my twitter @ jchex


Published by


Software Project Manager