Managing Risk or Managing the Risk Environment

As a good project manager, I am certain that you are managing specific risks on your projects. But are you also managing the risk environment?  What’s the difference?

Managing specific risks focuses on how to solve a specific problem on your project.  Managing the risk environment focuses on setting up the project conditions in such a way that there are fewer risks and the remaining risks are of a lower magnitude. 

Different Project Approaches: Different Risk Environments

Let’s use an example from everyday life to illustrate the point.  While preparing your evening meal, you realize that you need to go out that night and get several items from the market for your breakfast the next day.  You could drive to a large market several miles away that has a wide selection but is next to a large sports arena.  Or you could walk several blocks to a small local market with less selection.  If it is a pleasant evening and there is a big game at the arena with crowds of rowdy fans, the local market is a lower risk option even though the selection is less.  If it is a stormy night and there is no game, the large market is a better approach even though it is farther away.  There are risks with either approach, but depending upon the circumstances the risks with one approach are likely to be more severe than the other.

Most of the project risk management tools and techniques are based upon managing specific risks.  Project risk analysis often focuses on two factors, the probability and the impact of each risk.  However, to do this analysis, much of the project plan must be completed so that the specific probability and impact can be determined.  In order to have completed the project plan, the basic project approach must be set.  If that project approach is set in a high risk environment, the susceptibility to risks is increased and the ability to respond to risks is reduced. The project team can manage the individual risks in this environment.  But it would be even better if we proactively managed the risk environment so there were inherently fewer and lower risks.

Risk Environment Can Be Assessed Before Project Planning

Project susceptibility to risk can be assessed at the time of the Project Charter, as soon as objectives, boundaries, assumptions, and constraints are defined. There are factors in a project environment that are risk enablers and risk magnifiers.  By redefining the project at the time the Project Charter is created some of these factors can be eliminated.  Even if they are not eliminated, knowing that there are many factors creating a high risk environment may change the project planning and executing approach.  For instance task level estimates may be increased, resource selection may change, resource allocation may change, or the frequency and types of reviews may be modified.

A Real Life Example

I applied this concept with a large global contract manufacturer.  We analysed a large set of their recent customer projects, both successes and failures, and looked for common factors.  For this company we found that the factors were:

•  Product complexity – an assessment of the product design difficulty and stability.
• Technology maturity – were the required manufacturing processes mature and stable in the company’s operating locations.
• Quality requirements – did the customer have unique or extreme quality requirements.
• Geographical dispersion – the number of nodes (company and customer stakeholders directly involved in the project) and their locations, including country and time zones.
• Cultural aspects – the number of languages and cultures represented on the project team (regardless of location).
• Contracts and governance – the contractual and regulatory environment associated with the customer and product.
• Organizational capacity – the number of current projects and the phases they were in.

For each of these factors a rating scale was developed and then a score was set.  A composite risk assessment of all the factors was created using a radar chart.  The company began to use this assessment to screen new projects before deciding to take the work.  If the “web” in the radar chart was small, they would take the project.  If the “web” in the radar chart was large they would either avoid the project or ensure they negotiated time and budget reserves.  If the “web” was lopsided, it gave the project manager insight into areas where extra attention was required in both planning and executing the project.

Managing individual risks is good practice.  Managing the risk environment is even better.