Real, Useful Project Risks

By Bob McGannon, PMP, GWCPM, MPC

Long considered the area of project management that is deployed in the poorest manner, risk management for most typically involves documenting a set of vague, high level risks and response strategies. This weak ‘risk management plan’ is typically created at the beginning of a project, and it rarely sees the light of day thereafter. Why is this critical aspect of project management and business analysis treated with such casual disregard? It is because the ‘risks’ derived in the typical risk management plan are not crisp and relevant, and as a result the response strategies are often useless. Creating a relevant risk management plan involves starting with the right risks, defined the right way. We will explore those ‘right risks’ and how to create them so your risk management planning will be useful and pragmatic.

Risks should be written in a ‘Cause and Effect’ framework

Full scale risk management involves deriving your overall approach to managing risk, then identifying risks, engaging in a filtering process to sort through and prioritise the risks you wish to address, determining how you will respond to the filtered risks you decide to manage. Finally, the process is repeated throughout the life cycle of a project. Repeating this process ensures that new risks are considered, and risks you have bypassed are no longer being considered. The key to making this process worthwhile is the identification of risks that are a) feasible to be addressed, and b) specific enough to be treatable. Here is an example of how risks are often written, which is not specific enough to allow for a feasible action plan:

For a major logistics project, a risk is written which states: Our fuel trucks might not arrive in time to ensure the fleet’s fuel cells are full before departure.  Certainly this could be a potential outcome – the fuel cells would not be full – but this is not a risk that is detailed enough to address appropriately. It is inappropriate because it is not written in a cause and effect structure.

For instance, you could have extra fuel trucks available if the concern was a flat tire or some other form of mechanical fault with the fuel trucks. On the other hand, if the fuel trucks don’t arrive in time because the fuel truck drivers have gone on strike, all the extra fuel trucks you may allocate to relieve this risk won’t do you any good. So, in a cause and effect structure, the risk would be written as ‘A strike by the truck drivers causes the fuel trucks to miss their deadline to ensure the fleet’s fuel cells are full before departure.’ This is a risk that can be specifically addressed with a focused response plan. Writing risks in this manner requires more concentrated effort up front. This is well worth it however as having a set of treatable risks is a prerequisite to the success of the risk management process, and to the project as a whole.

Develop more than just technical delivery risks

When written well, focus can be placed on the source and impact of the risks being considered in the risk management plan. A great percentage of risks focus on the nature of ‘building the products’ that are the deliverables of the project. What is missing from a great number of risk management plans are the business risks that are applicable for the project. Presumably, the project has been justified because of either a) a potential business opportunity exists or b) a significant business problem exists that needs to be overcome. As a result, there are risks associated with the project not delivering on its promise. Also, there can be risks associated with a partial scope delivery or a full scope delivery later than committed in the project schedule. These risks are often not addressed in risk management plans.

In addition, there are many other business focused risks that should be considered. Risks associated with a change in business processes, customer acceptance, training of staff who may be hesitant to change, and political opposition to new or changed processes  frequently haunt otherwise sound projects. These risks however go unaddressed in risk management plans and the project outcome is jeopardised at best, and is not delivered at all in the worst cases.

A business perspective is KEY

The best teams of project managers and business analysts will address the business based risks we discussed above, and others that are specific to any given project. Supported by the project manager, the knowledgeable business analyst can surface these risks early in the project lifecycle so they may be appropriately addressed. The very best teams also work together on the strategy, structure and approach the project will take to design and initiate change, often avoiding the business risks altogether. For instance, timing of project deliverables being implemented can be considered against the operational needs of the business. Certainly, a Point-of-Sale process change at a retail store is unwise to implement during the Christmas holiday shopping rush. Similar timing circumstances exist in almost every business environment. Other challenges include balancing the skilled resources available for a given project when compared to the entire portfolio of change that is ongoing at any point, and balancing specific large customer needs against the business as a whole. All of these should be considered by the project manager and the business analyst when designing the timing and approach the project will take to initiate change.

A risk based culture for project management

Designing the project with risk reduction in mind is the first part of bringing a “culture of risk reduction” to the everyday management of a project. As project managers are faced with a number of challenges and possible activities in guiding their projects to a successful conclusion, a means to prioritise their time and activities needs to be applied. As project management is overhead, the justification for the PM resource should be based in risk reduction. Why spend time creating an extensive communication plan if there was no risk that communication issues would arise? Why work on a quality management plan if you were absolutely certain that no quality issues could arise for your products? These deliverables are created to mitigate risk; the greater the risk the more important the artifact. This risk mindset should guide the project manager or business analyst’s every move.

Risk mitigation starts with the design of the product. Risk identification should be a major activity in the early stages of the project lifecycle. Risk should be discussed in every project status meeting, and be included in every project status report. Risk should be considered when creating deliverables, planning testing and implementation, and when considering the operational time period when project deliverables will be utilised.

Project managers and business analysts are risk managers. Starting with well defined risks, taking risk management to heart and making it a mantra for the approach to everyday management of projects will increase the probability of successful project delivery.

Bob McGannon is a Founder and Principal of MINDAVATION; a company providing program and project management training and consulting, leadership workshops, keynotes and project coaching worldwide. Bob can be reached at MINDAVATION via the web at or by calling 866-888-MIND (6463) in the USA or 1300 947 572 in Australia.

The Mindavation Foundation is proud to donate 5% of profits towards development of youth leaders.
Copyright © 2011 Mindavation - All rights reserved.