A Case for Opportunity or Risk Management, Essay Example

Introduction

This paper addresses the concepts of opportunity and risk management through a kitchen remodeling project. Most Project Managers are familiar with concepts of risk and the need to provide for mitigation actions to minimise or prevent the impact of risk. Vulnerability means being susceptible to the impact of one or more events that may be within or external to your control of influence. For example: one of the biggest risks that an individual faces is that of the personal mortgage on your property. If you fail to maintain the regular monthly payments, then the Bank or Finance company may foreclose upon you. As such they may seize your property and place this for sale in order to redeem their investment. This has two immediate impacts on you as an individual (1) You are suddenly homeless and without a place to live (2) Your credit rating is adversely impacted making it very difficult to obtain another mortgage or personal loan. This may even make it difficult for you to obtain a rental agreement owing to the poor credit rating.

The concept of Opportunity relates to recognizing the potential of risks and taking corrective action that not only mitigates such risks but provides for alternate courses of action that charts a new direction. (Chapman, C.B. 2003)

Risk Management

Risk Management can have a very positive effect on the project. It provides a means of planning for unforeseen events or occurrences and putting in place appropriate mitigation actions that can either lessen or eliminate the serious adverse impact associated with such a risk. In addition, it ensures that the project has an appropriate contingency fund in the budget to cater for the need of additional resources and costs to implement any of the counter-measures that may be required. Risk Mitigation is an essential part of any project planning process and needs to be built into the plan as a distinct activity with assigned tasks and resources.

In identification of risks there is always a degree of uncertainty. This includes the probability or the likelihood of the risk occurring, the potential magnitude or impact of the risk in terms of fall-out should the event occur. In this instance one should plan for best and worst case scenarios with perhaps the contingency model being somewhere in the middle of the event. The other factor is that of time – how long will the event disrupt the business and as such this links disaster recovery to the important aspect of business continuity planning.

Typical Risk Management Process

There are essentially four key phases of operation, as illustrated above. (1) The actual identification of the risk itself. This answers those questions that describe the risk, the potential impact of the risk if it goes wrong etc. (2) The Analysis of the risk. – this includes sensitivity analysis in terms of the trend of the risk whether it increases, decreases or remains stable over time and the quantified (estimated) consequences of the impact (3) The mitigation planning stage defining what needs to be accomplished in terms of time, cost and resource effort in order to mitigate the risk (4) Mitigation Plan implementation – Inclusion of the risk mitigation steps in the project plan.

Risk Management is concerned with the potential identification of threats and providing certain mitigation actions to prevent or minimize the impact of such threats should they become a reality. Such Risk Management plans prioritize the level of threats and provide sensitivity analysis illustrating the threat levels. This is often accomplished by the use of simple colour coding tags, sometimes referred to as RAG (Red, Amber, Green) analysis where RED indicates an imminent and high level risk, Amber a medium threat and Green a low threat. The trend of the risk can then be assessed by and trend analysis. These form three types (1) Increasing: The risk increases in severity of time (2) Stable: The risk neither increases nor decreases over time it remains stable (flat-line) (3) Decreasing: The risk decreases in severity over time. You can now see what happens when you apply the colour (RAG) coding to specified risk identification. For example:

Risk Identification: Possible forced entry to the bank in the evening

Category: RED INCREASING

Means this represents a serious risk to the Bank and the possibility of impact increases over time without appropriate intervention or mitigation actions taking place. These become priority 1 risk avoidance actions

Category: GREEN DECREASING

This represents a relatively low risk to the Bank and the threat level is steadily diminishing over time to the point where it no longer represents a risk. These type of risks are low priority items and often do not have mitigation actions placed against them.

Risk Identification

Identifying risks are essentially a five stage process:-

1. Risk Management Planning which describes how the remaining four steps will be carried out on a project
2. Risk Identification – Analysis of project risk factors and identification of potential risk events.
3. Risk Assessment – Analysis of the probability and impact of each risk event and the prioritization of risk events for response planning.
4. Risk Response Planning – Preparation of risk responses to transfer, avoid, mitigate or accept the project risk.
5. Risk Monitoring & Control – Tracking the status of project risks and invoking risk response plans where required

In the kitchen re-modelling project these actions would correlate as follows:

 Risk Management Planning – Identification of the process activities and tasks that define how risk management will be dealt with on the project. This covers the remaining four identified steps.

Risk Identification – Identifying the project risk factors and what events are likely to trigger or initiate risks. Includes potential impact statements i.e. cause and effect.

Risk Assessment – This looks at the probability of the risks that may occur and their significant impact i.e. high, medium, low. In addition the trend of such risks whether they increase over time, are stable over time (flat-liners) or decrease over time.

Risk response planning – What actions (mitigations) need to take place to address these issues. Involves assigning resources and defining a potential mitigation outcome in measurable terms.

Risk Monitoring – How the risks will be monitored through the lifecycle of the project.

It is useful to construct a Risk Breakdown Structure (RBS). The Risk Breakdown Structure (RBS) is a hierarchical breakdown of risk factors and potential risk sources. The RBS can be populated over time with risk events encountered on projects and used for future risk identification and assessment. An illustration of an RBS is shown in the illustration to the right. (Loosemore, M. 2006)

Risk Planning

Identifying Risk Tolerances and Thresholds – Stakeholder risk tolerances and response plan thresholds should be identified for each project objective. Risk tolerances and thresholds are not the same. Risk tolerances refer to the limit of risk that is acceptable to funding authority stakeholders (such as the project sponsor or business management). Risk threshold is the point at which action is required to ensure that the risk tolerance is not exceeded. Progress towards the risk threshold is tracked using a risk indicator. In the cost overrun example above, the indicator is actual costs; in the schedule example, the indicator is forecast end date.

Risk tolerances are often based on the culture of the organization. Conservative organizations (such as banks or insurance companies) may have a low risk tolerance. Innovative organizations may have a higher risk tolerance. Risk tolerances are also related to the scope management strategy. Date constrained projects will have a low schedule risk tolerance but may have a higher cost risk tolerance. Quality constrained projects may have low quality risk tolerances and greater acceptance of schedule or cost risks. Risk tolerances and thresholds are determined by interviewing project stakeholders, specifically the funding authority, product usage and product support stakeholders. (Kendric, T. 2009)

Funding – Risk responses, such as mitigation and transference, will require funding from a risk contingency reserve. Indicate the risk contingency amounts allocated by cost account. These amounts must be agreed to by funding authority stakeholders. Contingency reserves will help guide the choice of risk response plans during risk assessment and response planning.

Risk Tracking and Control

Risk tracking should be incorporated into the other project tracking (schedule, budget, quality) processes. This can be accomplished through:

• Discussion of project risks during team tracking meetings,
• Identification of new risks during time reporting,
• Tracking risk indicators against thresholds,
• Verifying assumptions on a regular basis,
• Checking the impact of project events (issues, changes, decisions or actions) against project risks,
• Monitoring the execution of risk response plans,
• Regular schedule and cost tracking.

Issue resolution often results in:

• Changes that require deviations from project plan and can impact project scope, cost or schedule,
• Decisions that may cause changes to scope, cost or schedule, or require further actions to be undertaken,
• Action items – unplanned tasks required to respond to issues or risk occurrence.

It is important to understand both the terminology and process flow in the monitoring and control of risks. The following process flow shows the main events:

Note that RISKS in themselves become ISSUES and this in turn prompts both a CHANGE condition and the need to take some form of REMEDIAL ACTION. The CHANGE causes a decision to be made whereas the ACTION results in the creation of that decision. Many Project Managers tend to confuse the understanding of RISKS and ISSUES but this has been clearly articulated in PMBOK[1]. (Frenkel, M. 2005)

Risk Closure – Risks can be closed under any of the following conditions:

• The probability of the risk event occurring has fallen below a defined threshold and the risk is no longer a threat,
• The impact of the risk event has been reduced below a defined threshold,
• The risk has occurred and corrective response plans have been executed.

When risks are closed, the closure date should be recorded on the Risk Event Log sheet on the Risk Register.

Risk Avoidance

Risk avoidance involves eliminating the cause of the risk event or selecting an option or approach with less risk. Examples of risk avoidance include:

• Using proven suppliers for products or services,
• Using stable proven technology instead of trying new technology,
• Staffing the project team with employees to eliminate contractor risks,
• Removing troublesome resources from the project to promote a cohesive team environment,
• Removing complex requirements from the project product,
• Preparing a good project plan with tangible milestones to minimize schedule, external contractor, and existing system risks.

Because risk avoidance plans are directed at the cause of the risk, consideration should also be given to the frequency and growth of the potential risk event. Risk avoidance strategies should also consider the long term effect of the risk decision. For example, choosing a cheaper supplier to avoid immediate cost risks may introduce longer-term cost and schedule risks associated with product support. In some cases, the higher risk option for the project may be best for the organization.

Risk Mitigation

Risk mitigation will either reduce the probability of the risk occurring or mitigate the impact of a risk event. Risk mitigation responses may be preventative or corrective. Examples of preventative risk mitigation responses include:

• Providing training in new techniques or tools,
• Use of reviews and inspections to confirm deliverable quality,
• Performing a ‘proof of concept’ to test new technology,
• Prototypes to establish requirements and design approaches,
• Status reporting from vendors providing project deliverables,
• Team building activities to implement collaborative conflict resolution strategies,
• Introduction of a new systems development environment to reduce technology risks

References

B. Chapman, S. W. (2003). Project risk management: processes, techniques, and insights. London: John Wiley.

Kendric, T. (2009). Identifying and Managing Project Risk: Essential Tools for Failure-Proofing … New York: AMACOM.

Martin Loosemore, J. R. (2006). Risk management in projects. New York: Taylor and Francis.

Michael Frenkel, U. H. (2005). Risk management: challenge and opportunity. New York: Springer.

[1] Project Management Body of Knowledge, as provided by the Project Management Institute in the USA.