Ballparks and Estimates for Software Development Projects
“Hello, I’d like this app built. Could you give me an estimate on how much it’d cost?” said everyone always. I have a great answer for this, I usually tell them something in the line of “You just asked me ‘I’d like to buy a car, how much does it cost?’“. It costs between a hundred dollars for a used old rag all the way to seven digits for Rimac Nevera newest model.
This usually resonates well (if you say it in a funny and charming way and not in a pompous condescending way 🙂 ). And then we start discussing what the needs are and so on. I usually invest some time to get a basic understanding of what the client would like to do. The client very often has their own ideas on how they would like it done, but having over 15 years of experience in the software development industry, I am often able to suggest some things that should be done differently, as well as some things they did not pay attention to and they should.
After a few meetings, we have a sort-of-a-specification and a list of features. Depending on how detailed this is, the estimate will be more precise.
Giving an estimate is a process
An estimate is not a number that you throw out. Or, at least a realistic estimate isn’t. If someone is asking you to give one right away on the spot – they are amateur. I usually ask some time to go back and work on it and let them know.
Then I have a process:
Divide the scope of work into tasks
Discuss the tasks with the team
Assign a minimum and maximum task value
Calculate the total
Prepare a presentation of the estimate and what it includes
For this I have created a spreadsheet that helps me. Based on this, I calculate the totals.
Then I write a short presentation of what is to be included and what are the disclaimers (and, let’s be realistic, there are always disclaimers!) and go to the client with this for further discussion.
Dividing the scope of work into tasks
When talking to a client about their application, they will often say something like “The application will allow users to… but admins will be able to do …”.
Based on experience, as soon as you hear the word “Users” you already know that you have some tasks you will need to do e.g.:
authentication
authorization (if they mentioned more roles)
login, register, forgot password
user management
…
And this is the way my mind works – as I am listening to the client and/or reading through my notes, I am envisioning a rough sketch of a data model. It does not need to be perfect initially, but it does need to make some sense. Of course, you cannot do this without a development background or experience.
Based on the model, I can then see which interfaces (and here I mean UIs) and which screens the application will need/have. Then, based on how those screens will interact with the user, I know which functionality the application (both front end and/or backend) would need. And then I just write up tasks for that to happen.
During the course of this usually several questions will arise, and I always prefer to go back to the client with those, for additional clarity. If the client is open to discussing their application in more detail, that is usually a good sign. If they are opposed to doing that, in my book it is a red flag.
Discussing with the people who will build it
I have seen this step overlooked way too often. In larger companies it is often expected that business analysts and/or PMs can do this on their own. From my experience, a discussion with the team that will build it is needed. They will help with estimating how long it will take and they will (more importantly) help by pointing out technical challenges that might be great pitfalls and might be something a PM or business analyst does not necessarily think about.
I prefer going over the task list with the team. We discuss each item how we’d roughly develop it. Any “smaller” things will be handled as a part of the task, but in general we have a rough idea on how to do it. E.g. if you’ve never done an integration with a particular authentication provider, but have done one of those and know in general how they work, then you should be able to estimate the task – even without knowing the details of the authentication provider itself.
For each task we assign two values – minimum and maximum. Minimum – if we get everything right the first time and everything works. Maximum – if all hell breaks loose and we completely missed a huge thing that came back and bit us on the arse hard! If we are talking about a really small project then we do estimates in hours, but I prefer keeping the minimum unit to one man-day.
The total time is not time for development summed up!
After making the estimation for all the tasks you just sum it all up and presto – you have your estimation! Nothing could be further from the truth.
Time dedicated for QA
Every development project should have time dedicated for QA. Some might argue that code should have automated tests and the code should ensure that it functions etc. And they are absolutely correct, I agree with that. And on top of that we need to allocate time for QA. Or at least this is what we do in our software development process.
In my book, the QA time is time it takes people manually testing to find and locate bugs and time it takes the team to fix them. It is often the case that companies will agree that testing and QA is the client’s job. And while finding bugs during the QA process can be a responsibility of the client, I guarantee you that fixing them is a part of the vendor’s job.
I usually set QA as a percentage of the total development time. Usually I play with 15-20% of the total development time. (Yes, it is that high, developers are not wizards to get everything right from the first go, we also make mistakes).
Time dedicated for PM
Every project will have management. Even if we go Agile, there always needs to be someone to run those meetings, prepare the tasks, communicate the status to product owners etc. This does seem like not so much time, like some typing here and there and a few calls here and there. But, if done right, it does take up some time that needs to be accounted for. On the other hand, if done right, it keeps the client happy, as they are always aware of what the status of the project is, what are possible roadblocks or risks etc.
I usually set PM time as a percentage of the total development time, but I also factor in the general size of the project, size of the team as well as the infrastructure from the clients side (whether they have a really dedicated product owner or product manager even etc.). This can vary between about 15% and 30% of development time.
Safety factor
If you need to provide an estimate based on a specification of 50 pages with wireframes and detailed user stories, that is often easy and can be really accurate. However, in most cases people have a vague idea of what they want to do, usually without any functional specification about how it should work. This makes estimations harder to provide.
I introduce what I call a safety factor. It is basically a number I’ll use to multiply the time I calculated to get. The poorer the specification, the larger the number. It really depends on the quality of the specification and the impression that the client leaves on you. If the client feels confident about the way forward, this is good. If, during the first two calls, the client changes their mind about stuff, this is usually a bad sign.
But the safety factor can be anything from 20% (yes, even with perfect specs I leave 20%) all the way to 150% for people who come up to you with an idea described in one paragraph. (“I just want a small and simple application that will build spaceships! What do you mean you need more details??”).
Calculate the total
If you’ve followed this method, in end you should come up with a really large time span. E.g., if your initial development time came to 20-40 man days, after multiplying it with all these factors it could become something like 30-90 man days. You really don’t want to tell someone that something will take 30-90 man days because they cannot really plan anything with that answer.
There is a way around it. You need to be at peace with the fact that not everything will go as planned and there will be unexpected issues that take time. On the other hand, opposed to what Murphy’s Laws teach us, usually not everything will go wrong. So, I take the middle between the minimum and maximum man-days calculated and put a time span around that.
What I usually do is pick a number (most often 15%) and just put it around the middle of the calculated minimum and maximum man-days. So, if the calculation gave me 30-90 man days, the middle is 60 man-days, 15% of 60 is 9, so I’d say it would take between 51 and 69 man days.
Present the estimate to the client
I usually don’t present all these in-between steps to the client. I will write up a “specification” that will describe the tasks we used for estimation, but in a human language. It will also speak only about tasks that the client can actually see and feel, while infrastructural tasks will be tucked away in the background (unless the client is highly technical). What it means is that if we have tasks which are:
create a data model in the database for X
create a migration
create a service in the backend
switch the existing service with the new one to be used over DI
create component A that allows CRUD on X on screens 1, 2, 3
create component B that allows CRUD on X on screens 4, 5
update data models on the client side
…
To the client this will be presented just like “We need to update the system so that entity X can be entered in different ways from screens 1, 2, 3, 4 and 5”. Usually the technical “under the hood” stuff is not relevant at this ponit.
And then, in the end I always just provide them with a final time span calculated.
Disclaimers
What the offer includes
Be clear about what is included and what isn’t. Generally in life there are a few things that annoy me more than “Ah, yes, but that isn’t included in the price!”. Be upfront about the services you will provide and the services you will not.
This gives the clients an option to search for these services themselves or to let us handle them, but either way, they know the situation upfront and will not be disappointed with the solution they received (e.g. for expecting a fully automated infrastructure as a service and not knowing it was not included.)
What are the risks
If a certain application depends on 3rd party services a lot, then this is a bit risky. Because if, for any reason and at any point, the 3rd party can change their terms of service and just pull the ground from under your feet.
I usually warn the clients that this could happen and that they need to handle the legal stuff with that service provider to protect themselves as much as possible.
There could be other risks as well – if I (or anyone in our team) recognize them, I am always upfront with the client about those.
Conclusion
Our estimates come up high. A lot of other service providers that don’t have a process similar to this one end up estimating lower. However, a good estimation is not the lowest one. It is the most accurate one. (And there is a law that says that if you want to pick the expert in the room, choose the one who says that the project is going to take the longest and cost the most.)
We usually do a post-mortem on every project we do, and after applying this method on several recent projects, we got quite good results comparing actual time spent and time estimated. This is something I am very proud of, as I know it is a great problem in the industry in general.
Also, as the estimates come up high, there were some cases where companies decided on others that estimated lower. And then there were cases where those companies asked for us on their next project just because of the approach we showed.
To sum up – a good estimate is one where you’re honest about what you provide and as accurate as possible about the time it takes you to provide it. And I am very happy my team has a process that helps us really nail both of these.
