Project Risk

Risk is inherent in all projects because projects, by definition, represent a one time improvement to an operational process.

There is usually some sort of primary risk factor under which the project was defined, such as market risk for the development of a new product, or technical risk for an assembly line improvement project (will it speed up the line, etc?).  After that, a host of secondary risks present themselves which, if ignored, can trip up a project.

Because of this, risk management is integral to project management.  The more risk management you do, the safer your projects.  Of course, a project manager’s time is valuable too, and since many have other technical duties to attend to it is important to carry out the correct amount of risk management.

The earlier in a project life cycle a risk is identified, the more realistic the project plans and expectations will be.

Definition of Risk

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

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.

I will illustrate with an example.  The risk of getting hit by a car is something for which you probably perform basic avoidance actions on a daily basis.  This risk has a very low likelihood of happening, but a high impact.  The impact creates the perception of risk.  Meanwhile the risk of tripping over an protruding tree branch is high probability, but low impact.  In this case the risk perception 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 toxic atmosphere for the project.

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 a communication issue sometimes.  It’s really about quantifying and communicating the risks, and the changes to them, at the appropriate times to the appropriate stakeholders.

Risk Tolerance

The amount of acceptable risk on a project depends on the organization’s as well as individual stakeholders 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 it’s 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

Risk management is often overlooked in favor of schedule and cost, the two stereotypical 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.

The true goal is a risk management culture within the organization.  When a good risk culture is established, project managers are always thinking about what 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 Plan

A risk management plan 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 I include it 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, tools, and anything else that doesn’t warrant its own space.
2. 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, maybe it’s time to have a chat with them.  Communication is key here.
3. 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.
4. Risk Register.  This is where the value is created.  The risk register, also called a risk log, is a central repository of project risks 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.  The risk register also contains the results of risk analysis, which prioritize risks by probability and impact, the two underlying factors.
5. Risk Response Plans.  Most of the time I put risk response plans as an additional column of the risk register.  But the largest, more important risks usually require a written response and/or mitigation plan that needs a separate section.
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.  For most projects I would suggest weekly is an appropriate timeline.  Often revisiting the risk register during a project is an easy task because risks are made obsolete (i.e. they can be labeled “did not occur”).
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.  Thus, 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.

This 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 (the wrong chemical is 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?
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 be able to identify most of the risks and know what to do about 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 and take 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.  This is a recurring theme for me in my project management career, and thus I would consider it one of the biggest single factors for project success.

Determine Action Plans

The final piece of information that completes the risk register is an action plan.  Triggers allow you to quickly identify when a risk has occurred (or is occurring).  The action plan is the response.  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.