There is more to risk management than making a risk analysis. Most projects perform some sort of mini-risk analysis by assigning two values to each identified risk. The first value is a probability, where 1 signifies a very low probably for the risk to occur, and 5 signifies a very high probability.

The second value describes the consequence, where 1 signifies no noticeable impact, and 5 signifies a catastrophic impact on the project. The two values are then multiplied, and the project decides to address all values over a certain limit, for example 15. The Project Manager then outlines in the Project Specification or Risk Management Plan how the risks should be monitored and mitigated. This is standard procedure and describes the “mechanical” part of it.

If you know something about measurement scales, you also know that risks cannot be assigned an absolute value like this. A risk with a probability value of 4 is not twice as likely to occur as a risk value of 2. Nor is the consequence value 3 three times as serious as the consequence value 1. But you see this non-scientific approach all the time.

An alternative method is to rank identified risks. The project makes two rankings, one that describes the probability and one that describes the consequence of the risk. You then take the upper quartile (the highest 25%) of the consequence ranking and ask: Which of these risks appear in the upper 50th percentile (the upper 50%) of the probability ranking? These are the risks the Project Manager need to address.

There is only one problem with this risk analysis approach: the project will only address the risks it can see. The risks the project can’t see is often the biggest ones, and they will appear from nowhere. The risk analysis is also usually performed before all requirements are known, and the requirements is a really great way to make risks visible. Therefore, risk analysis should be done on a regular basis. But there are other ways to mitigate risks as well.

Risks comes from our inability to manage complexity. The more complex a product or project is, the higher the risks are. Executing a project in increments is a great way to reduce complexity. Instead of specifying all requirements before implementation starts, the project is divided into two or more increments. The project decides, together with the customer, what functionality on a high level should be realised in which increment. If a project is shorter than six months, there may be no point in using increments, but if the project is one year or more, you should seriously consider it. Each increment is like a mini-project lasting three of four months; you specify the requirements, design, implement, test and deliver. The customer can now give you real feedback on real functionality. You may decide to reduce the amount of testing (skipping acceptance testing, for example) in favour of getting real feedback from end-users.

There are some risks with incremental development as well. When the project reaches increment three, it may discover that the things it did in increment one wasn’t up to the standard, and things need to be redesigned. In my experience, this is seldom catastrophic. Things that took three weeks to code the first time, will only take one week the second time; and it will be much better.

Executing a project in increments also means that the different work-flows are “phase shifted”. The Requirements Engineering team is four to six weeks ahead of design, which is four weeks ahead of implementation, which is four weeks ahead of testing etc. The Software Engineering and Test Engineering teams may still work on increment two, while the Requirements Engineering team is working on increment three. This may require up to 25% more resources in a project, as people work in parallel.

Some customers don’t allow a project to deliver in increments, for different reasons. They may not have the resources to handle a delivered increment (remember that it will put some pressure on the customer as well), or they may think that it is less risky to nail all requirements at once. Even if you can’t get acceptance for an incremental approach the first time, it may be apparent for all parties after four months that it is in everybody's interest to take the incremental approach.