In Part 3, “The Missing Something”, I recommended holding an initial Risk Workshop at the beginning of the project.
Risk Workshops provide early identification of risks. The workshop is conducted as a brainstorming facilitated meeting with a Facilitator and note taker. The Kickoff Workshop should be conducted with representatives from all affected groups – from Senior Management to workers (Vice Presidents, Directors, CIO, line managers, solution specialists, production supervisors, etc.). The reason for having such a broad group is to ensure that the project risks and environment are articulated from across the organization. The discussion in such a disparate group will awaken awareness and possibly bring forward risks which may have been overlooked.
For example, I held a Kickoff Risk Workshop at the Headquarters of a major shipping company. The scope involved an overhaul of worldwide shipping activities by replacing and updating processes and the infrastructure needed to achieve the goals. Participants included C-level executives as well as operations and technical managers – all were subject matter experts in their areas of expertise. During a roundtable discussion, I asked what the impact would be if this project didn’t work or was not delivered on time. The CIO answered “I will lose my job” – an unexpected answer but one that focused all participants.
The activities of a Risk Workshop are
· Identify the Risks
· Quantify and prioritize the risks
· Develop risk responses
· Assign Actions and Owners
1. Identify the Risks
Risks can come from a variety of factors including technical, internal, external, resource, project operations, vendor, client, political, and economic
Ask the questions:
· What can go wrong on my project?
· What can go wrong on the bigger project?
· What can go wrong elsewhere?
Explore the project documents and the following categories of risk looking for areas of uncertainty. A statement that "The project will be late" is not a risk, it is an impact. A risk that would make a project late may be "We have underestimated the likely duration of task xxx." (The Elements of Project Risk Management, Coblands Consulting, UK, 1996)
One of the dangers in looking for risks is that people tend to examine only their responsibility areas and fail to look at the broader environment. For example, in the business world it is common to look at your immediate competitors in order to identify business risks. This short view often prevents a business owner from anticipating the impact that a multi-national corporation will have on their environment. The same may be true of an IT department that wants to implement a “state of the art” technology and fails to take into consideration that their user community or the company infrastructure cannot handle such an abrupt change.
One of the dangers in looking for risks is that people tend to examine only their responsibility areas and fail to look at the broader environment. For example, in the business world it is common to look at your immediate competitors in order to identify business risks. This short view often prevents a business owner from anticipating the impact that a multi-national corporation will have on their environment. The same may be true of an IT department that wants to implement a “state of the art” technology and fails to take into consideration that their user community or the company infrastructure cannot handle such an abrupt change.
It is always a good practice for Risk Workshops to have participants in the same sessions from the user, management, support, technical, operations, and executive communities so that different views can be brought to bear on potential risks and the means for overcoming them.
Participants in the Workshop should be asked to confirm that the definitions for Impact and Probability given below apply to their environment. Of course, the best method of determining impact and probability would be historical records of magnitude and severity measurements accompanied by statistical analysis of these measurements. In the absence of these records, it is still necessary for the group to agree on definitions.
A risk should be examined for its impact on Scope, Cost (Budget), Schedule, and Quality and quantified as low, medium, or high.
· High = if risk occurs, it would cause delays in the timeline and increase costs. The entire project could be jeopardized.
· Medium = if risk occurs, it could cause delays, setbacks, schedule changes, and increased costs, but the project could be recovered.
· Low = if risk occurs, it would be easy to work around
The probability of a risk occurring should be classified as:
· Medium = Probability is greater than 5% and less than or equal to 20%
· Low = Probability is less than or equal to 5%
· Classification
Classifying the risk sets the priority to be used in preparing and elaborating risk responses. Priority 1 risks are most critical with Priority 4 risks being least critical.
· Priority 1 = High Impact and High Probability
· Priority 2 = High Impact and Low Probability
· Priority 3 = Low Impact and High Probability
· Priority 4 = Low Impact and Low Probability
There are several responses depending on a risk’s probability and impact:
· Assume the risk (Priority 4 only)
· Mitigate the risk (Reduce or eliminate)
· Transfer the risk (insurance, sub-contract, warranties, bonds)
· Create contingency plans (what to do if the risk occurs)
One step that is sometimes overlooked is to have distinct owners of the action for each risk. Assigning a person sets the responsibility for completing the action in a timely manner and allows tracking of progress. The person who is assigned responsibility is allowed to delegate the task to others; however, the assigned person is the one who is held responsible.
To be effective in controlling risks, the Risk Log must be reviewed at frequent intervals, typically at weekly status meetings; first to determine if there are any new or developing risks, second to determine if assigned actions are being pursued, and third to make sure that risks are being controlled so that they do not become issues. It is critical that risks be controlled before they become issues – issues may have the potential of destroying momentum and may result in failure of the project.
A Risk Log should be created starting with the initial Risk Workshop and be used for the entire Project or Program. The Log should be modified from the following:
· Risk ID No.
· Description (Commentary)
· Risk Date (When the risk was identified)
· Risk Identifier (Who first identified the risk)
· Risk Owner (Who is responsible for performing the risk response?) – Very Important!
· Potential Impact (High, Medium, Low)
· Probability (High, Medium, Low)
· Risk Priority (Priority 1 = High Impact and High Probability, Priority 2 = High Impact and Low Probability, Priority 3 = Low Impact and High Probability, Priority 4 = Low Impact and Low Probability)
· Response
o Assume the risk (Only for risks that have a low potential impact and a low probability of occurrence. No action is necessary other than tracking)
o Mitigate the risk (Reduce or eliminate prior to becoming an issue. Elaborate on method of mitigating. Include details and due date)
o Transfer the risk (insurance, sub-contract, warranties, bonds. Elaborate on method of transfer. Include details and due date)
o Create contingency plans (Plans to be executed in the event that the risk becomes an issue. Include details and due date)
· Comments and Status
Part 6 addresses Risk Follow-up. See you then.
Charles
Hey Charles, I LOVE this series. Great work!
ReplyDeleteNote that I added a break to this long post. I'll send you a video to show you how to do that . . .
Alan