A recent project I worked on was proven to be severely underestimated by the architect. The estimate was out by at least 500%.
Unfortunately I was brought onto the project after the estimate had been signed off with the customer. As senior dev, I quickly realised that the functional and technical spec. contained some huge gaps and uncertanties.
As a result I felt compelled to call an emergency meeting with the business and technical directors to let them know the reality. As first and foremost a developer, I found this a very stressful and difficult situation. The "business" accused IT of being incompetent and being the messenger I received a few "bullets".
The customer threatened to cancel the account, however to date the project is still unfinished and I am no longer directly involved with it.
The architect was a nice guy socially, but based on this episode was either simply incompetent or there were large sales/business pressures influencing his estimate.
So, as programmers, what is your experience of this sort of situation and how would you advise dealing with it?
Best Answer
Long reply, but hey, I’ve got a summary on the end, so just skip to summary if you can’t be bothered reading the entire thing!
As a developer I had to deal with the situation literally every other project, but it's not until I moved into project management that I learned how to deal with it effectively. For me dealing effectively is about two things: managing expectations and understanding how estimation works.
Start with a premise that it is unethical to provide an estimate, commit to an estimate or give any other indication of estimate accuracy without being able to carry some due diligence first. Other people rely on your professional ability to predict an amount of work required, giving a false indication will hurt them and their business.
But you have to give something, in real life you dragged into an impromptu meeting or a late project and your superior will probably make it clear they expect you to come up with some figure straight away or comment on the estimate they provided. This is where expectations management comes into play.
Explain that it would be wrong of you to give any figure or any indication without understanding the problem and working the numbers out for yourself. Say that their figures might be quite correct, you just don’t know before you went through the estimation exercise yourself. And even though you might have a good picture of what is needed there and when, say that you still need some time to work the numbers out. There is only one estimate they might expect you to give: when you going to be able to provide an estimate. By all means do provide that figure.
As a developer never take responsibility for (or give indication that can be interpreted as acceptance of) other people estimates without being able to review them first. As a project manager it is a totally different matter, because then you actually have some control over the estimation process: the way an estimate is derived and reviewed and you have to rely on other people to get the actual work done and you need to make sure they are committed.
Never even comment on estimates without being able to do the due diligence. This is ethical. A lawyer or a doctor will make it absolutely clear they cannot give any advice unless a client (or patient) plays by their rules and goes through an assessment procedure first. You similarly have a right to satisfy your questions before giving professional opinion.
The second part is about how estimation works. I suggest researching various approaches to doing estimates and how estimation process works, including industries other than software development (manufacturing, financial markets, construction). This will give you idea what can be reasonably expected from you by your boss or client and, strangely, will help making more accurate predictions about the amount of work. It will improve your ability to defend your estimates and you will need to defend the figures every time they are different from the ones provided by an architect or a sales person.
Normally, the way it works, is that your estimate is first scanned for odd looking or relatively large items. Hence be prepared to defend anything with “non-standard” name. Also split larger tasks so that all tasks have same order of magnitude, i.e. if most tasks take 2 days and one single task is 10 days be prepared to get drilled.
Be clear about what is included in each task, its best to split dev and unit testing instead of just having dev and having someone assume that it includes documentation as well. Obviously this way you’ll need to produce a fairly fine grained estimate.
Next the drilling comes. Since it is quite difficult to review a long work breakdown your client or boss is likely to adopt a different strategy: concentrate on a random bit they might know something about and drill down until they manage to discredit the entire estimate or will be satisfied with your answers. The credibility of entire estimate might depend on a random sample! Hence once again, you need time to prepare it carefully, include only relevant bits, exclude any extras or move them to a “nice to haves” section and think through how you going to defend the figures.
Obviously you can be either consistent in your approach, i.e. estimating on the basis of features, number of screens etc or have a mix of approaches, but in any case be prepared to defend why you selected a certain way of estimation. Be also prepared to explain why your figures are different from whoever else’s attempt at predicting the amount of work required.
Learn the obvious signs of weak estimates:
Filled with general run-of-the-mill tasks, copied from template (good estimates are specific to the task at hand).
Coarse grained estimates (i.e. tasks longer than couple of days).
Estimates done on early stage of a project or by someone who might not have actual knowledge of the requirements or work involved.
Estimates compiled by people other than actual doers
Vague estimates (not clear what is included and, equally important, excluded).
Substantial difference in the order of task magnitudes.
Practise in evaluating other people estimates and drilling the figures without actual knowledge of implementation detail. This will help to back your claim for some extra time when pressed with the request to confirm someone else’s estimate when you have no hard evidence.
To summarise:
Do not commit to an awful or any estimate for that matter, before you had an opportunity to do due diligence.
Make it clear on the outset, don’t let anyone assume it is any other way and interpret your silence as a sign of agreement.
Know how various estimation methods work, their practical application and merits, including these outside software development.
Be prepared to defend your estimate.
Learn how to evaluate other people estimates so you don’t have to commit yourself to vastly inaccurate figures.