Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
By signing up for your free account, you agree to receive e-mails from Triggre.
By signing up for your free account, you agree to receive e-mails from Triggre.
It was the summer of 2001, when I walked into the office of a small student recruitment agency. They were in the business of finding exceptionally talented students for part-time jobs working in the IT industry.
For students, it meant bringing their knowledge into practice, while for the companies it was both an opportunity to get work done at a low price, as well as a recruitment channel. But I was there for a different reason.
The recruitment agency had asked me to custom build their website. Nowadays you wouldn’t build your own CMS, but in the early days of the internet, this was more common. So, there I was, ready to talk requirements on a hot summer day, in the souterrain of a canal house in Amsterdam.
Across the table from me was one of the owners of the agency. They explained in detail what the goal of the site was, which functionality he wanted and how things should look. We made a few changes to the sketches he had already made, and I was good to go.
To give an accurate quote, I broke down the work into smaller pieces. Designing the database, writing code to retrieve and store data, and code to handle the functionality. Finally, writing HTML and CSS to make sure the site would look nice in all browsers.
I then estimated each piece separately, making sure no single estimation was higher than 1 day of work. If that was the case, I would break it down into smaller pieces. Grand total: about 10 days.
With the estimation and the work in hand, I started coding. I already had considerable experience at the time, since I was used to doing a lot of similar coding, so I was confident in my estimations. As I was coding, I continuously checked how much time I had for each piece. This forced me to work quickly and effectively.
After I had finished coding and testing I had spent exactly 4 hours less than I had estimated. The site was now ready to be tested by the agency.
When I entered the office of the recruitment agency again, the owner was already there. He had tested the site and, apart from a few minor pointers, it was completely to his liking. Then he told me that he didn’t expect me to finish this quickly. He had actually anticipated the project to take 1.5 to 2 times longer!
I was perplexed, I had given him a very detailed quote, which he’d accepted and he expected me to take longer than I told him? What did he know about how fast I can work!? So I decided to ask him why he thought I would take so much longer.
In his experience, he had never had a project done in the estimated time. It usually took at least 1.5 times longer than projected, which is why he had already factored in this number. He then told me that he did the same towards clients. A student would give him a quote, he would double it, and present that to his customer.
It all seemed strange to me, these were people that were good at what they did, had some experience with it, yet couldn’t estimate a simple project correctly… I didn’t give it much more thought then; my customer was happy and I was happy having done a good job.
Years later, I encountered similar situations in software projects where I wasn’t the one making the quote. It only then occurred to me that there was something that most quotes have in common, which leads to the estimation being incorrect.
Where I had broken down all my work into neat little pieces that were easy to estimate, this is not always possible. There are several reasons why this is the case. The most common one is that not all requirements are known when the quote is requested, making it very hard to give an accurate quote. Estimating for uncertainty is something that is bound to be inaccurate.
Another reason is that usually the work isn’t broken down into smaller pieces that are each estimated separately. Rather, the project is estimated as a whole, or in big chunks of work. Humans are notoriously bad at estimating, which means that the larger the chunks are, the bigger the difference between the quote and the actual effort will be.
The final reason is the most important one. You have requested a quote. But you have not requested a single quote. Usually, you request multiple quotes. And the most important decision factor is price. This means that companies will often leverage the fact they don’t know all requirements. They will estimate everything that is known, but leave all other points open. This will of course be ironclad in the fine print.
To get a good quote, it is very important to have someone who can judge the details of the quote. And I don’t mean the financials, that’s the easy part. It’s about the technical details. You will need to involve one of your team members who can identify what has been left out, even if it’s not specified.
The most overlooked aspects are usually security and testing. Testing should simply be part of the quote, as well as fixing any issues that emerge from testing. Security is a very costly aspect if not done right. And getting it right, is hard. So, make sure to get a security expert involved in all of your software projects, as early as possible.
And the last thing you can do, is to ask for a fixed price for the entire project. This can identify the points of the quote that have intentionally be left open. Because when the company knows they cannot charge you more if it costs more time, it is suddenly in their best interest (instead of yours) to get the quote right.
