Hong Life CalculatorsUnderstanding the software man-month estimate — concept and principle
A man-month (or person-month) is the amount of work one person does in one month. Teams and clients use it to price projects and plan schedules. This calculator builds a bottom-up estimate from the number of features, the effort per feature and an overhead allowance, then converts it into cost and calendar time for a given team. It works with any currency.
How it is calculated
- Man-months = features × average person-days per feature × (1 + overhead % ÷ 100) ÷ 20.9
- Total cost = man-months × monthly rate per developer
- Calendar months with team = man-months ÷ team size
The divisor 20.9 is the average number of working days in a month that the calculator assumes (roughly five working days a week across a year). Overhead covers testing, project management, meetings, code review and deployment.
The principle
Bottom-up estimation breaks a project into pieces small enough to judge, then adds them up. Overhead is applied as a percentage because coordination and quality work grow with the size of the build. Converting days to months and multiplying by a monthly rate turns effort into money. The last step, dividing by team size, assumes the work can be split perfectly, which is rarely true. Fred Brooks argued in The Mythical Man-Month that people and months are not interchangeable: communication paths grow with team size, and adding people to a late project tends to make it later.
Worked example
- 24 features, 4 person-days each, 35% overhead, $9,000 per developer per month, team of 3.
- Base effort = 24 × 4 = 96 person-days.
- With overhead = 96 × 1.35 = 129.6 person-days.
- Man-months = 129.6 ÷ 20.9 ≈ 6.2.
- Total cost = 6.2010 × 9,000 ≈ $55,808.61.
- Calendar time = 6.2010 ÷ 3 ≈ 2.1 months.
How to read the result
Treat the output as a central estimate. Early in a project, real effort commonly ends up well above or below the first estimate, so quote a range and add contingency. If calendar time matters more than cost, adding people helps only for work that can genuinely run in parallel. If the cost is too high, reduce scope first; cutting the overhead percentage usually just moves the work into bugs later.
Common mistakes
- Estimating only coding time and leaving out design, testing and fixes.
- Assuming a developer is productive on project work every working day, with no holidays or support duties.
- Dividing by team size and treating the result as a deadline.
Frequently asked questions
Why 20.9 days and not 22?
It is an average over a year of weekdays; holidays and leave reduce real availability further, which you can reflect in the overhead.
What overhead percentage is typical?
It varies by team and process; records from your own past projects are the best guide.
Is man-month the same as FTE?
Related but different: FTE describes staffing level, while man-months measure total effort.
Sources: Brooks, The Mythical Man-Month: Essays on Software Engineering (Addison-Wesley, 1975; anniversary ed. 1995) · McConnell, Software Estimation: Demystifying the Black Art (Microsoft Press, 2006)