Project Estimates: A Collusion of Optimists!

Steve McConnell’s Software Estimation: Demystifying the Black Art revolves around the idea of a cone – a cone of uncertainty.

What this means is that software estimates are not simplistic single point numbers. These are probabilities on a number line. The probability of making the correct estimate is low at the beginning of a project. The deviation can be as high as 4 times either way. This variability is due to the variability in the software requirements. It only improves as we move into the design of the project. But this improvement does not happen on its own – it has to be controlled. Else the uncertainty remains pretty much the same till the end of the project – and the cone becomes a cloud of uncertainty instead.

While you read through the remainder of this article, take note of the “**” symbol and then read towards the end about it!

Imagine a regular day at the office. You have your head down trying to figure out which color scheme your client will like on their SCADA. your colleague from sales walks in and asks you,

” Remember that awesome project we were talking about the other day. how many hours do you think it will take to deliver it? “

You know you don’t want to answer this question, but it would not look nice if you don’t. So you think about it for a minute and come up with an off the cuff estimate of .. 1000 hours.

“Oh! That’s too much. I don’t think this will get us any close to getting the project. Can’t we do it in any less of a time? We did something similar last year too”. (**)

You nod to him and almost feel obliged to revise down the number to say 900 even though you have not worked on that previous project he was talking about.

So your colleague goes back to his desk and while giving the final touches to his estimate, shaves another 100 hours from it – assuming that you must have kept this much buffer in your estimate to be on the safe side (**)

Happy with the number, he takes his working to his manager. His manager thinks that we have the cream of the cream when it comes to our engineering prowess. The processes that we have – no one else does the expertise that we have has no match. We can easily do this project in what you had estimated minus 300 hours (**).

So your estimate was halved by the time it landed with the customer. Now let’s talk about the asterisks above.

** – The Fantasy Factor

Optimism is near-universal. It is found even at places you would least expect. In the above example, while you might find it hard to believe (and your colleague impossible!), but you did optimistically think about the effort. Most probably you did not account for the non-functional overheads in your estimate (e.g., ramp-up time, mentoring, performance tuning, demonstrating software to the customer, creating test data, etc, etc, etc.)

And the same goes for your management. They might optimistically think that a lot of things went wrong on the last project – we have learned our lessons and hence we will do better (but did we really learn our lessons or do we just want to make believe that we did as otherwise, we would look like nincompoops!)

Steve names this phenomenon as “Collusion of Optimists” in which,

Developers present estimates that are optimistic. Executives like the optimistic estimates because they imply that desirable business targets are achievable. Managers like the estimates because they imply that they can support upper management’s objectives. And so the software project is off and running with no one ever taking a critical look at whether the estimates were well-founded in the first place.

Steve McConnell: Software Estimation: Demystifying the Black Art

The book goes on and explains how to make the estimates better and how to negotiate or rather work together to get better estimates that can add immense value to your business. This brings me to the last part of this article.

Negotiating or working together?

So, if the organization is not able to make correct estimates of effort and cost, whose responsibility is it to make these correct? You might not like the answer, but major responsibility falls on the shoulders of the technical staff. For this, we need to understand the difference between an estimate, a target and a commitment and a bit of what it’s like being a salesman!

You can estimate that a project will take 1000 hours. But business may have a hard-external target to do it in 500. You know the nuances of the work better than anyone else. It falls upon your shoulders to find workarounds that best match the target. If you have tried all permutations and combinations and still the target cannot be met, then it’s better to walk away from the opportunity. But hopefully in a going concern, 8 out of 10 times you will be able to find means to meet the target.

Once the target is mutually agreed, it then becomes a commitment – that both you and business strive to meet.

An argument that you might present maybe – “I always try to explain why more hours are needed, but they always push back and never agree to what I say”.

There is a saying which is often attributed to Einstein that goes like this – If you can’t explain it simply, you do not understand it well enough!

You also have to understand that being assertive is a primary requirement of being a salesman. You cannot fetch business from the teeth of your competitors if you are not assertive and aggressive.

Expecting them not to be assertive is a luxury no company can afford in today’s competitive market.  

In fact, you should also be assertive about your estimates – and then you will find them receptive to your inputs. You will be surprised that they may even decide to walk away from a project if you explain and explain assertively. Steve’s book explains this art of negotiation in detail. I don’t want to take the risk of plagiarizing, so I leave it up to you to find it out for yourself from the book!

In the past, project estimation at Avanceon used to suffer from the same unhealthy dose of optimism when pitching projects. However, through synergy among departments, we’ve been able to understand where improvements are needed and how to make these.

But every day is a new day on the treadmill – and the same zest is needed to stay smart!