April 17, 2004

Estimating Tasks

I love this scenario, someone presents you with a piece of paper or an email. It details some vague task or concept. Like for instance create an interface from the student information system to the finance system. No specs, no fields desired, no format, no transport mechanism and then they ask can you do it by the end of May?

Nevermind the six or seven balls you are juggling :) Estimating the time for tasks is something that is sorely missed. First there needs to be clearly defined requirements for the task at hand. Yes, there will probably be scope changes to some of the requirements, but hopefully not the essence of the requirements. Then a couple of estimates would be good, have two or three people, derive the optimistic, realistic, and pessimistic estimates. Average the estimates, with a higher weight on realistic and pessimistic.

The best practice is to get a central repository of task that have previously been completed with the slip time of the task, the time the task took to completion, the skillset performing the task, and the obstacles encountered. This will assist in generating the realistic estimate.

For the optimistic scenario, base it on a highly skilled individual, for the pessimistic base it on a newbie. One doesn't always get the most skilled individual for a project, and the newbie will probably encounter more obstacles. (Its all a part of learning)

Yes, this process would take more time than the standard 2 days, 2 weeks, 2 months guestimation mechanisms. But accurate reliable estimates of the time to complete work will only create a better project plan, and any tools that would help with this process are worth their weight. A detailed scope of work, makes it very clear upfront whether this project is worth the time, instead of wasting time and then not delivering.

Posted by Elyse at April 17, 2004 12:26 PM | TrackBack
Comments

Your first sentence reminds me of today's Dilbert
http://www.dilbert.com/comics/dilbert/archive/dilbert-20040417.html

Posted by: Laura at April 17, 2004 1:11 PM

This is exactly why, at work we re-designed our project management process.

It's important to re-evaluate every so often, so that your idea of what you need to get a job done is the same as their idea.

I am a very literal minded person, you tell me what you want to get done, and i'll be happy to work my butt off to get it done on time.

You leave me guessing, clueless as to what you want done, why you want done or how you want done. I consider a complete waste of my time.

I feel it should be a law, to assign a project you must provide all details so as to leave no wondering if my idea of what you want is anything like your idea.

Posted by: Craig M. Rosenblum at April 18, 2004 9:14 AM

change the scenario to that which has requirements defined and all that and the observations made still hold. my problem has always been that i fall more to the optimistic side... therefore calculating two-week schedules as 3 days :)... and as craig points out, unless you are the one who's creating/defining the requirements in the first place, there's always a good chance that requirements communicated are not fully understood... then there's also the problem of emergent properties (not-so-project-bloating additions :)) down the line

the optimistic view sometimes leads to increased productivity even though you might overwhelm your skillset (with catastrophic efffects)... as with everything, you are able to make more realistic (however optimistic) estimates when you have more similar projects in your out tray

Posted by: eokyere at April 18, 2004 2:45 PM
Post a comment









Remember personal info?