Jeremy's World

The views and opinions expressed in this page are strictly those of the page author. The contents of this page have not been reviewed or approved by the University of North Carolina.

A big part of my job is managing projects.  Big projects with complex dependencies, multiple milestones, stakeholders wanting date commitments, etc.  The last one in particular is always a challenge, and if a Project Manager tells you otherwise they are lying.  It’s never possible to say – with any reasonable certainty – that a given project can be done on a specific date or will take a specific number of hours.  Disagree?

The usual game that’s played is to put in some CYA padding.  The PM’s internal conversation goes something like,

“Ok, I don’t really know the specifics of the project yet, but we can usually do them in 3 weeks.  I’ll commit to 4 weeks ‘just in case.’”

Back to the question in the title…How long is your commute?  10 minutes?  What if there’s traffic?  20 minutes.  What if it’s snowing?  40 minutes.  What if, what if, what if.  All of these “what if’s” reflect the obvious reality that there is always uncertainty with things like this.  Sure, we can’t plan for every “what if,” but in the project world with padded estimates, we try to give ourselves wiggle room.

What inevitably happens is the client says, “Whoa, can’t we do that faster?”  It turns into a negotiation on timelines that were ambiguous, padded swags in the first place!  The padding goes away in the negotiation, something happens, and a date is missed.  How has this worked out traditionally in the software world?

The Standish Group did a study called “Chaos 98” that is often quoted on this topic.  The bottom line – according to their report – is that

75% of all software projects fail because they go over budget, miss the delivery dates, or are of substandard quality.

Ouch.  Not a metric I want on my resume.

An IEEE report shows that when project management tools are used, success rates to increase pretty dramatically.  However, these tools are based on the model of setting a single date and marching toward it.  Inevitably that date is the result of a negotiation where it’s been “talked down” by the client and IT “hopes” to meet it.

What can we do about it?  How about model our projects based on real life.

Seems like a no-brainer, but do we negotiate how long our commute is?  If it snows, do we say, “It’ll take 40 minutes but that’s too long so I’ll do it in 30?”  We could, but that would probably (literally) crash and burn.  Why then should we play that game with our projects?  What if instead we could plan our projects in a way that could account for certain levels of uncertainty?  Well, the tools want a date.  A single date.  Do we set that optimistically and hope to reach it?  Pessimistically and pad for uncertain events that may cause delays?  Neither of these strike me as an answer that will lead to success.

Enter Liquid Planner (Part 1).

I found this SaaS product after evaluating literally more than a hundred software tools in the hunt to find a better way.  The “magic” of Liquid Planner is that it allows for real-life modeling of projects…Admit there is uncertainty, recognize its impact, and factor it in in a meaningful way.  That meaningful way that Liquid Planner enables is to allow for probability-based estimating.  Put some science behind the estimates!

Huh?  It really is brilliant.  Remember the PM’s internal conversation from before (“Ok, I don’t really know the specifics of the project yet, but we can usually do them in 3 weeks.  I’ll commit to 4 weeks ‘just in case.’”)?  What if instead, that conversation could be something like,

“Best case we could do this in 2 weeks.  Because we don’t know some of these specifics, it could take up to 4 weeks.  So, I am pretty comfortable…with about 80% confidence…that the project will finish somewhere between 2 to 4 weeks.  Statistically speaking (more on that in a minute), I would expect it to finish in about 2 weeks, 3 days.”

Sounds like a “duh” statement, doesn’t it?  But until now our tools didn’t allow us to do this.  We could do two plans – a best case and a worst case – but that’s a big time hassle.  And, what would that statistically reasonable “expected” statement be?  It would be a swag.  But not with Liquid Planner.

Part of Liquid Planner’s secret sauce is in scheduling projects based on identified uncertainty and mapping that against a normal statistical distribution.  On a single task basis, you could say, “well, that’s just the midpoint, right?”  True.  But when aggregated with all of the tasks in a project, considering ramp up and ramp down time, and the whole standard deviation stuff when considering statistical distributions, it’s a much more complicated science.  Amazingly, that’s the science that Liquid Planner performs.

Looking at things in terms of recognized and accounted for uncertainty, the client conversation can now be, “Ok, we want this faster…What can we do to remove some of this uncertainty in order to reduce the best case/worst case span?”  Ah…now we’re talking about real things.  “If we could nail down X requirement now, our ‘worst case’ estimate could come in.  If we could reconsider Y, our ‘worst case’ estimate would go to…”  It’s not a negotiation of promise dates, but instead is a proactive, partnership-based approach to reducing uncertainty where possible, and transparently recognizing and accepting the potential for variance based on that uncertainty.  The expectations are a bit more fluid with all of these considerations…Hence the name “Liquid Planner.”

Don’t get me wrong…This product will not manage your projects for you.  It is still reliant on your experience to be able to a. identify the necessary steps to complete a project and b. be able to estimate the effort in a reasonable…80% confidence…range.  That takes skill and experience that no software will do for us.  But with those skills and changing the conversation to admit the uncertainty, the claim is that our chance of project success is much, much higher.

I’m currently running 2 projects using this method.  Each is in different phases of the project, but so far, work has fallen within the ranged estimates and they are going well.  Our clients seemed to understand and buy in to our approach of ranged estimating, so the commitments aren’t “It’ll be done on September 4.”  They are, “We should complete the project somewhere between August 15 (10% chance) and December 30 (98% chance), but we expect it to complete around September 4 (50% chance).  And the genius of the software is that your project plans are actually built accordingly and that information is readily available in a very slick, AJAX-y interface.

I’ll write more on another distinguishing topic of Liquid Planner in another post.  In the mean time, I’ve already informed the folks at Liquid Planner (who are insanely accessible and very cool) that should we ever move back home to Washington, I’ll be calling for a job! 

Happy planning!

PS. I can’t take credit for the “How long is your commute?” metaphor.  That comes right from Liquid Planner’s materials.  But it’s just so dang clear in making the point, I went with it instead of trying to come up with something clever on my own.