We’ve all made commitments to complete tasks by a certain deadline that later proved impossible to meet – it’s human nature. Most people, irrespective of their gender, race, nationality and age, display what is known as optimism bias – a tendency to overestimate the likelihood of positive events [1]. When we make plans, we expect things to go smoothly, with hardly any issues getting in the way.
Optimism bias is only one of many challenges that organisations face when estimating web projects. At the start of the project the levels of uncertainty are high which means that developers aren’t able to estimate some technical tasks until they are well into doing the actual work. Some terms are not well understood, some skills are missing. In addition, the deadline for the project, and the pressure that comes with it, is often predetermined by external circumstances which have nothing to do with the organisation’s ability to deliver.
Despite these challenges, estimation of web development project isn’t something that an organisation can choose not to do. If no estimation is done at all, the project simply cannot go ahead. Fortunately, there are techniques you can use to make your estimation efforts more successful.
Addressing optimism bias
Optimism bias makes people unrealistically positive about their own future, however this skewed perception doesn’t happen when estimating other people’s work, and is also less pronounced when evaluating work that has already happened in the past. Therefore several people with appropriate experience can estimate work more accurately than a single developer who is tasked both to estimate and to deliver a certain task.
One estimation technique that is used in agile development to address the issue of optimism bias is planning poker. In planning poker, developers discuss a feature and ask questions to make sure that the requirements are clear. After the discussion has taken place, developers estimate the feature individually using ‘poker cards’ which assign a number of units (such as hours, days or effort points) to the feature. The average estimate is then revealed which gives the team an opportunity to understand why some developers rated the job as a much simpler or a much harder task than others. Through this process the team uncovers different perspectives and new information which makes the final estimate much more accurate.
Dealing with uncertainty
At the start of every project there is limited information about what exactly needs to be accomplished. Project goals and success criteria should be clear from the outset, but you might not know how to get there in a detailed, step-by-step way and you might not even have the skills within your team to understand it better. As the project progresses, you will learn more and more, and the uncertainty will be reduced over time, until at the end of the project there will be no uncertainty left at all.
Project managers deal with uncertainty by building in contingency that matches the worst case scenario in relation to each of the unknowns. If some of these unknowns turn out to be easy to resolve, then this is good news.
For web agencies adopting this approach, the obvious risk lies in the possibility of being outbid by a competitor who managed to remove some of the uncertainty and arrived at a genuinely lower estimate. A more transparent and helpful response may be to outline the areas of uncertainty and provide a price range which can be further negotiated once more information is available.
Difference between estimates and targets
Sometimes a hard business deadline lands on a developer’s desk, with no regard to the other tasks the developer is already working on or the little time left to complete it. It’s not uncommon for less experienced developers to reverse-engineer their plan in order to match this unrealistic target date. This is not a healthy habit – cutting corners can lead to unmanageable stress levels and can affect the quality of work.
In order to avoid this scenario, it is important that managers and developers alike acknowledge the difference between estimates and targets. Estimate is an attempt to predict how long a job will take based on the information available and also past experience of doing similar projects. By definition it can’t be a completely certain, 100% guaranteed promise. Predicting the future just isn’t like that. By contrast, a business deadline is often very specific and definitive, for example it may be tied to an agreed date of a merger or a date when a new legislation comes into force.
Measuring effort
The end goal of estimating a project is to find out the total time and cost needed to complete it. Traditionally development teams estimated their effort in person-days, and the total estimated cost of the project was calculated as person-days multiplied by the daily rate. More recently agile development teams started to use story points instead of person-days as part of the agile methodology. Story points are abstract units of measure that represent the effort required to build a feature. The more complex the feature is, the higher the number of points. Story points follow Fibonacci sequence (1, 2, 3, 5, 8, 13, 21 and so on) which reflects the fact that complexity of development tasks doesn’t increase in a linear way. Developers find story points less stressful because they are no longer linked to hours and are less likely to be misconstrued as a promise. It is then up to the project manager to use this data in order to predict estimated time and cost of the project.
Degree of precision
Precision isn’t the same as accuracy. If your project estimate comes at $236,102.23 it may create an impression that the chances of this estimate coming true are very high, but of course this isn’t the case. It’s a good idea to round up all the figures (including daily rates and timescale assumptions for example) so that the numbers are easier to read and compare.
Instead of focusing on precision, concentrate on how accurate your estimate is and how helpful it is in the context of moving the project forward.
Conclusion
Estimating large web projects is not easy. Even with significant previous experience of planning similar projects in the past, there will always be elements of uncertainty and relentless optimism bias. Address them by verifying estimates with more than one subject matter expert and resist the pressure to match up estimates to externally driven business targets. If you’d like to learn more about estimation, I recommend excellent books Software Estimation – Demystifying the Black Art by Steve McConnel and The Black Swan: The Impact of the Highly Improbable by Nassim Taleb.
[1] https://www.cell.com/current-biology/fulltext/S0960-9822(11)01191-2?_returnURL=https%3A%2F%2Flinkinghub.elsevier.com%2Fretrieve%2Fpii%2FS0960982211011912%3Fshowall%3Dtrue