Team-based risk assessment
Turning Naysayers and Saboteurs Into Supporters
by Paula Martin and Karen Tate, PMP
HAVEYOU EVER HAD any of the following problems?
A glitch arises with the project and someone comes to you and says, “I could have told you that would happen, if you had bothered to ask.”
You develop a list of potential risks, but you can’t get agreement from the sponsor or the team that these are the key risks for the project.
People outside the project team seem to be working hard at sabotaging the project.
Your project fails and someone tells you, “That project was doomed from the beginning.”
If you want to avoid these problems, you need to get the naysayers and saboteurs involved in the risk assessment process right from the beginning. By participating, they contribute all of their negativity where it can be most productive—in identifying the risks that the project will face and then identifying ways to counteract those risks. They are forced to come up with solutions for the problems that they are sure plague your project. The ownership they feel for these problems then becomes transformed into ownership of solutions. Potential enemies become potential supporters.
Although everyone seems to know that participation creates ownership and thus buy-in, participation has not been universally applied to the management of projects. One place to start is with the risk assessment activity. In order to foster team participation, we need to use team-based, visual tools—tools that allow information to be viewed and manipulated by everyone on the team. The risk analysis tool that we use is a variation on the Process Decision Program Chart (PDPC). It allows everyone to participate in identifying the risks and countermeasures that will reduce the project risk.
Risk assessment is an important part of project planning. When we evaluate risk, we assess what could go wrong and then determine what we can do to prevent those potential problems from occurring.
There are two basic types of risk: scope risk and resource risk. Scope risk is the risk that the team will not be able to physically produce the project's deliverables: that they won't have the know-how, skills, technology, or information to produce the final deliverable according to the customer's acceptance criteria. This is also known as technical risk. Resource risk is the risk that the team won't be able to produce the deliverables on time, or within the staffing and spending limits prescribed by the sponsor. Scope and resource risks can be assessed together or separately.
Exhibit 1. Place Post-it Notes on banner paper with the project name at the top and the names of every project deliverable underneath.
Exhibit 2. For each risk identified, write the risk on a Post-it Note. Leave space at the bottom of the Note for the impact, probability and risk total. Place each Risk Note under the appropriate Deliverable Note on your banner paper.
We're going to walk you through the steps of doing a participative risk analysis for scope risk.
Assemble the Team. Make sure that your team represents all the key stakeholders in the project. A stakeholder is anyone or any group that will be affected by the project. Stakeholders include customers, key suppliers, functional groups that will perform project work, any group that will be affected by the results of the project, and any group that can affect your results. Also, invite any experts you might need to help you assess the technical risks of the project.
Review the Scope Description. The team must first be clear about what deliverables they are going to produce. Compile a complete description of each deliverable (including features, functions, and success criteria) and make sure that everyone involved in the risk analysis activity has read and understands the scope description.
Tape Banner Paper to the Wall. Cut a large piece of banner paper, at least 4 ft. high and 6–10 ft. wide, and tape it to the wall. (You can also tape pages of flip chart paper together.) This is the working space for the risk chart that the team will develop.
Add the Names of the Deliverables to the Chart. Write the project name on the top of the chart. Then create a Post-it Note for each of the project deliverables. Place them in a row underneath the project name. Connect the Notes to each other and to the project name (so it looks like an organizational chart, as in Exhibit 1.)
For Each Deliverable, Brainstorm Possible Risks. Ask the question, “What could go wrong?” Write every risk idea on the top half of a Post-it Note (a different color than the deliverables) and place it on the banner paper under the appropriate deliverable. Remind the team of the rules of brainstorming: all ideas are good ideas, no judgment, the more ideas the better. Don't worry if a risk seems insignificant or highly unlikely; you will deal with those issues later. Leave space at the bottom of the Note for risk ratings. When the brainstorming exercise has been completed, weed out duplicates and “ridiculous” risks.
There are three categories of scope risk:
Supply risk. This is the risk that a supplier will not supply what you need, according to your specifications or requirements. Identify only supplies that are at risk. For example, in a project to develop community leaders, one supplier risk was the risk of not finding qualified people to do community-based leadership training.
Unknowns/potential problems. For scope risk, these are the technical risks of not producing the deliverable according to the success criteria. One technical problem the community leader project faced was that each leader candidate had different training needs.
Risky assumptions. This is the risk that your assumptions may not be correct. Do not list every assumption, just those that might be wrong. For example, one of the community leader assumptions was that two weeks of leadership training would be sufficient to develop the skills required to satisfy the requirements of the grant.
Evaluate the Impact of Each Risk. If the identified risk were to occur, what impact would it have on the team's ability to produce the deliverable? Use a 1 to 10 scale with 1 to 3 being a low impact, 4 to 7 being a medium impact, and 8 to 10 being high. (Optional: Quantify the impact of the risk instead of using the 1–10 scale.) Write the impact number on the lower left-hand corner of the Post-it Note (as in Exhibit 2.)
Evaluate the Probability of Each Risk Occurring. For each risk, evaluate the probability that the risk will occur. Use the 1 to 10 scale, with 1–3 being a low probability, 4–7 medium probability, and 8–10 being high. Write the probability rating in the lower right-hand corner of the Note (as in Exhibit 2.) (Optional: Gather and analyze data to use as the basis of the probability rating.) Record the reasons for the impact and probability ratings on a separate chart.
Exhibit 3. After the team identifies the risks, have them brainstorm countermeasures for preventing or responding to the risks. Write each countermeasure on a Post-it Note and place it underneath the appropriate risk.
Exhibit 4. Transfer the risk and countermeasure information from the wall to a risk table. This will help you document and communicate the risk assessment for your project.
Calculate a Risk Total for Each Risk and Realign the Post-it Notes From Highest to Lowest Risk. First multiply the impact rating and the probability rating to get a risk total. Write the result on the bottom of the Post-it Note (as in Exhibit 2.) Then rearrange the Notes so that the highest risk numbers are on the left and the lowest are on the right.
Review the Risks and Assign a Risk Rating for Each Deliverable. Use the 1–10 scale for the deliverable risk rating. A rating of 1 to 3 indicates there is little risk that the team will not be able to produce the deliverable. A 4 to 7 rating indicates a medium risk, and 8 to 10 indicates a high risk.
Compare the Risk Rating to the Risk Limit Set by the Sponsor. Is the risk of producing the deliverable too high? If so, you'll need to develop countermeasures to reduce the risk. If the sponsor has not given the team a limit for risk, develop countermeasures for any deliverables that have a medium or high risk rating (4 or above).
For Each Deliverable With an Unacceptable Level of Risk, Brainstorm Countermeasures. If you have a lot of risks that will require countermeasures, start with those that have the highest risk numbers and the highest impact numbers (regardless of probability). Have each person write his or her ideas for countermeasure on the top half of a Post-it Note. (Use a different color than you used for the risks.) Place the countermeasure Notes underneath the risk that they apply to. Draw lines to connect the countermeasures to the corresponding risks (as in Exhibit 3.) After the individual ideas have been exhausted, have the group brainstorm more ideas to add to the chart.
The Benefits of Team Participation
■ The team members understand the reasons behind the risk plan.
■ More potential risks are identified.
■ More ideas for countermeasures are generated.
■ More expertise is available to analyze risk and countermeasures.
■ Team members buy into the completed risk plan.
Tips for Holding a Successful Risk Meeting
■ Make sure you have all the stakeholders represented.
■ Make sure you have the technical expertise you need.
■ Don’t let people debate ideas. Write each idea down and move on. The process will weed out ideas that don’t fit.
■ If you don’t think enough risks (or countermeasures) have been identified, ask the team for “just 10 more ideas.”
■ Act as a facilitator, not a judge. Your job is to keep the process on track, not solve the risk issues.
■ Don’t rush the process. If you need to, hold more than one session of 1–2 hours each. Let people “sleep on” what’s been accomplished thus far.
■ If the project is large and complex, break the risk analysis down into subgroups and let each subgroup work through the steps of the process. However, get them back together to compile results after they have identified the risks and when they have preliminarily selected the countermeasures.
Reader Service Number 5068
Make Sure You've Covered All Feasible Countermeasures. Review your risk chart. Have you covered all possible risks? Have you listed every reasonable countermeasure? You might want to review the chart with others outside the team. Get their inputs and ideas. Make sure you’ve covered everything.
Select Countermeasures That are Consistent With the Project Priorities and That Bring the Risk Down to the Risk Limit. Project priorities determine how the trade-offs should be made between scope (adding more functions and features), schedule (completing the project ahead of schedule), and cost (come in under budget). For example, is it more important to add more features to a deliverable or to complete the project early? Is it more important to finish your project early or to spend less money? The sponsor should set the priorities for your project. If they have not been set, ask the sponsor to clarify the priorities for you and then judge the countermeasures against the priorities. For example, if schedule is the No. 1 priority, then countermeasures that will cost more but not delay the project would take precedence over those that would not cost as much but would take more time. Select countermeasures (write an “O” or place a dot on the countermeasures selected) that will bring the risk rating down to the limit set by the sponsor, or if no risk limit was set, down to a low risk level (3 or less). Countermeasures that do not lengthen the schedule, or cost more money, or adversely impact the scope should be added regardless of the risk rating. And, all things being equal, preventive countermeasures are usually better than reactive ones.
Assign Each Countermeasure to Someone on the Team. On the countermeasure Post-it Note write the name of the person who will be accountable to make sure the countermeasure is accomplished.
Include the Selected Countermeasures in the Project Plan. Countermeasures must be included in the schedule, staffing estimate and spending estimate, as appropriate.
Convert the information on the Chart Into a Risk Table. Distribute the risk chart to all team members and key stakeholders and review it regularly. Add new risks as they are identified, eliminate risks that no longer apply (as illustrated by Exhibit 4).
THESE STEPS FOR assessing risk can be used for any type of project: simple or complex, small or large. Leading the team through the steps builds understanding of what the potential problems might be and agreement about how the team will prevent them from occurring.
Of course not every problem can be prevented. Therefore, during the execution phase of your project, constantly monitor the environment for new problems that might be lurking around the next corner. Include a risk review on your team meeting and sponsor/customer review meeting agendas. Check back with those prior naysayers and saboteurs. They may have some more potential problems for you. And don't forget to give them lots of positive feedback and recognition. They'll become supporters not only for this project but also for every project you lead in the future. ■
Paula Martin and Karen Tate are co-founders of Martin-Tate, a project management training and consulting firm specializing in team-based project management. They are also the authors of the Project Management Memory Jogger. They can be reached at 513/984-8150 or 908/806-3974 or www.projectresults.com.
PM Network • February 1998