Risk Management on Projects

Project Risk Management

How does project risk management differ from any other type of risk management? Well in most regards it doesn’t. However, as this is a project focused activity it helps simplify the overall focus by looking only at the core project fundamentals of scope – which are cost, quality and time. Remember that, I may test you later!

There are a number of good training videos available on YouTube that cover this principal. I’ve added a couple below to help bring home the point of this article. I find watching a presentation often easier to take in than reading some else’s thoughts.

Project Risk Management

So what is project Risk Management is all about? In an earlier article I talk about what risk and risk management are about. If you are still confused about what risks are and what risk management is about then read this article, it should bring you into the picture. On projects we talk about risk as any event that could cause an unplanned change to the projects scope – i.e. impact the project costs, timeline or quality of the deliverables, or any combination of the three.

What isn’t always obvious when talking about project risk management is that we also need to consider the positive impact a risk may have on a project – i.e. reduce costs, decrease the time line or increase the quality of deliverables. In reality it’s not very often that project risks present positive opportunities. Never the less, as project managers we have a responsibility to recognize and act on these risks positive or negative. That’s Project Risk Management.

David Hinde wrote a good article back in 2009 about using the Prince 2 Risk Management technique. Without getting imbedded in any particular methodology, the general approach to project risk management should follow a similar framework and this is as good as any for the purpose of this article:

David talks through a Seven Step process,

Step 1: Having a Risk Management Strategy

This means setting up a process and procedure and getting full buy-in from stake holders in how the organization will manage risk management for the project.

Step 2: Risk Management Identification Techniques

Where do you start in the identification of risks around a project? There are many risk management techniques and David suggests a few which are excellent. However, I like to take a step back and make a list of all the critical elements of a project on the basis of “if this task doesn’t happen will it be a show stopper?”. This helps be build a prioritized list of critical tasks against which I can then consider the risks – what could go wrong to impact this task.

Here’s my thought process on risk identification outlined:

List out critical deliverables
List out, against each deliverable, dependent tasks
List out against all dependent tasks and critical deliverables “any” potential event that could delay or stop the delivery to plan.
Grab a template risk analysis matrix and complete the first pass of assessment – probability v impact for each risk.
Take it to a project meeting and use it as the baseline for brainstorming.

Step 3: Risk Management Early Warning Indicators

Don’t rely on basic performance of the project as an indicator that everything is going well. Status reports showing a steady completion of tasks could be hiding a potential risk.

In risk management a number of other factors need to be on the project managers radar on daily basis. Things that I always look for are delivery dates from vendors – how confirmed are they, is there a movement in delivery dates (you’ll only see this if you regularly ask for confirmation updates from the vendor), resource issues – key individuals taking sick leave or personal leave more often than normal.

Delays in getting certain approvals signed-off by the steering committee or other governance bodies – will this impact orders going out or decisions being made on critical tasks? Getting qualified people in for inspections and certification (new buildings for example require a lot of local regulatory inspections). These are just a few of the daily challenges a Project Manager will face and all can be indicators of trouble to come.

As you gain more experience in risk management you start to instinctively recognize the early warning signs and challenge the culprits earlier in the process. You’ll also finds the a good project manager will build-in mitigation for the common project ailments at the very start, sometimes seeing the tell-tale signs when selecting vendors or suppliers will be enough to select better alternatives and this is what I call dynamic risk management at work.

Also keep an eye on the world around you – economic or geological events elsewhere can have a dramatic impact on local suppliers and supplies of key project materials. For example, flooding in Thailand has impacted the delivery of various computer components that are manufactured there, causing impact in both supply lines and pricing. (Yes, I work in Asia so see this type of impact first hand..)

Step 4: Assessing the Overall Risk Exposure in Risk Management

Taken directly from David’s article as he says this quite clearly – “PRINCE2 2009 gives an approach to show the overall risk situation of a project. Each risk is given a likelihood in percentage terms and an impact should it occur in monetary terms. By multiplying one by the other an expected value can be calculated. Totaling the expected values of all the risks gives a monetary figure that easily shows the exposure of the whole project to risk.”

There are many similar ways I’ve seen risk calculated in organizations variations on risk management. Â As long as there is a common approach for showing all risks, prioritization and impact on a project then risk management will work and add value in protecting the investment in the project. Each project and each organization will have their own requirements in terms of how they want to see risks analysed and presented. By and large it doesn’t matter how this is done, as long as it IS doesn’t and it makes sense in the context of the project and organization. There are risk management tools to help organise and manage this.

In another article I’ll talk more about the Risk Management matrix and show a few examples. In my mind the only wrong way to do this is to not do it at all.

Step 5: Considering the Effect of Time on a Risk and Risk Management

The effect of time when analyzing risks is that the more imminent a risk the higher priority it may take. I say “may” as it may be that a very low priority risk with low impact may be about to happen where as a higher priority risk may be weeks or months away. How do you manage this?

Common sense (of which there is no such thing) would suggest that if the higher priority risks are still a long time away then the imminent lower priority risks should be dealt with first, as a higher priority..? Perhaps?

You’ll have to take a pragmatic view on this, every situation needs to be taken on its merits and in risk management, not being an exact science, you’ll be expected to make judgment calls and discuss options with your client and project board or steering committee. After all, the governance board of a project has a responsibility to steer such decisions so the role of a good project manager should be to collate the facts and present the data with recommendations. Let the higher paid guys make the big decisions.

Step 6: Giving a Clearer Approach to Help Define Risks in Risk Management

David gives an example in his article which I’m struggling to relate to the world of projects as I know them. I think essentially what this focuses on is the “mechanics” of the risks in such a way as to help us understand and look at the cause and effect of scenarios that could lead to the risk happening.

In this way we can focus on the lowest common denominator(s) that will generate the risk and mitigate those items. Is that a little confusing? The principal is, I believe to nip the problem in the bud by recognizing what or where the bud is. Don’t get hung up on this, I would say this is something you’d tend to do naturally as you gain experience in reviewing risks and dealing with risk mitigation (prevention).

Step 7: Focus on Opportunities in Risk Management

Finally – and last but not least, where can we make or recognize risks as opportunities. An example David talks about suggests that, for example, a new release of a software product that would offer major benefits if included in the project would be a possible “positive” risk.

This I can relate to more, with the experience of being asked to change the specification on a traders dealing system half way through a major project because the manufacturer had released a major systems improvement, a completely new model, that the bank saw as a strategic advantage.

The analysis of this risk covered the obvious change in costs, the new system was more expensive, the implementation was zero impact compared to the older system however there was a large element of re-training the trading staff and proving the system for the bank before go live. This became the biggest challenge once the cost differential had been signed-off by the project board.

Enterprise Risk Management and the PMBOK

Enterprise Risk Management is a term used to describe a holistic approach to managing the risks and opportunities that the organization must manage intelligently in order to create maximum value for their shareholders. The foundation for the approach is the alignment of the organization’s management of risks and opportunities to their goals and objectives. One of the keys to this alignment is the “Risk Appetite” statement which is a statement encapsulating the direction the Board gives management to guide their risk management methods. The statement should describe in general terms what kinds of risk the organization can tolerate and which it can’t. This statement plus the organization’s goals and objectives guides management in the selection of projects the organization undertakes. The statement also guides management in setting risk tolerance levels and determining which risks are acceptable and which must be mitigated.

This article will attempt to review Enterprise Risk Management (ERM) and relate it to the best project management practices found in the PMBOK® (4th Edition). The source for most of my information about ERM comes from a study published by the Committee of Sponsoring Organizations (COSO) of the Treadway commission published in 2004. The Treadway commission was sponsored by the American Institute of Certified Public Accountants (AICPA) and the COSO consisted of representatives from 5 different accounting oversight groups as well as North Carolina State University, E.I. Dupont, Motorola, American Express, Protective Life Corporation, Community Trust Bancorp, and Brigham Young University. The study was authored by PriceWaterhouseCoopers. The reason for listing the oversight committee and authors is to demonstrate the influence the insurance and financial industries had over the study.

The approach suggested by the study, which is probably the most authoritative source of ERM information, is very similar to approaches taken to managing quality in the organization in that it places emphasis on the responsibility of senior management to support ERM efforts and provide guidance. The difference here is that, while Quality methodologies such as CMM or CMMI place the responsibility on management to formulate and implement quality policies, ERM takes responsibility right to the top: the Board of Directors.

Let’s go through the study recommendations and relate them to the processes recommended in the PMBOK. To refresh your memories, those processes are:

Plan Risk Management
Identify Risks
Perform Qualitative Risk Analysis
Perform Quantitative Risk Analysis
Plan Risk Response
Monitor and Control Risks

ERM begins by segregating goals and objectives into 4 groups: strategic, operations, reporting, and compliance. For the purposes of managing projects, we need not concern ourselves with operational risks. Our projects might support implementation of reports and our projects may be constrained by the need to comply with organizational or governmental guidelines, standards, or policies. Projects in the construction industry will be constrained by the need to comply with the relevant safety laws enforced in their location. Projects in the financial, oil & gas, defense, and pharmaceutical industries will also be required to comply with government laws and standards. Even software development projects may be required to comply with standards adopted by the organization, for example quality standards. Projects are a key means of implementing strategic goals so goals in this group are usually applicable to our projects.