How to Choose the Best Freelance Project Proposals

In this article, I would like to talk about the approach in the estimation process and how to drill it down. The problem is equally relevant both for customers and vendors.

Very often customers ask for a proposal from several providers at the same time to compare and then make their final decision. The reality is that very often price factor plays a crucial role.

Keeping this in mind, unfair providers are clearly starting to dump in order to win the tender and just “get involved” into the job. Others are simply too optimistic in their estimates, may not consider certain necessary functionality, do not have enough expertise etc. As the result, the project does not fit into the agreed time frame and the customer pays more, possibly even more than the price of top proposals.

Where is the happy medium? What items sometimes are not taken into account? What you should definitely pay attention while comparing proposals?

First thing I would like to note is that any estimate by definition assumes certain roughness. But it is also impossible to work without it. Personally, we are guided by a simple rule: “it is better to overestimate the project rather than underestimate”. In the process, we will better do our job faster and cheaper and thus will look even more professional in the customer’s eyes rather than leaves without figs.

Yes, this approach may scare some potential customers who dumping on the market, but your reputation is more important in the long run. It is a fine line here. You will need to explain the inherent buffer correctly.

A few simple things to keep in mind

• We always try to make our work breakdown as detailed as possible — no items longer than 6–8 man-hours.
• We assume in our calculations that 1 business day is not 8 hrs, but 6 since this is the real productive time (we don’t like overtimes)
• An estimate is made in man-hours, but two or more people does not mean 2x, 3x performance. Some things can not be done in parallel, plus time for communication/interaction between them. In reality coefficient for 2 developers is 1.5x.
• Each phase (milestone) should include some QA work, stabilization/bug fixing and buffer for change requests.
• We also usually secure another 10 — 20% as a buffer on top of the whole project. We do this in a separate line in our assessment and do not split it between other tasks since in such a case an estimate for minor problems will look absurd. If this buffer was useless — the client will not be charged.
• Consider some time for HTML / CSS coding or it’s integration.
• Consider management, communication with the client (this can be 10 minutes or up to 2 — 4 hours daily). While you talk, your other tasks are shifted in time.
• Take into account such stages as application architecture, DB design, infrastructure set up (QA, UAT, PROD environments), deployments (daily, weekly etc.)
• Consider time to write unit / functional tests
• Add wireframes round. Frames help to avoid guesswork in development.

Perhaps something from above does not apply to every single project. Otherwise, either you do it for free, or will ask your customer to pay, explaining that initially it was not clearly specified.

The initial assessment is only half of the story. Next important thing is to adhere to your initial estimate.

How to keep time frame/budget

• Keep in touch on a regular basis. Make sure you understand each other. If something is not clear — pronounce. We follow a simple rule: “if something is not clear — we will discuss again and again and again… As long as you said “clear”, ideally you should never get back to the same issue”.
• Plan weekly/bi-weekly releases that demonstrate your progress. Show it to the customer
• Try to avoid scope changes during release. Collect all requests in backlog and do them only after primary functionality was completed.

As a summary I would like to recall the famous saying — “a miser pays twice.”