*"My husband has worked out an effective formula for how long I will take for any software engineering task: I work out in some detail how long I think I will take, and he multiplies by 3. Never fails."*

Steve and John have stumbled upon one of the great mysteries of the universe here, and he has clearly used appropriate rounding to come to this conclusion.

Having been involved in engineering, project management and costing for longer than I care to remember, I have used that trick regularly. Even this week I found myself explaining my method of costing to an apprentice. Although it seems slightly random and spurious to do this, a healthy dose of pragmatism has taught me to trust it, but only in the right circumstances.

For ordinary, 'low risk', projects and for purchases of bespoke items, I have always taken a few moments to consider how long it might take and how much the materials might cost, then added those values together and then . . . multiplied by the well-known mathematical constant, Pi (or 3.14).

Some 'scholars' tell me that I am being unnecessarily pessimistic, and that instead I shouldn't use Pi. They usually suggest the use of another universal mathematical constant, namely e (which has a value of 2.72). However, this hardly matters, because being a pragmatic/engineering physics type person - I work to one decimal place and usually try to encourage the clever people around me to do the same. I'm not always successful.

One trick that I use when presented with a 5 digit result from a complex engineering calculation is to challenge one of the first few digits. e.g. faced with a number like 5.6789, I might ask "Are you certain that the second digit is 6?" and when they look surprised I might back up the question by choosing one of the numbers that they used as the basis for their calculations and ask where they got it from. (Something like - "What value have you used for the emissivity of stainless steel at that temperature?" might do it.)" After that it is often sufficient to know that the answer is 'about 5 or 6', not 5.6789. This is not as imprecise as you might think. Knowing that it is 5, and not 0.5 or 50 is often very valuable.

This brings us back to the estimate of 3! Perhaps now you can see that it is close enough, because the errors in everything else are bound to be bigger, and from experience, people are usually optimistic in their estimates - even if they know that people are usually optimistic.

Incidentally, for more risky projects this rule breaks down. If the planned work is something that has never been done before, then I might go for a different factor such as Pi squared (or 10). Once again, one can argue about the accuracy of this rounding to 10, but at a value of 9.87 it is much closer to 10 than you might have expected, and definitely more accurate than almost any of the assumptions that you might use in your estimates.

From experience, since many people shy away from risky technical projects it is often possible to get an order for something that appears to be blatantly over-priced. However, from having managed projects like this sometimes in previous roles, I would say that the few cases where you beat the risk and make a killing barely cover the many cases where you encounter such great difficulties that you lose your shirt. That is why risky one-off projects sometimes seem expensive.

Of course none of this works in a mass-production environment. I remember a story about the development of the Ford Fiesta (which was sometimes known as the Ford Fiasco in the early days). I think the first car cost £500,000 to build. (In the late 70s that was a

*lot*of money!) Then the first batch of 10 cost £40,000 each. Ultimately the selling price of the vehicles came down to around £5000 or less, so it is clear that the build cost was lower.

## No comments:

Post a Comment