10 Mar
As of recently I have gotten really into the estimation topic. There are many reasons for that. Firstly, I wanted to improve my company’s finances by losing less money on poorly estimated contracts. I also wanted to reduce the pressure on my developers – when estimations and deadlines are realistic, there is less stress and the team is happier. And finally, I simply wanted to cut the time I spend on estimating requirements.
My team and I are now producing highly accurate estimates, applying all the knowledge I have recently acquired. After all, I have been researching this topic for over a year now. It’s safe to say that my estimations were not always as accurate as they are today – they were way worse in the beginning of my career in IT.
How it all started
I started my journey into IT very early, as a teenager, with small projects. I’d like to tell you the story about the first paid project I did. I was in high school at the time and, somehow, my friend Jarek and I were asked to create an online card game (“The Black Lady”) for a card game association. Mind you, this was almost 15 years ago, and online games were not that popular back then. The idea was to allow association members to play the game remotely. This was interesting because these people usually met on a regular basis to play, but not everyone could always attend the session.
Of course, the major challenge for Jarek and me was a question about the technology to use and whether we can deliver such a difficult project. Money didn’t play the main role here, we were happy enough to get “real” work in programming. We estimated the cost of the project at £200. This doesn’t even cover a developer’s hourly rate, but back then what mattered was that we get to do something for money, something real that people will use. Given the same project today, I would estimate it at £5,000 (that’s just for a game people can play online, without statistics, no backend or other features and modules like that).
We delivered the project in a couple of weeks and it was used for a bit by the association. It had some bugs that were noticeable if players were not following the “happy scenario”. We did not provide any support as it wasn’t something we agreed. Eventually, the project was shut down after a few months. As I see it, it was more a proof of concept, a marketing tool rather than something to be used in a serious environment.
Things like this happen these days too. You can find people who are willing to deliver a project at a low cost so they can build up their portfolio, or even just for fun. Such projects are always underestimated and tempting for those who want to build something on a budget. Unfortunately, such projects rarely succeed and contain a huge technological debt – definitely something to avoid in the business world.
Moving on up
But let’s move on to my first more serious project, which still only involved a silly amount of money. When Jarek and I were studying computer science, we were asked to solve a particular problem for the highschool I graduated from. This school, one of two in the country that was running classes in an “experimental model”, had a problem with signing students up for the courses. The idea of this model was that students sign up for teachers and attend lessons they are interested in, creating their own course plan every trimester. They, of course, have to attend all mandatory courses, but other than that can freely choose their classes.
This creates a real headache when planning the courses, and even more hassle allowing one thousands students to sign up for various classes while maintaining pupil limits. This is somewhat similar to what Bill Gates had solved as a teenager for his school’s class-scheduling system, but from the other side.
We accepted the challenge, got some ideas and help from the school staff, and we got to work after agreeing that for this project we would charge £1,000. Again, we were students, it was great to have the ability to solve a real life problem, and money wasn’t that much of a factor.
Today, I think it would require around £12,000 to deliver this high quality product within a reasonable time. It took us several months to accomplish the final version of the product, and the school used it for a while.
After we stabilised the product, we were asked to estimate the cost of creating a bigger project to manage student’s scores, among other things. By that point we had gotten more experience both in programming and in doing business, so we could better price the value of such a project. While the first project we made for them was more of a favor for school staff and it felt great to help our former teachers, the new project was funded from the budget in a more commercial manner. We estimated the cost at £20,000, including the ongoing support, training and other important services.
This estimation was more realistic – currently, I would estimate it at £30,000. The difference between the accuracy of the first estimation (£1000 to £12,000) and this one (£20,000 to £30,000) is dramatic. The reason why we were more realistic was because:
- We knew what value the product would bring to all parties (school staff, students and their parents)
- We had experience from a previous project and knew what workload to expect
- We were much more experienced and skilled
This estimation did not go through, though, and it was actually our fault. The client could not understand where such a dramatic increase in price came from. Our first project was just very, very badly priced. We weren’t suggesting a more agile approach, nor did we suggest options in budgeting such a project.
Afterwards, while studying, I worked as a software developer at Ink Aviation. This is where I finally started learning about best practice and how to estimate properly. During this time I learned how to compile better estimations, how to use safety margins, and how to split requirements into reasonable groups. I wasn’t perfect, but my estimations were definitely becoming more and more accurate, allowing for profit.
In conclusion
There are two takeaways from these stories. The first one is that developers (especially juniors) tend to underestimate their workload. Developers can be way too confident in their skills and approach work very optimistically. They are also challenge-driven – sometimes the opportunity to do something new, fun or challenging is more precious to them than another round of numbers in their bank account.
Secondly – never underestimate your value. Don’t be tempted to bid to win. You will eventually win the contract, but you will not make any profit, and you will make the client expect low, unrealistic prices from you in the future. In most such cases it will be very difficult, even impossible, to later increase your prices to a profitable level.
Piotr Pozniak is the co-founder of The Beaverhead, a business process optimisation company, and the brains behind The Estimation blog. Before establishing The Beaverhead, Piotr worked as a software developer creating high-end products for the aviation industry. He saw how enterprise software is built, what the challenges are and how it works, and he wanted to provide that quality to smaller businesses and entrepreneurs. Over the years, Piotr has worked towards becoming a software cost estimation expert, and today he shares his knowledge through The Estimation blog.
Piotr Pozniak