ApproachesToRisk

Identification

First, identify the risks. Beware of InaccurateRiskPerception, and use whatever risk lists are available to try and cover all common risks. The list of risks given on this site in the RiskToPatternTable has a rather narrower focus (at the time of writing) than the list provided in Capers Jones’ book “Assessment and Control of Software Risks”. However, this site has the benefit of 10 years progress since the publication of that work, a fact particularly relevant owing to the advent of Agile approaches during that time.

Broad Approaches

There are in effect 4 broad approaches one may take to deal with an individual risk:

1. Prevention – preventative approaches to avoid the risk.
2. Amelioration – approaches to reduce the impact of the risk when it happens.
3. Acceptance – take the hit and pay the price when it happens.
4. Delegation – the problem is identified as somebody else’s responsibility.

The Appropriate Process Movement advocates efficiency. Some amount of prevention is likely always to be cost effective, but preventative approaches obey the law of diminishing returns.

Prevention

One of the big distinctions between traditional and agile approaches is in which risks are addressed by prevention, and how much prevention is considered to be worthwhile. It is probably true that some prevention is always worthwhile, but agile approaches challenge the notion that prevention is better than cure. Prevention suffers from the law of diminishing returns. Traditional approaches tend to go for “Big Design Up Front” (BDUF) and expend effort in earlier phases to prevent problems in later phases. Unfortunately, BDUF has a perennial problem with changing requirements – once the users get to see what is delivered they suddenly reach an understanding of what it is they really need. One could approach this problem itself by preventative means and do plenty of Business Modelling, but this has limited success. One could accept that requirements will change, and aim for ameliorative approaches.

Amelioration

Requirements change. Attempts to stop this happening create an alternative risk of delivering a product that is not fit for the purpose. For some risks, the best approach may be to accept that they cannot entirely be prevented, and to deal with them by reducing their impact when they occur. In the case of changing requirements, amelioration may be achieved by designing the core of the system round things that do not change, the ‘Domain Invariants’ that can be identified during Object-Oriented Analysis. Another ameliorative approach favoured by agile approaches is directly to reduce the cost of change to the code, using approaches such as refactoring and its supporting techniques.

Acceptance

Some risks may be so rare, so difficult to deal with, or have such low impact that we choose not to attempt prevention or amelioration, and accept the risk. If it occurs, we will take the hit. Asteroid strike by a dinosaur killer can seriously damage the commercial success of a project, but there’s not much to be done about it. This is an extreme example. More realistic scenarios may include mergers, where the possibility may be ignored, or the risk may be considered and explicitly accepted. Developers taking time off on sick leave may be ameliorated statistically, but the individual occurrences are accepted. By default, risks get accepted; if you do nothing else, then you are accepting the risk. Of the risks listed in Capers Jones’ book, many tend to get accepted by default, having never been considered. However, these risks are not trivial, and perhaps acceptance is not the best approach.

Delegation

Certain risks should be delegated. The risks of fire, flood and similar damage can be delegated in part to insurers, though one should also take precautions to prevent and ameliorate the risk. One may choose to delegate security issues to specialists, or one may choose to deal with some or all of these within the project. Delegation of risk should always be considered where the risk falls outside one’s core areas of competence.

Dynamic Behaviour

Risks change priority with time. Typically, we start without knowing what project to do, so we develop an idea into a ‘vision’ (see LackOfVision). Having had the idea, the risk is that it may not be worth doing, so we develop a Business Case. UndefinedScope becomes a high risk, followed by unknown requirements. Once we have some requirements, we risk that they are not understood. Once we have analysed them and reduced this risk to a reasonable degree, the solution architecture becomes the highest priority risk. An ArchitecturalSpike to prove the architecture can leave us with the remaining uncertainty over the requirements as our highest priority risk, one that we may choose to address by EarlyAndRegularDelivery.

Note that the reduction of a particular risk will eventually result in a different risk taking over as the current major risk; the failure to deal with this fact was probably the greatest failing of ‘Waterfall’ development processes.

The techniques that we use to address the dynamic behaviour of the risks are melded together into a Development Process. There is a risk here that the process will not be known (see UnknownProcess) or will not be well formed (a risk addressed by this site as a whole, see in particular the Manifesto). The ideal process will address the dynamic behaviour of risks as they vary for a particular project. Thus the process ought to be tailored to the project, and ideally ought to adapt as better knowledge of the actual risks emerges.