Assess the usefulness of quantification

In some projects it may be useful to quantify no issues at all. There are two reasons for this:

1. the client is not prepared to accept any significant sources, so all significant sources need to be transferred to other parties or avoided in some other manner, and there are no significant opportunity management issues usefully addressed in quantitative terms, so quantitative risk analysis is not required;

2. one or more 'show-stoppers' have been identified earlier, and managing the show-stoppers is the most effective next move.

Assuming these general reasons do not apply, a range of other specific reasons for non-quantification might apply, such as significant changes in the project environment.

Example 10.3 No need to quantify show-stoppers

A multinational weapon platform project was approaching an early feasibility assessment. It was the first project those responsible had subjected to a formal risk analysis process. Most other risk analyses undertaken else-

where in the organization were quantitative. However, while quantitative risk analysis was an objective, it was not a commitment. When qualitative risk analysis clearly defined a small set of show-stoppers, risk management focused on managing away the show-stoppers. There was no need at this stage for quantitative analysis, because it would not have served any useful purpose.

Example 10.4 No value in quantifying the probability of changes of direction

The North Sea, offshore, pipe-laying project examples cited earlier involved a number of issues that were usefully quantified in most cases: buckles, weather, equipment failures, and so on. Of the 40 or so pipe-laying issues typically identified, about 30 were not quantified, but flagged as important 'conditions', assumptions that the analysis depended on.

As an example of an issue not usefully quantified, one project involved a source identified as 'the management may change its mind where the pipeline is to go' (because the company was drilling for oil on an adjacent site and a strike would probably lead to replanning a 'collector network'). It was important to keep the plan as flexible as possible to respond effectively to a possible change in route. However, the board owned this issue, not the project, and there was clearly no point going to the board with an estimate that says 'we think there is an x% chance you will change your mind about what you want and, if you do, it will cost y and take z days longer'.

It is important to stress that the identification of conditions of the kind illustrated by the above example can be much more important than the identification of sources that are subsequently quantified. Such conditions may be the key to effective contract design, claims for 'extras', and risk avoidance or reduction management, which is central to the overall risk management process. As well as quantified issues, flagged conditions are an important output of the estimate phase.

Was this article helpful?

0 0

Post a comment