In the previous section we talked about how to start talking about the risks. You take a certain aspect and think about it in terms of what you don't know or what might go different then expected. Even better, you do this exercise with some colleagues in a meeting. For every risk that you might come up, you have to specify the following items:

· Risk; A description of the actual risk. Example: Uncertainty availability programming resources.

· Impact (or consequence); The impact on the project (process or product) if the risk occurs. Example: Delay in construction interfaces.

· Possibility; The possibility that the risk occurs (use e.g. high/medium/low). Example: Medium

· Action; The action that can/will be taken to avoid the risk from happening or reduce the chance for it, or reduce the impact. Example: Get planning clear. Investigate possibility external programmers.

· Cost; What is the cost if the risk occurs (time and money). Example: Delay 3 weeks.

You have to review the list that is generated in this way periodically (once a week). If the list is too large to give all the risks your attention, you have to create some priorities. A nice way is to create every time a top ten of the most urgent risks, so you will be sure you focus on the more important ones.

There are a lot more things to say about the subject of risk management. But first of all it's a state of mind. And with the few things shown in the section, you have a good starting point to reach the state. Remember, risk is not a bad thing, and if you come up with an action to resolve it, execute it… don't just talk the talk, but walk the risk management.

View Comments

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?

View Comments

Dealing With The Unknown

You have come a long way, all the way up to this chapter. I have discussed expectations, estimations and anticipations withing a project. I tried to make it sound as good as possible, but let's face it, it's all vague stuff. You have to think about how someone else thinks, and base your complete approach on that assessment. We handled requirements, and stated that it's best to assume that they are wrong and will change anyway. It, it's like flipping a coin or laying cards.

Software project management cannot be performed without a good practice to handle all these unknown parameters. A project manager has to be able to live with uncertainties, and have a good way to structure his approach to handle them. The first is a personal aspect, which you have to do all by yourself. The latter is where "project risk management" comes in…

"Project risk management focuses the project manager's attention on those portions of the project most likely to cause trouble and to compromise participants' win conditions." [Boehm,1989 ]

So, in other words, it's a set of actions which helps the project manager structure his approach on dealing with the unknown or the "things not sure".

"… we define risk as the possibility of loss. We obtain an instance of risk by specifying values for the risk attributes of probability (the possibility) and consequence (the loss). Probability is the likelihood that the consequence will occur. Consequence is the effect of an unsatisfactory outcome." (Hall, 1998)

So, the idea is to specify explicitly the items that you are not sure about and define what will happen if what is expected (or assumed) is not true.

If you are not sure about the estimate ending of a certain task, you can define the risk for this situation as follows: delay of the actual end of the activity * very likely to happen. What the consequences and advantages are of this approach, is the subject of this section.

Risk is not a bad thing

The problem with risk management is the negative image of the word "risk". Of course, unless there is a potential for loss, there is no risk. The loss can be either a bad outcome or a lost opportunity. The tendency of most stakeholders is to jump very stressfully at the statement "this is a risk". Therefore most of the time it's not very easy to discuss about risks, because that's always a conversation about problems. It's very important the risk is not perceived as a bad thing, but as a positive attitude to make sure everyone will become a winner in the end.

Remember, risk management helps you being aware of the goals you have to achieve, and what can happen if you don't satisfy the goals. It supports you in making the right choices!

So, risk is not a bad thing! Say it loud! Spread the word!

Related links

Numbers Are Useless To The Novice

Human Failure Modes

View Comments