Is Your Schedule Based on a Guess or an Estimate?

Clearcut Ideals and Messy Realities
Ever work with Microsoft Project? Ever spend hours and hours—or rather days and weeks—gathering project requirements and schedule projections from team members ("how many days do you think your part of the project will take? OK, we'll say three"), so you can generate draft after draft of Gantt charts and timelines, leading up to the official copy that you present to management, then print out—page after page of solid lines presented in a staggered order like a vast, irregular staircase—and tape up on the wall of your office?

If you've ever worked on a project plan like that, you may find yourself holding your breath now, because you know, in the pit of your stomach, that the process I've just described is only the beginning. It's only the beginning, because inevitably, important aspects of the project change. Some tasks finish late; others finish early; others disappear from the schedule entirely, while new ones, unimagined in the planning stages, miraculously appear. If you're lucky—and a lot of people are—the team will manage to complete the project—or some semblance of it—overall.

When the project is finished and you look back at all those charts you printed out and taped do your wall, how do you feel? Don't those solid lines and neat demarcations—progressing across the page with the neat precision of a well drilled marching band—now look hopelessly optimistic—like the budget projections of a politician or the crop forecasts in a Soviet five-year plan? I mean, how could anything as random as a bunch of human beings working on complex project ever proceed in such a neat manner, with such precision?

But what's your alternative? You can't afford to be vague when you're scheduling a project, can you? And you do have to produce some kind of schedule or plan. And whether you use Microsoft Project or some other planning program, most likely the output is going to be hard lines, those promises of firm dates, neat beginnings and endings.

Nothing really ever works out that way. Precise project scheduling is like penciling in a landing strip for a water balloon.

A New Approach to Planning
One of the most useful products I saw demonstrated at the Enterprise 2.0 Conference in Boston didn't really have much to do with Enterprise 2.0, as far as I could tell. It's a piece of collaboration software, but it's no more collaborative than Project or other planning tools that have been around for over a decade. It doesn't explicitly make use of network effects, though it does support discussion threads and Web-based scheduling. Most importantly, though, it offers a new and potentially very useful approach to planning.

The project is called Liquid Planner, and it's based on the premise, which seems blindingly obvious in retrospect, that accurate planning should be based on estimates and probabilities, not hard certainties.

Bruce Henry, whose title at Liquid Planner is Director of Rocket Science, explained the "Ah-ha!" moment that led to the founding of the company. He and some of his colleagues from Expedia were taking a class from Steve McConnell, the author of Software Estimation: Demystifying the Black Art and Rapid Development, among other books. McConnell pointing out that when you ask how long someone will take to do something, and they say, "4 to 6 days," and you say, "OK, we'll call it 5," you're making a guess, not an estimate. Estimates are based on ranges and probabilities. Guesses pick a number and use it as the basis of planning.

Most organizations base their planning on guesses. It's not surprising then, that most schedules slip, and that most Gantt charts end up looking hopelessly optimistic.

Two of Henry's colleagues from Expedia—Charles Seybold and Jason Carlson—founded Liquid Planner to address this problem. Henry joined them and wrote the probability engine that's at the heart of Liquid Planner's software. The goal: make project planning more accurate by enabling teams to base their schedules on realistic probabilities rather than unrealistic "certainties."

Here's a screenshot of the software, showing probabilities and date ranges for tasks.



Henry points out that seeing a list of probabilities can raise red flags early in the planning process. For example, if managers notice that a particular task has only a 30% chance of completing on time, they might ask why. They might discover dependencies they weren't aware of. They might be able to apply people and resources to address any dependencies or shortcomings, greatly increasing the task's chance of completing on time.

I haven't tried this software myself, but it seems like it's worth a look for any team beginning a new project.

The company launched its public Beta at the DEMO Conference in February, 2008. Since then, over 11,000 users and organizations Philips, Butterball Farms, and Reed Business Information have signed up for their online service. At the Enterprise 2.0 Conference in Boston in June, 2008, Liquid Planner announced its commercial version.

The service is free for teams with up to 3 members, for 501(c)(3) non-profits, and for educational users. Larger teams can take advantage of a free 15-day trial, then pay monthly or annual fees per user. You'll find pricing details here.