I was wondering if there is any standard or basis by which to consider overhead costs in a project. Normally we practice 10-15%, but I wanted to know what others are following and what's the best practice.

I use a bit more sophisticated method - basically every task in work/product (depending on the approach) is estimated with 3 values:

• minimum time (TMIN) - minimal time task will take to complete
• maximum time (TMAX) - maximum time task will take to complete
• risk factor in percentage (RISK) - this is basically the possibility of the fact we need to use full maximum time.

All 3 values are assigned by developers. As I learned the main problem they mostly have is to specify RISK - so the explanation for that is if they know the subject, they did something like this already before and they have an idea right away how to do that - they should put 10-15% in there. If they were doing something similar before, but this one is much more customized and they do not know fully yet how to design that - they should put 20-40%. If the subject is less known for them - they should put there 50-80%.

Now to calculate something I call real time (REAL) you need I use a bit modified PERT equation:

``````REAL = (TMIN + ((100%-RISK) x TMIN + RISK x TMAX) x 3 + TMAX) / 5
``````

In standard PERT you additionally have additional value which is realistic time - in the equation above this is that formula: ((100%-RISK) x TMIN + RISK x TMAX)

Then when I have all the tasks estimated this way I use weighted average of RISK for all the tasks (with REAL as weight) to calculate overall overhead/margin for whole project.

• Documentation - I put 20-30% here depending on the documentation standard (of course as long as there are reasonable client requirements - since there are situations when documentation can even take 50-80% of whole time)
• Service - if you are not adding service fee in the contract

There is actually one more overhead you should consider also in the situation when you share resources between the projects. This overhead is time needed for specialist to switch between tasks/projects. In most cases I use the 5% for switching/onboarding - however depending on the level of detail of your tasks you can also use fixed value such as 1 hour. What is quite important in here is that this overhead should actually not be covered by the project, but by the operational costs. I find this not as a project expense, but the expense of having a specialist that is shared between the projects. And as such the cost of this 5%/1h should rather not be added to the project cost, but should be considered to project schedule.

Hope that helps.

• Thanks for your detailed explanation. Really appreciate it. I haven't used this method earlier and I liked this approach. Will discuss with my team. We have been using 10-15% rates as given by our Finance people to calculate overhead costs; i am not sure they consider risks or not. Jan 25 '17 at 9:27
• The risks is I believe complete different topic - as detailed risk planning is something you do not do during project estimation. So I would put aside risk management here rather then overdoing it during offering process. Jan 25 '17 at 9:35
• completely agree. Jan 25 '17 at 9:41

The best way is to improve the accuracy of estimations :) But that's another topic. We've been using 20% overhead value, and to be more accurate with the deadlines, consider that you have only 80% of the resource. E.g. the super-accurate-estimate is 40 hours. Add 20%, this makes it 48 hours. Then, assuming the developer works 8 hours per day and starts on Monday, the deadline is next Wednesday. 80% of dev resource is 6.4 hours per day. 48/6.4 = 7.5 days.

• Yes, estimation comes with experience. We use the same as you are doing (10-15%); i am also discussing the method as above with my team this week. Jan 27 '17 at 2:04