Risks within your project | Pre-Mortem
Intro
Have you ever faced any failures during your software development? Or building a nice family house you hope to hand it over to your children? Possibly you faced some negative events at your wedding ceremony? Or anything similar to this? If your answer is yes — you have faced the risk. A product or a project doesn’t matter, the only important thing here, if you were ready for it?
I am working in the field of software development and my main responsibility is to assure that the quality level of a product would face customer’s expectations at least. The product must be delivered on schedule, any activity performed within the team must be transparent, time and cost-effective, and understood by the team itself. Also, in a perfect world, the customer expects me to prevent or, at least, to predict, all the risks the product may face so we can avoid or prepare for it. Definitely, it is not possible to know everything about your project and, truth be told, this would be just a waste of time. But still, one must know the most obvious and devoured issues the project may face during its development.
So, how one can know it due to all limitations of human beings?
The Team and its imagination
The answer is always closer than it may seem — the Team may provide itself with all the data required to prevent and prepare for the majority of risks the project may face. There are a lot of different methodologies for risk clarification, but my favorite one is Pre-Mortem. It is based on the team’s consciousness and understanding of the product. Very agile, people-oriented and in my humble opinion, effective.
So, how does it work?
Step 1. Enlight the team
People don’t like to do activities they don’t understand. So, it is up to you to clarify why you need it and what the goals you aimed for were. We need to decrease the level of uncertainty, we need to understand clearly our weak spots and how severe consequences of that weakness could be. We need to be prepared for the most disastrous scenarios one may imagine, even if they are not highly possible. To be honest, all the crises in the world economy came from the circumstances with “very low possibility”, so let us at least be aware of it.
Step 2. Limit the Scope
When everyone shares your goals and understands your intention with the risks, let’s limit the scope. We have to focus on something to effectively analyze it. In my case, it is usually a sprint or a few of them. But you can apply it to anything, just try to find the golden middle — not too huge, because it would be very vague, not too small, otherwise, you drawn in the details.
Step 3. Tools
That depends on the format of your meeting. If you go online like I usually have to, the Trello always helps me a lot with the generation phase, but any similar service would do the same. Just create a board, share with all the participants and voi là — everyone can scribe down their threats. In case you work offline, you need a whiteboard, magnets and a lot of stickers with pens. Have three columns for now: Ideas (to store all the generated threats), Keep and Not now (will cover a bit later).
Step 4. Generate!
Now let the team generate any ideas on the possible risks for the product or project they can only imagine within the clarified scope. If you have any — go for it too and remember — at this phase everything is allowed.
Spent about 15–20 minutes on this activity, usually, that’s enough for a regular person to generate all the risks he or she could think of.
Step 5. Sort it
Now we have it scribed down on the cards so let’s review it and discuss it on behalf of possibility and severity. Everything that is highly possible and highly severe — goes to Keep; Low possibility and high severity — Keep, but disputable; High possibility but low severity — Keep; Possibility and severity are low — Not now.
Step 6. Manage
Ok, we have the relevant risks left only — sort them by next parameters:
Likelihood — how possible is it? Is it high (3), medium (2) or low (1)? Some methodologies would require you to have a clear baseline for what the difference between all of them was, but in this case, I’d rather go for intuition and discussion, instead of baselines.
Impact — how severe the consequences for us would be if this happens? Is it high (3), medium (2) or low (1)? Same for the baseline here as for me. Discuss it and go for the price you feel it.
Risk Level — your final score that shows, what stands behind that risk. Just do some maths, Likelihood * Impact = Risk Level and you have quite a clear picture of what requires your attention here and now, what can wait for a little or wait at all.
I am trying to prevent or avoid everything that has level 9 — this is a real danger for the project so after identifying one, we can reprioritize all our activities immediately to get rid of this outcome.
Level 6 usually calls for the same but without a rush. In case we have no options to avoid it, we tend to create a contingency plan in case we face this risk.
Level 4 fate depends on every individual risk. The priority here is not to spend all the resources on the risks because we still have the goals project is supposed to achieve in the schedule.
Level 3 to 1 are just ignored. We are not throwing them away, just do nothing about them until their level grows enough to call for our attention.
Step 7. Execute
Any good intention may die at the beginning of its journey, so assign responsible persons for all the activities, set the deadlines (always) and milestones (if necessary) and make sure your Risk Assessment Session becomes part of your routine working schedule.
P.S. Always remember — you can not prepare for everything and Black Swang will come to you sooner or later.
