In this article I would like to drill down approaches to a project estimation process. The problem is relevant for both customers and service providers. Customers very often ask several suppliers to prepare proposals at the same time to then compare them and make a final decision. In reality the price factor usually plays a significant if not defining role.

Knowing this, some companies start to mark down in order to win tender and just “get involved” into the job.

Some are too optimistic about their estimates, some may not take certain functionality needed to be provided into consideration, others do not have enough expertise, etc. As a result, a project can’t fit into agreed time & cost limits forcing the customer to pay more, possibly even more than other providers have bidden.

Below are my thoughts on how to strike a happy medium in estimation, what things may not accidentally be taken into account and what you should definitely pay attention to when comparing proposals.

First thing I want to note is that any estimate assumes certain roughness by definition. Nevertheless, it is impossible to do without it. We are personally guided by a simple rule:

It is better to overestimate the project rather than underestimate it.

We’d better do our job faster and at lower costs and thus look even more professional in the eye of the customer than not be able to live up to our promises. Of course, this approach may scare some potential customers who look for bargains, but your reputation is more important in the long term. There is a fine line here between adding an appropriate time and cost buffer and not scaring clients away.

A few simple pieces of advice to keep in mind:

• Always try to make your work breakdown as detailed as possible – no items longer then 6-8 man-hours.
• Assume that 1 business day is not 8 hrs, but 6 – 7 since people can’t be equally productive during the whole work day.
• An estimate is provided in man-hours, but two or more people involved do not mean x2 or x3 performance boost. Some things cannot be done simultaneously, plus do not forget about time spent on communication / interaction between the team members. In reality productivity coefficient for 2 developers is 1.5.
• Each phase (milestone) should include a QA phase, stabilization/bug fixing and a buffer for adding changes requested by the client.
• Try to always add 10 – 20% buffer to the project in general. We put down buffer time & costs as a separate line in our estimation docs and do not break them down further since estimation buffers for every minor task will look ridiculous. If buffer time is overestimated, the client won’t be charged for it anyway.
• Consider time for HTML / CSS coding or its integration.
• Count time spent on management issues & communication with the client (it can take from 10 minutes up to 2 – 4 hours daily). While you’re talking and not participating in the development, task completion gets postponed.
• Take into account such steps as building application architecture, creating DB design, setting up infrastructure (QA, UAT, PROD servers), deployments (daily, weekly, etc.).
• Consider time for writing unit / functional tests.
• Add time for creating wireframes. These help to get rid of the guessing game in development.

Perhaps, not all of the above mentioned points apply to every project. But anyway, if some things are not stated in your estimates, it’ll be harder to convince your customer to pay for them later.

However, the initial assessment is only half the deal. No less important thing is to adhere to your initial estimates.

How to keep to your time frame/budget:

• Keep in touch with the client on a regular basis and make sure you perfectly understand each other. If something is not explicit, do your best to grasp or explain it. We follow a simple rule: if something is not clear, we will discuss it again and again and again until the issue becomes crystal clear for both sides.
• Plan weekly/bi-weekly releases to demonstrate your progress. Don’t forget to show them to the customer.
• Try to avoid scope changes during releases. Keep all change requests in backlog and get down to them only after primary functionality is completed.

In the end, I would like to remind that a miser customer pays twice and it’s better to measure thrice, check twice, cut once for every project.

Tell us what you think on the topic and feel free to share your project estimation guidelines.