Risk Identification

Why is risk identification important?

Identifying risks is the first and perhaps the most important step in the risk management process.
It involves generating a comprehensive list of threats and opportunities based on events that
might enhance, prevent, degrade, accelerate or delay the achievement of your objectives. If you
dont identify a risk, you cant manage it. Its also important to scan the environment from time to
time to identify new and emerging risks, as the departments exposure to risk may be constantly
changing.

IP: EE Factors, OP assets, project scope statement (assumptions), risk management plan(R&R,
RBS, risk provisions), project management plan

Tools: Documentation reviews, info gathering techniques (Brainstorming, Delphi tech,

interviewing, RCA, SWOT); Check List Analysis based on Historical information of previous
similar projects. The lowest level of RBS is used as Risk Checklist; Assumption analysis;
Diagramming tech: C&E, system/process flow chart, influence diagram,

OP: Risk Register

Knowledg Major Primary Tools & Primary

e Areas Processes Inputs Techniques Outputs

Risk Determining 1. Enterprise 1.Documentat 1.Risk Register

Identificatio which risks Environmental ion reviews
n are likely to Factors 2. Info-
affect the 2. gathering
project & Organizational techniques
documentin
Process Assets
g their
characteristi 3. Checklist
cs 3.Risk analysis
management
plan 4.
Assumptions
4. Project analysis
Scope
Statement 5.
Diagramming
5. Project techniques
Management
Plan
Identify the risks
The purpose of this step is to identify what could go wrong (likelihood) and what is the
consequence (loss or damage) of it occurring.
Key questions to ask include:
What can happen? List risks, incidents or accidents that might happen by systematically
working through each competition, activity or stage of your event to identify what might
happen at each stage.
How and why it can happen? List the possible causes and scenarios or description of the
risk, incident or accident.
What is the likelihood of them happening?
What will be the consequences if they do happen?
Risks can be physical, financial, ethical or legal.
Physical risks are those involving personal injuries, environmental and weather conditions and the
physical assets of the organisation such as property, buildings, equipment, vehicles, stock and
grounds.
Financial risks are those that involve the assets of the organisation and include theft, fraud, loans,
license fees, attendances, membership fees, insurance costs, lease payments, pay-out of damages
claims or penalties and fines by the government.
Ethical risks involve actual or potential harm to the reputation or beliefs of your club, while legal
risks consist of responsibilities imposed on providers, participants and consumers arising from laws
made by federal, state and local government authorities.

.
As a project manager, it is important to think about what future events may impact your projects.
These events may be positive or negative, so understanding them allows you to prepare, and put
plans in place to deal with them. But how can you forecast the future with any degree of certainty?
The Delphi Technique can help.

The Delphi Technique is a method used to estimate the likelihood and outcome of future events. A
group of experts exchange views, and each independently gives estimates and assumptions to a
facilitator who reviews the data and issues a summary report.
The group members discuss and review the summary report, and give updated forecasts to the
facilitator, who again reviews the material and issues a second report. This process continues until
all participants reach a consensus.

The experts at each round have a full record of what forecasts other experts have made, but they
do not know who made which forecast. Anonymity allows the experts to express their opinions
freely, encourages openness and avoids admitting errors by revising earlier forecasts.

This article looks at how to run a Delphi session. On completion of this guide, you will be able to
run a session enabling you to predict future events and their likely impact on your projects.

The technique is an iterative process, and first aims to get a broad range of opinions from the
group of experts. The results of the first round of questions, when summarised, provide the basis
for the second round of questions. Results from the second round of questions feed into the third
and final round.

The aim is to clarify and expand on issues, identify areas of agreement or disagreement and begin
to find consensus.

Step 1: Choose a Facilitator

The first step is to choose your facilitator. You may wish to take on this role yourself, or find
a neutral person within your organisation. It is useful to have someone that is familiar with
research and data collection.

Step 2: Identify Your Experts

The Delphi technique relies on a panel of experts. This panel may be your project team, including
the customer, or other experts from within your organisation or industry. An expert is, any
individual with relevant knowledge and experience of a particular topic.

Step 3: Define the Problem

What is the problem or issue you are seeking to understand? The experts need to know what
problem they are commenting on, so ensure you provide a precise and comprehensive definition.

Step 4: Round One Questions

Ask general questions to gain a broad understanding of the experts view on future events. The
questions may go out in the form of a questionnaire or survey. Collate and summarise the
responses, removing any irrelevant material and looking for common viewpoints.

Step 5: Round Two Questions

Based on the answers to the first questions, the next questions should delve deeper into the topic
to clarify specific issues. These questions may also go out in the form of a questionnaire or survey.
Again, collate and summarise the results, removing any irrelevant material and look for the
common ground. Remember, we are seeking to build consensus.
Step 6: Round Three Questions

The final questionnaire aims to focus on supporting decision making. Hone in on the areas of
agreement. What is it the experts are all agreed upon?

You may wish to have more than three rounds of questioning to reach a closer consensus.

Step 7: Act on Your Findings

After this round of questions, your experts will have, we hope, reached a consensus and you will
have a view of future events. Analyse the findings and put plans in place to deal with future risks
and opportunities to your project.

Conclusion

Use the Delphi Technique for creating Work Breakdown Structures, identifying risks and
opportunities, compiling lessons learned and anytime you would usually conduct a brainstorming
session.

Predicting the future is not an exact science, but the Delphi Technique can help you understand the
likelihood of future events and what impact they may have on your project.
 Guidance for Performing Root Cause Analysis (RCA) with Performance Improvement

Overview: RCA is a structured facilitated team process to identify root causes of an event that
resulted in an undesired outcome and develop corrective actions. The RCA process provides you
with a way to identify breakdowns in processes and systems that contributed to the event and
how to prevent future events. The purpose of an RCA is to find out what happened, why it
happened, and determine what changes need to be made. It can be an early step in a PIP,
helping to identify what needs to be changed to improve performance. Once you have identified
what changes need to be made, the steps you will follow are those you would use in any type of
PIP. Note there are a number of tools you can use to perform RCA, described below.

Directions: Use this guide to walk through a Root Cause Analysis (RCA) to investigate events in
your facility (e.g., adverse event, incident, near miss, complaint). Facilities accredited by the
Joint Commission or in states with regulations governing completion of RCAs should refer to
those requirements to be sure all necessary steps are followed.

Below is a quick overview of the steps a PIP team might use to conduct RCA.

Steps
1. Identify the event to
be investigated and
gather preliminary
information
2. Charter and select team
facilitator and team
members
3. Describe what happened
4. Identify the contributing
factors
5. Identify the root causes
6. Design and implement
changes to eliminate the
7. root causes
Measure the
success of changes
Explanation
Events and issues can come from many sources (e.g.,
incident report, risk management referral, resident or family
complaint, health department citation). The facility should
have a process for selecting events that will undergo an
RCA.
Leadership should provide a project charter to launch the
team. The facilitator is appointed by leadership. Team
members are people with personal knowledge of the
processes and systems involved in the event to be
investigated.
Collect and organize the facts surrounding the event to
understand what happened.
The situations, circumstances or conditions that
increased the likelihood of the event are identified.
A thorough analysis of contributing factors leads to
identification of the underlying process and system issues
(root causes)
The team of the event.
determines how best to change processes and
systems to reduce the likelihood of another similar event.
Like all improvement projects, the success of improvement
actions is evaluated.

Steps two through six should be completed as quickly as possible. For facilities accredited by the
Joint Commission, these steps must be completed within 45 days of occurrence of the event.
 Step 1: Select the event to be investigated and gather preliminary information

Events that may be investigated using the RCA process can be identified from many sources
(e.g., incident report, risk management referral, staff, resident, or family feedback, health
department citation). High priority should be given to events that resulted in significant
resident harm or death and other events the facility is required by regulation to investigate.
Also consider doing an RCA for near miss or close call events that could have resulted in
harm to the resident, but did not, either by chance or timely intervention. The latter types of
events represent high risk situations that could, in the future, cause a resident to be harmed.

Once an event is selected for a Performance Improvement Project (PIP) involving RCA, someone
involved in the facility QAPI program can begin gathering preliminary information, including
the incident report and any documentation from the preliminary investigation, for later
discussion by the team. This may include interviews with those involved including the resident
or family members, collection of pertinent documentation or photographs, review of relevant
policies and procedures, quarantine of defective equipment, etc. This preliminary information
is also useful for deciding which individuals should be invited to serve as members of the
team as described in Step 2.

Helpful Tips:
o Involve facility leaders in the prioritization and decision to proceed with an RCA.
There will be greater cooperation in completing RCAs when the process is viewed
as leadership-driven.
o Be sure to start with a problem and not the solution. It is tempting to assume we
know what will fix the problem before weve thoroughly examined it.
Assumptions are often wrong and may hinder complete analysis of the
underlying causes.
o Dont define the problem as a need for something. The problem statement should
objectively state what went wrong, not why, or how. An example of an effective
problem statement is, Resident X continued to receive a medication one week
after the order was given for discontinuation. A good problem statement will
facilitate a more thorough examination of the problem.
o If the event represents a liability concern or questionable practices by an
employee, the leadership team can initiate a risk management review or an
employee performance review to start simultaneous with, but separate, from the
RCA process. The RCA process should focus on systems rather than individual
performance.

Step 2: Select the event to be investigated and gather preliminary information

Next, leadership designates a facilitator for the PIP team, and works with the facilitator to
create a charter that will help guide the team in managing the scope of the project and
making changes that are ultimately linked to the root causes identified in the RCA process.
Together, leadership and the facilitator select staff to participate on the PIP team.
As managers and supervisors gain experience in doing RCAs, more people in the facility can be
trained to serve as team facilitators. The facilitator is responsible for assembling and
managing the team, guiding the analysis, documenting findings and reporting to the
appropriate persons.

The number of team members depends on the scope of the investigation. Individuals selected
to serve as team members must be familiar with the processes and systems associated with
the event. People who have personal knowledge of what actually happened should be included
as team members or given an opportunity to contribute to the investigation through interviews.

Helpful Tips:
o Team members should be selected for their ability to discuss and review what
happened during the event in an objective and unbiased manner. In some
situations, staff members personally involved in the event are the best people to
serve as team members. In other situations, staff members not personally
involved in the event are the best people to serve as team members with the
people personally involved asked to share their experience during interviews. This
may be appropriate if the people directly involved in the event are dealing with
emotions and are not able to be objective. However, if this is the case, it is a good
idea to provide those staff persons directly involved with counseling and support
so that they are able to participate in the RCA process. Participating in the RCA
process and hearing others objective viewpoints can help them to deal with the
situation in a positive manner.
o Keep the number of management or supervisory level individuals on the team to a
minimum.
Staff members may be inhibited from speaking up or being completely candid
during discussions about what happened if their direct supervisor is in the room. If
this is not possible, the facilitator should explain the need for members to be free
to discuss the process honestly, as it is actually carried out in the facility.
o Make it clear to everyone involved that the RCA process is confidential. This
reassurance helps people feel safer discussing the process and system
breakdowns that may have caused an inadvertent mistake.

Step 3: Describe what happened

At the first meeting of the team, a time line of the event under review is created. The
preliminary information gathered in step 1 is shared with the team and other details about the
event are elicited from team members. If the people personally involved in the event are not
part of the team, their comments about what happened are shared with team members. All of
this information is used to create a time line of the event the sequence of steps leading up to
the harmful event.

Below is a time line for a situation involving a resident that suffered a serious injury during his
transfer from a wheelchair back to his bed. This tall and larger man (300-pound) was placed in
a Hoyer lift and elevated into the air above his wheelchair. As the CNAs turned the lift toward
the bed it began to sink because the lift arm couldn't handle the residents weight. In an
attempt to complete the transfer before the patient was below the level of the bed, the CNAs
swung the lift quickly toward the bed. The lift tilted dangerously to the side and the legs
started to move together, narrowing the base of support. The resident dropped to the ground
and the lift fell on top of him.
 EVENT

CNAs get Hoyer lift and position

Resident
it by residents
is raised from
bed wheelchair using
CNAs
the Hoyer
swing lift
resident toward
Lift starts
bed to collapse andResident
tips to one
drops
sideto ground and lift falls on resident

TIME LINE:

Use a flipchart or sticky notes to draw a preliminary time line. Before proceeding to Step 4 of
the RCA, be sure that everyone agrees that the time line represents what actually happened.
Now is the time for the team to add missing steps or clarify factual inconsistencies about the
event.

Helpful Tips:
o The time line of the event should describe just the facts not what caused the facts
to happen.
For instance, the CNAs may have mistakenly used a Hoyer lift that was not strong
enough to move a tall resident weighing 300 lbs. This factor may have contributed
to the event, but it is not documented in the time line. Only the facts of what
happened should be included in the time line, the causal factors are added in a
later step.
o Once the preliminary time line has been created, the facilitator finalizes the time
line by asking the team:
Does the time line adequately tell the "story" of the incident? If not, the
scope of the timeline may need to be extended further back in time or
expanded to include what happened after the event.
Does each step in the time line derive directly from the step it precedes? If
each step is not derived logically from the one preceding it, it usually
indicates that one or more steps in the sequence have been left out. Add
missing steps to the time line.
Is each step in the timeline pertinent to the incident under investigation?
The answer may be "yes", "no," or "not sure." Include only the "yes" and
"not sure" steps in the final event line.
o In rare situations the team cannot identify a sequence of steps leading up to the
harmful event. For instance, when a resident develops an intravenous (IV)
catheterrelated infection it may not be possible to pinpoint the exact steps
preceding the infection event. The infection appears to have occurred despite
staff members apparently doing all the right things (e.g., following good hygiene
when inserting catheters and caring for catheterized residents). In these
situations, a time line is not created however dont jump to this conclusion too
quickly. It is harder to find all the root causes of an undesirable event if the team
does not have a time line to guide their decisions.
o Resist the temptation to skip right to step 5 of the RCA process, which is Identify
the root causes. Team members may insist the root causes of the event are
already understood and it is not necessary to go through steps 2 through 4.
Jumping to conclusions about root causes increases the likelihood the team will
end up with quick-fix solutions that do not address the underlying systems gaps,
or contributing factors, and fail to prevent similar events in the future.
o
o
Step 4: Identify the contributing factors
o
o Here is where the knowledge gained during step 3 is used by the team to dig deeper into
what happened to discover why it happened.
o
o Step 4 involves the team looking at each step of time line and asking, What was going on
at this point in time that increased the likelihood the event would occur? These are the
contributing factors situations, circumstances or conditions that collectively increased the
likelihood of an incident. By itself a contributing factor may not have caused the incident, but
when they occur at the same time, the probability an incident will occur increases.
o
o As mentioned in Step 2, it is important to get the perspective of people personally involved
in the event when identifying the contributing factors at each step. These may be the only
individuals aware of the actual circumstances affecting what happened. For instance, the CNA
who chose the wrong type of lift might have felt pressured by her supervisor to find a lift as
quickly as possible so the resident would not be kept waiting. Team members not personally
involved in the event might be unaware this contributing factor existed.
o
o Below are examples of contributing factors that might be identified for each step of the
time line for the event involving a resident injury during transfer from wheelchair to bed.
o
o EVENT
o
o CNAs get Hoyer lift and position
Resident
it byisresidents
raised from
bedwheelchair using
CNAs
the swing
Hoyer resident
lift toward
Lift starts
Resident drops to
bed to collapse and tips to one side
ground and lift
o TIME LINE: falls on resident

o
o
o CONTR CNAs had to
hurry to find a lift
No sign on lift
Resident was
moved rapidly
Sharp movement
of resident by
indicating weight
IBUTIN so resident would
limit
toward bed CNAs
not be kept because lift
G waiting arm started to
slip
FACTO
RS:
o
o
o Facility's one CNAs unaware Lift not strong
CNAs not
heavy duty lift the lift they are enough to
trained to
was being used using is not rated hold resident
respond to lift
in another location for use with very
malfunctions
heavy residents

o
Helpful Tips:
o Consider what was happening at each step in the time line to ensure the
team does not overlook some important factors. Whenever possible, use a
time line as the basis for identifying contributing factors.
o Brainstorming can be an effective tool to identify contributing factors by asking,
What might have happened that would increase the likelihood the event would
occur? Consider what recommended practices might not have been followed,
e.g. sterile dressing changes not done for IV-catheter sites. Consider what
 procedure work-arounds might have occurred. Consider how staffing at the
time of the event might have impacted the eventual outcome.
o When identifying contributing factors be careful to avoid hindsight bias. Knowing
the eventual outcome of a time line can influence how team members view
activities leading up to the event. Remember to consider only those factors that
were actually present and known to those involved at the time not what was
only realized after-the-fact.
o
o
Step 5: Identify the root causes
o
o All incidents have a direct cause. This is the occurrence or condition that directly
produced the incident. In the resident incident described in Step 3, the tilting and collapsing
Hoyer lift is the direct cause of the accident. However, the direct cause is not the root cause.
o
o Root causes are underlying faulty process or system issues that lead to the harmful event.
Often there are several root causes for an event.
o
o Contributing factors are not root causes. The team needs to examine the contributing
factors to find the root causes. This can be done by digging deeper asking repeated why
questions of the contributing factors.
o This is called the five whys technique, which is illustrated below.
o

o
o
o This questioning process is continued until all the root causes are found. It is common to
find the same root cause for two or more contributing factors.
o
Helpful Tips:
o The team must determine if theyve truly identified a root cause, versus a
contributing factor which requires the team to do more digging. Ask the
questions below about each potential root cause identified by the team. If the
answers are NO, then the team has identified root causes and they can stop the
questioning process. If the answer to any question is YES, then the team may not
have identified true root causes and needs to ask more why questions to get to
the root causes. Keep asking these until you get to root causes.
Would the event have occurred if this cause had not been present?
Will the problem recur if this cause is corrected or eliminated?
o The team should not make judgments about whether an individual did the right
thing. This judgment is to be made by the manager responsible for evaluating
the employees performance. The facilitator may need to remind team members
that the RCA process is not where these judgments are to be made.
 o The team facilitator should watch out for discussion manipulation during this
stage. Some team members may try to divert attention from root causes
originating in their department or direct the discussion away from root causes that
will require additional resources or necessitate significant changes to how work is
now being done. A successful RCA process requires frank and open discussions of
the causes of the event.
o A fishbone diagram can also be used to determine root causes; see the CMS QAPI
website for more information on this tool.
o
o
o
Step 6: Design and implement changes to eliminate the root causes
o
o In this step the team evaluates each root cause to determine how best to reduce or prevent
it from triggering another harmful event. The key is to choose actions that address each root
cause. These actions will generally require creating a new process or making a change to a
current process. The steps to accomplish this are the same as those used in any type of PIP.
Note that at this point, you may want to reevaluate the composition of your team to make sure
you have included people who are part of the process being changed. It is a good idea
throughout a project to make sure you have the right people on the team and to adjust
membership as needed.
o
o At least one corrective action should be developed to reduce or eliminate each root cause.
Some action plans will be short-term solutions to fix a contributing factor, e.g. purchase an
additional Hoyer lift rated for use by residents weighing over 250 lbs. But short-term solutions
rarely fix root causes. For instance, in the example event the team also needs to recommend
that a formal evaluation of future specialized equipment needs for residents be regularly
incorporated into the facility strategic planning and budgeting process.
o
o When developing corrective actions consider questions such as:
What safeguards are needed to prevent this root cause from happening again?
What contributing factors might trigger this root cause to reoccur? How can we
prevent this from happening?
How could we change the way we do things to make sure that this root cause never
happens?
If an event like this happened again, how could we stop the accident trajectory
(quickly catch and correct the problem) before a resident was harmed?
If a resident were harmed by this root cause, how could we minimize the effect of the
failure on the resident?

o Aim for corrective actions with a stronger or intermediate rating, based on the categories
of actions below. Corrective actions that change the system and do not allow the errors to
occur are the strongest.
o
o Stronger Actions
Change physical surroundings
Usability testing of devices before purchasing
Engineering controls into system (forcing functions which force the user to complete an
action)
Simplify process and remove unnecessary steps
 Standardize equipment or process
 Tangible involvement and action by leadership in support of resident safety; i.e., leaders
are seen and heard making or supporting the change

Intermediate Actions
Increase staffing/decrease in workload
Software enhancements/modifications
Eliminate/reduce distractions
Checklist/cognitive aid
Eliminate look alike and sound alike terms
Read back to assure clear communication
Enhanced documentation/communication

Weaker Actions
Double checks
Warnings and labels
New procedure/memorandum/policy
Training
Additional study/analysis

For example, suppose staff members cannot locate the equipment to use when lifting
larger residents, because the specialty equipment is not kept in the same location. The
strongest action to prevent another accident would be to keep all equipment designed for
special needs residents in just one storage area (change physical surroundings). Staff
members will no longer need to differentiate usual equipment from specialized equipment.
If this action is not feasible, consider placing a sign on the lift equipment DO NOT USE FOR
RESIDENTS OVER 250 LBS. This is an example of a warning or label (sometimes called a visual
cue). It is a weak action because staff members might overlook the warning, but if no other
stronger action is available, a weak action is better than none at all.

When designing corrective actions, clearly state what is to be done, by whom, and when.
Satisfactory implementation of the corrective actions will be monitored so it is important to
have clearly defined plans.

Helpful Tips:
o The team leader should encourage team members to come up with as many
intermediate and strong actions as possible. It is helpful to involve supervisory
and management staff in the action planning discussions. Designing intermediate
and strong actions often requires an understanding of various resident care
systems and the facilitys resource allocation priorities. Staff members on the
team may not possess this knowledge.
o Because the feasibility and costs associated with corrective actions must also be
considered it is helpful to include facility management in the corrective action
discussions, if they are not already members of the team.
o If a particular action cannot be accomplished due to current constraints (e.g. lack
of resources), the team should look for other ways of changing the process to
prevent a similar event from occurring in the future. Doing nothing should not be
an option.
o
o
Step 7: Measure the success of changes
o
o Concurrent with implementation of action plans, mechanisms are established to gather data
that will be used to measure the success of the corrective action. The RCA should reduce the
risk of future harmful events by minimizing or eliminating the root causes. What you measure
should provide answers to three questions:
o
1. Did the recommended corrective actions actually get done? (e.g., Did the warning signs
get put on the Hoyer lifts? Did a formal equipment evaluation step get added to the
annual budgeting process?)
2. Are people complying with the recommended changes (e.g., How often is the wrong type
of Hoyer lift used for residents weighing over a predetermined weight? Is staff provided
an opportunity to participate in an equipment needs assessment during the budgeting
process?)
3. Have the changes made a difference? (Has another resident been harmed by
equipment unsuited for their physical condition?)
o
o Evaluating the success of the PIP usually occurs after the team has been disbanded, and
will become the responsibility of the person designated to monitor the corrective action/s. The
QAA committee is responsible for overseeing all QAPI activities, which includes reviewing data
on the effectiveness of all improvement projects. Ideally, all of the following criteria should be
met to conclude a PIP has been successful:
Measures of success were monitored over time.
The goal was attained (process changes were made and sustained, no recurrent events).
You are confident that the change is permanent.
 RCA PIP Template

This template can be used to document the completed RCA PIP process, including
follow-up actions and measures. Revise it as necessary to meet your needs.

Team Facilitator: Date RCA Started: Date

Ended: Team Members:

Name Position Name Position

Brief Narrative Description of Event (include time line if available):

 Root Causes and Contributing Factors

Conduct your systematic analyses to determine your contributing factors and root causes.
Use techniques such as the five whys, flowcharting, or the fishbone diagram to assist in
identifying the root causes. Additional tools are available that guide the use of each of these
techniques. It is helpful to keep any of these analyses with your PIP documentation for future
reference. Describe each root cause as identified by the team. Enter these in the table below.

Corrective Action Plans
For each root cause identified, enter the corrective action plans intended to prevent the
root cause from causing another harmful event. There can be more than one action plan for
each root cause. Some action plans may be short-term interventions which can be
accomplished quickly and some action plans require more long-term implementation steps. For
each action plan designate the individual or group responsible for completing the action and
the time frame for completion.

Root Cause Corrective Action Respo Completion
nsible Deadline
Individual/Gr
oup

 Measures of Success

Measures of
Repor
Success ting
Correc (How we will Schedule
tive Action know if this action is
and
successful) Consider Signatur
Individual
measures of how often e of RCA team
or Group
recommended leader Date
Responsibl
processes are not e for

followed and the Reviewing
incidence of similar Results
adverse events.

Checklist Analysis

The checklist of risk categories is used to come up with additional risks

for the project. There are many tools and techniques available in
identifying risks processes used in project management and one of them
is checklist analysis. It is a technique use to systematically review
different materials using a list to determine the accuracy and
completeness of the project.

The checklist analysis provides an avenue in determining the risks

involved in a particular project management plan. The checklist is
usually developed based on the knowledge obtained from previous
projects that are similar to the current one as well as historical
information.
 Checklist analysis is one of the simplest and quickest ways to identify
risks processes. One of its advantages is that it is suitable for team
members who have fewer experiences. While it is simple, building an
exhaustive checklist can be challenging as projects, albeit similar, can
still have their own unique and different risks. It is also crucial for the
team members to review and prune the related items when they are no
longer appropriate for the checklist. Lastly, the checklist should be
reviewed during the closure of the project to improve future projects by
incorporating valuable lessons learned.

Assumption Analysis
Identification of different assumptions of the project and determining
their validity, further helps in identifying risks for the project.
Assumptions analysis refers to a specific technique that is used by
project team members to minimize risks involved in
making assumptions during the process of planning a particular project.
The process in which this analysis takes place is fairly straightforward,
yet is essential to minimizing risk. The project team members must
identify and document all of the assumptions being made during the
project planning process, and then on a one by one basis, identify the
risks that exist as a result of each assumption to the project based on
the potential inaccuracies or inconsistencies that the assumoption may
exhibit. During this process, it may be deemed that the assumption is
valid and worth any perceived risk or, in some cases, it may be
determined that an assumption is in fact not valid, and an alternate
course of action may be recommended and/or implemented outright.
Assumptions analysis is a process that likely should be repeated
throughout a projects life.

Variance and Trend Analysis - Comparing actual results to planned

results is a great way to see if something is getting worse or improving.
Look for variances in defects, schedule, performance and cost to identify
risks that may have cropped up on your project.

How to perform Variance analysis?

Variance analysis is a technique used for evaluating the difference

between planned and actual figures. This can be applied to time,
resources and any other factor that has a major impact on your project.
The total time spent on your project can be analysed by evaluating the
difference between the planned time and the actual time.
 Variance analysis allows the business analyst to understand the reason
for the difference by revealing answers to critical questions such as:
What happened? Why did we exceed the budget? Why didn't we meet
the deadline? Why did we require more business analyst effort than we
planned?

Variance analysis would typically take place at the end of the project.

So, what are the steps you need to take to conduct variance analysis?

PRACTICAL APPLICATION

Plan Variance Analysis - Determine which metrics you'd like to

collect/compare and create an appropriate model in Excel. Are you comparing
the number of business analyst resources required for one project phase to
another? Or are you comparing the total number of business analyst resources
required from one phase to another across multiple projects?

Set the Materiality Threshold - This is the point at which variance

starts to matter. For example, if you set a 4% threshold on time, a 2% time
overage may not mean much and may not require any cause analysis. A 10%
time overage may however, be worrisome and you would want to investigate
further.

Cause Analysis - This is where you determine the cause of the variance.
The insight you gain here is certainly critical to making business decisions and
future adjustments.

In order to produce useful reports on how variances have

aff ected your project , you must always consider the context in
which the variance occurred.

CASE 1: Business Analysis Project A

Let X = No. of Business Analysts (Planned) = 5

 Let Y = Number of Business Analysts Assigned (Actual) = 3

%age Variance = ((X - Y)/X) * 100 = (2/5) * 100 = 40%

CASE 2: Business Analysis Project B

Let X = No. of Business Analysts (Planned) = 5

Let Y = Number of Business Analysts Assigned (Actual) = 8

%age Variance = ((X - Y)/X)* 100 = (-3/5) * 100 = -60%

While a positive variance is not necessarily a bad thing (As seen in this
case where less resources were used than planned), a negative variance
is almost always a source of worry. Both cases need to be analysed to
understand why and to ensure you keep doing more of the positive
things and less of the negative.

Reserve Analysis This involves keeping tabs on the money you have
set aside for responding to risks. This is also known as a contingency
reserve. Running low on this means you may not have enough funds to
cover the remaining risks. While the Management Reserve is for
managing unknown unknowns, the contingency reserve is for known
unknowns.

Risk Audits In this exercise, an outside party comes in to examine an

organization's risk response strategy and how effective it is. They check
to confirm that risk responses address their root causes and determine
how effective risk planning processes are.

Technical Performance Measurement This involves checking the

performance information of your project to see if it measures up to what
was planned.
 Status Meetings - Every status meeting should have an element of
risk identfication and review. They can help to head off problems, initiate
a risk response on time or identify an opportunity that needs to be
exploited. Be sure to solicit input from frontline staff - they will be better
at identifying risks since they are the ones doing the job. Techniques like
brainstorming can further complement this.

Risk Probability and Impact assessment: What is the probability

that a risk will occur? What will it cost the business if it does happen?
The Probability and Impact Matrix indicates which risks need to be
managed before others.

Risk Reassessment This involves reassessing risks to see if anything

has changed. The main goal is to find any new risks that may have come
up and to examine if previously identified risks are still valid.

Project Risk Register

What is a Risk Register?

The Risk Register records details of all the risks identified at the
beginning and during the life of the project, their grading in terms of
likelihood of occurring and seriousness of impact on the project, initial
plans for mitigating each high level risk, the costs and responsibilities of
the prescribed mitigation strategies and subsequent results.

It usually includes:

a unique identifier for each risk;

a description of each risk and how it will affect the project;

an assessment of the likelihood it will occur and the possible

seriousness/impact if it does occur (low, medium, high);

a grading of each risk according to a risk assessment table (refer to Table 1);

who is responsible for managing the risk;

 an outline of proposed mitigation actions (preventative and contingency);
and

in larger projects, costings for each mitigation strategy.

This Register should be maintained throughout the project and will

change regularly as existing risks are re-graded in the light of the
effectiveness of the mitigation strategy, and new risks are identified. In
smaller projects, the Risk Register is often used as the Risk Management
Plan.

Why would you develop a Risk Register?

A Risk Register is developed to:

provide a useful tool for managing and reducing the risks identified before
and during the project;

document risk mitigation strategies being pursued in response to the

identified risks and their grading in terms of likelihood and seriousness;

provide the Project Sponsor, Steering Committee/senior management with a

documented framework from which risk status can be reported;

ensure the communication of risk management issues to key stakeholders;

provide a mechanism for seeking and acting on feedback to encourage the

involvement of the key stakeholders; and

identify the mitigation actions required for implementation of the risk

management plan and associated costings.

When would you develop a Risk Register?

Initial risks must be identified and graded according to likelihood and

seriousness very early in the Project. This initial risk assessment will
form part of the Project Proposal/Brief or Project Business Case for the
project. Once the project is approved the Risk Management Plan and
Risk Register should be fully developed. In the case of smaller projects
the Risk Register may serve both purposes.

What you need before you start:

Knowledge and understanding of the project.

Knowledge and understanding of the Key Stakeholders.

 Knowledge and understanding of appropriate types of risk management
activities, or where to obtain them.

Any of the following documents Project Proposal/Brief, Project Business

Case, or Project Business Plan.

The Tasmanian Government Project Management Guidelines.

Also advisable:

Departmental Project Management Guidelines.

Corporate/Business Plan for the Department/Business Unit.