Why development

always takes longer

than expected

Why development always takes longer than expected

As an electrical engineer and biomedical engineer I have been involved in many development projects. I often had discussions about questions like “Why did this development project take much more time than expected?” or “Why can’t you give me an accurate estimate on how long this development would take?”. In many cases these discussions were with investors or managers with little experience in high tech product development (although investors and managers that do have this experience might recognize the discussions too). In this post I would like to present my personal view on this topic by using a simple analogy: A bike traveler going from point A to point B.

Imagine this: Your boss comes in and asks you to give an accurate estimate how many days it would take you to travel from Gemert (small town in the Netherlands) to Wuzhenzhen (a town in Eastern China). By bike. This would translate to a large development project in our analogy.

First you would need to calculate the distance. You need to decide which countries you would cross, since some countries might be easier to travel through than others. This can be translated to a rough planning of the project and schematically drawing the outlines of the project. Then you would need to calculate the distance between places in the countries you would cross, resulting in a total estimated distance. This would translate in a more detailed description of the tasks that are needed for the project. Using the average traveling speed, an estimate on the total traveling time can be calculated. This would translate to estimating the time needed for each task and resulting in a total estimated time for the project. Done.

a simple analogy: A traveler going from point A to point B by bike

In a perfect world this would be a good estimate. But what if your bike is broken and no repair shops are near (you found this great component, but there is no stock and the lead time is 9 months)? Or what if you get injured and have to go to the hospital (one of your key developers is not available for some time)? Or what if some roads you chose earlier are forbidden to travel by bike (you made a design choice earlier and some necessary features are impossible)? Or what if the customer decides that the destination location changes to some other town in Eastern China (the specifications of the end product are changed).

Any developer can name many more examples of problems that can occur along the way. Common for all these problems is that although you can be certain that a problem will occur, you don’t know when or which problem. This does not mean that technical people are bad planners. It just shows that the uncertainties related to high tech developments are unpredictable. Common for all these problems is that although you can be certain that a problem will occur, you don’t know when or which problem will occur

This does not mean that technical people are bad planners

The best estimate is probably the perfect world average speed estimate with an added penalty for the uncertainties. These uncertainties depend on several factors, for example how experienced the traveler is (they take less risk, are in better shape, have more knowledge on traveling through different countries, etc.) which translates to the experience of the developer. An experienced developer can better estimate which uncertainties can occur and what the estimated chance of occurrence is. But also external factors play a role; do not underestimate a change in specification in the end product (even though it might seem small at first). It will result in a different route and seldom a shorter one. But also distractions can result in a non proportional loss of time. If the traveler has to stop often to do push-ups it will also affect the average speed during the remaining time on the bike. If a developer is interrupted often it takes additional time to “switch” back to his development project.

So next time that you ask your developer how long a certain development project takes, remember that the estimate is probably based on a best case average time plus some penalty time for expected problems. The latter is highly person dependent and often underestimated.

About the author

Frans Kanters received his M.Sc. Electrical Engineering and his Ph.D. Biomedical Engineering both from the Eindhoven University of Technology. During his Ph.D. he founded a company mainly focusing on consultancy in the field of image analysis. After his Ph.D. Frans worked part time as a researcher at the Eindhoven University of Technology and also received an Executive Master of Business Innovation from Tilburg University. In 2013 he was co-founder of a company developing intelligent camera technology for sports applications and in 2017 he co-founded Next Generation Technology, a company which focuses on critical communication technology. During his professional career Frans has been involved in many high tech development projects.