In the project management world, “How much time do you think this will take?” is often a loaded question. This is true not only when senior managers ask this to a project manager, but is also true when a project manager asks this to a developer or other team member.
As a former developer, my knee-jerk response when asked, “How much time…” was almost always to respond with the correct answer – but under only the best possible conditions and outcomes. It was only when I began managing projects that I saw how often my estimates were low and began to understand why. I’ve coined this under-estimation of work effort on an individual task or unit of work “Developer’s Optimism”, though it’s just as likely that any other member of a project team could make this mistake. Developer’s Optimism has many causes, but it can be alleviated using a few basic cures, or adjustments, to the estimating process. I’ll explore both the causes and the cures in today’s blog.
Developer’s optimism is, on the surface, what the phrase states – a well-meaning software developer or other expert on the project team gives an estimate that is theoretically possible but highly unlikely. In most cases, the developer may be quite experienced, yet their estimate only has a one in ten chance of being accurate. Why?
It’s not that the developer wants to ruin your estimate, though you may begin to believe this is the case if you’ve had this occur with the same person repeatedly. In nearly every case, he or she has made one of six mistakes in their estimating that you need to help them avoid, as described below:
- He did not include unit testing. In most cases, a developer will not include unit testing in their estimating, particularly if you phrased the question as we did in the first paragraph. In most developer’s minds, the work is done when the last line of code has been written on an alpha version, not when testing has been completed. This common difference in dividing lines can throw off your estimate by 10-25% or more.
- She did not include re-work. Perhaps all of your developers do perfect work and they deliver the first version of their code working exactly as your specifications are written. But, then the client takes a look at the outcome during a prototyping session and says she’d like a few changes. Depending upon your client’s level of scrutiny and detail, this could bias your estimate downward by between 5-50%. Sure, change requests can add hours to cover this, but isn’t better to plan for a moderate amount of change in advance, rather than come back and asking for more time and money mid-project?
- He estimated based on his own skills and not those of others. Hoping for a better estimate, project managers nearly always go to only senior developers, designers and architects to benefit from their experience – big mistake! A senior developer will almost always tell you how long it will take them to do the work themselves, not how long it will take the average developer. Inevitably, when the time comes for the project manager to staff their team, the senior developer is not available and the estimate is unrealistic. In this scenario, it could take as little as 10% and as much as 10 times longer (yes, doubting senior manager reading this now – 10 times!) for an inexperienced developer to complete the same work as an experienced one – particularly if the senior developer is not available to provide coaching or guidance.
- She estimated her portion of the work but did not include the work of others. In this case, she’s spot-on with her estimate, but she’s the user interface (UI) developer and not the database developer. So, if you use her estimate, the hours are gone and the UI looks beautiful, but the database queries/procedures aren’t written and the graphics haven’t been spruced up by the graphic artist.
- He did not include bug-fixing. Depending upon how you estimate testing and quality assurance, you may or may not assume that the developer has included time to make bug-fixes in their estimates. In most cases, he has not done this, because bug-fixing often occurs weeks or months after the code was written. Depending upon the complexity of the task and experience of the developer, bug-fixing typically takes between 10% and 30% more time than completing the work itself.
- She did not account for complexity and risk. In some cases, project managers never ask the critical follow-up question to “How long will this take?” — “How hard is this?” When asked, we begin to understand how complex and risky the task actually is. Particularly if a project involves many high risk tasks, one of these tasks is certain to face many setbacks as it is developed, blowing our initial estimate out of the water. For high risk tasks, it’s not uncommon for the task to have a 25% chance of taking twice as long.
Fortunately, project managers can cure their teams (and themselves) of Developer’s Optimism by taking roughly a half-dozen steps when making their estimates. These include:
- Asking multiple individuals to estimate. Instead of asking one senior developer, ask two or three developers of varying skills, then average their work.
- Use analogous estimating. Analogous estimating uses historic project data to look back at the level of effort spent to complete similar tasks in prior projects. It then adjusts them based upon the differences between old and new to estimate time for the current task. As a result, analogous estimating takes away some of the risk of downward bias that is so common when project estimates are developed.
- Make it clear what “this” is. When asking the question, “How much time will THIS take?” make it very clear what THIS entails – are you assuming THIS includes unit testing, bug-fixing, re-work, the work of other team members, or none of the above. If none of the above, be certain to include these in your own, separate estimate.
- Add “…an average developer…” to the question. Instead of placing the developer in the position of assuming they will do the work, ask them to assume that they WON’T do the work by rephrasing, “How much time will this take for the average developer?” In many cases, the developer can remember their skills when they just started or when they were a few years on the job, and will give you a better estimate.
- Assess complexity and risk. For each task and the project as a whole, conduct a risk assessment and set aside a legitimate number of hours for risk contingency based on the probability of a specific approach to completing a task failing and the likely number of hours to develop an alternative if the primary fails. Risk management is a key discipline in project management – one that impacts your estimation as much as it does your execution of the project.
- Use PERT. Not a shampoo, many project managers have encountered Program Evaluation and Review Technique as a way to estimate project duration and level of effort. During the evaluation process, PERT asks individual estimators to provide three estimates – one optimistic estimate, one moderate estimate and one pessimistic estimate for the same activity. PERT then averages these three values using the formula, Expected time = ( optimistic + 4 x moderate + pessimistic ) / 6. While I tend to use 3 times the most likely and divide by 5 because I think project variation tends to be greater than 4 times the moderate estimate, I have found PERT’s estimating formula to be a good way to level out the bias.
An Optimistic Ending
Project estimation is almost always fraught with some degree of inaccuracy, so its not as though taking the steps above will result in perfect estimates. But it is possible to have a reasonably accurate outcome – one that consistently is + or – 10% for the entire project — on a vast majority of projects. To do this, however, project managers must take methodical steps to reduce innaccuracy. They must also ask their team members and their senior managers to take off the rose-tinted glasses before giving or speculating on an estimate.