This article describes how a project team applied a grassroots risk management approach that achieved important business benefits. The term "risk clinic" is my term for a risk assessment and response planning session. I hope you will apply these ideas to your own projects.

The Investments Department of an insurance company uses its portfolio asset management system for the recording and maintenance of company and financial data. The system generates reports for internal decision and control purposes and for required reporting to external regulatory agencies. An upgrade project was underway to migrate to a new software platform.

Both the Investments Department and the IS organization became concerned as the project moved into implementation. The initial concerns included the following:

1. this was a mission-critical application for several important stakeholders,
2. the software vendor was discontinuing support,
3. hardware and software dependencies were involved,
4. the project team had performed little formal planning and had not communicated project status.

The project manager had previously participated in a risk assessment workshop, and asked me to facilitate a joint user-developer risk assessment. We used this four-step team process:

1. identify risks,
2. assess the risks,
3. develop risk responses,
4. implement risk responses.

(Note these steps align with the four Project Risk Management processes described in A Guide to the PMBOK.)

My goal was to engage those who know the project best - the project team - in a practical, straightforward, and proven process. The process requires that the team acknowledge and take responsibility for the success of their project; and do it in a proactive way that builds ownership and responsibility for the actions that lead to the outcomes.

In Steps 1 and 2, the project team identified and described over 40 risk items. After evaluating for probability and impact, the team determined that 32 of the 40 risk events were in the "high" or "medium high" category. Through a screening method, the team narrowed the list to a top 11, and then ranked them. Most identified risks involved resource issues and prioritization decisions.

Often teams act irresponsibly and stop at the end of step 2, using their list of risks as an excuse for poor performance: "See, we identified that risk, don't blame us." The team described in this case understood they were accountable for results and needed to craft strategies designed to overcome the obstacles.

In Step 3, I assisted the team in developing a risk response planning strategy using a set of one-page templates that helped the project team and rank responses, as well as identify owners for the risk events. The team answered these questions: How can I avoid the risk? How can I reduce the probability or impact of this event? How can I reduce the impact of this risk? If I accept the risk, what are the implications? This step helped them move from being victims of risk to masters of the outcomes of their project.

Step 4, implement the risk responses, included incorporating the risk response planning templates into other project documents. The work was scheduled for one day, but participants found it to be of great value and requested an additional session for additional risk response planning.

The team noted immediate benefits of enhanced communication and better teamwork:

Common language - It is essential to make sure that the team has commonly understood lexicon. Issues are different from risks. Mitigation is not the same thing as avoidance.

Common mental models - The approach surfaces assumptions and avoids hiding behind numbers or computer terminals. Most people are rational in their approach, but need help in understanding their mental models.

Sense of mutual dependence - The team realized their work is dependent on the work of others. They focused on integration instead of fragmentation.

Customer skepticism to advocacy - The customer entered the meeting somewhat suspicious and emerged as an advocate. She said, "I can go back to my department and report this project has identified and is managing its risks." She became a strong proponent of project management in her department.

The team's experience validated Edward Yourdon's advice that he wrote in his classic book, Deathmarch, "The key is to ensure that [the risk management approach] is one that will be understood, accepted, and followed by everyone on the project team - for it's the peons at the bottom of the hierarchy who are usually the first to see the emergence of new risks. The risks must be pounced on and attacked by the team as a whole to prevent them from getting out of control."

This risk clinic was a big success. As you lead your teams through the four-step project risk management process, focus on these principles.

Manage anxiety, and recognize the root causes - Many technical professionals by nature are not good at conflict for at least two reasons: conflict is not rational, and they typically get little training and practice in negotiation. Consequently, they tend to avoid discussing risk because risk analysis brings with it "bad news." Strong, knowledgeable facilitation is needed.

Have fun - I was surprised to find some toys (Wiffle balls, blasters) in the room, and we used them to stimulate creativity and to relieve tension.

Get the right people there - The team would have gotten even better understanding by including a key technical person.

The fact that projects fail and cause great organizational pain is not new. As we increasingly realize that project management is a process for decision making, we increase our chances of getting the outcomes we want. A good decision increases the probability of success and decreases the probability of failure.

Are you having a challenge getting project management recognized as a discipline within your organization? Try approaching it from the perspective of project risk management.