Many trainers have probably spent at least one all-nighter in a hotel room, as our team recently did, scrambling to put a complex instructor-led training program back on track.
We had previously discovered that wireless access to the custom enterprise application was not provided, making it impossible for us to deliver the courses in the hotel training rooms we had booked. Training was supposed to start in a few hours, with hundreds of learners scheduled to arrive at the hotel.
The likelihood of this IT risk existed from the beginning. Risk management, the process of assessing, mitigating, and monitoring risks, would have helped project managers prepare for what unfolded, hours before the courses were to begin.
A lack of risk management can mean that potential risk goes unnoticed. An unnoticed risk can take a project by surprise and cause disastrous results, especially if it affects more than one area of the project. But the term "risk management" sounds like something that only high-level project managers and sponsors face.
Not so.
In a perfect world, every team member owns risk management. When the instructional designer serves as project manager, courseware developer, trainer, and graphics designer, it becomes even more important for that team of one to plan for risks, as there is a chance that no one else in the organization is doing so.
Cover all bases
Imagining what the learning environment will look like and what participants will need is a crucial first step to mitigating risk. An instructional design team built a computer-based training course for learners in the manufacturing field. In the rush to complete the design and development of the course, the team failed to notice that the course included audio, yet the learners' machines had no audio cards.
A risk checklist, which could have included "adequate hardware available for computers," would have reminded the project team to question the needs analysis data and confirm that audio cards were available on learners' machines.
Consider another scenario. A vendor spent months building a training solution for a client. The vendor knew that the client considered the look and feel of the training materials to be just as important as the content. The vendor also knew that the client's corporate identity team had a reputation for firing vendors who failed to meet presentation standards.
Though they were aware of this risk, the vendor's strategy was to work hard on the visual design of the training materials. Unfortunately, they never formulated a plan for what to do if the client didn't like the presentation. As it happened, the client didn't like the vendor's work, and the project was thrown into turmoil when the client threatened to fire the vendor. Eventually, the vendor and the client struggled to reach a compromise.
Every member of the vendor's team knew that getting fired was a distinct possibility, but no one wanted to state the obvious, fearing that they'd be branded as a naysayer. It's the job of the project manager, sponsor, and team leader to publicize to encourage risk discussions in the project team as a way to ensure success. In fact, by seeing a risk and not saying anything, a team member endangers the project.
Teams need to be aware that this type of discussion requires a culture shift and could take time. Although some team members might have strong opinions about a particular project risk, they might feel constrained by the culture of the organization to stay quiet. Project leaders need to be sensitive to this.
Talk about it
How can learning professionals anticipate such pitfalls and map out an alternative? Primarily, don't treat risk like a four-letter word. Make risk conversations part of project planning and create a place for them in design documents, status reports, agendas, and recommendations.
In large projects, include risk in executive dashboard reports to reassure executives that the team has a handle on potential problems. Encourage every team member, especially the quiet ones, to contribute to discussions about risk. Leverage the diverse experiences that team members bring to the table. For example, experienced team members who are aware of risks associated with various clients can offer valuable information to help the team anticipate problems before they arise.
When Rod Dunican, a Berkeley, California - based executive coach, trainer, and speaker, manages a project, he discusses his thoughts on risk management with his client before work begins.
"I always explain to the client that risk discussions are productive ways to keep a project on track," Dunican says. "I need the cooperation of the client to ensure that the entire project team is encouraged to freely share their concerns about risk."
In some corporate cultures, people hesitate to discuss risk because they fear that the discussion implies that someone on the team has made a mistake. In fact, some project managers are so averse to the topic of risk that they perform a strengths, weaknesses, opportunities, threats (SWOT) analysis, avoiding even the mere mention of the word risk.
It's important to remember that risks are issues that haven't occurred, so nobody should be implicated if the group discusses them. Project leaders need to make it clear to their teams that risk discussions don't imply failure. Rather, they are productive discussions that can help avoid failure. Another option is to create a way to collect anonymous feedback from project team members. This information can be helpful if the organizational culture simply does not allow team members to speak freely.
What can project leaders do to facilitate the culture shift? Brainstorming at project kickoff meetings can help team members think about risk in strategic terms. Provide team members with a list of the most typical risks that your organization encounters. Ask them if they think any of these risks, or others, could apply to the project.
Track the topics and ideas that come out of this brainstorming session Then, for each risk, ask team members to speculate about the likelihood and consequence of the risk on a scale from 1 (low) to 10 (high).
Brainstorm with the team about how to handle major risks. Options include
- reporting status on potential risk at weekly meetings
- transferring the risk, which would have made sense in our first scenario, in which IT should have been tracking the risk of wireless access not being available
- avoiding the risk, which, in our first scenario, could have meant not planning to use the wireless access for training delivery
- reducing the negative effect of the risk, which might entail putting a plan B in place so that, if the risk is realized, the consequence is not so dire
- accepting the consequences of the risk, which might have financial implications that you'll need to budget for, such as late fees.
Build a risk register
For companies that routinely encounter the same types of issues, an automated approach to risk management can help avoid costly problems. On large projects, some teams build a risk register - a database where teams list and track every risk as it surfaces.
The teams then regularly review the risk register. This approach might seem like overkill for your project. In that case, you might assign responsibility for each high-level risk to an individual who can monitor the status. This way, you avoid surprises without adding extra tracking work.
To conclude, risk management is an activity that teams generally want project managers to handle. However, risk management is most effective when teams work with project managers to identify trouble spots and prevent catastrophic surprises. Teams that focus on project risks and openly discuss them prevent risks from becoming realities, or lessen the impact.
In either case, a strong approach to risk management means that you'll be sleeping at 2 a.m., not rescuing projects from disaster.