DISQUS

DISQUS Hello! Oracle AppsLab is using DISQUS, a powerful comment system, to manage its comments. Learn more.

Community Page

Jump to original thread »
Author

The Art of Estimation

Started by manalang · 9 months ago

If you’ve worked in product management or consulting for any amount of time, you’re familiar with the estimation gremlin.
I’ve always hated managing projects. For me, it’s too much whip-cracking and tattletaling, but it’s an unfortu ... Continue reading »

16 comments

  • @Jake, Nice post - estimation becomes laughable when all the manager is interested in is that if you estimated 4 weeks for a project and you're a week in then you should be at 25% complete! Software dev is a little 'hockey stickish' - managers need to remember that.

    @Dave - grey hair!?! ... I wish! When I arrived in the US in 99 I had a full head of it. Those that know me, will know that 'a bit thin on top' is a gross exaggeration :0)
    Im not blaming s/w development - I blame my kids :0)
  • @Tim - now you mention it, s/w is a walk in the park compared to kids
  • Yeah, project planning is so hard b/c it attempts to apply hard and fast dates to work that's highly variable, even hour-to-hour for the same person on the same project.
  • The way discussions often go, is I explain what needs to be done with some squiggles on a white board, a lot of talking and a bit of arm waving. Then I ask the engineer
    "How long do you think that would take?"
    They respond
    "What's the deadline?"
    "I just want an idea how much work you think it is"
    "Well it depends. What deadline do I have?"
    "Tomorrow"
    "Tomorrow! It'll take me at least two weeks"
    "Finally, thanks"
  • Yeah, this is a problem with deadline-based estimating. If only we could build s/w in a vacuum w/o any deadlines. I'll bet that would rock.
  • Totally, this is estimation by bullying with a date. Not sure why this happens so much, but it's very common.
  • The bit that gets me is whether the manager wants an estimate of effort time, or calendar time. It may take a week of coding to do a module, but you have to wait for an API spec to write one call, or for a db refresh to run a test, so there's two or three weeks between start and end.
    Any estimate that doesn't come in a format like "About x hours for the first week, then y for the next two and another z at the end for sign-off, but only after Fred is back" is too simplistic
  • I am happy to get an estimate of x hours to design, code and unit test. As a project manager my job is to help put all the other moving parts into place, dependencies, documentation, QA, performance testing, vacations etc.
  • You're right. That doesn't make it easy though.
  • You sound like a very scientific estimator.

    You and Meg both bring up a reason that development is hard to estimate; there are inevitably unforeseen and unscoped moving parts that frequently are forgotten or can't be estimated anyway.

    Another reason why project management is maddening.
  • Jake, you come close to nailing it for me with this one although I tend to see a few more layers between. One thing I find a lot is not just the estimate time but also the comprehension of "what" the estimate should include. Developers I work with are quick to think of design/code/unit test but what about UE polish? Performance testing? Integration testing? ADA compliance testing? automation? and so on. The "oh, I wasn't including that" is where the biggest risks come into the picture for me. Probably a sign of the size projects I tend to be involved with but all those "little things" can add up to be a project killer if you are not clear on the "what"
  • Good point. From my days in apps development, mandates moved too fast for training to keep up with them, e.g. Forms to OAF impacted estimates across the board, design/code/test/doc all that.

    Don't ever let anyone tell you s/w is easy.
  • writing software is easy, building a robust, performant, scalable, deployable, ADA compliant, platform independent, patchable, upgradeable and commercially viable ERP suite is tough. That's why my hair is turning gray.
  • Your hair isn't gray, and s/w is hard. Everyone should know that by now.
  • 5-6 years back I had a manager, who used to ask me for estimates with break down and when he builds the schedule he used to simple double the estimates and publish it up. It kind of made sense in a way with all the little little things that pop up we could never meet the dates and it also used to give us time to learn, find new ways to things if we do finish things on time. As a dev manager now I try to follow those principles however sometimes we try to break the complexity using Agile development methodologies,twice a month deliverables with a complete dev,qe, integration and product management validaton cycles. For sometime I also used LiquidPlanner to come with estimates with some fluidity built in, I blogged little bit about it at http://www.appme.net/2008/09/09/liquidplanner-p...
  • Doubling the estimate is a classic tactic, but it underlines the fact that the estimate is wrong from the get-go. How great would it be if the estimates were right?

    Whenever possible, I prefer to ask the developers to commit to a number and negotiate down to where we're both comfortable. This means they own the dates as much as management does. Classic wisdom from a box whose name escapes me right now.

Add New Comment

Returning? Login