5

When I am making a price estimation in some project, I try to predict the number of work hours based on my experience or my logic. Of course, many times you face features you did not implement before and then you have to guess number of work hours. And in such cases, I am usually wrong and then I have to work extra hours for free since the clients usually say "sorry we do not have any more money in this project for extra costs".

Now, I know that companies usually count these extra work hours into its price. For example, if they estimate that they need 100 man hours, then they multiply 100 with some percentage to get the final estimation. Some other use standard deviation formulas, and so on.

I have 2 questions:

  1. Can you tell me what percentage do you use to calculate all extra man hours for all unpredicted events?
  2. Do you increase number of work hours on your own or you make a special time milestone called "Extra hours" or "unpredicted events" which you spend in case you come across event I described here?

NOTE: Since I am not sure which terminology to use, anyone can fix the title to make it better! It's possible that these extra hours in some project have its own name and I do not know it. Thanks!

Improve this question

2 Answers 2

Reset to default
4

A standard contingency in many organisations I have worked in is 15%, but as you are working alone I would push that up to 20%, as I indicated in a similar answer here. The key is to get as much scope agreed with the client up front so that you don't have any surprises down the road, but the only thing that can really help you regarding estimation of time to deliver requirements is experience. The more experience you have of delivering similar functionality, the better your estimation will become.

In every project you undertake, try to get in the habit of recording how long every requirement takes to deliver, noting down in particular any aspects that took longer than expected. If you can build this log up over time it will become an invaluable resource for future estimation. The key to estimating well is to spot the potential gotchas early and incorporate enough time in your quote to deal with them.

You will have to gauge the client, but I think it's reasonable to provide a higher and lower estimation for areas of functionality that you are unsure of in terms of time. You could provide 2 quotes so that they prepare for the worst. If you can deliver to the lower quote it would stand you in good stead for future work if you then charge them the lower of the 2 quotes upon delivery.

If you are careful to define the scope up front with the client, then anything that falls outside of that can trigger a Change Control, which can be captured and charged for separately. The key here is that the extra work is because of functionality requested by the client and not because you underestimated the original scope.

Improve this answer
3
  • This sentence sounds cool "The key here is that the extra work is because of functionality requested by the client and not because you underestimated the original scope." Can you explain it a bit more?
    – Peter MV
    Jul 16, 2013 at 9:44
  • 1
    Sure - it's simply that it's because the client has thrown something extra in that they'd forgotten about or asked you to make extra changes that are quite time consuming and would change the original scope a lot, rather than the fact that you didn't spot that something was going to be very time consuming (because you are unfamiliar with delivering functionality like that, it's actually quite complex and not as simple as it looked or whatever) and thus you gave a low estimate instead of a realistic one. It's much harder to justify asking for more money because you got your estimate wrong.
    – levelnis
    Jul 16, 2013 at 10:25
  • Yes. But there are very few cases when the client oversaw something :). Most of times we, contractors, were unable to predict the real costs of some feature. Thanks
    – Peter MV
    Jul 16, 2013 at 11:01
2

On a fixed-price engineering job I bill time and expenses for a couple of weeks (typically) while I'm mostly onsite getting familiar with the project's current state and the client's expectations and requirements, and co-writing a spec or work-statement. When we have agreed on the spec, I'm in a much better position to estimate the work that follows, and even so, I'll need to build in a little bit of contingency.

Most of my clients, and especially in research & development, have preferred a time and expenses contract anyway. I think they feel they have more flexibility to change course - or contractors! - as the project progresses.

Improve this answer
3
  • Hey man, have a heart :). R&D? T&E?
    – Peter MV
    Jul 16, 2013 at 16:19
  • Yes, onsite is much easier. But very few of us have clients so close that we can travel onsite.
    – Peter MV
    Jul 16, 2013 at 16:20
  • My experience is in embedded systems, where there may be two but probably only one prototype in exisistence, and I and the staff engineers will be sharing it. That's probably peculiar to my industry; Otherwise, I see no reason why those interviews, question/answer sessions, hand-holding the client, bouncing ideas around, etc., couldn't be done just as well electronically.
    – JRobert
    Jul 16, 2013 at 18:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.