Project Risk And Product Risk

This paper queries the over abundance of mathematical approaches to project risk management and looks at methods successfully applied in practise. The paper suggests that project risk and product risk impact on the project life cycle differently and therefore need to be managed differently. Experience has shown that while project risk originates and impacts in the proposal stage of the project, product risk originates in the planning and impacts on the implementation stage. Two models found in practise leading to project success is described and the applications using project life cycles is discussed What is proposed is that when a risk is identified, it be made the end condition of a stage in the life cycle. The project would not progress until the risk is eliminated. The entire project team would focus on the identified risk until it is solved. The solution is that risk must be eliminated at the point where it originates.

It has long puzzled me how a random number, the Monte Carlo Method and 30 000 iterations of a formula based only on time and cost can tell me anything about project risk.

My thought on the subject is that risk originates somewhere in the project’s life cycle and impacts on the project with effect to; an increase in duration, an increase in cost, or both. The whole idea of risk management is to avoid the impact, or at least to have contingencies in-place to reduce the effect.

From 20 years’ experience working in various facets of project management I realised the there are two different kinds of risk: Project Risk and Product Risk. One impacts on the delivery of the project the other interferes with the product that the project is to deliver.

I have developed a somewhat unique perspective (philosophy?) on risk which I would like to share. It may not be ‘THE’ solution but it may shed some new light on the subject.

As a point of departure let us consider the project life cycle (time span) and see if we can determine the origin project risk and product risk, the risk’s impact and what can be done about it.

Consider a project life cycle with four stages progressing from project start to end, having a proposal stage, a planning stage, a construction stage, and a close-out stage. In this model each stage has to achieve a defined end state before work can start on the next stage. (In practice some work is unofficially done on the next stage)

Next we populate each stage with some generic sort of things that happen in each of the stages to reveal the following:

(Germination of the original idea from which the project is to produce its product starts with the project champion who seeks a project manager to help him develop the idea into a project by finding a sponsor who agrees to the resource constraints.)

[resource constraints = number of people, total man hours, equipment and money required]

The percentages at the bottom of each stage refer to the accuracy of quantitative data that can be achieved for that stage. Some of you may not like the figures but that can form the basis of a different argument in a later article.

In the proposal stage the idea for the project is barely formed and the accuracy of quantitative data is only 50%. Agreed, some basic design is required to formulate a proposal but this is done only in conceptual terms.

Failure to understand this aspect leads to the full design being done in the proposal stage, thereby incurring huge costs before the project is fully approved. My experience has shown that if the accuracy of quantitative data is understood and explained to the client and the sponsor at this juncture, a better understanding of cost escalation and the management of resource constraints is obtained.

During the proposal stage the feasibility study is undertaken. It is during this study that factors concerned with market opportunity, environment, government legislation and pressure groups are investigated.

These issues are what I call "Project Killers". These are risks that impact directly on project viability. That is if they occur they stop the project totally.

All to often these days stakeholders are not consulted during feasibility and only get to hear about it in the implementation stage. This results in a huge uproar and clashes between stakeholders and the project team leading to delays and escalated costs.

If managed correctly project risk is identified, quantified, the response developed and controlled in the proposal stage.

Although the product is described in the proposal stage and referred to during feasibility full design has to be done in order for the risk to be quantified adequately. This occurs in the planning stage.

If the project has not been approved to proceed with resource expenditure, how can product risk exist? Product risk originates in the design of the product that the project is to produce, which is in the planning stage.

Risk cannot impact before it originates. Therefore product risk cannot have an impact on the proposal stage. Only project risk impacts on the proposal stage.

Product risk impact on the planning stage is a moot point. It is possible but not probable. The risk is more likely to impact on some future time period.

Based on practical experience I have found product risk to impact only in the construction stage as design flaws, weather conditions and supplier foul ups occur most frequently during construction.

Product risk originates in design then it impacts in implementation. Project risk on the other hand if not dealt with adequitly in the proposal stage will continue to plague the project and has the potential to "kill" the project in any stage.

Once the proposal and planning stages are completed no amount of modifications during the construction stage will repair a basically poor design.

If product risk originates in the design then it must be eliminated during the planning stage.

If project risk originates in the feasibility then it must be eliminated during the proposal stage.

I was requested by a colleague who was working on a classified project to develop a new kind of alarm system for which the technology to develop it did not exist; i.e. a high risk project.

Here’s how we solved it

During design a number of insurmountable product risks were identified, the impact of each could cancel the project.

What I proposed was that when such a risk was identified it should be made the end condition of a stage in the life cycle. The project would not progress until the risk was eliminated. The entire project team would focus on the identified risk until it was solved.

The project has proceeded with success achieving an international patient as "Alarm State Navigation".

Let me show you what I mean with an example project life cycle.

Please note that in the planning stage the design activity has identified three risks. We now redraw the planning stage as follows:

Note: Three different possible solutions are shown for the three risks.

The construction and close-out stages remain unchanged while the project life cycle now contains seven stages, the planning stage having been subdivided into four stages.

An altogether different solution with which I have had some success is to include a design activity in the proposal stage, as well as in the planning and construction stages. This method works well where a high accuracy of estimates is required, as it provides for pre-design, design and post-design opportunity as follows:

Personally I feel very uncomfortable with design work being allowed in the construction stage as this legalises change of time and cost estimates.

You could say that this is a risky solution.

Project risk originates somewhere in the projects life cycle and impacts on a project by effecting, an increase in duration, an increase in cost or both. Risk management is to avoid the impact, or else to have contingencies in-place to reduce the effect.

If managed correctly project risk is identified, quantified, the response developed and controlled in the proposal stage.

Within the project life cycle it is debated, that product risk can only originate in the design activity, where time and cost are accurately determined and that product risk impacts only in the construction stage as most often design flaws, weather conditions and supplier foul ups occur this stage.

The solution is that if project risk originates in the feasibility study then it must be eliminated in the proposal stage. If product risk originates in the design then it must be eliminated in the planning stage.

What has been proposed is that when a risk is identified, it be made the end condition of a stage in the life cycle. The project would not progress until the risk is eliminated. The entire project team would focus on the identified risk until it is solved.

One can almost say that risk has a natural law; Change during construction stage results in project failure. Restricting changes to the design of the product in the planning stage results in the project succeeding.

************************