Manager In A Strange Land: Accuracy vs. Precision

One of my pet peeves is when people mix up the terms "accuracy" and "precision" - a pet peeve I picked up from reading Steve McConnell's *Rapid Development*.  (Page 173 of my edition - it's in the index!  What a great book.)

Suppose someone asks you for an estimate.  You say, "I think it'll take around two weeks."  They then ask, "Can you be more accurate?"

You probably cannot, not without a crystal ball.  (That said, there is a way to cheat to make it seem like you're more accurate.  That's below.)  But that's okay, because what they probably mean is:  "Can you be more precise?"

"Sure," you can then say.  "I think it'll take thirteen days, four hours, eleven minutes, and fifteen seconds."

Steve McConnel says "False precision is the enemy of accuracy."  Because now, when you take twelve days and zero hours to deliver, you've proven that your precise estimate was, in fact, inaccurate.  But your imprecise estimate (around two weeks) is still accurate.

But, well, come on, Steve!  Would *you* fund a project if they told you, "Well, it'll take somewhere between 10 and 20 million dollars."  No.  But you might fund a project if they told you, "It'll take 20 million dollars at most."  You - and by "you" I mean "me" - are kind of illogical that way.

So, the cheat is this - sandbag on your estimate ("It'll take three weeks and zero days") and finish early.  Also known as "the Engineer Scotty method."

We typically give a highly broken-down, itemized list of features and requirements to our potential clients, each with its own (admittedly overly precise) estimate.  Then we run some math on the back-end to account for "Fristrom's Law" and our historical velocity, and then we add a contingency buffer - that's the sandbagging that will protect us from our overly precise estimate.  Because if we slip, hey, that's our responsibility.

Of course, our competitors don't seem to be putting padding into their estimates.  Which means we often lose the bid.  But that's okay: the alternative--the risk of ending up contractually bound to a project where we're losing money--is worse.  And who knows?  Maybe our competitors will screw up their projects and we'll be remembered as the "honest guys" and we'll get the next project.

What do you do when someone asks you for an estimate?

Comments

[CDriK]

I take at least a whole day to get the engineers and testers estimate their respective tasks and add 20% for integration and 10% for slipping risks.

25+25+25+25 => 132

[Meg H.]

I'm the planner, my husband is the coder. I am quickly learning that coding is more art than science. And estimating art? Yikes!

My general rule of thumb is that it will take 3 times longer than what we initially think it should. LOL!

Actually, being experienced with your team is the best way to know how to estimate, see
The Mythical Man-Month by Frederick P. Brooks Jr. & Slack by Tom DeMarco .

Best of luck!!

[Jay]

Working solo, I estimate my time as precisely as I can but charge hourly whenever possible. I get paid for all the work I do, they only pay for work that gets done. Sadly, not all projects can be billed this way.

It must be exponentially difficult to estimate time for teams larger than just yourself.

[davidicus]

i'm with Meg--art is impossible to estimate well. i avoid quotes. that's why i'm also with Jay about charging hourly.

instead of estimating the traditional way, i'll show a client the the most similar project i have, describe its process, and tell them roughly what that cost. then i use a time tracking and billing application for a true and detailed invoice.

you can set a cap with the client and notify them if it's at risk at any point, or once you're within say 15% of the top. they understand that if sign-offs go smoothly and the project parameters don't change much that i can come in under the cap in the end.