Risk is everywhere in life, work, organizations, traditional business projects, and information technology projects. There is no way to avoid it. It is very important to know it exists. We should not to just close our eyes and bury our heads in the sand like an ostrich. Everybody deals with risks everyday. We manage risk knowingly and consciously sometimes and sometimes we manage it unknowingly and unconsciously. An example is when you are walking across the street. Everyone should look both ways and make certain that no cars are going to hit them. If there are no cars coming, a person will cross because they see very little risk doing it. If there is a car coming but it is very far away some people will still cross taking a slight risk. If there is a car but it is close by, maybe that person won’t cross. What this person has done is basically risk analysis and risk management. This person has identified the risk, a car crashing into them. Measured the risk, in this case a major one. Managed the risk by not crossing the street. They also have even learned from the risk, seeing the driver make eye contact, slowed down, or even sped up. This person can keep the data he has collected and use it for the next time he crosses a street. This is very basic risk management.
Risk is something that has a negative effect on a project. Risks have many effects from slight delay in completion, budget overruns, total failure etc. Risks can never be totally avoided. As long as it continues to provide a financial benefit it will be a integral part of project management.
A textbook definition of risk is: “The identification of the hazards and possible problems, the evaluation of their importance and drawing up of plans to monitor and deal with those problems”.
“Project risk management is the art and science of identifying, analyzing, and responding to risk throughout the life of a project and in the best interests of meeting project objectives. A frequently overlooked aspect of project management, risk management can often result in significant improvements in the ultimate success of projects. Risk management can have a positive impact on selecting projects, determining their scope, and developing realistic schedules and cost estimates. It helps project stakeholders understand the nature of the project, involves team members in defining strengths and weaknesses, and helps to integrate the other project management knowledge areas.”
Proper risk management increases the certainty of a project meeting its goals.
Risk Management is a major component and critical knowledge area in today’s project management. Project Managers are tasked with identifying risks, measuring risks, mitigating risks, and existing with risks.
According to Boehm the following are the elements of risk management:
- Risk Assessment
- Risk Identification
- Risk Analysis
- Risk Prioritization
- Risk Control
- Risk Management Planning
- Risk Resolution
- Risk Monitoring
The initial step in project risk management is to recognize and identify risks. Boehm refers to this as Risk Identification in the Risk Assessment stage of his list. This is also referred to a qualitative analysis of risk. Qualitative analysis can be achieved in many ways. Risk analysis can be achieved through checklists, brainstorms, and studies. Another identification is the SWOT analysis (Strength, Weakness, Opportunities and Threats). The threats segment of the SWOT would help identify the risks. There can even be information available from lessons learned reports on other projects. Qualitative risk identification is subjective in nature. This analysis is considered easier than the Quantitative method and more error prone. The metrics that can be obtained at this stage would be probability of occurrence. Once a risk is identified a risk owner must be assigned to it. The standard it that each risk will have a specific team member assigned to it. For every risk there is an “owner”. This assists with accountability. A good tactic would be to create a register for all identified risks. Just as the stakeholders have a registry or document so can risk owners. When proper Identification is completed you can move on to the next area.
The next step after risks have been properly identified they need to be measured. This is quantitative analysis. It will generate values, number, dates, expenses and other more finite definable data. This is considered the objective analysis. Actual measurements will be generated of the risks. Estimates of exact costs can be obtained. Also time delays can we estimated and evaluated. Proballistic techniques will be used to generate actual numbers backed up by data. Proballistic estimates use a combination of optimistic, pessimistic and most likely estimates to create a value.
Table 1 contains a graphical aspect to risk analysis prioritization can be more easily achieved. There are many ways quantify risk. One way is the risk categorization framework. This is usually a chart with four separate boxes also called quadrants. Risks can be mapped onto this grid for analysis. As risks are mapped further out on the grid the perceived level of importance and level of control increases and as they are mapped closer in they levels drop respectively.
(communications of the ACM 11/1998/vol 41 No.11 p80)
The next phase in project management would be mitigating risk. Boehm refers to this area as risk control. It is comprised of risk management planning, risk resolution, and risk monitoring.
“Tools and techniques for performing risk control include risk reassessment, risk audits, variance and trend analysis, technical performance measurements, reserve analysis, and status meetings ...”
Based on which area of the framework the risk is located determines the strategy for combatting, mitigating, and managing the risk.
If a risk were to land in Quadrant number one (1) it would require interventions into customer relationships, perceptions, and attitudes toward the project. Customers are considered stakeholder in any project and their acceptance is an integral part of the project success. The customer mandate is completed when customers formally accept the deliverables from the project and are satisfied with them. Upper management should be involved and represented to build a bridge of trust and co-operation.
Risks that land in Quadrant number two (2) deal with scope. Scope is another way for saying all the work and processes that go into a project. Scope is the backbone of any project and a major component of the triple constraint. The strategies in this quadrant deal with change management. This is because the scope will evolve after the onset of the project. Project managers need to keep all stakeholders of the implications of change to minimize scope creep. This quadrant greatly controlled by the project manager but total he must always consider stakeholder needs to achieve success.
Quadrant #3 Execution falls is the low importance zone on the framework. As we know most of the time and resources are spent in the execution phase of a project. Risks in this area are resources, assets, manpower, and methodologies. The reason this is perceived as a low importance area is because a project manager has the most control over the risks in this quadrant. Under normal circumstances with proper management risks in this quadrant do not pose a threat to the project.
Quadrant 4 Environmental Risks. Theses risks exist both inside and outside an organization. There risks consist of actual natural disasters. Risks such as fires, floods, earthquakes, or even tsunamis are in this zone. Also external would be the government mandates, political unrest, and competition. There are also many internal environmental risks. Some of the internal risks are changes in management, department conflicts, corporate restructuring. Proper infrastructure can also be part of the environmental risks. This quadrant is also where anything that doesn’t fall into the other three quadrants will land. The risks here are very unlikely and the Project Manager had very little control over. This also makes them land in the area of unimportant.
In order to live with the risk and still continue to prosper in the PM role. A PM needs to pick his battles and allocate his resources and assets while respecting risks. The goal of the PM is to finish the project with the original parameters set out in the Plan. By using the framework as a tool he knows it is more important to keep in close contact to consumer/customer sentiment than to brace for an earthquake. Although planning should be done for both.
Proper risk management increases the certainty of a project meeting its goals. Risk is something that has a negative effect on a project. Risks have many effects from slight delay in completion, budget overruns, total failure etc. Risks can never be totally avoided. As long as it continues to provide a financial benefit it will be a integral part of project management.
Risk Management is a major component and critical knowledge area in today’s project management. Project Managers are tasked with identifying risks, measuring risks, mitigating risks, and existing with risks. Risk can be managed using qualitative methods which tend to be easier and subjective. They can be managed qualitatively which tends to be more definable and objective. Approaches can used such as a proballistic approach. There ways to impose the “Monte Carlo” simulation onto the assessment. Frameworks and diagrams help document, record and learn from risk analysis. Any combination of all of these methodologies can be implemented as well as all of them in succession. The more stringent the analysis the more protected and prepared project will be against risk.
- Hughes and Cotterell,(2002).Software Project Management.3rd Ed.P.134 McGraw Hill,UK
- Schwable,K. (2016).Information Technology Project Management.8th Ed.P426 Cengage Learning Boston,MA
- Boehm, B (1991) “Software Risk Management: Principles and Practices”, IEEE Software p32
- Table 1 (communications of the ACM 11/1998/vol 41 No.11 p80) “Public Knowledge”
. Hughes and Cotterell,(2002).Software Project Management.3rd Ed.P.134 McGraw Hill,UK
. Schwable,K. (2016).Information Technology Project Management.8th Ed.P426 Cengage Learning Boston,MA
. Boehm, B (1991) “Software Risk Management: Principles and Practices”, IEEE Software, pp 32- 41.
. Schwable,K. (2016).Information Technology Project Management.8th Ed.P55 Cengage Learning Boston,MA
Cite This Work
To export a reference to this article please select a referencing stye below:
Related ServicesView all
DMCA / Removal Request
If you are the original writer of this assignment and no longer wish to have your work published on the UKDiss.com website then please: