Wednesday, June 28, 2006

A Simple Pair of Risk Metrics

I was sitting in a project review today and watched the project leader skip over the risk section of the presentation. He had left it blank. We recently changed our project tracking process. In the old system, there was a complicated formula for assigning a risk number to each project. When the advocate of that system left the company, so did all interest in continuing the cumbersome calculation. Instead we were left with a blank spot in the presentation.

Obviously, it's bad form to not show risks in a project review. Unfortunately, "high," "medium," and "low" don't seem to communicate much. In thinking about what to fill the blank spot with, I came up with the idea of measuring two simple, but meaningful project parameters:

Schedule Variability
The time difference between the first possible project completion date and a reasonably highly likely completion date. That variability is an indication of how many things could go wrong on the project.
Schedule Aggressiveness
A measure of how close you set your planned completion date to the earliest possible completion date instead of the more comfortable highly likely completion date.

The figure below shows a typical distribution of probable project end dates. There is no possibility of finishing on any of the early dates of the project, until you reach the very low probability of finishing on the earliest completion date. Then the likelihood of finishing on various dates goes up sharply. Finally, the probability declines to nearly zero. It goes on forever with some small probability because there is a chance with any project that it will never finish.

I've marked a couple of key points in the figure. The first point is the earliest completion date. The math savvy will recognize that the probability of hitting this date is vanishing close to zero. The second point comes at the peak of the curve. It is the date that the project is most likely to complete on. The next key date is what I'll call the "over/under date." It's the date at which the project is just as likely to finish before as after: That is, the 50% point.

It is important for budding project managers to realize that the over/under date is later than the most likely completion date. Put another way, projects complete successfully on the most likely completion date less than half the time. Experienced project managers realize this, but may think it's because people are bad at estimating the most likely completion date.

The next key point is a comfortable delivery date. It can't be at 100% confidence, because that date doesn't exist, so I backed it off to 90% likelihood. People set their schedule commitment date somewhere in this range. It actually doesn't matter too much where, so long as they are clear where they set the date.

Another clue for budding project managers: When someone gives you a date commitment, ask them what they mean by that date. Are they telling you the earliest date they can finish, the most likely date they will finish, or the conservative (highly-likely) date they will finish on?

Wrapping up the risk metrics. The first risk metric is the schedule variability. Measure it by taking the difference in calendar days between the earliest possible completion date and the 90% likely completion date. Over time, as you get closer to the end of the project, the variability-days should go down. This happens because the earliest date slips out as problems occur and because you gain more project knowledge.

The second risk metric is the schedule aggressiveness. Calculate it by taking the difference between the planned completion date and the 90% completion date then divide that by the schedule variability. 100% aggressiveness means you have scheduled to complete on the earliest completion date: yeah, right. 0% aggressiveness means you plan to complete the project at the most comfortable point.

Take a baseline at the beginning of the project, then recheck the metric with any updated delivery plans at each project checkpoint. This should be a simple way of describing the risk in your project schedules and showing you how you are managing against it.

Tuesday, June 20, 2006

Presenting without PowerPoint

I've been experimenting with giving presentations without slides for a while now. I did so again today. Coincidentally, today I also visited the AYE Wiki, WhyWeDoNotUsePowerPoint.

People always seem a bit confused when you don't hook up your laptop for a slide show. They look at you like you came unprepared. Don't fret it much; if you are prepared it will be clear by the end of the presentation.

It's worth questioning your motives in using PowerPoint slides. After all, the three most practiced types of public speakers almost never use slides: Politicians, preachers and teachers. I try to learn by watching them.

Slides do have value. They certainly make excellent handouts to take notes on. They appeal to the visual learners in your audience, augmenting your spoken word. They can also be an effective way to show detailed information like charts or even pictures, although, you could just hold up a large chart or picture. That's what politicians do.

On the other hand, you shouldn't use slides as a script or a memory aid. People get bored watching your read a slide set. Nor should you use them as proof that you have properly prepared. Everyone will know if you prepared by your content and delivery. Finally, you shouldn't use them as an aid to soothing stage-fright. It's much more effective to prepare better. Use a podium instead if you must (but that's another posting).

I find when I present without slides I get a much better connection with the audience. I can tell what's working and adjust as needed. It helps me to focus on the goals of my presentation, and tailor the delivery to meet those goals rather than fit the confines of PowerPoint. People seem to like it.

While it's not for every presentation, I'd challenge you to give it a try.