In the first part of this article I looked at how we go about making rough estimates for clients to use during the validation phase. Assuming they like what they hear, it’ll be time to move on to the detailed estimate. That could be a one or two step phase depending on the client. Let’s take a look at what it involves.
Detailed rough quotes
Sometimes a client might say something like: “Yes, I’m happy with that range but can I get more clarity on where exactly the time is going to be spent or which parts of the project contain the most variation and uncertainty?”. They’ve probably not given us any more info about the project. They just want a breakdown of how we got to that initial number.
This isn’t hard for us to do, we’ve essentially already answered this question for ourselves, we just haven’t passed it onto the client as we know that most clients aren’t interested in the breakdown at this stage. They just want the ballpark figure for validation.
Producing detailed rough quotes
Now though, we produce a detailed breakdown for them. We split the project into measurable pieces including the different functions and features wanted in the final product. Each piece is labelled with the amount of time we’ve allocated to it in our rough estimate.
Once they’ve got the detailed rough quote, the client sees a fuller picture of their project. They understand how the time is spent and have a chance to review and revise, reprioritise or simplify the features.
A rough detailed quote for the Uber style app example we looked at in the last article might look like this:
Login and registration functions 80 – 160 hrs (depending on how many types of login are used, if social logins are used, complexity of driver registration, etc.)
Driver view: car details, user pickup, profile settings – 140 – 270 hrs
User view: request pickup, interactions with driver – 100 – 180 hrs
Payment options – 80 – 280 hrs (depending on the number of payment systems to be integrated)
Encrypted API – 130 – 180 hrs (phase 1 features only, based on the brief)
Backend admin panel with driver management – 240 – 360 hrs (based on specifics outlined in the initial brief)
Assumptions
As you can see from this example, I added assumptions in brackets for a few features. It’s crucial to provide assumptions, as these explain some of your reasoning, allowing the client to see where the potential to incur more costs arises and make decisions accordingly. That’s why we dedicate a lot of attention to indicating any assumptions clearly. Assumptions set expectations.
Detailed fixed price quotes
If the client likes the rough or detailed rough quote we’ve provided, it’s time for us to produce a detailed final quote. For us to do this, it’s preferred that we have a full scope of work to develop the quote from. At the very least we’ll need to go through all of the project’s technical details, clarifying with the client the exact requirements that they have, especially where we’ve indicated assumptions in a detailed rough quote. This helps us come to a detailed understanding of exactly what functionality is required for each feature, what work that will involve and put a number of hours next to each item.
Once the fixed-priced estimate is complete, you should have a set number of hours for each feature and functionality. This means that the price to be paid and the product being produced are both clearly set out.
Very often even in a final estimate, there can still be a range of hours connected to some items. This is usually because it can’t be precisely guessed how much work some elements will take to produce until another part is already finished. This means that most final estimates are not just a number but still a range. This is ok, the project can still begin at this point. The range is already much more precise than in a rough estimate. In most cases the functionality whose hours are unknown come a little way down the line, so the costs connected to the first part of the project are known completely.
How many hours does it take to make detailed estimate?
This is a great question because often the amount of work involved in producing an estimate is overlooked. An average mobile app estimate can easily take up 6 to 8 hours between several different people (depending on the size of the project). Specifically I’d expect at least 3 people to have been involved: a manager, a mobile app developer and a backend developer. They’ll have spent that time talking through the project’s elements and potential difficulties, writing questions and assumptions and then checking back with the client for more clarification. Once that process has been gone through several times, the manager would create a summary of their work containing the final quote for the client.
So it’s not a quick process. The manager and developers will have had at least 3 separate conversations about the project before the quote is ready. They’ll have also spent at least 6 hours breaking everything down in detail. This is all happening before a contract has even been signed, and unfortunately not every final estimate gets approved and the contract won. This is part of the competitive nature of today’s app and web development industry, but with a good system in place you can at least make sure that the contracts you do win are won on the basis of accurate estimates that you’re not going to lose money on.