The task was simple — to compute the total disk requirements for a new system (when disk space was scarce and expensive). Because everyone in the process built in a (cumulative) contingency allowance the final estimate was approximately six times reality. Indeed, more than the whole company used! The task had to be done again.

Estimating is an art and a challenge. An art in knowing what can go wrong and how long things really take; and a challenge in that if the estimates are not tight, effort will expand to the time available.

Goldratt, the constraints-theory man, argues that the solution is to take all contingency allowances out of estimates, collect them centrally, halve them and then allocate contingency out to tasks that are running late.

There is good psychology in keeping estimates tight.

Your ability to estimate is seen as a sign of professionalism — an indication of whether you know what you're doing. Therefore, if you estimate a task will take, say, 6 weeks and it is complete in 6 days this is not so much seen as good but as evidence of poor estimating. (In one organization I was in, a 6-month estimated project was completed in a week and was sat on by management for another 5 months to avoid any embarrassment! Subsequently delivered "one week early" the project was seen by the business as a success.)

So, when you estimate, there is little incentive to deliver early.

A simplistic solution is to reward delivery within estimate. But, perversely, this can encourage over estimates in order to come in within estimate and be rewarded. Can you win?

There are two dimensions to estimates — the actual workload and the elapse time to delivery. Most managers manage to the delivery date. The trick is to manage to the actual workload. You need to ask for example; How much effort will it take to develop, say, the simplified business case format? Why that long? What approach are you taking? Are there faster/better approaches? What would need to be done/exist to reduce this time? Now, when will it be ready (elapsed date).

Some Project Managers are reluctant to question their 'experts' on their estimates because the project manager is aware they don't know as much as their experts therefore think they don't have a strong basis from which to question any estimate.

But you do — its called experience and, above all, common sense.

Experience in knowing how long types of work really take (planning, scheduling, running and processing a workshop as opposed to just the workshop's duration).

Common sense in that their answers should make sense and be justifiable.

I once project managed an operating software development project. I have never programmed. But I could ask hard questions to establish if they knew what they were talking about or were 'hamming' it.

That's what you want to know. How sure, confident and clear are they? Be sceptical. If there is room for doubt, keep questioning. Make them convince you that their estimate is real, not padded and their due date is a challenge.