How to estimate how long an unfamiliar task will take?

One way of coming up with a rough estimate is to talk to someone who does have experience with the type of task you're facing. (The folks at Home Depot don't know me and they've never been in my basement, but they're surprisingly good at estimating how long it will take me to paint it, if I give them just a little bit of information.) If no one in your organization has any experience, you might need to hire a consultant.

The margin of error is going to depend on your best-case and worst-case estimates. The text we're using in my Systems Analysis course gives the following formula for calculating most likely duration:

D = ((1 * OD) + (4 * ED) + (1 * PD)) / 6

Where:

• OD = Optimistic Duration
• ED = Expected Duration (your best guess)
• PD = Pessimistic Duration
• D = Most likely duration

Source: Systems Analysis and Design Methods

The formula is simply a weighted average of your own estimates, so it's really only good for turning the range [worst case - best case] into a single numerical estimate. If your input estimates are only guesses then the output will be no better. The important thing to take away from the formula is that your margin of error can be very wide depending on your PD and OD values.

When you have no idea how to estimate a task, popping out your calculators isn't going to help much. The principle of Garbage In, Garbage Out still applies: just because you did some clever math with your made up Optimistic/Expected/Pessimistic Durations doesn't mean that the number you get out is any less made up.

If you are having trouble estimating something and even the purported domain experts don't know how long it would take, ask yourself:

1. Have you broken down the task into sufficient sub-tasks? The trouble with estimating may come from the fact that you are considering a large, complex task with many parts that you don't fully understand. For example, "Build a shed"... the shed could be large, small, complex, simple: the trouble with estimating comes from insufficient thought about what the shed will be.

In this case the solution will almost always be to refine the design of the shed and figure out whether it's store-bought or homemade, how big it is, whether it will have a foundation or not, etc. etc. And when you break it down to sub-tasks you will have to sort out these issues which will produce a much more reliable estimate.

1. Is the task truly "normally" distributed? Certain types of tasks, especially "searching" tasks, may involve trial and error. These will be pareto-distributed, not normally distributed, and they can lead to enormous risks in a project.

For example, if the project has a line item for "finding a development site," it can be notoriously hard to predict how long that will take, because you might find the site on the first day, or you might find it on the 180th day. In fact this task has an equal probability of being completed on any given day, because every day, you go out and evaluate a site, and it either fits or it doesn't, and you have to keep doing that until you find one that fits. The mathematical shape of the distribution of probabilities for such searching tasks is pareto, not bell. There is thus a small risk of extreme overrun if the item you were searching for is not found.

It is the responsibility of the project manager to (1) identify cases where tasks are not sufficiently designed to get a good estimate, so that the domain experts can reduce project risk by nailing down the design and (2) identify cases where tasks are "searching tasks" and might cause enormous project risk, so that they can be moved forward in the schedule as much as possible. A project manager who applies formulas to made-up numbers because some book told them to do that is not doing anyone any favors.

An old often overlooked technique is the Wide-band Delphi estimating technique. It's a technique where a group of experts arrive at a consensus decision iteratively. It has more or less be resurrected by the Agile development community as 'planning poker'. In a nutshell, the steps (again from Wikipedia) are:

1. Coordinator presents each expert with a specification and an estimation form.
2. Coordinator calls a group meeting in which the experts discuss estimation issues with the coordinator and each other.
3. Experts fill out forms anonymously.
4. Coordinator prepares and distributes a summary of the estimates
5. Coordinator calls a group meeting, specifically focusing on having the experts discuss points where their estimates vary widely
6. Experts fill out forms, again anonymously, and steps 4 to 6 are iterated for as many rounds as appropriate.

This only helps define consensus, not accuracy. If no one on the team has a clue, then you will still be in trouble. markbruns advice still applies.

Not sure what industry you are in, but in Software Engineering Economics, I think Boehm has a graph that conceptually tries to capture the uncertainty - bottom line, figure +/- 100% to 150% during the earliest phases of a project, the farther you are into the project, the less error you can assume. This graph described the total estimate error, not the error in a single task, however.

If you have many tasks with this kind of uncertaintly basked in, or you don't know how many tasks you may have to perform, you may find it helpful to resort to a parametric estimating method (a ''top-down'' approach) as opposed to the task oriented, ''bottoms-up'' approach. Examples are [COCOMO][5] and the [Putnam model (SLIM)][6]. The learning curve in using these tools may be a factor, however.

See also:

• http://www.amazon.com/Software-Engineering-Economics-Barry-Boehm/dp/0138221227
• http://www.amazon.com/Software-Cost-Estimation-COCOMO-paperback/dp/0137025769

There are already some very good answers here, so I'll just quickly mention a couple of concepts I haven't seen represented yet.

First, keep in mind that these are estimates. By definition, they are only approximations of the actual time required. For small, well defined projects, it's possible to nail down estimates pretty tightly. But for a large project involving a lot of people and resources, the estimate is likely going to be rough and will evolve with the project as unexpected delays (and triumphs) come into play.

You specifically asked about an unfamiliar task. It has been my experience that tasks that are initially unfamiliar, often are made up of familiar subtasks. So one of the first things I would do in creating an estimate for an unfamiliar task is to see if I can break it into subtasks that might be more familiar and therefore easier to estimate. You will probably still have one or more subtasks that are unfamiliar, but by pulling out as many subtasks as possible, you reduce the effect of a less accurate estimate on the unfamiliar parts.

Start with a best guess based on past experience and talking to other people.
This generally has a margin of error of 50% +/-.

As the task gets better defined or gets underway, you should aim to have a guess that carries a margin of error of 10%.

It is hard to estimate and answer as the assumption of your question is that the teammate do not want to achieve.

If I were the project manager, I shall do a research on the project , corresponding technology and discuss with the teammates about their proficiency to the related technology. At least , the Pm can get the overview and anticipate the difficulties with respect to the technological and human level.

As ,the major responsibility to get the project done is burdened onto the developers , letting them to get the consensus is a must. PM should never involve in micro-management to help developers solve the problem by direct coding.

As the project start, regular meetings can be held and access the difficulties and risk by risk matrix. Prioritize which to be resolved first. Sometimes, you may provide training to the developers by introducing the workshops , seminars , courses or even some website for reference.

To be extreme, system analyst can also held responsibilities to conduct research and assign tasks to developers. PM and System Analyst can work together in this case. Collaboration and Mutual Trust can be built. I personally think that System Analyst can help much by estimate the working time in a detailed way and set the tentative time frame as they are more experienced in estimating the learning curve among the developers towards the new technology involved in the project.

Just a precision: begin small and grow accordingly to the new needs you will discover along the road. Watch your team members work, analyse their non verbal language: you will see easily if they have some spare time or not. For example, if they are regularely talking about their weekend on the jod, I guess they would accept another task...