One of the most powerful tools available to the project
manager is the collective knowledge of the project team. A project manager's
success or failure on a project is determined, to some extent, by how well they
use this tool. This is particularly true in the case of risk management. Sure
there are other sources the project manager can turn to when searching for
information on the risks their project faces. Information is available from
professional associations, consultants, government organizations, historical
databases, and risk management artefacts from previous projects. These are all
valuable sources of information but they will not provide you with information
specific to your project. Even if they could, they would not be able to provide
you with information specific to your project, and your project team. The best
source for that information is from the project team.
The team combines the knowledge they have of your project,
its goals, objectives, schedule, tools, and technology which you provide with
the knowledge and experience they have gained from projects they have worked on
in the past. This combination is what enables them to identify the risks your
project faces, their relative probability, and impact to the project if they
should happen. They will also be able to identify the strategies that will be
effective in your organization, for your project.
Risk workshops rely on brainstorming techniques to make the
collective team knowledge greater than the sum of its parts. To brainstorm
effectively a team must be physically together, either in one room or several
rooms, depending on the size of the team. This means that Risk Workshops need
the team to be collocated to succeed. The only exception to this is when a
project team consists of several sub-teams with different responsibilities and
the sub-teams are collocated although each sub-team is situated in a different
This is not an article about brainstorming but you do have
to understand the concept in order to run a Risk Workshop. We'll run through
the basics here (sort of a quick Wikipedia rundown) and then tell you how to
apply them to the Risk Workshop.
Brainstorming relies on group creativity to produce a large
volume of ideas devoted to the solution of a problem. In order to generate a
large volume of ideas and to ensure that the ideas generated benefit from group
participation, the following ground rules need to be enforced:
- Everyone must participate. The idea is to
generate a large quantity of ideas so no possibility is missed. Every
participant must contribute to meet this objective. The general purpose of
quantity in brainstorming is to produce the best solution to the problem. We
state the purpose a little differently for risks. We want to ensure that every possible
risk our project faces is identified.
- Criticism must be withheld until a later stage.
Criticism of ideas as they are articulated by session participants will inhibit
the contribution of ideas. There will be those that will not be fazed by
criticism of their ideas while others will be shamed into silence. Don't allow
this to happen.
- "Outside the box" thinking should be
encouraged. This means that the team must bring fresh perspectives on project
risk into the room. Inhibitors such as "we've never had that happen to us
before", or "that strategy wouldn't work in this organization"
should be left at the door. Outside the box thinking is what will bring the
team members' experience outside the organization to bear on the problem.
- Improve on the session outcome by combining and
improving ideas. During brainstorming sessions you will hear one risk event
described by several participants in different ways (usually about one per
participant). These descriptions should be combined into one risk event description.
Group discussion of mitigation strategies can combine several good strategies
into one great one.
Your first step will be to select the participants to the
workshop. While it would be nice to have everyone in the organization
contribute to your session, it would be very expensive and they probably
wouldn't all fit in one room. Choose the participants carefully so that every
aspect of the project is covered without overcrowding. You should have
representatives for each project phase at the workshop and each skill set
should be represented. Each of the key deliverables should also be represented.
Analyze your project to determine how many unique deliverables you have. Where
different skill sets are called upon to produce the deliverable, have at least
one representative for each skill set involved. Where the same skill sets
produce several deliverables, the deliverables can be represented by one team
member per skill set.
Take into consideration the size of the room you choose to
host the event. Participants should be made comfortable which means adequate
seating, access to desks or tables, etc. Use more than one room and session to
accommodate groups too large to fit comfortably into the available rooms. You
can use a main room to kick the event off and then break the group up into
sub-teams situated in smaller rooms if you wish. There is no one optimal group
size for brainstorming. You will need to look at your project team and the
available rooms to host your event and choose the group that is optimal for
Schedule the session well in advance to allow the invitees
time to juggle their schedules and make room for the workshop. Put the event
right in participants' calendars where possible so there is no possibility of
conflict. You should send a formal invitation to the participants which
includes a description of the risk workshop, the objectives for the workshop,
and what will take place. Workshop objectives will be:
- A list of risk event descriptions. Risk events
can either be threats to the project or opportunities for the project to exceed
- A prioritized list of risks based on the
probability of the risk event happening and the impact to the project if it
- A list of mitigation strategies, at least one
for each risk that exceeds the project risk threshold. I'll explain risk
thresholds a little later in this article. One mitigation strategy might serve
more than one risk so the number of strategies does not necessarily have to
exceed the number of risks.
Participants should be educated
about the project. The education should
include a description of at least the major deliverables of the project, the
key goals and objectives, key milestones, tools and techniques, assumptions,
and constraints. The reason for doing this is twofold: to prepare the
participants in advance and to improve production from those folks who will
refuse to share an idea unless they have thoroughly analyzed it and are sure it
will not be criticized. You can deliver this information in the meeting
invitation or as an attachment to it.
There will be 3 distinct segments
in your workshop:
- Risk identification and grouping
- Risk evaluation or prioritization
- Risk mitigation strategy identification
You should plan on separating each
of these segments with a break. You may even want to break the workshop up into
2 or even 3 sessions on as many different days, depending on the size and
complexity of your project and the number of participants. Don't plan on
working more than 1.5 - 2.0 hours without a break. If you are planning on
having participants available for the day, plan refreshments for breaks and
lunch. The more rested and refreshed your participants are, the more productive
they will be. Include the timeline for each of the segments in your invitation.
The invitation will not be in the form of a meeting agenda but should indicate
the major segments and the time reserved for each.
You'll need some stationary
supplies for your workshop. Provide the workshop with sticky notes to capture
risk descriptions and mitigation strategy descriptions. Provide each
participant with a pad of these. Participants will also need a felt tip pen for
writing. You'll need a laptop with MS Excel to capture the information in your
risk register. You'll also need a projector to present information to the team.
The room should also have a whiteboard. I'll explain how these are to be used
in my description of the workshop.
The risk register from a previous
project, an industry checklist, or a list of risk events taken from a previous
project's Lessons Learned can stimulate thinking on the team. Examine this
material for relevance to your project. Only include this information if was
derived from a similar project. A risk checklist for a construction project is
of little use to a software development project and vice versa. Keep in mind
that the objective is to stimulate thought and even when a risk event is not directly
related to your project, it might
stimulate a participant to think of one that is.
Finally, you will want to send out
a meeting reminder especially if you sent the original invitation well in
advance. Include all the information from the original invite in the reminder,
or at least a link to that information just in case any participants ignored it
the first time around.
Professional facilitators, especially those with experience
in conducting Risk Workshops, will greatly benefit your workshop. Check on the
availability of a facilitator if your project budget can afford one. The first
place to start is within your own organization. Does your PMO have a
facilitator, or project manager with experience in facilitating these meetings?
Does another group in your organization have one? Look outside the organization
when it cannot offer one. You will have to fill the role of facilitator if you
can't find one, or the project budget will not accommodate one.
The Workshop (Phase I)
You're going to use a model of the project for the participants
to attach their sticky notes. The best form of model is a timeline which
depicts the major project milestones on a timeline. The major deliverables
should also be depicted. You can make the icon you use to represent the
deliverable cover the entire build window or place it on the timeline where it
is to be delivered. Using a room with a whiteboard will allow you to draw the
graph directly. Use flip chart paper, draft paper or any other large paper form
if your room lacks a whiteboard, and tack the paper up in the front of the
room. Draw your project graph on the paper.
Introduce the workshop with an overview of the project, the
key goals, objectives, deliverables, milestones, constraints, and assumptions.
I know, this is the same information I told you to include on your invitation
and reminder, but repeating this information at the beginning of the workshop
will refresh everyone's memory. There will also be those who simply won't have
read the information because of a disinclination or because they didn't have
the time. Introduce the facilitator, if you are fortunate enough to have
acquired one. They will go over the workshop format, goals and objectives.
Describe the workshop, timelines, goals, and objectives to the team if you are
serving as the facilitator. Don't forget the basics in your pre-oration. I mean
things like the washroom locations, break times, coffee machines, etc., etc.
Finish your introduction with the workshop rules. The rules
- No criticism of another's ideas
- Each participant must produce at least one risk
- Everyone should participate in discussions
- No outside interruptions
- Cell phones, i-phones, and Blackberries must be
turned off, or set to vibrate
Now set the team to work. Have each team member write out a
description of a risk event on the sticky note pad they have been provided. The
more risk events they can describe, the better. Have them place the sticky note
on the graph on the deliverable or milestone they are applicable to. This
segment will be finished when no-one is placing sticky notes on the graph.
The next segment requires the participants to examine the
risk event descriptions for duplicates. Where they believe a risk event
description is the same as, or similar to, another description they should
place the sticky notes on top of one another. Allow the participants to move
the sticky notes where they believe they have been assigned to the wrong
deliverable or milestone. Where a sticky is moved more than once, it is very
likely that more than one milestone or deliverable is susceptible to the
same risk event. Copy the original event
description on another sticky and apply the sticky to both.
The exercise will also produce a fair degree of movement of
sticky notes between groups. Watch for disagreements about which group a risk
event belongs to. Excessive movement of the sticky will be one indicator of a
disagreement. Take the participants involved aside and determine the cause of
the disagreement. Disagreements can arise for a variety of reasons: different
understandings of the risk event, different experience, different skill sets,
etc. You (or the facilitator) are the arbiter. Make the call so as not to
embarrass either participant. There are no right or wrong answers, simply the
one you think is the best for the project. It is possible that the disagreement
has arisen over two different risk events sharing the same description. Have
one or the other of the participants write a new description and assign it to
the competing group where this is the case.
This step is complete when all the discrepancies have been
reconciled and the risk event descriptions grouped. The next step is to review
the groups of sticky notes and determine which describe the same risk event.
The best way to tackle this task is to break the team into groups and have each
group take responsibility for a project phase, deliverable, or milestone. How
you divide the work up will depend on the size of the team and the number of
sticky notes. The objective should be to rationalize the sticky notes
eliminating duplicates and creating a new risk event description to replace
several descriptions of the same risk event. Make sure that in doing this step,
no risk event is lost.
All the risk event descriptions should find their way into
your risk register. This can be done in several ways. You can have the groups
elect a spokesperson who articulates each risk event description to you (and
the rest of the team) as you type it into the register. You can type in the
risk event descriptions into your register while the team is having its break. You
could provide each group with a copy of the register and have the group type it
in. The advantage of having the groups articulate each risk event description
to you is the tendency this will have to stimulate conversation - this is still
a brainstorming session. The advantage of typing them in on your own is the
reduction in the time the team spends in the workshop. Choose a strategy that
best suits your circumstances.
The next segment deals with prioritizing the risks. The
exercise requires the team to assign a score to each risk event based on the
probability that the event will happen and the impact to the project if it does
happen. Don't worry about quantifying the risk in terms of cost at this point.
The objective of the exercise is to prioritize the risks against one another.
There are many different ways of doing this. I'll describe
one that should work for any project. Post each risk event description on the
graph in advance of this exercise; this is an ideal time for the team to take a
break. The descriptions should be written out so that they are easily read.
Next, choose a scoring system. Numeric systems are best for this exercise as
they make comparisons easier than a high, medium, low system. 1 through 9
should be the only numbers used for probability as 0 means the event cannot
happen and 10 means that it must happen. Have the team assign each risk a
score, from 0 to 10 by writing their score on a sticky note which they will
attach to the risk being scored. The score should be an average of the assigned
scores. Check the scores to identify any 0s or 10s and get clarification on the
reason for the score. Anything the team deems impossible (a 0) should be
discarded. Anything the team deems a certainty (a 10) should be further
analyzed to determine why the team views it as part of the plan.
The next step is to have the team perform the same exercise
for impact on the project. Impact should be measured against one of the
project's key objectives in the areas of budget, quality, schedule, and scope. Use
the same method you used to measure probability scores.
Risk Tolerance Threshold
A key part of your risk management plan ought to be the
establishment of a "risk threshold". The threshold is an indicator of
the project sponsor's appetite for risk. Using the same scale used for
measuring probability and impact in the workshop will make your task easier. The
risk threshold is a PxI (probability times impact) score above which a risk
should be mitigated and below which a risk will be accepted without mitigation.
The next workshop phase will require the team to devisemitigation strategies to manage the risks they identified in phase I so in the
intervening time you need to compare the scored risks (PxI) against the project
risk threshold and identify those which will be accepted. Accepted risks will
not be analyzed by the team identifying mitigation strategies.
The Workshop (Phase II)
Now that you have your list of risks to be mitigated, it's
time to put the team back to work. Preserve the whiteboard or graph paper you
used in Phase I. This will be the bulletin board the team will post their
mitigation strategies to. The objective is to identify the most effective
mitigation strategies to deal with the risks to be managed. This is an exercise
that will lend itself to dividing the team up into groups with a limited number
of risks to analyze. The more time a group spends on each mitigation strategy,
the more effective the strategy is likely to be. Try dividing the risks up into
deliverables but make sure that each group contains a cross section of skill
sets so that the chances for innovative thinking are increased.
Have the groups write their proposed mitigation strategies
on different coloured sticky note paper. You will probably want to use a larger
size than for risk descriptions as the description of the strategy may be more
complex than that of the risk event. When each group has posted at least one
sticky note on each of their risks, have the groups examine their mitigation
strategies against the risks outside their assigned risks. Where a strategy can
be used to mitigate more than one risk, have the group copy the strategy onto
additional sticky notes and post these to the risks.
Review the strategies as they are being posted to ensure
your understanding. Get clarification where you are unsure of actions to be
taken or who will be responsible for the actions. Ask the group to identify
triggers where the strategy is a contingency plan.
Describe the next steps at the conclusion of your workshop.
Stakeholders who make a contribution to the project will be curious to know how
their contribution will be used and deserve to know that their time will not be
Now that you've gotten a base of possible risk events and
mitigation strategies, you'll need a place to store the information so that it
can be accessed and used to manage project risks. This will be a spreadsheet,
or workbook containing several spreadsheets, unless your organization has
invested in a database or other risk management software application. Make sure
that all the information produced at the workshop is captured, even those risks
which will not be mitigated.
You will need to assess the cost of the mitigation
strategies and determine whether they fit within the budget assigned to risk
management, or the overall project budget. Each mitigation strategy should be
accompanied by a mini business case which answers the question "does the
value of the risk reduction realized by the mitigation strategy exceed the cost
of implementing that strategy?" Mitigation strategies that have a good
business case should get implemented, those that don't may not.
Strategies that get implemented will be captured in the WBS
(Work Breakdown Structure) as the work is identified and broken down. This will
require the risk to be tracked in 2 places, the MS Project file and the Risk
Register. Risks should be reviewed periodically to ensure that mitigation
strategies are still effective, to identify new risks, and to identify obsolete
The Risk Workshop should also serve as a team building
exercise. To this end, make sure that team members are all introduced to one
another and that the group enjoys the exercise. You may want to engage an HR
representative in the workshop to handle the team building aspects. Although
this is not primarily a team building exercise, don't overlook the opportunity
to build the team.
You are ultimately responsible for managing risks to your
project so that it delivers on its promises. Using the collective knowledge of
your team should provide you with a solid base of information about risks. You
should not overlook risks that the team cannot see because they do not have
your overall view of the project. Add your own risks to the risk register. You
may be able to do this as a participant in the workshop if you are lucky enough
to have engaged a facilitator.
There are 2 significant risk scores: the PxI score before
mitigation and the PxI score after mitigation. The PxI score post mitigation
should be under the project's risk threshold. Measure these scores periodically
to determine if the strategy is still effective. Changing conditions around the
project will affect risk scores, both initial and residual, so you should
constantly monitor the risks in your register.
You should run your workshop at the conclusion of the
planning phase. At this point enough is known about the project work to
identify risks, yet the bulk of the budget is still to be spent. You can repeat
these workshops as often as you like during the course of the project, just
keep in mind that the workshops cost money and may impact on your teams ability
to deliver their work to schedule.
Risk Workshops certainly aren't for every project. For one
thing, the brain storming approach lends itself to projects where team members
are collocated so if you lead a project where resources are distributed over
the globe you probably shouldn't consider the workshop. The key objectives of
the workshop are to identify risks the project faces (or opportunities you
should take advantage of) and to identify effective mitigation strategies for
managing them. If you already have this information because your project is
similar to ones done by your organization in the past and you have a wealth of
historical information, or the information is available from another source
such as a trade organization, government, or society then don't waste the teams
valuable time going over old ground. If you think your project can benefit from
a Risk Workshop you will probably identify all the significant risks to the
project and have some fun along the way.