INTRODUCTION

When we build a Backlog for Agile Projects, we just pile it on and try to always use the latest and greatest, untested tools out there.

Now … let’s get back to earth for a moment. In real life, do you really want to put your projects, customers or your own organization at risk? … we don’t think so.

(Quick note: This document is by no mean a training on the methodology but a high-level description so that you can understand the essence. Also, this is one version of a Risk Management Methodology and there are several out there following different approaches with different flavours. You are free to pick and choose and even combine.)

WHAT

“Everything we do in our day to day lives has some risks and we know it… and we accept it as facts.”

For the most part, it’s instinct that will kick in and we, without really realizing that we are doing it, are managing the risks. Now, that’s what we do in our day to day lives … what about at work or during our projects we manage?

WHEN

This is when a Risk Management Methodology comes into play. Since we tend to forget about Risks, it’s important when managing to always ensure we force ourselves to bring them forth and understand what the possible impact would be by properly applying Risk Estimation.

You will see us referring to the GOLDEN RULES, well that’s just a term to refer to a best practice based on Emyode’s experience in the field which, obviously, can be adapted to how you feel comfortable with. But at least it gives you a concept to start testing and applying some concepts of Risk Management.

Before we get into HOW, it is important to understand that applying a Risk factor is different from applying a Buffer percentage. This one is controversial since most people say that Buffer management and Risk management are one and the same. Buffer management is more of a rounding than anything else and the project you are working on may have no risk per say. (More about Buffer management in my article about Time Estimation).

So now let’s look at …

HOW

Here is the detail behind the Risk Estimation Factors and how you need to apply it to your projects:

RISK FACTOR: For Each User Story (or if you want to go more granular, you can go by Task – it’s your choice), there is an element of Risk associated with it. How you define Risk can be open to many discussions. However, there are basic Criteria to take into consideration for each level. This is just to give you the essence.

• NONE – Well that is … no risk at all … but still add 10% and you know why? Because even though it’s something that we’ve done before there are always unforeseen changes and requests which may impact your time estimate. That would be for User Stories which are more Administrative for example.
• LOW – add 15%: Some information is still to be validated like a new resource, small gap in Knowledge between some resources.
• MEDIUM – add 20%: Using a new “version” of the environment, untested Hardware, vague deliverable or even if it looks it was well explained, it may be interpreted (i.e. Training vs Knowledge Transfer for example); when at least 2 outside vendors are involved; when at least 3 teams are impacted.
• HIGH – add 25%: A project involving New Software or New Hardware, Critical Environment; Multiple Sites involved; Time Zone involved.

The goal here is to use your judgement when looking at this list and understand the type of risk associated to the proper level.

GOLDEN RULES

CONCLUSION

Risks are important to estimate and should be taken into consideration on all of your projects when you go through Time Estimation, either Time and Material or Fixed Fee efforts, for those in consulting.  So now that we’ve made you think about Risk, we will let you go and have fun!