Sooner or later we come across a task in our project, with which we are totally unfamiliar ('we' as in PM, but also possibly the staff assigned to do this particular task).
How can we estimate amount of time/work/resources needed to complete such a task? What margins of error should we assume?
Don't place too much confidence on your first guess just because you've used a sophisticated formula to derive your estimate. Do your best, move on, plan to revise your estimate, don't let bad estimates linger and destroy the discipline of your project schedule ... errors in time estimates are likely to be lognormally distributed... use a method that incorporates an optimistic guess, a pessimistic guess and heavily weights your best guess.
Estimate, test, check, then revise and update your project schedule. The third or fourth revision of the estimates is usually about as accurate as you can hope for; your second estimate is far better than your first guess ... if possible, try to get a measure from an early trial of a similar or analogous task ... revise the estimate and revise your plan as soon as better data becomes available.
If your first estimate was too conservative, don't allow slack time to corrupt completion of succeeding tasks. If your first estimate was overly optimistic, make your adjustments EARLY and let your stakeholders and customers know. It's more important to be good at following up, to check your estimates and to competently communicate updates than it is to be a develop skill as an estimator of unfamiliar tasks.
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 (Three-point estimation) for calculating most likely duration:
D = ((1 * OD) + (4 * ED) + (1 * PD)) / 6
Where:
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:
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.
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:
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 and the Putnam model (SLIM). The learning curve in using these tools may be a factor, however.
See also:
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.
In my team, we create a separate task, usually 2h, to research an issue that we don't know very well.
With the information, you can give some insights to your team and make the first estimation.
Those 2h of research are negotiated with the customer and are part of our Cooperation models, so the customer knows in advance that some tasks will require extra research.
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...
Planning poker is often used to generate discussion and bring in different viewpoints. The discussion will eventually lead to an estimate comparative to a previous work done, which can then be translated into man hours or similar by the project manager. Note that it should be the team doing the actual work, not the project managers, that participate in the planning poker. https://en.wikipedia.org/wiki/Planning_poker
