Truth (or Clarity) in Scheduling

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.