Risk or Constraint – Project Management Processes

Risk Management

Risk Management is now accepted as a key ingredient in any mature project management framework and one of the key project management processes that you need to get right to effectively manage bids, proposals and projects.

One small but important part of this process is that a lot of people mix up constraints and risks during the risk analysis process. You will probably find in your risk workshops many constraints will be identified as well as risks and they require a clear differentiation and distinctly different treatment, luckily they are easy to identify if you are conscious of the difference.

As we know, a risk is something that may happen and that is why risk management processes are developed to monitor the project environment to identify their potential occurrence and treat them when and if they do occur.

Constraint Management

A constraint however is something that will happen and as such you need to remove it from the risk register. In the risk register it’s a maybe and therefore it belongs in the the cost estimate because it’s a definate, where you need to make the appropriate scope, schedule and budget allowances for it, let me provide an example;

In some of the industries I’ve worked in, the likelihood of rain in construction projects was usually a factor when putting budgets and schedules together. I have worked in Dubai where it rarely rains and in Melbourne where it rains far too much, so the approach to the same project factor, rain, would be treated differently in either location.

So if the team identifies a risk “Rain will delay construction ”

In Dubai, this is a risk because, believe it or not, it does occasionally rain during the December to February months and when it does the ground turns to sludge and it may delay progress.

In Melbourne however, this is a constraint, because it will always rains, especially in Winter, and meteorological records provide a very good indication of the likely rainfall on a month by month basis, allowing you to make the appropriate cost and schedule allowances for days that are likely to be lost due to rain.

Conclusion

So you see by this simple example two points:

• Risks and constraints are different and must be identified as such and treated differently.
• Risks and constraints can be different based on the context of the project.

A further related point to be aware of is that when a risk is rated as having a very high Likelihood of occurrence, i.e. above 90% consideration should be given to also considering this as a certainty and making scope, cost and schedule allowance for it as well.

So, next time you are in a risk workshop, double check to ascertain if any constraints have been accidentally identified as risks and move them into the estimate.

Featured Partners: Project Management Software

If you’re interested in learning more about top rated project management software, the editors at Project-Management.com actively recommend the following: