6.2 RISK MANAGEMENT

< Day Day Up >

Risk Management is a topic that really does require a book in its own right and like many other topics it is one that has strong links to Software Metrics. All that can be done in the space available here is to give a brief overview of the subject and to demonstrate those linkages between Risk Management and Software Metrics.

The process of Risk Management starts, as one might expect, with an identification of those factors that could cause problems for the project, identifying the "risks" themselves. These can range from the possibility of key individuals going sick to the satisfaction of requirements being more complex than was originally thought. Basically you should identify anything that your experience, and the experience of others, tells you could cause you problems, and by problems we mean factors that could result in missing milestones and delivery or exceeding your cost budget.

Each risk factor should now have assigned to it a probability of occurring. This brings us to the first link between Risk Management and Software Metrics. In an ideal world you would look back at your collection of project data, all partitioned by class of project, and within the relevant class you would identify each time that particular factor made its presence felt. Is it too much to ask how many of your last one hundred projects, reported absence due to illness of a key individual? Of course it is. As we said before, you probably do not have decent data on your last project, let alone the last one hundred. Sorry, this is not patronizing, you know your own reality just as I do.

So what do you do? Well one thing that you can consider is to use a Delphi approach to probability assignment. Get some of your team together and ask them, how likely is it that we are going to suffer from sickness? Alternatively make a guess yourself. This is not a perfect or even good solution but at least you are starting to think about managing the project rather than letting it manage you. Managers who let their projects control them rather than vice versa often state that they spend most of their time firefighting. The trick is not to let the fire start.

Of course there is something else that you can do. You can start to collect information on risk factors. But what about the fact that every project is different? Let us see if some of the commonly identified risk factors ring any bells with you:

Milestones being missed
Requirements volatility and growth
Staff loss and turnover, resulting in a lowering of application knowledge
Customer or management pressure on delivery dates
Morale loss due to external events such as a reorganization
Unanticipated complexity, sometimes called the "how-did-I- get-into-this-mess" syndrome.

If these do ring bells with you then you probably know projects where they have occurred. The chances are, unfortunately, that you will work on projects in the future where they will also occur. You will find that most managers will agree that these are probably risk factors on their projects wherever they are. That being the case you should be able to collect information from projects where those risks become problems and, equally, from those projects where they do not. This enables you, at some time in the future, to derive probabilities based on more than pure guesswork.

But why bother? You want those probabilities for a very pragmatic reason. There are only so many hours in the day and you do not want to spend time managing a risk that has a 1% probability of occurring as a problem. Much better to concentrate your efforts on those that are likely to become problems.

As a personal guideline, I believe that Risk Management principles should be applied to any risk factor with a 25% or more probability of occurring. Mind you, I am a great believer in Sods Law that says that anything that can go wrong will, at the worst possible moment!

Having decided what risk factors are probable (or at least more probable) to be the problems of tomorrow you should decide what you are going to do about them if and when they occur. In other words, you should prepare contingency plans. Personally I prefer two levels of contingency planning, what I call amber plans and crisis plans. My amber plans usually reflect the belief that I can still contain the problem, perhaps by working a little overtime or shifting a couple of priorities. The crisis plan is something else again. When a crisis plan kicks in, the bells go off, lifeboats are readied, break out the extra-strong coffee and cancel leave until we get it licked.

Never plan to run a crisis plan for long. Neither you nor your people can work at the pitch a crisis demands for long. If you try the chances are you will make the situation worse!

To give you an example of the two different types of plan let us look at a much simplified pair of plans. Let us say that I notice that morale is dropping because of concerns about a reorganization. The first thing to do is "go public." A memo goes off to my manager saying that the lack of information is causing me problems. I might also decide to take everyone out for an extended lunch, the idea being to get them off the battlefield and somewhere they can talk more freely. I may also start to run a "happy hour" for the last couple of hours on a Friday.

Now what if things still go from bad to worse? The situation is that people feel so browned off that work is not getting done. What is getting done is shoddy and, because of an increase in rework, it really looks like this project is going to miss delivery, exceed its budget and be seen as a failure. Assume I also KNOW that the cause of this is the way the reorganization is being handled. First rule again, go public. Start banging the drum so hard that someone has to take notice. Advise the most senior director you can get access to, advise the customer, at least of the effect if not the cause. Run a containment action. The team members are so fed up that it is affecting their work, so maybe we should stop work, get them off-site for a couple of days and talk it through as a group. Maybe nothing can be done to fix the problem but we can certainly start to feel better about the way we handle the problem.

Now, you may not agree with the bare bones of the approach I have outlined to handling the particular problem I chose as an illustration but you should realize one thing: none of the reactions outlined was a spur-of-the-moment thing. They were all planned in advance and were there ready and waiting to be called into play when needed. This approach means that you are able to worry about containing the effects of the problem rather than worrying about how you are going to achieve that containment.

The trick of course is to know when to kick in those contingency plans and this brings us to the next link between Risk Management and Software Metrics: the risk factors must have measures associated with them, and these measures must be monitored. Additionally, there should be predetermined levels at which the contingency plans, amber or crisis, come into play.

< Day Day Up >