What you don't know, can't hurt you… You sure, right… not. When you are hooked on cigarettes, you smoke like a maniac, chances are you will claim you aren't addicted. Even if you can't stop, there's always this "if I really want, I can stop right away." You are in denial. You know you have a problem, but you're mentally not ready to accept it. In software projects you also have these kind of "denial" things.

You know problems can occur, but you just ignore them hoping they will blow over, will not happen anyway, you don't want to rock the boat, cross that bridge when we come to it… ("… if there is a problem, we get over it…", lyrics of some old 80ties disco tune).

So, basically, there are things that you know you don't know around software projects. If you ignore them that's bad, but at least you know. And yep, there are more problematic things, the stuff you are not aware that you don't know them. They will sneak upon you, and you'll never know what hit you. It's very difficult to prepare yourself for the REALLY unknown.

If you have done this software risk management thing for years, you develop some nose for it. You have feelings ("FEELINGS, hohohoho, FEELINGS… lalala"), you have some gut stuff, etc. But how do you start this ability to identify risks? Or, how to bootstrap your gutt.

Develop risk checklists for software risk management

The answer my friend is … checklists. Start creating lists of points that you want to review for risks. As you do this more often, your risk management checklist will grow, you can put all your experiences in it, in order to avoid having the problem in the future. But how to get started?

First of all, you are not alone. This is not a unique thing you are doing. So, of course, there are standard checklist you can start from. The Software Engineering Institute provides a very nice starting point. The SEI risk taxonomy is a structured risk checklist that organises software development risks into a certain framework. But, with all the work you have done in the previous sections, you also come a long way. We could name it "Stakeholders Risk Taxonomy", or, more appropriately "the bloody list." I created it by writing down 30 minutes some aspects I covered in the previous chapters. It is not intended to be complete, it is merely intended as an example on how you can deduct checklist from this book.

Stakeholders

* Have you identified all stakeholders?

* Have you identified from all groups the leader or spokesman?

* Have you ever met the stakeholders?

* Do you have information on the background of the stakeholders (history)?

Stakes

Fears

* Do you know what the fears are generally for the type of stakeholders you have (e.g. programmers)?

* Do you know what the fears are of the stakeholders per group?

* Do you know what the fears are for each individual?

* Do you know how this project affects the fears of the stakeholders?

Wishes

* Do you know what the wishes are generally for the type of stakeholders you have (e.g. programmers)?

* Do you know what the wishes are of the stakeholders per group?

* Do you know what the wishes are for each individual?

* Do you know how this project affects the wishes of the stakeholders?

Requirements

Product

* Are the cause and goal of the project clear to you?

* Is the project scope identified and does it include what you can change, what you must change, and what you can't change?

Process

* Are the constraints identified (money, time, people)?

* Do you have any idea how much room there is to negotiate these constraints?

* If there are already estimations, do you know how much you can trust them?

* Is the project strategy clear and easy?

* Is the project organisation identified? Does every member have added value to the project?

Project management

* Are you able to negotiate?

* Are you able to think in win-win situations?

* Are you risk averse?

* Do you include your own stakes into the process?

* Are you able to give the project back in case it smells like a trap?

Feedback

* Is everyone aware for the need and use of giving feedback?

* Have you any idea how to provide feedback?

* Do you really understand the techniques you want to use?

* Did you schedule (time, money, people) activities to provide the feedback?