In the past I have used some pretty dodgy approaches to defining risks in a project, from formal approaches like fault tree analysis through to informal approaches like “the evil genius” and “an international standard for being scared“.
So this article is not really a new one. It is more a combination of evil geniuses and international standards for being scared. But I think this workshop should work well when starting any project and particularly small projects with a simple project charter.
The idea is that we start the project by being really pessimistic, then we start to knock off the challenges and hopefully end up with a plan we are confident in.
Gather the people who will be involved in your project. If there are more than 5 then stop and abort this process and find another way to start you project. If you have only 5 or less people then continue (If you are brave then you could try with up to 9).
Step one is to agree what we are achieving. For the minimum starting point you can come up with a quick story and for a longer one you will need a proper charter to define what you need. Select from the following options:
- At the moment (insert something) but we would prefer (insert something) so we will start a project to deliver (something)
- We want to deliver (what) to (who) so they can (why would they want it).
- Complete the lazy team project charter attached at this link
So much for being positive. Now that you are clear one what you are doing then it is time to panic. Even though we always have grand plans for success, the forces of anarchy and general suckiness tend to attack projects in any organisation. So rather than being happy and then shocked during the project, let’s start by being really miserable and then hopefully be happier tomorrow.
Form into groups of 2-3 and select one of the following prophesies of doom. Run through your assigned list of questions until you have so many issues you think it is time to end it all (er .. that is abandon the project, not abandon all hope).:
- Go through the list of why you should be scared. Go through each thing that can go wrong and keep building on it. The winner is the team that comes up with the most terrifying list of why we are doomed.
- If you are rolling something out to users, then you can instead choose to go through the list of all the stupid things they will do with our beautiful project to make it hurt them. Believe it or not people have already researched this list for you here.
- If your project is an internal one, then you can instead list the organisational antibodies that will attack your idea.
Keep adding things to your list without worrying about what to do about them.
Now you might feel a bit depressed. So stop and have a coffee and refresh yourself.
At this point things get a bit more optimistic though. Ask each team (or group of “prophets of doom”) to rank their prophesies and pick the scariest few. These become your Prophesies of Doom. For each one write it out in the following format:
- The specific event will be that [insert event like “we forgot to log a patent and someone beat us to it”]
- This would suck (be sub-optimal) because [insert why it is bad]
Then come back together and work through them.
For each one, decide whether to:
- Watch out for it.
- Panic (or deal with it); or
- Take the risk.
If you decide to take the risk then you don’t have to do anything more with it. The only complication is that if you are unlucky and the prophecy of doom comes true you have to say “fair cop, we were unlucky” rather than assigning blame to anyone.
If you decide to watch-out, then you need to agree:
- The prophecy is worth watching out for.
- If it did happen, we might see the following symptoms early one [what would you notice]
- In addition, we might see the following indicators that mean it is becoming more likely [what might suggest we should reconsider this risk]
- Who will keep watch and when and how will they report back?
If you decide to “panic or deal with it”. Then list the risk (potential doom) and prepare the following assessment
- The potential risk is (what the prophets of doom said)
- This is significant because (why does it matter and how much does it matter)
- What we should do next is (assess it; call a meeting, roll out a feature etc).
Finally, you just put all of this into a todo list and agree to how you will track it:
- Who will do something
- When will they do it
- What will they do
- When/how do we meet or communicate to track it
Of course the other version is to predict doom and go on holidays until it is safe to come back 🙂
Sadly though, I predict that if you do, then the proejct will get delayed until the week you get back and you will have been promoted to be the project manager.