Project Management

Truth (or Clarity) in Scheduling

From the Project Management 2.0 Blog
New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog


Recent Posts

Are You Prepping For The PMP 24/7?

Are You Just Too Darn Busy?

Eliciting Requirements... Creatively!

What To Expect When Your Stakeholders Are Expecting

8 More Templates to Save You Time

Situation: You need a more accurate project schedule (and who doesnt?).

The inspiration for the whole Agile movement hinged on the fact that we all know that linear schedules are usually wrong.  The more complex the project, the more that is true.  Agile approaches are one way of dealing with that uncomfortable truth.  Another is to use a really interesting approach offered by the folks at Liquid Planner.  Recently,  we spoke with Charles Seybold, their CEO and founder who offered us some insight into how the tool works.

Q.  Liquid Planner uses date ranges and probabilities to deliver a more accurate view of project progress.  It’s pretty clear how that could be more accurate than any single date.  Could you talk a bit about how input from team members affects deadlines? 

First off, we don’t actually have an entity called a deadline in LiquidPlanner. Rather we have expected dates which we mark with a big [E] on the schedule (these are always flowing) and we have promise dates which are shown on the schedule with the traditional black diamond of a deadline.  The key is to manage to the [E] but set your promise dates at the end of the bars (which are drawn to the 98% confidence date). Setting the promise date “locks” your commitment and you will get an alert if any action puts those promise dates at risk. Any item can have a promise date, but they work best on projects and deliverables.

By asking team members to estimate in a range you are giving them a mechanism which allows them to be honest. Most things have intrinsic uncertainty so we just cannot be that precise. For instance, can we really say we will be done in with exactly 10 days of effort?  If the person says 9-11 days, that tells you they probably have it under pretty good control. If they say 5-15 days, that says something is not well known and that working to understand the requirements better might pay off. 

What really is a single point estimate?  It is the expected case? Best case? Worst case? A sandbag perhaps? 

It’s fun to note that estimating in ranges pretty much eliminates “sandbagging”.  This phenomenon happens when single point estimation meets experience. The experienced worker knows that they need to give estimates they feel 90% confident in so that they will not get dinged for a miss, but when you estimate at that level, 9 times out of 10 you’ll be early.  When that happens the worker can sometimes fill that time with things that maybe were not part of the plan and… well you know the rest. Single point estimates are just bad for relationships.

The other great thing about a team member capturing uncertainty is that it inherits through their chain of prioritized work so that the exit dates on later work get a correspondingly higher about of uncertainty even if they are small tasks. This makes sense because if the exit date of your first task is uncertain, the start date of your next task is uncertain.

Q.  I personally like the Liquid Planner interface from a usability perspective.  What unique steps did you take to test Liquid Planner before its release? From a usability perspective, how do you think it compares to other Ruby on Rails PM apps like Basecamp? (using specific examples)

I’ll interpret your question broadly. In my previous corporate gig like I spent a great deal of time working on planning tools (mostly Excel based) where we were modeling concepts like ranged estimation and flowing work. From basically the first week of LiquidPlanner’s existence, we started prototyping. I maintained a prototype in PowerPoint that we used to mock up every feature we added and I kept that prototype up to date with the work the dev team was doing. This allowed us to test designs very early and make very rapid decisions and modifications for the UI. In short, it was try-fail-learn at a very fast, ridiculously lost cost rate. Looking back at my archive, I see over 200 versions of prototype. This allowed us to narrow in on a design that felt right to us and our friends many months before we put it in the hands of Alpha customers.  Even with that, we’re not perfect; we found some things that needed rework in our private alpha and I expect we’ll find and fix some things in the beta.

We are built on Ruby on Rails and drew inspiration from what the 37 Signals crew accomplished. We like Basecamp and think they did a great job showing the world that web software could be easy. There are many applications out there that are basically Basecamp clones and we think there is no point in repeating that again.  Our goal with LiquidPlanner was to take on a much broader set of objectives for a higher level of professional planning. We wanted to build for a greater scale with hundreds of projects and thousands of tasks. We wanted to be more like a desktop application.  LiquidPlanner is designed to be a platform for project management which, over time, will grow to serve large enterprises while staying true to our belief that the most important feature is usability.  Since you asked for an example, I’ll point out that many of the lightweight online task management tools are not built to put a ton of data in them. LiquidPlanner is build like a data warehouse and uses rich work breakdown structure as the backbone of your collaboration data so that your discussions, documents, and reports will stay organized as you reorganize your plan.

Q.  I really like the idea of everyone owning the schedule, based on their direct input.  Are there typical ways outside of the tool that PMs motivate team members to give honest input (versus padding their tasks) so that you can maximize accuracy?

None that we know of that work with other tools on the market.

Fundamentally a single point estimate is interpreted as a promise and this means that people will negotiate or obfuscate through them. A pattern we see is that the estimate giver and the estimate taker often do not have the same skill level in negotiation and the estimate giver gets backed into what we call “the least defensible estimate” which lies very close to the optimistic estimate.

Some techniques for getting better estimates from your team are tee-shirt sizing, wide band Delphi, and estimating by analogy but they all embrace notions of uncertainty and calibration.  Group estimating is quite effective even informally.

Q.  You talk a lot about “one source of truth”.  How do you see requirements playing into that “single big picture” view of the project, when using Liquid Planner?

Another word for truth is clarity, and any process that you can bring more clarity to is what we are talking about.  For example, in my last company we had a full SDLC and wrote specifications full of requirements for development work. We had a system of rating the specs 1 through 4 based on their “readiness” for Dev; level 4 meant it was done. In practice this was a binary state – not ready vs. ready.  I submit their would be real value in a ranged estimate at these stages to capture a meaningful metric regarding how much uncertainty exists. I think the feedback would be super useful to the person responsible for the requirements as well as a manager who wants to be able to direct her efforts to the projects with the most uncertainty.  If you want to take it a step further, you can do what we do, which is spec requirements in LiquidPlanner and let the projects, categories, and work items carried those requirements with them. That way each item can be assigned and estimated as you go and you can use uncertainty to guide your management actions. It’s the best way to facilitate one of my favorite practices: cut early and cut often.
Posted on: February 25, 2008 04:57 AM | Permalink

Comments (8)

Please login or join to subscribe to this item
Visited the site and created an account for a trial run. From the description of the product it sounds excellent!
More to follow after some runtime...

In the general there is a similarity to the methodology called PERT (see wikipedia : in which planning has an optimistic, pessimistic and most likely planning.

This looks (from both this info as well as recent eWeek articles) like a project management tool with some potential. If my next project assignment involves software development, I may have a look at this program.

Looks good. But a bit too complex ("capturing the uncertainty"). I'd recommend also checking the alternative - 5pm (

Is it just another tool that provides a more sexy presentation than PMW or Microsoft Project or other planning tool that you use?

From what I have read it does not give me any additional advantage over and above what my current team of business analysts, technical analysts and project managers provide me so that when I plan and present the project to the users they see the cold hard facts and commitment to their needs.

I know that a picture is worth a thousand words but a methodical plan and a team with commitment impresses our customers more

Hi Geofrey - thanks for your comments. Its just another PM tool alternative, with a somewhat unique twist on estimation that seemed to be worth a look. I think the difference here goes beyond presentation in the way it gathers bottom-up feedback (including probability estimates) from team members.

There has been an explosion of online SaaS PM tools recently - some that I've written about here. The majority of these new simple tools target organizations with large numbers of simple, currently unmanaged projects. I try to highlight what makes each one different, then people can decide whether there is any point in looking into them further. My hope is that it will be valuable to everyone reading, even if it only exposes them to what some new tools have to offer.

Given your comments above, I doubt that something like this would help in situations where you have time to prepare formal status presentations (talking to all of the team members about each task challenge and its impacts in detail). It might, however, offer a better way to know what's going on at any given point in time just because updates to the estimate are made frequently by the people performing the tasks, as they perform them and theoretically factoring in the team members % probability estimates at that granular level. (how's that for a run-on sentence?) So maybe it's a good tool for portfolios that contain dynamically changing projects and where you need precise status fairly frequently? Of course all of this hinges upon proper use of the tool at all levels - and that's always a trick.

Very cool, I agree that it can take some time to "get used to" but then again I am not the brightest crayon in the box. Quick help: we use Project Insight I was wondering how Liquid Planner would augment what we already use? Or how it would augment any PM tool? Do you all feel it would add confusion.

We own a handmade scented candles shop and this website has been a great resource in running our business. Thank you so much.

Please Login/Register to leave a comment.


"He felt that his whole life was some kind of dream, and he sometimes wondered whose it was and whether they were enjoying it."

- Douglas Adams