Risk Workshops

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.

Brainstorming

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 location.

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:

1. 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.
2. 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.
3. "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.
4. 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.

Preparation

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 your project.

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 expectations.
• A prioritized list of risks based on the probability of the risk event happening and the impact to the project if it does happen.
• 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:

1. Risk identification and grouping
2. Risk evaluation or prioritization
3. 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.

Facilitators

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 should include:

• No criticism of another's ideas
• Each participant must produce at least one risk event description
• 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 wasted.

Next Steps

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 risks.

Wrap-up

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.