Identifying and Analyzing Project Risks

Every project involves some degree of risk ("nothing ventured, nothing gained...."),  but that risk can be controlled with a bit of careful analysis, planning and communication.  As a project manager (or a manager dealing with projects), it is your job to anticipate project risks, and then to devise the means to control those risks before they  can get out of hand.  This is where the risk management process comes in, beginning with risk identification and analysis.

While you're here, pick
					up a few things for your manager's bag of tricks.The starting point in the risk identification and analysis process is to consider the nature and complexity of the project at hand.  Risk analysis will take time, and any steps taken to avoid or mitigate risk may negatively impact project schedules and budgets.  Therefore, you want to carefully consider the effort to be put into risk management.  A short term, non-production project, such as an internal review of purchasing procedures, would warrant limited risk analysis.  However, the physical deployment of new purchasing systems, with the potential for operational disruption, could call for further risk consideration.  In view of the operational impact, most technology projects deserve some degree of risk management.

Steps FOR RISK ANALYSIS

The starting point for risk identification and analysis is predicated upon the existence and quality of project scope and goals. If you have clearly identified your project goals and priorities, then you will be able to use that knowledge to assess the impact and consequences of any probable project risks. For example, if you view probable risk and likely impact in context of overall project priorities, you will be in a better position to evaluate the need for targeted action.

To that end, with your identified risks in hand, you will now need to consider the following types of questions.....

1. Can this risk affect the quality of my product or project end-result?
2. Can this risk affect project budgets and costs?
3. Can this risk affect the project schedule?
4. Can this risk affect the project planning and management process?
5. Can this risk affect the stability of project work environment?

For each "yes", you can then proceed to the next series of questions.

Does this risk pose a sufficient threat to my project so that further action is warranted?

If the answer is "no", then the results of that analysis should be properly documented, thus declaring that no further action is warranted. Remember that the goal of risk management is not just to avoid risk, but to also apply logic and reality to any decisions and strategies for dealing with risk. If, at this point, you can acknowledge risks, and logically decide to take no further action, your goals in risk management will be realized.

However, if the answer is once again "yes", thus acknowledging the need for further action, then continued assessment should proceed. Once you acknowledge the possibility of impact, and the need for further action, you will then need to look at the issue of consequences. For example, you may know that a delay in network card delivery could impact a desktop installation project, but how will that delay affect the overall project .... will that one delay affect the entire schedule, or can other parallel activities help to make up for that lost time? The answers to these types of questions will help you to pinpoint the likely consequences of a given risk.
With this information in hand, you can then evaluate the need for mitigation and control.

ITtoolkit Navigation Guide

Start at the Home Page
Find White Papers and Project Templates
Explore More How-To-IT Topics and Content