Estimating time in a project that includes unfamiliar concepts?

Question

When giving a time estimate for a project that includes work in areas you don't have experience with how do you estimate?

In most cases it is hard enough to get the estimate right when the project's areas are familiar.

What methods have you used in these cases? How well did they work?

Answer 1

MinMaxLikely is the method I use. The minimum for the case where everything goes well, the maximum for everything going pear-shaped, and the likely somewhere in between.

Of course, management only ever looks at the minimum figure but, by the time they start complaining about cost over-runs and missed deliverables, you've already got them locked in and you have been (hopefully) keeping the fully appraised of any problems you've encountered and the effect those problems are having (pushing the actuals away from Min and closer to Max).

Answer 2

Not Serious...

1. Reach your hand up in the air.
2. Grab an estimate.
3. Write down what you find.

Ok, ok...

It's hard. Actually, it is not possible to give an accurate estimate of something that is not known. But that doesn't stop people from needing to know.

1. Write down a list of all functional components or aspects that you are aware of.
2. Be as vague as necessary to cover everything.

Now, you have a list of components. For each component, do your best to get the business and/or functional requirements of that part. Why is it there? What is it supposed to do? Why? How? Drill down to more detail, add as many items to your list as possible (nested, components, sub-components).

The more items you have the easier it is to estimate each one.

Then double it!

I think it is very reasonable to walk the stakeholders through some level of design in order to provide an estimate. Otherwise, it's like walking up to a construction company and saying "I want a house, how much will it cost?"

And keep in mind -- it is an estimate :)

Oh, one last thing... Be clear about what it is that you are estimating. If it is "a, b, c" and they later ask for "d", it will be easy to point out that your estimate did not cover "d"... your new estimate is ...

Answer 3

Wherever possible, go one meta-level up: give an estimate of when you can give reasonably accurate estimate.

"I don't know enough about Foo to give an accurate estimate, but I will know enough about Foo by Thursday week."

I acknowledge it often isn't possible, but I try to make it an option when I am project managing.

You can even go up another meta-level, in large projects.

"I don't know how long it will take for us to get a expert in to give us an estimate. I will talk with my colleagues, and give you an estimate on Friday of how long it will take to get an expert estimate."

This can be combined with large error margins, diminishing rapidly. "It will take 1 year, +/- 9 months. I'll give you another estimate with an error range +/- 3 months by June 30."

Answer 4

Have you tried planning poker?

These SO questions might be relevant:

How to estimate the length of a programming task

Dealing with awful estimates

The most significant project management mistakes

Do you practice the planning game?

Answer 5

You cannot estimate these, you can only guess. The difference, to me, is that an estimate is based on knowledge & experience, and you have neither for the unknown.

You have to constantly reevaluate where you started, where you stand, and your guess on what's left. You could probably break down your problem into steps but your biggest issue will be in the "footnotes" of what you're learning.

The example that comes to mind was my first C# interop with Word. It was entirely unknown and I didn't have the foggiest clue what it would take to generate a 1000 page formatted document based on database information. It, in itself, is pretty straight-forward: open Word, format page, and insert data. There are all kinds of issues that cropped up that you couldn't fathom and that easily doubles your guess.

Answer 6

Ask people who are familar with the concepts how long it would have taken them back when they first learnt the technique (including how long to learn). Average the results and adjust based on your capability to learn.

Then guess anyway and triple the quote. Doubling is for chumps.

Answer 7

Know what you Know AND Know what you don't Know and you'll be successful.
Use a work breakdown structure (WBS) to get the sub parts of the project/application/whatever. You can provide an est. (to a degree) of the effort to get the knowns complete, as with any project there are the unknowns - identifying them is the first big step. The best next step is to add to the WBS steps to better know those unknowns, for example, if the task is to go BBQ a cheese burger with strips of bacon and you've never BBQ'd bacon before - then you break the job down to getting the ingredients, getting the BBQ, starting the BBQ, etc. and the one thing you don't know - getting/cooking bacon you add some sub-components like:

• call butcher
• research bacon cooking
• hire bacon BBQ'er expert etc. - each of those you can assign some est. to and put a ? near the actual cooking. Call it a proof of concept (can you bbq bacon?), research and development, whatever - but there are somethings when you start a project you don't know, but you can devise a plan to better know those areas AND once you do revisit the plan and add the findings. By doing this you're communicating out to the team, sponsors, etc. what you know, those areas you don't know but have a plan to get to know, and a rough est. with the unknowns identified.