How to Create an Ideal Environment to Implement Risk Responses

A team conditioned to the inevitability of project risk is prepared to handle project riskKnowing is not doing. Planning risk response is not implementing risk response.

It seems that I’ve written more about project risk than about any other project management topic:

Maybe the number of articles is indicative of how we as Project Managers typically manage risk on our projects – we write about risk and we talk about risk; yet we seldom take the time to implement the risk responses that will stave off the negative consequences of unintended risk. We let risk events simmer as we go about the harried life of day-to-day task execution, and then express surprise when risk events materialize.

In my own experience, we were the most successful in implementing risk responses when we had conditioned the project teams to be fully prepared to handle risk events even before they began to surface. Nothing magic here – just common sense borne of experience. Being proactive rather than reactive. Not putting the plan on a shelf, but reviewing it often. Where process taught us to plan risk response, focusing on the people aspects of project delivery taught us how to implement risk response successfully.

Project Managers can prepare their project environments to handle any risk event quickly and efficiently with minimal disruption to the project. The following characteristics of such project environments are tried and true methods that lead to successfully handling project risks:

  • Establish executive support. IT vendor and client executives alike are not typically involved in projects on a daily basis. However, the executives need to be aware that they may be called upon at any time to help manage project risk. This establishes urgency within the executive team, and gives the project team confidence that the executives have their backs.

    Typical situations in which executives can be called upon to remove obstacles are with regard to funding decisions, freeing up resources for the project, negotiating contracts, and other such actions that are outside the purview of the Project Manager.

  • Maintain excellent documentation. Keeping the risk register current at all times, including initial response plans at the risk event level, helps focus attention on identified risks at all time. Documentation that is out of date or incomplete diminishes the team’s ability to rapidly respond to risk events.

    Similarly, lessons learned documents from past projects or from the current project are invaluable when determining how to (or how not to) manage an emerging risk event. Additionally, the project assumptions log is a quick reminder for why certain decisions were made and whether or not they can contribute to managing the risk event.

  • Be vigilant. It often happens that in the process of implementing a risk response plan, the team becomes less alert to the possibility of new risks. Risk identification and risk response are overlapping activities, and both must be managed simultaneously for the duration of the project.
  • Keep subject matter experts on speed dial. Risk events can materialize at any moment. During the planning process, an experienced Project Manager will identify those areas in which risk is more likely, and for which he or she will need expert help.
  • For example, when implementing a system in a new technology (whether the technology itself is new or it is new to the team), an experienced Project Manager will have immediate access to expert technicians who are ready and able to assist with any technology issues.

    Similarly, on the client side, staff with certain expertise may not be part of the project team, but should be at the ready to assist in functional areas that are not well understood by the client representatives who are on the team fulltime.

  • Involve team members. In keeping with the emphasis on the people aspects of project management, an experienced Project Manager would have already involved members of his or her team and client staff in developing the risk management/risk response plans. During project execution, those same team members are in the best position to help implement the risk responses when risks materialize.

    For example, major changes in functionality are often requested after the system requirements have been approved and signed-off. It is probable that a change request will be required. The subject matter experts from both the IT provider and the client who were most cognizant of this risk occurring are the best choice to quickly develop the change strategy.

  • Monitor implementation of risk responses. As risk events materialize and owners are assigned to manage them, frequent reporting on the status of the risk response is required. All project team members and risk owners outside of the project team must be part of the project culture that requires accountability in handling risk events as quickly and efficiently as possible.
  • Develop flexibility within the project team. While budgets and schedules may be fixed, the project team should have ample leeway within the fixed project constraints to do their jobs as they see fit. Too much rigidity stifles creative approaches and solutions. Allowing creativity and flexibility in daily tasks (while maintaining best practices and adhering to project standards) creates an atmosphere that is more responsive to handling risk events in a creative and flexible way as well. In actuality, a team that understands the project risks that have been identified will often creatively eliminate them from ever occurring in the first place.
  • Foster communication and collaboration across the team. The team that communicates well up and down the organization and across the teams is well on its way to being able to handle any risk event that may arise. Teams that continuously communicate respond quickly to any risk events that materialize.

    Collaboration is as important as communication. By developing a collaborative atmosphere from the outset of the project, and communicating the importance of risk management before any risks even occur, the project is better prepared to manage risk events.

  • Develop a culture of problem-solving. It’s been my experience that some project teams sit back and wait for instructions. Not only are they frustrating to work with, but their approach to pivoting with the changes thrown at them by risk events is one of sit back and watch it happen. These teams are seldom successful.

    Other teams are self-managing and push themselves to perform well. These self-directed teams are eager to utilize their problem-solving abilities. They know that project risk events are inevitable and are challenged to tackle the risk expeditiously and creatively, with minimal disruption to the project.

  • Instill an attitude of expectation. As noted, project risk events are inevitable. The IT and client teams must be prepared to expect this probability and not panic when they occur. That’s why the project team planned risk management in the first place. When a risk event occurs, the teams must methodically analyze the situation and decide on the best course of action.

Regardless of the situation, there really are only five ways to respond to any risk event that occurs:

  1. escalate it to senior level staff,
  2. avoid or eliminate it by removing the reason it happened in the first place,
  3. transfer it to its rightful owner outside the project,
  4. mitigate it according to the creative strategies of the team responsible, or
  5. accept it and apply the contingency set aside for it.

Having a project environment in place to expect risk events and to deal with them efficiently goes a long way to managing the risk while minimizing the disruption to the project.

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.