There are different standards for different industries and functional areas. Since our theme is about project management in the business and technology sectors, we just list several standards that are well accepted in these sectors and relevant to our discussion. These include PMBOK 2004, AS/NZS4360:2004-Risk Management, UK Risk Management Standard by IRM/AIRMIC/ALARM, and NIST 800-30 Risk Management Guide for Information Technology Systems.
We do not intend to go through them one by one. Instead we want to highlight some commonalities among them.
Definition of Risk
PMBOK: An uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.
Risk Management Handbook by Max Wideman: The cumulative effect of the chances of uncertain occurrences which will adversely affect project objectives.
APM / BS: Combination of the probability or frequency of occurrence of a defined threat or opportunity and the magnitude of the consequences of the occurrence.
RUP: An ongoing or upcoming concern that has a significant probability of adversely affecting the success of major milestones.
Notice that all definitions focus on impacts on the successful delivery of a project. This definition may not be entirely relevant to the business world. For a real-life project, anything that can jeopardize the organization, stakeholders, or even the project manager herself, should be considered risks. The project itself is just a means to an end - the ultimate business objectives of the project, which is usually some tangible/intangible benefits to the organization or a group of stakeholders. If something bad may happen to them as a direct or indirect results of the project, they are to be considered risks and be probably managed.
Common Logic of Formal Risk Methods
Notice that all definitions focus on impacts on the successful delivery of a project. This definition may not be entirely relevant to the business world. For a real-life project, anything that can jeopardize the organization, stakeholders, or even the project manager herself, should be considered risks. The project itself is just a means to an end - the ultimate business objectives of the project, which is usually some tangible/intangible benefits to the organization or a group of stakeholders. If something bad may happen to them as a direct or indirect results of the project, they are to be considered risks and be probably managed.
Common Logic of Formal Risk Methods
All formal methods follow more or less the same logic.
Step 1: Identify risks
Step 2: Analyze risks (can be both qualitative and quantitative)
Step 3: Plan risk responses
Step 4: Monitor and control risks
In the next article, we will continue to explore formal methods for handling project risks. Some of their drawbacks and practicalities in the real world will also be discussed.
To be continued...
Copyright 2008 Knowledge Century Limited.
Posts
No comments:
Post a Comment