PRJM6003: Project Risk Management Process -Critical Analysis Reflection - Project Risk Management Assesment Answer

For Part A, you are to select ONE project, which can be either a project that you are presently involved with in your professional work; or a social project. The risk selected for Part A must be for a FUTURE EVENT, not a risk that has already eventuated. NOTE: it must be a project, not operational, risk.1. RISKIDENTIFICATION

A. Select and fully explain one risk event Provide any relevant contextual information

B. Fully explain two key causes only for your selected risk event

2. QUALITATIVE RISK ANALYSIS

A. Create a 5-level Consequence table (insignificant, minor, moderate, major, catastrophic). Explain why you have selected the criteria/objectives in your table (e.g. why is cost in your consequence table). (Reminder: the consequence table is used to analyse the consequence of all risks on your project, not just your selected risk). Note: Examples of consequence table provided in paper 4 – but you must create your own that is applicable to your specific project objectives)

B. Qualitative Risk Analysis requires the use of 3 tables. Using

Likelihood table (copy into your assignment- see next page)

Consequence table from 2A above,

Likelihood-Consequence table (copy into your assignment- see next page)

For your selected risk, explain and fully justify:

• level of consequences;

• level of probability;3. RISK TREATMENT- For your chosen risk:

• Describe 3 possible treatment strategies , fully assess each treatment then select/reject these treatments

• Fully explain and reflect on the level of residual risk based on the application of the selected treatment(s)

• Identify and analyse one possible secondary risk from your selected treatment(s), and one treatment4. Produce a RISK REGISTER, containing details for your selected risk and reflecting ALL the abovePART B Reflection (This can be a different project to Part A)5. CRITICAL ANALYSIS – Select a major risk event that has eventuated on a project that you have has involvement in. Reflect and Critically analyse (don’t just report the facts) the quality of the risk management. e.g. what risk management occurred? Was it good or bad risk management? Why? What should have been done? Etc

1. Risk Identification

A. Description of Risk Event

For this section, the selected project is ‘cloud-based ERP implementation by an organization’. When a particular organization attempts to adopt an ERP system, there are a number of potential risks associated with the process (Edwards and Bowen 2013). A risk event is referred to one such risk taking place or occurring that in turn affects in significant change in a specific set of circumstances.

However, in relation to the present scenario of implementation of cloud-based ERP in an organization, one such risk event can be inability to appropriately cope with the organizational change. When a particular organization undertakes an ERP project, the overall implementation of ERP essentially transforms the way employees and people in the company use to work. It results in making a much more automated, transparent and connected set of activities. Thus, with the change existing business processes, the roles and responsibilities of individual employees also significantly change (Hillson and Simon 2012). To successfully deal with the issue, change management approach is necessary. Otherwise, without a proper change management plan, the ERP project implementation might entire go in vain if the people are not able to adopt the changes brought about by the ERP system implementation.

B. Description of Two Key Causes

An ERP (Enterprise Resource Planning) system implementation project entirely transforms the existing business processes as well as the individual roles and responsibilities of the employees associated with those business processes. Therefore, the organization needs to carefully handle the change management process side-by-side with the ERP system adoption project. Significant risks may arise in the areas of managing the change in process as well as the overall technological change (Kerzner 2013). Without proper change management techniques, the ERP project managers are sure to fail making an effective transition to the post ERP go live. Thus, from the initiation of the ERP project, adequate awareness regarding the change is to be created across departments with respect to change in business processes, technology use, employee roles as well as on end user involvement.

Another key cause behind inability of the organization in coping with change can be ineffective or inefficient regulatory requirements. An organization needs to set appropriate rules and regulatory measures to be followed by the employees in regards to the business processes carried out in the firm. However, in any case, if there is any non-compliance with the regulatory measures, then it might result in significant disruption in the entire process or undertaking of the ERP implementation process (Turner 2014). Therefore, the organization needs to make sure that there exist an adequate an appropriate set of rules and principles that is to be applied across the organization to ensure smooth and successful transition to the new approaches of performing the new activities without any form of disruptions or mismanagement.

2. Qualitative Risk Analysis

A. Consequence Table

Likelihood TableLikelihood - Consequence Table

Justification for Level of Consequence

For the selected risk, which is inability to cope with the overall organizational and technological change in ERP-system implementation projects, the level of consequence is marked as ‘Major’. Despite so, in certain cases, the consequence might be ‘Catastrophic’ too. It is mainly because without a change management technique that organization is not aware of the huge changes that the adoption of ERP brings about to the overall business processes and employee responsibilities. It may result in disruption of key activities for a significant number of days consecutively (Peixoto et al. 2014). In addition, the change might potentially create mismanagement and commotion among the staff and disrupt the performance and production for long consecutive hours. It additionally involves the possibility of technical and regulatory breaches if the employees are not properly trained and guided regarding the new system (Pritchardand PMP 2014). Therefore, in order to overcome the major negative aspects that might result from incapability of coping with the change, the organization may potentially need unbudgeted resources outside of the estimations for resolving the issues and it might delay the final and successful transition of ERP ‘go-live’.

Justification for Level of Probability

The level of probability for this type of risk, which is incapability of coping with overall organizational, operational as well as technological change brought about by ERP implementation projects, can be marked as ‘Unlikely’ or ‘Possible’. It is mainly because most organizations are adequately aware of the huge change impact that an ERP project would essentially bring to the existing system. For this purpose, companies make sure to adopt an efficient and smart change management approach that starts from the beginning or initiation of the ERP implementation. This change management technique involves ensuring appropriate awareness regarding the changed processes and roles all across the departments and activities. Therefore, it is very unlikely that an organization would face such a situation (Phillips 2013). Usually, before taking on an ERP system project, an organization goes through a number of certain systematic steps to ensure the overall outcome of the project will be desired and achieve a successful accomplishment when the final transition is to be made. Thus, before undertaking the venture, it is a rule for every organization to set their change management strategies by establishing a team with appropriate change management expertise. This team mainly handles the responsibility of change impact and design along with providing proper training to the users of the new ERP system to be incorporated.

3. Risk Treatment

Treatment Strategies

Risk Avoidance

This treatment method deals with the particular risk by completely avoiding the risk event. The company neither gets involved in, nor withdraws from a certain situation involving potential risk. The activity or area that raises the potential risk is straightly avoided i.e. not continued. It aims to reach a zero probability on the certain area of risk, which in turn ensures zero consequences (Marcelino-Sadaba et al. 2014). The process of avoiding a risk can usually take multiple forms. It can result in change of scope or specific processes associated with the undertaken project, not entering or indulging into a specific/ new activity, adopting a familiar approach to do a job rather than adopting an innovative approach. In some situation, it may also result in termination of a project.

However, in the context of the present ERP project, risk avoidance may not come as a useful technique to solve the particular issues with dealing with the significant operational, organizational and technological change.

Risk reduction is another process of treating the risk with an aim of reducing the possibility of loss. The technique followed in risk reduction involves increasing precautions and ensuring better safety, thereby reducing the uncertainly with increasing availability and access of information. There can be two types or firms of risk reduction. One is based on reducing the probability and another one is based on reducing consequences (Liu, Meng and Fellows 2015). The first one follows a preventive approach aiming to lower the possibilities that a particular risk event will occur or take place. Thus, the probability is minimized. On the other hand, the second approach bases itself on a corrective plan. It aims to reduce the severity of the consequences.

However, in relation to the present risk event, it is suitable to adopt a treatment based on reducing the probability of the risk. In this way, it will be effective and help making sure that the organization can adequately incorporate and cope with the overall significant changes brought about by the implementation of an ERP system.

Risk Transfer

Transferring the risk refers to mainly sharing the risk with another third party that is directly or indirectly associated with the project. The shifting of responsibility to another party helps the main organization to remove the areas of risk and thereby lessens the burden of risk management to be applied on that particular risk area. Transferring of risks to other third parties can be achieved by insurance and contracts (McNeil, Frey and Embrechts 2015). It essentially involves sharing of risks such as establishing partnerships and joint ventures in the particular business scenario.

In this specific context, however, transferring of risk does not apply as much as risk reduction does. However, there are certain areas of possibilities where the organization can attempt to establish partnerships in order to share the risks associated with adoption of ERP system into the organization.

Level of Residual Risk

Residual risk is based on the remaining level of risk after taking the treatment approaches and ensuring proper implementation with effectiveness. A risk treatment such as risk reduction may reduce the probability of a certain risk to lower down the probability as well as lower the severity of consequences. In this is type of scenario; the residual rating is effective in indicating the appropriate effectiveness of that particular risk treatment. In the chosen project and associated risk event, the reduction of probability has been implemented (Caron 2013). Therefore, the organization needs to make sure that after the risk treatment is complete and fully implemented, whether the residual risk level is acceptable or tolerable. Based on the outcome of this decision, the risk treatment process is repeated or withdrawn.

Secondary Risk

The risk treatment adopted in this context may or may not possibly generate another secondary risk. The application of the chosen risk treatment strategy (i.e. reducing probability of risk) however, may create secondary risk so as to result in increase in budget for providing adequate training to the users of the new ERP system (Burke 2013). To some extent, it might result in potential delay depending on the time taken by the organizational people to fully understand and grasp the new way of working of the business processes and functionalities.

4. Risk Register

img class="wp-image-2868 size-full aligncenter" src="https://www.myassignment-services.com.au/wp-content/uploads/2018/11/Pic4.png" alt="" width="732" height="431" />

Delay and significant increase in time taken to complete the project M H A NEW Re-scope project, focusing on time and resourcing Consultant

Part B: Reflection

5. Critical Analysis

In a particular software development life cycle project, a proper risk management strategy needs to be followed so as to ensure the project’s success. However, there are significant potential risks associated in a software development project. For this reason, a risk management plan with systematic identification, analysis, prioritization, monitoring, planning, and mitigation is required. I was involved in a website development project where we had a group of 5 team members. We made sure to adopt a specific risk management strategy to ensure smooth execution and accomplishment of a successful and running website. For this purpose, we adopted the traditional risk management practice involving the step-by-step approach of identifying, analyzing, monitoring and mit6igating the risks.

However, in the development phase, we had identified the following risks:

Change in requirements: When the project was in middle level i.e. in development phase, there were certain changes in the design specifications of the website that had been brought about by the end user.

Understanding of technology: A specific member of our project team was not adequately familiar with the particular programming language that we were using to develop the project.

After identifying these risks, we decided to perform a risk analysis to assess the impact of loss and the magnitude of risk. According to the risk analysis and prioritization for the individual risks, we moved forward to develop appropriate contingency plan for the individual risk events. The risk mitigation strategies that we had adopted in relation to this context are discussed as follows:

Risk reduction: We attempted to reduce the risks by incorporating adequate strategies to allow the modifications into our design in a least costly and most efficient way that was possible by us. In addition, we had arranged for long training sessions for the specific team members so as to make them familiar with the domain of work and the programming language that we were dealing with.

Risk monitoring: After the identification, mitigation and risk treatment, it was also important to regularly monitor the progress and ensuring proper resolution of the risky areas and items so as to prepare contingency plans and take corrective measures as and when necessary.

Communication: We made sure there was an ongoing and effective communication process between the project team and the end user so as to avoid any confusion and ambiguity regarding the requirements, outcomes and deliverables of the project.