by Robert Bowman

Created on: November 20, 2007

Risk Analysis and Risk Management are two of the cornerstones of Project Management Methodologies. This has been the case for many years, and yet many projects start without any formal Risk Analysis taking place, only to suffer because of risks which could and should have been identified from the outset. I've briefly set out what I consider to be the most common risks i.e. those that I have encountered most often. There are twelve of them The Dirty Dozen' and all of them can be identified at the very early stages of any project by using standard Risk Analysis processes. Most of them can be mitigated by using standard PM techniques. My advice to all Project Managers is very simple don't neglect this key area. It simply isn't worth the risk!

1. Reliance on new or unreleased Technology

It is hard to exaggerate the impact this risk has on projects. Suppliers of technology are notorious for not hitting their projected release dates. In addition, newly released technology often doesn't work. As if this were not enough there is the additional impact of team members having to learn about the new technology.
Just because the risk has been identified doesn't mean that there is an easy solution. If the project requires the technology, and there is no alternative, what can be done? However, if the risk has been identified up front, at least it can be shared, and expectations set with regard to potential delays. If there is a proven alternative already available, and the project is time critical, use the alternative. Otherwise, Expect problems. Allow extra time for the supplier of the technology to release or correct the product. Build this into the plan, together with the time required by team members to get up to speed.

2. Reliance on unfamiliar Technology

As with Risks 1 and 2, the impact here is the learning curve for team members. Team members will often underestimate the learning curve. Allow plenty of time for them to get familiar with the technology. In addition, use expert support if it is available. Finally, don't wait until the week before the technology is required before bringing it in. Bring it in well in advance, and give team members more time to get to grips with it i.e. remove the learning curve from the Project's critical path.

3. Failure to identify internal Project dependencies

Most projects have dependencies. Failing to identify and model the dependencies will have a serious impact on the project - it will be impossible to decide the sequence activities must

• 1
• 2
• 3
• 4
• Next Page >>