How we change what others think, feel, believe and do
Estimation made easy
Estimating how long a project is going to take and the resources needed is never an easy task. But, by using a tool or two it can be made a little easier, and perhaps a little more accurate.
The Rule of Two
The simplest rule of thumb for estimating is to multiply every estimate by two. Although it may seem a little crude, this rule is based on some well-known facts of life, namely:
· We tend to be optimistic about estimates, assuming the best possible conditions and that risks will not occur. Unfortunately, people go on holiday, get sick and leave. Customers change their minds. Suppliers do not deliver on time. A thousand things can and do go wrong, as someone called Murphy once testified.
· There is pressure to complete the task in a very short space of time. We want to be customer-friendly or avoid the boss having a heart attack, so we estimate according to what they want, rather than what is realistically possible.
· If the project involves a test phase, we assume we will only need to run the tests once. Test overrun, especially in such new technologies as software, can be massive.
· We estimate assuming that we will be spending all our time on the task. In fact, all of those interruptions and telephone calls will still be there.
And so on. The bottom line is that you always need more time than you thought, and even a factor of two is not always enough to keep the over-schedule demons away. Overall, though, this simple rule can be surprisingly accurate and has saved the neck of more than a few project managers or estimation 'experts'.
The Delphi Method
This is a useful method when there are a number of people who can give estimates and where those estimates may be significantly different from one another. It works as follows:
1. Ask all members of the team to independently estimate for the task and to return their estimate to you without letting the others know the figure upon which they have decided.
2. Collate the responses and send out the list of different figures to the team, asking them to reconsider their original estimate in the light of this range of values. There is no pressure on them to change their estimates, but those who were uncertain about their original figures are likely to moderate their estimates towards the centre of the overall set of estimates.
3. Step two may be repeated as often as required, although one iteration is often enough. Consider repeating the step if estimates have change significantly.
4. Calculate the final estimate with the following formula:
Final estimate = (lowest response + (4 x average response) + highest response) / 6
The historical database
A very good practice if you are going to be doing a lot of similar estimation is to keep a record of the actual times taken for the project, along with characterising details of the project, such as the number of people involved, complexity details, some measure of project size, etc.
The new estimate may now be based on the actual times from real past projects. As you improve the database and the method of interpreting the data within it, your estimations will improve.
By successively breaking down tasks in to smaller and smaller pieces, you will end up with chunks of work that are reasonably easy to estimate. This activity may be helped with the use of a Tree Diagram. The whole task is then simply reassembled for the final estimate of total effort, although calendar time will depend on how the tasks interrelate, what can be done in parallel, how many people are available, etc. An Activity Diagram can be useful to calculate the critical path through the final network.
This ancestor of modern quality still has its uses in determining how long simple repetitive tasks will take. And although quality has spread from the factory to the office and beyond, the use of Cyclegraphs, Micromotion Photography and other such methods can still have their uses. The results can be kept in a book of standard times for standard tasks.
Some situations, such as building software database applications have been mathematically modelled, and all you need to do is plug in appropriate data, such as the number of screens, for the estimate to be produced. Beware of generic models: any model will almost certainly need to be calibrated for your specific environment before it can be proven and thus used with any real degree of confidence.
Surprisingly, perhaps, in the modern environment of computers and automation, there are still a number of situations where wheeling out the hoary old expert to sniff the air and cast the runes is still the most reliable method of estimation. In complex situations, the depth of actual human experience, coupled with the ruminations of the subconscious brain can beat the best of the rest.
But beware. Some witch-doctors are very good at hypnotising their audience into believing that they really can make it rain in the Sahara. As with other methods, only believe what is proven. Find yourself an expert, test their efficacy then pickle them in the best vinegar, pulling them out for the critical quotation before shutting them safely back in their box!
Next time: Pareto Diagram
This article first appeared in Quality World, the journal of the Institute for Quality Assurance
And the big