Risk Log

From apppm
Revision as of 11:27, 3 March 2019 by S181289 (Talk | contribs)

Jump to: navigation, search

In Projects, the most unavoidable aspect is Uncertainty, even the most proficient Managers faces difficulty to handle it. Various techniques are used by them like decision milestones to be expected outcomes, risk management for prevention of disasters and some uses computational procedure taken from previous projects to get indemnity of Desired deliverables, nonetheless, the project runs out of scheduled time, Increased Budget and compromise with the quality. Or sometimes it may fail.[1]
Conventional tools and activities are used such as work breakdown structure, Schedules and cost estimate all are proposed to be related to Risk Management. Though, the key management tool is Risk Log/Register. It is a record of identified risks, including results of analysis and planned responses. It is used in a range of project management activities; for example, it is one of the tools to control the project, to document lessons learned, or is used in procurement planning. [2] The Log for Risks is mainly used to document the Unforeseen risks which Come into the picture at the time of the project life cycle. And this document helps To Assess the risks for future projects and makes us prepared in advance for the unforeseen risks which now becomes foreseen risks for the next project.
This article will try to explain How to create Risk Log for a project with a probable format and the application tools of using it in Risk management. Moreover, the article will try to show the correlation of different aspect of risk management in the relation of Risk log. Risk log involving various input activities done by Project managers Such as risk identification, Assessment, treatment and monitoring the status of risk.


Contents

Risk Identification

Throughout the life cycle of projects, various risks may arrive with different impact on the project in terms of Time, Scope and cost variations. Moreover, the new risks may become foreseen ones as the project progresses and the level of impact on the project may change with the progress of the project. Sometimes the risk may have negative effect defined as ‘Threats’.[2] The Risks should be documented in the Log describing its Service line as per the Work breakdown structure, date of identification and the stage of the project in which it is identified.


[3].

Risk Assessment

Risks are assessed in terms of its occurrence, impact on the project and key stakeholders. The assessment of risks includes estimating the probability of incidence rate and the corresponding value for project objectives if the risk does occur. We must prioritize with an agreement to the assessment taking into the frame the time, cost and stakeholders and much we should accept it. In most of the cases, the risks are assessed with probability impact score, and this can be only done by an experienced person. The word PIRA is used in the case where assessment is done based on probability impact. In this process, the description of risk is needed in the context of its causes and implications to the project and these can be recorded in the log with nomenclature so that it can be compared later. The nomenclature should be very precise and proper causes should be mentioned with a realistic approach, also defining the implications and impacts in terms of capital is favorable as it justify the most. For instance the Example: If (event) occurs due to (driver), the consequences could result in (impact).

:

The Risks can be rated as per its objective in relation to cost, time, scope and quality, on the other side with its likelihood of occurrence and recorded in the log with some numeric or colored representation. Figure 1 Shows the classic version of rating the risk on Numerical scale.

Figure 1: Relative Or Numerical scale for risk impact and likelihood.

Figure 2 shows the latest version of assessing the risk impact in conjunction with the stakeholder’s involvement. Like in the figure it shows that risks having a high probability of occurrence and critical impact on business are categorized in the red zone and are a concern for Senior management.[2]

Figure 2: Double probability impact matrix

To make it more accurate Probability Impact risk assessment is done based on numbers rating with coded colors it makes easier for Project managers to see the risk and act accordingly with prioritizing the critical ones. For example in figure 3 we can see the impact is scaled on the basis of numbers set to a different range of cost incurred in risk to that of percentage range for the probability of occurrence assigned to different numbers. ]

Figure 3:Risk matrix (from The Actuarial Profession  www.actuaries.org.uk)

The rating can be done using this type of matrix with a number and color.



Risk Treatment and Monitoring

Risk treatment is a” measure that is modifying the risk” it may be a process, policy, device practice or other actions that modify the risk.[4] In the process of risk treatment more allocation of resource and activities are done into the budget and schedule. It is much favorable in dealing risk if a Risk Owner (Defined as ‘‘person or entity with accountability and authority to manage the risk’’ could be problematic for some risk management practitioners. Internal management allocation of responsibility for risk treatment initiatives does not transfer ‘‘ownership’’ of risk. It transfers obligations to perform tasks to a certain standard and within a certain time frame. While people understand the notion of task allocation and performance obligations, unnecessary confusion may be caused by the notion of risk ‘‘ownership.’’ Moreover, the ‘‘risk owner’’ should not only have the accountability and authority, but also the adequate resources to manage the risk.)[5]is allocated to overcome it, having specialization in respect of the actions needed to be performed. Moreover, the treatment should be effective in terms of cost and time and realistic within the project context and understood by all stakeholders involved. This also involves avoiding the risk by developing a plan, to mitigate the risk, to accept the risk or to make a contingency plan to be used in case of reoccurrence. It is very important to control risk and it is done by Tracking the progress of actions taken for identified risks by reviewing the progress and evaluating their effectiveness. Again, the process of identifying new risks, monitoring and assessment should be repeated unless the issue created gets closed. It is mainly performed by weekly or monthly reviewing the progress and rating it in each review so that it is easy to identify the progress in project schedules. It is also very important to overlap the risk log with project schedules so that it is easy for a Project manager to see and react accordingly.



Risk Log Layout

There are many layouts available for the risk log and many companies make it as per their own need and style. However, the basic layout of most of them is alike with many headings and subheadings. In a bigger context for program and portfolio management, there are further headings. Main headings are discussed below:

• Project name
• Service Area
• Project Manager
• Risk Identified date
• Risk identified stage
• Description of risk: causes and implications on project
• Rating: in terms of likelihood and impact can be done in terms of number or colored
• Risk treatment: Avoid/Mitigate/Accept
• Risk Owner
• Risk mitigation actions
• Task owner
• Due date
• Previous rating
• Risk actions were taken since the last reporting
• Rating: in terms of likelihood and impact can be done in terms of number or colored
• Risk Status: open/closed
• Risk closed date
• Remarks



Limitations

Risk Log has several limitations and some of them are discussed here:

• PIRA assessment does not give clear predictions and mostly it depends on the experience. So, in some cases assessment may be wrong or overpredicted
• Assessment of risks should be done in conjunction with capital management So as it makes clear to Programme managers while dealing with it and planning for future projects.
• The proper description of risk and companies should have word database for different risks so that it is easy to sort risks
• Visualization of risk as an event not as distribution


Conclusion

In spite of various limitations, this document is base for the risk management processes. Risk management is only an analysis without risk Log. So it can be said that it is a foundation stone for managing risks by any corporate.



References

  1. De Meyer, A., Loch, C. H., & Pich, M. T. (2002). “Managing project uncertainty: From variation to chaos”. In V. 43, Issue 2 (pp. 60-67).
  2. 2.0 2.1 2.2 Joana Geraldi, C. T. (2017) "How to DO projects"
  3. Alashwal, A. and Fong, P., 2015, ”Empirical Study to Determine Fragmentation of Construction Projects.”
  4. Aven, T. (2010). “On the new ISO guide on risk management terminology. In Reliability Engineering & System Safety”.
  5. Lajtha, A. D. (2012). ISO 31000 Risk Management— “The Gold Standard”.
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox