After graduating, I was not only in a position to implement large software projects with hundreds or even thousands of development hours, but also to appreciate them. Since the age of 18, I have always been involved in the development of software projects alongside my studies. Some of them even ran productively in 24/7 operation in plant parks. However, these were mostly smaller projects with a manageable scope. After my Information and Computer Science degree, I had the theoretical tools to develop complex functionalities. But that hardly helped me to make precise project time estimates. On the contrary: today I am convinced that too much theoretical computer science knowledge can actually lead to poorer estimates.
As a result, we spent almost twice as many hours on our second major project as initially planned - such an inaccurate estimation that took us a lot of time and nerves at the time. Due to my background in mechatronics, I'm certainly not the best software developer. However, exactly the same thing happens, or even worse, to extremely good computer scientists. I still remember a situation during an Industry 4.0 training course. During the training, it was mentioned that company XY is working on an Industry 4.0 app that automatically records plant downtimes and forwards critical messages via SMS to on-call technicians during the night shift or at the weekend. Sitting next to me was an extremely talented developer who stated confidently that this kind of app could be programmed easily within a week and would be robust for use in production. He held firm to his opinion - which led to surprised looks and noticeable skepticism from the experienced industry professionals in the room.
Substitution heuristic
Today I know that many here fall victim to the substitution heuristic. People like to replace a complex question with a simple one. For example, instead of carefully analyzing the question “Is this person competent?”, we might intuitively find an answer by replacing the question with “Does this person make a likeable or trustworthy impression?”. Kahneman describes this in detail in his book Thinking, Fast and Slow. In my opinion one of the best books ever and I recommend everyone to read it.
For a realistic time estimate of the Industry 4.0 app in particular, we would have had to answer numerous questions:
- How many different controllers and data protocols does the app need to communicate with?
- Are there any data security risks?
- How are critical and non-critical messages differentiated and prioritized?
- How are the machines in the plant park connected and which servers are allowed to communicate with them?
- Is there a database interface necessary to find out which technicians are currently available?
- What does the user interface for the connection look like?
- And much more...
However, the actual question was probably replaced by a much simpler one:
“How long do I need for a prototype that works in the simplest standard case and sends an SMS to my cell phone?”
The example from the training course was certainly an extreme case, but it shows a common problem: the Prototype vs. product substitution heuristic are one of the most common reasons why time estimates are off by factors.
A prototype often works under ideal conditions: with simple interfaces, without security aspects and without taking into account the real system complexity. A market-ready product, on the other hand, has to survive in a multi-layered environment - and it is precisely this discrepancy that is often not taken into account in the estimation. This leads to projects that take not just a few hours, but often tens of times longer than originally planned.
Young team, bad estimation
If you start a company very young, you often have small, young teams. As a result, there is often no one in the team with the project experience needed to deliver good estimations. However, misjudgements can quickly lead to the failure of the entire company. Before I move on to possible solutions, I would like to give another example that clearly shows how such incorrect estimates can be made by young developers.
We originally planned around 800 hours for one project. In the course of this project, the opportunity arose to integrate a small part of it - the development of a more extensive motion control system - into a bachelor's thesis. For the implementation, we had to teach the student modern software development, unit testing and the basics of motion applications in general.
An experienced developer from our team would probably have needed around 200 hours to fully develop the motion control, including all tests and optimizations. However, as this was the first implementation by an inexperienced bachelor student, we estimated the effort at 800 to 1000 hours. However, the student herself was convinced that she could manage not only the motion control, but the entire system - including dozens of other devices and hardware, HMI, error messages, data interfaces and unit tests - in just a few hundred hours. A huge miscalculation. At the end of the day, the core task of the bachelor's thesis had been completed after hundreds of hours, but had to be expanded considerably in order to actually be used productively. It would probably have taken years to fully implement the entire system. And that is completely normal for a first project - but in practice you rarely have this luxury of time.
This type of misjudgment and overestimation is particularly common among people who have learned a lot in a short period of time. In this case, too, they continued to learn on the job alongside their practical work. Unfortunately, this often leads to a massive overestimation of one's own abilities. People have the feeling that complex projects can easily be completed in a few hours on the side. However, this overlooks the fact that the tasks in teaching or practice projects are usually clear, unambiguous and very limited. The substitute heuristic “Which additional projects did I complete last year?” often leads to massive misjudgements. It overlooks how many side quests real projects contain: unclear requirements, feedback loops, technical hurdles or unexpected problems. What's more, in practice you don't always have the right textbook or the perfect step-by-step guide right next to you.
How to achieve better estimations
Delivering accurate time estimates is both an art and a science in itself. However, it is essential for companies to master this skill, as incorrect estimates can endanger not only projects, but entire companies.
In the coming blog posts, I will go into detail about the most common traps and practical approaches for better estimates. As a comprehensive analysis would go beyond the scope of this post, here are some quick tips to give you some initial inspiration.
First and foremost, two book tips:
Thinking, Fast and Slow by Daniel Kahneman
Hands down my favorite book. It has changed my view on many things and helps me in all kinds of situations. It's amazing how bad humans are at estimating things, and even more surprising how small things can influence us. A small example:
Study participants were asked to estimate the height of the tallest coast redwood tree, but with a special twist. Two different groups were given different “anchors” to influence their perception:
- The first group was asked whether the tallest coast redwood was higher or lower than 366 meters before giving their estimate.
- The second group received the same question, but with a significantly lower anchor of 55 meters.
The results were remarkable: the group with the high anchor (366 m) estimated the average height to be 257 meters, while the group with the low anchor (55 m) estimated only 86 meters. This difference of no less than 171 meters clearly shows how strongly initial information can influence our judgments.
Noise Olivier Sibony, Daniel Kahneman und Cass Sunstein
Quasi the sequel to Thinking, Fast and Slowalso by Daniel Kahneman. However, this book specifically addresses how to minimize misjudgements and recognize systematic biases - not only on an individual level, but also in a corporate context. In my opinion, an absolute must-read for anyone with project responsibility.
Data for baseline estimation
Even more important than the theoretical knowledge you can take away from these two books is the development of a solid data basis. To do this, you need the right tools to accurately book and track project hours. Once sufficient data is available, future projects can be estimated more realistically by comparing them with projects that have already been completed - projects where you know exactly how many hours were actually needed for implementation.
At AutoLab, we have introduced Tempo alongside JIRA and record every single minute either on a project-specific or general basis. The historical data makes it much easier to create accurate future estimates. It also gives you an accurate picture of what percentage of the business is consumed by so-called “overhead”.
I will explain more about this in another blog post. For now, however, I can only strongly recommend introducing time recording. It prevents flying blind and sets clear limits to purely subjective estimates.
English (UK) 
Deutsch
Leave a Reply