The Elements of Project Risk

Project risk is like an orchestra with many instruments.  All elements are crucial to the final result.  If even one instrument is not playing correctly, the whole performance can be a failure.

Hence, risk management is integral to project management.  Since projects have many moving parts and technical knowledge areas, risk management keeps everyone singing the same tune.

The project manager is the conductor that keeps all the elements working together, synchronized in perfect harmony to minimize the occurrence of risks throughout the project.

Definition of Risk

Project risk is an uncertain event or condition that, if it occurs, has a positive of negative effect on one or more project objectives (Project Management Institute).

When a risk event occurs, it is no longer uncertain.  It becomes an issue.

Risk can be broken down into two basic components.  The formula is:

Risk = Probability x Impact

• Probability:  The likelihood of the event happening.
• Impact:  The potential impact of the risk event.

For example, the risk of getting hit by a car is something for which you regularly take mitigative action (stop at the crosswalk, etc.).  This risk has a very low likelihood of happening, but a high impact.  It’s the impact that defines the severity of the risk.

On the opposite end of the spectrum, the risk of tripping over an protruding tree branch has high probability, but a low impact.  In this case the severity of the risk is driven by the probability.

The risk can be quantified by stating the probability and impact in numerical terms.  For example, if I determine that the likelihood of underestimating the time a mobile crane will be required is 20%, and the cost will be $3,000 (i.e. there is a 20% chance of incurring a $3,000 charge), you could assign a risk value of $600.  But what exactly does this number represent?  It means that if you entered a contingency of $600 into the project, it will cover the risk of underestimating the crane’s time if you had many, identical projects.

Of course, we know you will not have many identical projects, but statistically speaking this is the ideal contingency.

Risk Events

All projects have risk.  As a minimum, the project has a risk that it does not accomplish its stated objective.

But as you will see, there are a multitude of secondary risks that, if not carefully considered, create a high probability of cost and schedule overruns, or other negative outcomes.

It is not a worthwhile goal to attempt to eliminate all risks.  Project sponsors and stakeholders generally accept the basic inherent risks – that’s why they signed up to the project in the first place.  Because of this, risk management can feel like communication management instead.  It’s really about quantifying and communicating the risks to the appropriate stakeholders at the appropriate times.

Risk Tolerance

The amount of acceptable risk on a project depends on the organization’s as well as individual stakeholder’s risk tolerance.  Thus, stakeholder’s attitudes to risk is an important variable that the project manager should be familiar with and actively manage.

Opportunities

Project risk management is not only concerned with negative events.  Positive events can occur during a project’s execution, which are called opportunities.  Often project work results in circumstances that allow savings in time, cost, resources, or any other item that can be exploited to enhance the project’s mission.  In its relentless pursuit of its critical success factors, the project should seize any opportunities available to it.

Thus, risk management attempts to increase positive events as well as decrease negative events, and the positive events are an equally important part of the equation than the negative ones.

An example might be a building project where a trade is working on a site nearby during a specified time period and can quickly mobilize, saving time and money.  The project schedule can be adjusted to accommodate the potential savings.

Risk Management Culture

The true goal is a risk management culture within the organization.  When a good risk culture is established, project managers are always thinking about everything that could happen to the project, and communicating this with stakeholders.  Adequate risk planning and analysis of project risks is central to the organization, and project success on an organizational level is a huge benefit in a very competitive business landscape.

Risk management is often overlooked in favor of schedule and cost, the two stereotypical primary project management functions.  But to ensure a project isn’t blindsided by unexpected variances that consume project resources and threaten project success, a proper risk management plan should be developed.

Risk Management Plan

A risk management plan is like the song sheet which all musicians must be familiar with and execute to perfection.  It is a subset of a project management plan, and it provides the foundation for risk management for a project.  For large projects it can be a stand alone document, but usually it would be included as a section of the project management plan.

The Risk Management Plan contains the following items.

1. Introduction.  Risk management methodologies, organization, roles and responsibilities, and tools.
2. Risk Register.  This is where the value is created.  The risk register, also called a risk log, is a list of important project risk events which is created at the project planning stage.  The most important risks to the project’s critical success factors are determined, which are then categorized according to the Risk Breakdown Structure.  It is not possible to ensure all risks are identified, and you can go overboard with identifying small insignificant risks, but the exercise ensures that project stakeholders are satisfied that the risks to the project have been considered.
3. Stakeholder Risk Tolerance.  Although not always requiring its own dedicated space, stakeholder risk tolerance should be investigated and carefully considered.  If you can’t define and write down the risk tolerance of the stakeholders, you might not be able to define which risks are more important than other.  Communication is key here.
4. Risk Breakdown Structure.  This is an optional, categorized organization of the project risks.  Although PMI has only recently included this in the PMBOK, it’s helpful to organize risks into categories.  For an engineering project, risk might be divided into technical, organizational, and external risks.
5. Risk Response Plans.  Most of the time risk response plans are an additional column of the risk register.  But the largest, most important risks usually require a written response and/or mitigation plan.
6. Monitoring and Control.  It is important to re-visit the risks regularly throughout the project, and this section will define how often that will happen and what that will look like.  Over time, some risk events are made obsolete because they did not occur, while others change in importance (i.e. their probability or impact changes).
7. Communications.  I can easily think of many project issues over the years that weren’t really all that important on an absolute level, but made stakeholders unhappy because they were expecting something to have been different.  That is, small issues blow up due to poor communication.  For this reason, potential risks need to be communicated with stakeholders, so that everyone is prepared for the risks as they arise.  Managing stakeholder expectations is the central foundation of risk management, and thus communication is key.  Any changes to the risk profile of the project (i.e. the risk register) need to be communicated to the relevant stakeholders, and the communications plan can lay out how that will be done.

Identifying Risks

To provide a solid risk management plan upon which the project can depend, it is imperative that the most important project risks be identified and listed.  This is particularly true for inherently risky projects, like nuclear power plants, but all projects will benefit.

Identifying risk events is the cornerstone of the risk register and of risk management as a whole.  It requires careful consideration of the project risks and what could affect the project’s critical success factors.  Here are a few ideas to ensure that each risk is identified:

1. Use a Risk Breakdown Structure.  Dividing risks into categories is intuitive and allows for better organization.  Since many risks are unrelated to each other (for example, the wrong chemical gets delivered vs. the forklift operator quits), the systematic categorization of risks helps to ensure strong identification.
2. Develop a checklist.  Every business is different, and you are best suited to develop a checklist for yours.  That being said, we have developed a generic one.
3. Look at Assumptions.  Every project operates under a set of assumptions.  The business climate, client willingness, customer attitudes, etc. together result in the creation of the project.  What are these assumptions, and what happens if they change mid-project?
4. Previous Project Experience.  Many project based organizations have similar projects in their past history.  What types of issues did they experience?  On a related note, if there is no lessons learned database within the organization, maybe it’s time to start one.
5. Expert judgment.  Although I left this one for last, it can’t be understated.  A subject matter expert will usually have a strong risk register in their head, and know what to do about most o them.

It is not possible to list all project risks.  Although you should endeavor to identify the most important ones, you cannot predict everything and your stakeholders do not expect you to.  Sometimes the project manager must react to unexpected events during the execution of a project – this cannot be eliminated.  But I can assure you the stakeholders of your project will appreciate the time and effort given to the identification of risks.

On the other hand, you can go overboard and list too many risks.  This is easy to do once you get going and start brainstorming about airplanes crashing into your office (okay, maybe I’m going overboard now!).  I suggest that you should stick to risks that have a 5-10% (1 in 20-ish) chance of happening.  If it’s lower than that, you might have too big of a list.

Prioritizing Risks

Identifying risks to a project’s success is a great first step that would benefit most projects that I’ve seen.  But to create a strong risk management plan those risks must be analyzed and prioritized to determine which require the project manager’s time and attention, how often, and what resources are required.

Stakeholders can be pretty sensitive to issues the project manager considers minor.  Some stakeholders seem to demand excessive communication requirements.  Prioritizing risks ensures that stakeholders recognize the importance placed on their areas of concern which goes a long ways toward placating them.

Since risk has two components, probability and impact, each one should be prioritized.  The scale is not important, but it is often 1-10, low-medium-high, or a similar scale.

If your risk register is a table with the risks listed vertically (in rows), you would add two columns labelled probability and impact.  Each risk gets a ranking of 1-10, or whatever scale you choose.

After the initial ranking, an overall prioritization is often helpful to stakeholders.  You would multiply the probability and impact to get a risk level, and then sort the table from highest to lowest.  Clearly you will be able to see which risks to focus your attention on.

Even better, the risk register, together with its prioritizations, can be shared with stakeholders which will put each of their issues into perspective, keeping the stakeholders in line when problems arise.

Determine Triggers

After a risk occurs, it becomes an issue.  Issues require a response from the project manager or some other project member.

In order to quickly and decisively know when a risk becomes an issue, each risk should have an identifying risk trigger.  This is an important part of risk analysis and it allows for effective monitoring to quickly recognize when a risk has occurred in order to take the necessary mitigative action.

Throughout the project, risks change in importance.  Many will become obsolete at various stages of the project.  Because of this, the risk register is an evolving document.  It must be monitored and updated on a regular basis.

Identifying risk triggers allows you to make sure you are looking for the right factors which, if they occur at any regular monitoring/control point, allow you to change a risk’s status to an issue and take the appropriate action.

Taking early action is often one of the easiest way to mitigate an issue.  I’ve seen many project issues which were probably much worse than they appeared to be, but quick action by the project manager or a team member gave the affected stakeholder an impression of being on top of the issue, which smoothed it over.

Determine Action Plans

The final piece of information that completes the risk register is an action plan.  The action plan is the response when the trigger event occurs.  It is an appropriately thought out action plan to ensure you’re not flying off the seat of your pants when a risk occurs.

Notice that I said it must be an appropriate level of detail.  For major risks a good action plan is necessary in advance and could warrant its own write up.  For medium risks a small action plan could be placed within the risk register, and for small risks there could be no action plan at all.  It isn’t a necessity for all risks, but it is important to have one for the most important ones to make sure the project is in good hands.

Project management requires careful coordination to identify and manage project risks to ensure a successful project outcome.  Managing that risk is the secret ingredient that makes projects perform like a great orchestra.