Boehm’s Model - Explanation

Question

I am reading through "Mythical Man-Month" and near the end in the updates for the 20th anniversary edition it talks a bit about Boehm's model and the optimal time to delivery based upon the exected effort in man-months of a project.

His statement, when discussing Boehm's model, is:

His results solidly confirm The MM-M’s assertion that the trade-off between men and months is far from linear, that the man-month is indeed mythical as a measure of productivity. In particular, he finds:[16]

• There is a cost-optimum schedule time to first shipment, T = 2.5MM^1/3. That is, the optimum time in months goes as the cube root of the expected effort in man-months, a figure derived from the size estimate and other factors in his model. An optimum staffing curve is a corollary.

• The cost curve rises slowly as the planned schedule gets longer than the optimum. People with more time take more time.

• The cost curve rises sharply as the planned schedule gets shorter than the optimum.

• Hardly any projects succeed in less than 3/4 of the calculated optimum schedule, regardless of the number of people applied! This quotable result gives the software manager solid ammunition when higher management is demanding impossible schedule commitments

I am having a bit of difficulty in applying this statement practically, I wonder if anyone has any insight as to how this would inform software estimates? I am particually trying to interpret the estimate formula, as plotted here: cost-optimum schedule time plot

This seems to indicate that, for a project with 1 man-month of work, there is an cost-optimal time-to-delivery of 2.5 months. This makes sense, however, if you then assume that there is a project with 5 man-months of work, the plot suggests that the cost-optimal time-to-delivers is 4 months!

Does this suggest that more man-power should be allocate to deliver within this time frame, or that the estimates are too large?

Also, how can you estimate optimum staffing levels from this model? Thanks

Answer 1

As with any model there is no need to take it on blind faith, especially when the model is really easy to test:

Effort in MM Opt. Dur. Avg. Team Size
   1           2.5           0.4
   2           3.1           0.6
   3           3.6           0.8
   4           4.0           1.0
   5           4.3           1.2
   6           4.5           1.3
   7           4.8           1.5
   8           5.0           1.6
   9           5.2           1.7
  10           5.4           1.9
  20           6.8           2.9
  30           7.8           3.9
  40           8.5           4.7
  50           9.2           5.4
  60           9.8           6.1
  70          10.3           6.8
  80          10.8           7.4
  90          11.2           8.0
 100          11.6           8.6
 200          14.6          13.7
 300          16.7          17.9
 400          18.4          21.7
 500          19.8          25.2
 600          21.1          28.5
 700          22.2          31.5
 800          23.2          34.5
 900          24.1          37.3
1000          25.0          40.0

As far as I can see for software development projects of up to 10 man-months that currently prevail within business environments (in-house projects run within non-software companies) the optimal figures produced by the model do not reflect typical durations and team sizes.

The figures for projects over 20 man-months become much more believable, especially where efforts are tightly coupled.

As a result, I'd avoid using the formula for anything but a quick order of magnitude guestimate for projects of over 20 man-months in duration. For anything less than that a quick planning session would give you a more accurate and trustworthy result.

Answer 2

Essentially, all models are wrong, but some are useful. -- George E. P. Box

I don't have any references handy, but I think this model is derived from data from large waterfall-style projects. For small projects like 1 or 5 man-months, the model may not be applicable that well. Models give you wrong results if you try to extrapolate them too far from their validity range.

Though it's also true that especially in a small project, it's not always possible to do work that contributes to deliverables. For example, when waiting on external dependencies required in order to proceed.

I have used models like these to sanity check project offers within the same size range and with similar process characteristics. Not mechanistically, but as indicators to see if there are areas in the plan/offer that require closer attention.

Also, how can you estimate optimum staffing levels from this model?

If you have and optimum duration of T months and effort of MM persons*months, you allocate the staff to complete MM work in T time. Your average staffing level is MM/T persons.

Of course, in practice having a steady MM/T staffing level is not optimal. Start with a small team to get the high-level architectural issues settled and then grow the team only after there's something useful for new persons to do.