Read PPT, Previous Paper and instructions before start to work on this paper
Running Head: RISK MANAGEMENT 1
RISK MANAGEMENT 9
Risk Management Process
List and Description Components of Risk Management Process
Risk can be defined as events of uncertainty that bear positive or negative impacts on the schedule, cost as well as the performance of a project (Hillson, 2017). The negative impacts are usually threats, while the positive impacts normally present themselves as opportunities. Just like other important business activities, the risk management process needs to be a process that is easy to understand, follow-through, and above all, clear in purpose. Similarly, the process must consist of reliable inputs, properly-designed activities, and outputs of value-adding nature. The risk management process has some major components which include:
· Risk identification
· Risk assessment
· Risk response development
· Risk response control
Description of the Components
Risk Identification
Risk identification involves analyzing project activities to single out factors that may result in risks. As initially indicated, risks are not only negative impacts but also positive ones. Therefore, the process of risk identification must target both opportunities and threats that can influence the project process either positively or negatively. The process of analyzing project activities with the aim of identifying risks is carried following four distinct steps. The first step involves creating a list of threats and opportunities with the ability to positively or negatively impacting on the project. The second step involves a consideration of risks already maintained as well as managed in the risk register. Every risk, when described, forms two parts, risk statement, and the consequence. For instance, in our clap switch project, there can be a risk that we may not finish on assembling the motherboard as per the scheduled date, which will automatically lead to failure to deliver the product on the cost-bound date.
Risk Assessment
Once the risks have been identified, they are traced to where they emanated from. This helps in informing the drivers that triggered their occurrence. Dealing with a risk whose source is known can be faster than dealing with one that is not known yet. A risk assessment also involves attempting to know the extent to which the identified risks have gone (Kivilä, Martinsuo, & Vuorinen, 2017). With our project of clap switch, we can assess the risks by measuring their extent of affliction on various important project functions. For instance, on technical requirements, we will look at issues such as whether all the requirements as listed at the beginning of the project still have requisite stability and whether we can resolve technical uncertainties discovered.
Risk Response Development
In this component, risks have already been identified as well as their driving factors and the extent to which the impacts of these risks have gone. Armed with the right information concerning the type of risk and their sources, the project team decides on the best response approaches. The response approaches are categorized into four categories, which include avoiding, accepting, reducing, and sharing. Each response is usually relevant to the type of risks identified.
Risk Response Control
Response control comes as the last component of the risk management process and involves mitigation of the risks identified. Going by the risks response selected, the project team identifies existing gaps from the risks management capability of the team and enhances those capabilities so as the risk response approach picked can fully be implemented.
Tools and Techniques Used in Risk Identification
The conventional practice of identifying risks is through the review of project documents such as plans, files belonging to previous projects, documentations, lessons books, articles, and many others. The project team can create a list of threats and opportunities with the ability to positively or negatively impacting on the project (Iqbal et al., 2015). Also, a consideration of risks already maintained as well as managed in the risk register. Every risk, when described, forms two parts, risk statement, and the consequence.
Information Gathering Techniques
Some of the information gathering techniques include brainstorming, which is carried out by a group of individuals focused on identifying project risks. Another obvious technique that turns out to be very informative and effective is root cause analysis. It involves classifying the identified risks, then tracing them to their sources with the aim of knowing their causes (Hillson, 2017). Lastly is the interviews, which are also another traditional but still effective method of gathering information related to risks identified.
Qualitative Risk Analysis
The qualitative risk analysis involves categorization of risks that are highly specific with the project being undertaken with consideration of the apparent impact the risks bear on the budget and schedule of the project. For instance, in our project of design and development of the clap switch, we realized the initial design depended so much on unrealistic assumptions that were only found with the prototype we used. During implementation, we had to make adjustments that caused had a significant effect on our project budget and schedule, as shown below.
Project Schedule and Budget Table
|
|
10 days |
10 days |
10 days |
10 days |
|
Requirements elicitation $180 $200 $100 $80 $00 $80 |
|
|
|
|
|
Design |
|
|
|
|
|
Implementation |
|
|
|
|
|
Testing |
|
|
|
|
|
Project Closure |
|
|
|
|
From the schedule and budget table, as shown above, all activities were allocated ten days except testing and project closure, which were all combined into a 10 day period split into five days for each. However, due to the risk that took place under the design activity as explained above, there was a need for four extra days at the cost of $80. At the end of it, the project cost shot-up from $560 to $640.
|
|
Risk event |
Likelihood |
Impact |
When |
|
R1 |
Business (competitor + supplier) |
3 |
3 |
Executive |
|
R2 |
Technical |
4 |
5 |
Monitoring |
|
R3 |
Organizational |
3 |
5 |
Planning |
|
R4 |
Project Management |
2 |
4 |
Executive |
|
|
|
|
|
|
|
|
|
Project Management R4 |
Technical R2 |
|
|
|
|
|
|
|
|
|
|
|
|
Organizational R3 |
|
|
|
|
|
Business R1 |
Quantitative Risks Analysis
The quantitative risk analysis, on the other hand, involves categorization of risks that are highly specific with the project being undertaken with consideration of the apparent impact the risks bear on their high probability of occurrence and impact on the project Clap control home automation .
Contents of a Risk Response and develop a Risk Response
Going by the risks response selected, the project team identifies existing gaps from the risks management capability of the team and enhances those capabilities so as the risk response approach picked can fully be implemented. As initially stated, we accepted the risk as per the assessment outcome and redesigned the product. This was on the backdrop of the development of the clap switch when we realized that the initial design depended so much on unrealistic assumptions that were only found with the prototype we used.
Tools and techniques used to Control Risks
To fully put the mitigated risk under full control, the Risk Response Plan Report was implemented fully. This was carried out in full realization that there were no new risks recorded until the project was brought to a closure. The project team identified existing gaps from the risks management capability of the team and enhanced those capabilities so as the risk response approach applied to correct the risk could fully be implemented.
References
Hillson, D. (2017). Managing risk in projects. Routledge.
Iqbal, S., Choudhry, R. M., Holschemacher, K., Ali, A., & Tamošaitienė, J. (2015). Risk management in construction projects. Technological and Economic Development of Economy, 21(1), 65-78.
Kivilä, J., Martinsuo, M., & Vuorinen, L. (2017). Sustainable project management through project control in infrastructure projects. International Journal of Project Management, 35(6), 1167-1183.