Response Crafting

The irony of accuracy


Projects often require timeline or effort estimates – part of this drive toward “traceability” and “accuracy” and whatever else, and so we answer the question:

“When will this be done?”

And when it comes to actual and indisputable accuracy, the irony is that the most accurate answer is, quite literally:

“It’ll be done when it’s done.”

But we can’t say that. Because just as the answer of “we’ll get there when we get there” infuriated a whole generation of kids stuffed into the backseat for long-haul family road trips, this answer can have a similar effect on those who hear it now, who, understandably, expect a degree of diplomacy and professionalism and effort and Playing of The Game.

And so? We don’t say that. We instead offer an actual estimate. We evaluate the factors, weigh them against what we know, and, just as Dad probably could have done, give a better number; a best guess.

And the accuracy here depends not so much (not solely, anyway) on the guesser’s expertise alone, but a whole slew of endless factors, including consistency of project objectives, requirements, players, stakeholders, financial resources, timeline, market demands, technical constraints (or, more likely, breakdowns), culture, communication efficiency… the list goes on and on.

But somewhere in there, someone can take a look at things and say:

“Given all that we know (and some things that we don’t), this is our best guess.”

And typically, that’s enough to get us where we need to go.

But there are some – project managers and developers and clients alike – who want estimates to have “All Of The Accuracy.” All of it. All possible dependencies (ideally, known and unknown alike), all possible risks, all possible things that might happen and, furthermore, all of their possible consequences – not just the outcome alone, but the impact on The Number.

They spend hours, days even, generating the initial artifacts, and then hours and days more tending to their perpetual upkeep, using everything from basic algebra to homegrown algorithms to prescribed methodologies – like parametric estimation – to do the task. And when they’re done, they can drop a document on your desk and, for a short time only, point to it and say:

“Here in this 50-page document (isn’t it beautiful?), given this comprehensive list of all possible risks and dependencies (we thought of everything), their severity and the possibility of them happening, as well as their possible consequences (we know it all), this is most certainly (well, no. most likely) when this will be done.”

But here’s the thing: how many times have you seen any estimate, to any degree of granularity, actually prove out perfectly? If this stuff was truly accurate, wouldn’t we be hitting those timelines more often? Wouldn’t we never have to update the estimates ever again?

But we do. Because the irony, of course, is that no amount of algorithm will change the fact that, at the end of the day, they are fabricating fantasy. That’s what this always is.

Projects don’t succeed because of the accuracy of estimates. They succeed because of actual work, albeit on many levels. 

So rather than accuracy, maybe we should strive for action. And if we want to win, recognize that once the project really starts going and those risks really start manifesting, you’ve got two groups of people:

  1. Those who manage artifacts, burning through uncounted hours (yeah wait, just how many?) to perfect their plans, updating risk lists instead of actually resolving them.
  2. Those who actually manage the project, overturning the earth to get the team what they need, knocking on doors, going up against adversaries, whatever. rolling up sleeves and actually resolving the risks.

Timelines aren’t nailed by managing a project plan or obsessively re-algorithm’izing estimates, by re-measuring over and over until you’re at project-end and, low and behold, there’s your number (and just look at how well-documented it is!)

Timelines are nailed by stepping away from the spreadsheet and actually working. And it’s not that project managers need to program, but if things are falling behind, there’s probably something else we can actually do rather than sit down to type out: “Day 87: yet another day behind.”


2 thoughts on “The irony of accuracy

  1. Pingback: Project management is pretty much useless | Response Crafting

  2. Pingback: 2015 Review | Response Crafting

Share your thoughts

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s