Risk Management Plan Presentation

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

Regardless of the size of your project and the risk management effort, you always have to present the risk management plan. You need to put yourself in the mind of your audience. The audience at your presentation will often be hostile, in the sense that they don’t believe spending money and time on risk management improves the odds of completing the project on time and within budget. So you should assume they see risk management as a waste of time and money.  Risk Management Main Page

As a result, you don’t start the risk management presentation by burying your audience in the list of 63 negative risks that could adversely affect the project and 27 positive risks that could let you finish earlier and spend less money. You also do not present the results of either qualitative or quantitative risk analysis, no matter how proud you are of them.  That type of presentation will only convince your audience that you have wasted a lot of their time and money.

Risk Management Plan Presentation – How To Do It

In the first 60 seconds of your presentation, you need to acquaint your audience with one or two very significant risks and the impact those risks could have on the project. Let’s take a simple project and see how you might start the presentation.

“Good afternoon. I’m here to talk with you about our supply room project which has a goal to reduce the number of complaints about the supply room. Last year, we averaged 53 complaints per month. Our goal is to reduce it to less than 3 per month. The major deliverables that will lead to achieving that scope are:

First, that 95% of the time employees can find the supplies they want in less than 60 seconds.

And second, that we have fewer than 3 items each month that are out of stock.risk management plan presentation

We see two problems that could make it difficult or impossible for us to deliver that scope. The first problem is that the people who stock the supply room will not keep up the new, more efficient design which we will produce during the course of the project. That would create the same mess we have today. To avoid that problem, we would like to add a performance criteria to their job descriptions and annual performance reviews. It will require maintaining the supply room design by restocking supplies in the specified locations.

The second problem is that employees will not know where to look for the supplies they need. They will complain about the new design, perhaps more often than the current complaint rate. To avoid that problem, our design will place the most frequently needed supplies (those that account for 80% of the withdrawals) near the supply room entry. We would also like to print and distribute a supply room crib sheet with a map to all employees. We will also have a large-scale copy of the crib sheet and map on the supply room door.

If you approve these proposed solutions, I believe we can completely avoid both problems.

Taking this very direct approach to presenting your risk management plan is almost always more successful than a presentation that drowns the audience in data or complex statistics. Instead of all the numbers, you discuss the problems, the consequences and your remedy. Plus you do it in a just few minutes.

If you want to enhance your presentation skills, consider our online Presentation and Negotiation Skills course.  You work individually with your instructor who coaches you with techniques for improving the content and media of your presentations as well as your speech and body language.

Get free articles and videos like this every week

Risk Tradeoffs

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

Executives do not like project managers to mention risk (or planning for it) because they prefer to think the project manager can execute the project without any uncertainty. They also don’t want to pay any price for risk planning. However, it is a real impossible mission not to consider the risk tradeoffs on your project. The project manager’s mission is to use their risk management plan, including risk tradeoffs, to convince executives of the benefits of planning for risks. Risk Management Main Page

One of the project manager’s accountabilities is to spread the project management culture in the organization. And risk tradeoffs are part of that effort. First the PM should identify the potential positive or negative risks that might occur. Second, the PM should specify the level of risk – low, medium, or high. These should be based on the PM Office criteria, if they are available. If not, the PM should specify these criteria in their risk management plan. The possibility of a risk occurring should be shown as a percentage. The value of the risk might be estimated as hours or dollars and should also be included in the plan. Let’s look at two examples of risk categories below. Risk Responses

Risk\Duration Category

mohtable1

There should be a plan for responding to the risk once it occurs. For example, executives might accept increasing the project duration by 148 hours. Or they might want a different response plan such as increasing the project cost or lowering the project scope.  Small Project Risk Management

mohtable2In the example above, the PM is showing the executives the list of positive and negative risks and their impact on the project. The project manager is asking for approval to add $7,000 to the project cost to mitigate the uncertainty.
Once the PM provides executives with all the risk possibilities, their impacts, and suggested responses, the executives often accept the PM’s plan. On the other hand, they may discuss additional ideas for the PM to analyze.  Presenting Your Risk Plan

You can learn how to analyze and manage project risks in our online Project Management Tools course. You work individually with your instructor and get personal coaching at your convenience.

Get free articles and videos like this every week

 

User Management

User Relationships with Mistrust, Doubt and Fear Drain Your Team’s Energy and Creativity

By now, l’ve learned one thing for sure. Project management does not give a receipt of guaranteed success. It takes effort to manage people, align their goals and focus their efforts to achieve a common objective. People User Relationshipsare susceptible to moods, interests, biology, hormones, cultures, economics, weather, and even the moon. For this reasons the difference between success and failure is often much more subtle than executing with perfection some steps. Stakeholders Main Page

This first post, actually the first of a series, will start with one factor I have seen strongly influencing the final result; users. My experience is mainly in technology-related projects, new systems, integrations, etc. In all these projects, as much as I can remember, the top critical factor has always been managing user expectations.

The User Relationship Situation

On one case, we had a relatively large project being executed in a week matrix organization. It was related to a new system and I was part of the steering committee. The initiation phase was behind us and there was a board decision to go on with planning. The team had already worked together in the past. There had been some conflicts as well; conflicts related to a feature that the users reported as a bug but from the technical team, it was treated as new request. There were big discussions that produced very little value. In the end, the feature was developed but it left some bad blood among the team members.

The heavy mood was immediately visible during the requirements collection phase. Meetings resembled court rooms. On one side, business users were laying down requirements to be as broad, interpretable and as inclusive as possible. On the other side, architects and business analysts were asking details to a ridiculous level. The drama went on without an agreement. It burned all the time of the tasks, including any duration buffers we had. Suggestions were looked upon with doubt resulting in tiring and exhaustive sessions with no end in sight. If this was the requirements collection phase, we could only imagine what the situation would be during testing and acceptance.

So how do you work around such a situation when every sign, and your guts, are telling that this is headed toward a disaster? We tried two measures before getting to the radical step of changing some project team members. I always make all possible efforts to avoid changing team members. Changing team members often creates more damage than benefits. Especially if you work in an organization and you have to work again with these people.

The User Realtionship Solution

First we clearly stated, “Huston, we have a problem” and openly told the team that this was not working out. Their “cover my back” attitude and reluctance to take ownership and responsibility was jeopardizing the project. With the most problematic team members, we conducted one-to-one meetings to listen to their thoughts on how to move on and leave the past in the past.

Second, we had the team spend more time together during the day and at least once a week we gathered just for a drink. We went to the line managers and asked for dedicated project days. This prevented the people working on the project from switching among project and non-project tasks within the same day We were aiming for focus.

In the end it went fine, not great, just fine. We managed to finish within budget and scope, with some deviation from the time line. I would say we dodged a big risk.

The lesson learned was simple; resolve the conflicts or avoid them, as nobody wins endless conflict. Even if you gain some ground in the short term and the power balance is on your but in the end you pay it back and very often with interest. The best result is to see a considerable change in the attitude of the team.

It is so much easier to work in an environment of trust. Doubts and fears drain your energy and creativity. It is your choice where to invest your finite energies. You do something great with your users, or waste those energies going on the attack.

You learn all of those skills in our project management basics courses. Take a look at the basics course in your specialty.