How to Estimate the Cost of a Software ProjectUsing a Three-Point System
Written by Hendrik. Mar 29, 2022
9
7 min read
Estimating the Cost of a new Software Project
As a Solution Architect, it's part of my job to roughly estimate the cost of a new project that comes in. This can be quite a challenging task and takes more time and effort than one might think. In this blog-post, I'll walk you through two approaches on how to calculate the cost of a project. I've applied this method to many diverse software projects that our clients commission.
Table of Contents
- Analyzing Requirements and Creating Tickets
- Estimating Effort Using a One-Point System
- The Problem With the One-Point System
- Improvement Through a Three-Point System
- Conclusion
At Incloud, the way we approach a project-cost estimation is by examining our client's project requirements, breaking the requirements down into concrete stories and tickets, and then guess the required effort to finish each ticket. Afterwards, a typical uncertainty and management buffer is added to the sum to achieve the final score.
However, estimating the required effort to finish a ticket is tricky. Even when estimating the effort with several developers, who have plenty of experience, it can still result in lengthy discussions and inaccurate guesses.
Analyzing Requirements and Creating Tickets
Let's start from the beginning. Once we receive a list of requirements and specifications for a potential project, the first thing to do is to analyze it break it down into individual stories and tickets, which our developers could later implement. Each requirement is written down in a thoroughly phrased ticket.
This breaks the entire project down into tangible and solvable problems. The amount of effort to complete each ticket will later be guessed.
Estimating Effort Using a One-Point System
Each ticket is discussed with a group of developers. Developers who are experts in the tech-stack required for the project are preferred for the estimation. After explaining a ticket, every developer writes down what they estimate the required effort (in half-days) will be. Once everyone's come up with a value, they show their cards all at once. Via Microsoft Teams this usually results in everyone posting their value in the meeting's chat after a countdown from 3.
If someone deviated too far from the average score, they're given the chance to explain how they came up with their estimation. After all discussions the agreed upon value (usually the average) is assigned to the ticket. This is then repeated for each ticket.
The Problem With the One-Point System
Ok, so the one-point system is pretty straight forward. But, what's the problem with it?
The main problem is uncertainty. There is a lot of uncertainty involved when it comes to a new project. The requirements might be fuzzy, vague or unrealistic. How to implement requirements might not be perfectly clear and other unforeseeable problems might arise during development. All of these uncertainties can't be depicted using a single estimation. Using only one value, it's not possible to estimate how long a ticket will take if everything goes well or if everything goes poorly.
Experience shows that developers tend to be pessimistic about their estimations in order to not underestimate a ticket and to have enough of a buffer to work with later on. As a Solution Architect who has to present an offer with an estimated price to clients, this can be frustrating because the estimated sum cost of the project is the most pessimistic estimate. This results in a higher price than might be realistic. It would be nice to somehow be able to have developers guess a span of values which I can then use to present a more realistic price range to our clients.
Improvement Through a Three-Point System
An improvement over the one-point system, where developers might guess a pessimistic value in order to not run out of project-budget later, is the three-point system. As the name suggests, each ticket will be estimated using three values, instead of one. The values are the best case, worst case, and most likely case. This allows a ticket to receive an estimated range of effort. A final single-value score is then calculated using the following formula:
E = (best case + worst case + (x * most likely)) / (x + 2)
where x can be any type of weight added to the most likely case. The higher the weight, the more the most likely value will be fed into the final score. Wikipedia recommends using a weight of 4, however when all three values are very similar and don't deviate much, then having a weight of 4 is a bit overkill because the result will usually be the same as the most likely case. I prefer to use a weight of 2 for my cost estimations.
The previous problem of developers estimating pessimistically is now resolved. Through the worst case estimate, each ticket receives a slight buffer. However, unlike with the one-point system, the buffer is not the final value. Instead, it is weighted into the final score.
Not only is the final cost estimate for the project a bit more realistic, and not quite as pessimistic, it also gives me a range value that I can present to our clients. I can now tell them that if everything goes well, the project can cost as little as x, if some things go wrong it might cost y, but it will most likely cost z.
Conclusion
Estimating the final cost of a project is tricky. Step one is to break a client-project's requirements down into concrete stories and tickets. In order to estimate the effort of each ticket, two approaches can be taken. I prefer to use the three-point system as described above. This gives me a cost range for a potential project and a more realistic final price estimation rather than a pessimistic one.
Thanks for reading my post. I’d love to get feedback from you, so feel free to shoot me a tweet!
- Hendrik
