Man hours estimate

Note: Jan 10, 2008, updated March 2011
In my booklet "Evo Planning or How to Achieve the Most Important Requirement" (see Download page, booklet#7) you can find more on measuring and calibrating your estimates during the project, in order to quite accurately predict when you'd be really done and what you can do if the end date is farther away than you like.

Question on softwaredioxide.com: Posted March 28, 2002 12:02 AM


Can any body help me out how I could arrive at man hours estimate.
E.g.: I have a project which could be done in 25 working days with 3 programmers and 1 Project Leader.
What will be the final man hours figure. How would we estimate the cost from the man hours.
How do I convert the man hours in FP or FP into man hours?
Is it possible to convert or not?


My reply:

If you know for sure that the project can be done with 4 people in 25 days, assuming that they all work 100% on this project, then the number of man-hours is simply 25 x 8 x 4. If you acknowledge that nobody works a full 100% on any project (other activities: going to the toilet, drinking, discussing, helping each other, meeting, etc) then you could add a correction factor to the calculation.

However, how do you know that "it can be done" in 25 days? If you already know this, there is hardly a problem. The problem is usually to get to know the number of effort hours and from that deriving the number of lead-time days.
For more, read my booklet "Evolutionary Project Management Methods" (see Download page, booklet#1), chapter 3D, 3F and then read the rest. [added 2011: In booklets #2 and #7 you can find a much more developed, comprehensive, and proven process to help projects to get and keep control of their success.] If you have any comments or questions, please let me know.

Cost per man-hour depends on many factors:

Man-hours to FP (Function Points) and reverse is quite easy, as long as you compare similar type of work, with similar or same developers in the same organization. Comparing with results of other organizations and other circumstances will cause very much variation. At the other hand, using no metrics may be worse.

If you don't have any idea, do the work and measure:

In Evolutionary development mode (see Download page, booklet#1, [added 2010: but much more elaborated in booklet#7]), we do not learn from previous measurements per project, but rather per week. You may call this "oversampling", in order to get much more rapid and frequent feedback to faster and better predict the future.

Etc, etc. I could go on and on, but may be this is good for a start?