Posted on

Risk Management Plan Presentation

Dick Billows, PMP
Dick Billows, PMP

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

Posted on

Risk Tradeoffs

Dick Billows, PMP
Dick Billows, PMP

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


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


Posted on

3 Point Project Estimating: Padding, Accuracy, Commitment

Dick Billows, PMPEstimating is tricky for project managers with many conflicting pressures:

  • The customer or user wants the project done quickly and cheaply.
  • You, as PM, want to finish on time and within budget.
  • For commitment, the team needs to participate in a process their perceive as fair
  • The estimating technique should yield accurate numbers and some assessment of the accuracy.
  • Decision makers need information of the certainty of the project finishing on time

That list of requirements is a tough one for any project estimating process. The only process that meets all those requirements is 3-point estimating, which formerly called PERT (Program Evaluation and Review Technique). Project Estimating Main Page

Briefly, 3-point estimating has three-steps.  In each, the PM works closely with the people who will be doing the work. The first step is to discuss the deliverable the team member will be accountable for producing. This discussion includes the “good” risks that could cause this task to take less work and the “bad” risks that could cause it to take more work. Second, the PM notes these risks on the work package form that also contains the approach the team member will use. Third, the team member makes three estimates: an optimistic estimate, a pessimistic estimate and a best guess estimate. The PM applies the 3-point formulas (at the end of the article) to those three estimates to come up with the actual data that you will use in the project schedule.

Common Estimating & Risk Issues

Two mindsets often plague the estimating process:

  • Executives often believe that projects have no risks that affect duration or budget.
  • Team members think that padding their estimates will protect them from blame.

Both of these mindsets are false but they certainly get in the way of accurate estimating.

The 3-point estimating technique deals with both these mindsets. It gives PMs a data to communicate the risk of a work estimate. It also lets everyone stop pretending that task #135 is going to finish in precisely 15 days or that the project will absolutely finish by August 30.  Three-point estimating is a straightforward process for developing estimates using just a little bit of statistics. It gives you a tool to address the issue that most projects are launched with less than a 35 % chance of finishing by their promised due date.  Because no one talks about that issue, executives think the completion date is 100% guaranteed. It’s only missed when someone goofs off.

The best project managers have risk data for their sponsors.  They can document why a project has a 65% chance of finishing by August 30, as an example. These PMs also explain what they can do to increase those odds to 75% or 90% and what it will cost. Those same PMs manage the assignments of their project team members with an understanding that there is risk on each assignment. They use 3-point estimating techniques to get data on the risks.

Three Point Estimating in Detail

The 3-point estimating process starts with a discussion with the team member about the risks inherent in their assignment. You discuss the bad risks that will make their assignment take more work and duration (time). You also discuss the good risks that will cause it to take less work and duration (time). Why should you do this step? Because you need an estimating process that addresses the team member’s legitimate concern that bad things will happen on their assignment and they’ll be blamed for not meeting the completion date.  With agreement on the risks in the assignment and work package notes what you will do about them, you go on to the estimates work and duration.

As the name implies, 3-point estimating requires three estimates for each task. That sounds like it will take a lot of work but it takes a matter of minutes.  You and the team member develop an optimistic estimate, a pessimistic estimate and a best guess estimate for each task. By developing those three estimates, we get estimates that are more accurate from team members and assess the assignment’s degree of risk and the range of durations.

Padding Estimates

Before we go on, we need to talk a little bit about risk. When you ask me how long it will take to read this article, I might estimate five minutes. Am I guaranteeing you that no matter what happens I’ll be able to read the whole thing in five minutes? No, what I mean is that 5 minutes is my best guess. That means there is a 50% chance it will take me less than five minutes and a 50% chance it will take me more than five minutes.

However, if you were my project manager asking me for a task estimate, I would be a little hesitant about giving you an estimate in which there was a 50% chance of an overrun. What I would rather give you is an estimate where I’m 90% confident that I can finish in that amount of time or less. As the project manager, you would probably regard that estimate as padded. As the team member, I feel more comfortable with a 90% estimate. Unfortunately, there is no consistency in the amount of padding your team members will use.

Reducing Padding

You want your team members to leave the estimating process knowing that you considered the fact that things can go wrong on a task assignment. That’s why you identified risks at the beginning of the discussion and documented what you could do about the risks. With that recognition of the risks, we move on to gathering data on the impact those risks could have on the assignment. Using the three estimates enables you to do that. It’s better than having a team member give you a single estimate and play the padding game about how certain that estimate is. The three estimates tell you the variability in the task.

Best Guess, Optimistic and Pessimistic Estimates

Now let’s start the estimating process.  Your team member estimates that a task has a best guess estimate of 80 hours of work.  That means that 50% of the time it will take more work and 50% of the time it will take less.

Next, the optimistic work estimate is less work than the best guess.  The optimistic estimate is low enough that the team member thinks they can get the task done for less than the optimistic estimate only 20% of the time.  The task will require more work than the optimistic estimate 80% of the time.

The pessimistic estimate is more work than the best guess. It is not a “disaster” estimate but we want an estimate that’s based on the bad risks that we identified happening.  The pessimistic estimate is high enough that the team member thinks they can get the task done for less than the pessimistic estimate 80% of the time.  The task will require more work than the pessimistic estimate 20% of the time.

Now let’s dip our toe into the statistics and look at two tasks, Alpha and Beta, and the calculated work estimates we would use at three different level of confidence (* see formulas below).

What we did was take the three estimates and use some simple formulas to calculate the task’s work estimates and calculate the mean and standard deviation.  Using standard statistical tables (z-scores from a table of standardized normal deviates); we can take those means and standard deviations and use them to calculate levels of confidence of finishing within the estimate.  In other words, for task Alpha we could say that we have a 50% chance of completing the task with less than 54 hours of work.  For an 80% confidence level, we would calculate that 69 hours of work would be required.  This is the data to use with a client or project sponsor to quantify the cost of higher levels of certainty about a completion date. In the previous example with Alpha, we have to buy an additional 15 hours of work to move from 50% confidence to 80% confidence of getting the task done within the work estimate.  The beta is much less risky task than alpha. The mean work estimates are very close but the standard deviations are very different. To move from the 50% level of confidence that is 50 hours on task beta we would need to increase the work estimate to 51 hours. So for task beta higher levels of certainty a relatively inexpensive. Extending these calculations to the entire project is very easy with a spreadsheet such as the one we use in our classes. It gives project managers the ability to discuss the cost of higher levels of certainty. Sponsors always say they want to be 90% confident of finishing on time. When you present them with the cost of that level of certainty, it often is the case that lower levels of confidence would be acceptable.

Using 3-Point Estimates

All of the better project management software packages, such as Microsoft Project®, enable you to use 3-point (PERT) estimates and create a variety of reports that communicate the project’s risks. You can take estimates like those above and calculate the odds of finishing the entire project within various durations.  That information is a solid basis for a discussion with the sponsor about the tradeoffs between cost, scope, duration, risk and staffing levels.

To learn these 3-point estimating techniques and the entire estimating process, consider our private, online courses where you work individually with your instructor. They are available by phone, video conference or e-mail whenever you have a question or need help on an assignment. We can also deliver a customized training program at your site for up to 25 people. Call us at 303-596-0000 and speak to an instructor.

*Three point estimating Formulas

Mean= (4*bg)+OE+PE/6

SD= (PE-OE)/6

Probability level = work= Mean + (z-score for probability)*SD

Posted on

User Relationships

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.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”info” color=”#1e14a8″ border=”#940940″ window=”yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]

Posted on

How To Use Dynamic Project Scheduling

Dick Billows, PMP
Dick Billows, PMP

Dynamic project scheduling and the diagram of a predecessor network show us the sequence of tasks and let us design concurrent or parallel tasks. This can significantly shorten a project’s duration. Project Schedule & Software Main PageDynamic project Scheduling

Successful project managers use dynamic project scheduling because it saves them significant amounts of time and lets them quickly model the impact of changes to resources, work or cost. Dynamic scheduling automatically recalculates the duration and budget for the project every time you make a change in the resources, hourly rates, hours of work and predecessor relationships.

Dynamic Project Scheduling Tips

Many commercial scheduling software products allow for dynamic scheduling. But you must be aware of the critical elements required for the dynamic schedule to work.

Element number 1  –  your schedule must be based on the use of predecessor relationships between tasks, not the use of fixed start and finish dates. There are three primary kinds of predecessor relationships and the entire schedule must be built on these relationships. Predecessor Relationships

  • First is the finish-to-start predecessor relationship between tasks A and B. That tells the software that task B can’t start until task A has finished.
  • Second is the start-to-start predecessor relationship between tasks A and B. That tells the software that tasks A and B can start at the same time.
  • Third is the finish-to-finish predecessor relationship between tasks A and B. That tells the software that tasks A and B must finish on the same date, even though they may not start at the same time.

Element number 2  –  your schedule must be based on work durations that are calculated from resource availability and work estimates. You enter the amount of work and the resource’s availability, that is, how many hours a day each resource can work. As an example, say there is 80 hours of work for a team member who works on the project half-time, or four hours a day. The software calculates the task duration as 25 working days because the half-time team member can only complete four hours of work a day.

Dynamic Scheduling to Control the Task Sequence

You use dynamic scheduling with predecessor relationships to control the sequencing of the tasks in your project plan. As an example, you may specify a finish-to-finish predecessor relationship. That tells the project management software that you want to schedule two tasks and their resources so both tasks finish at the same time. When you are finished specifying all our predecessor relationships, your project plan becomes a network of tasks, linked by the predecessor relationships. The result is often called a PERT (Program Evaluation and Review Technique) chart. It displays your project plan and its network of tasks.

Each of the task bars is linked to the project network which allows our dynamic scheduling to control the sequencing of tasks based on the predecessor relationships and the amount of work in the task.

Get free articles and videos like this every week