In most companies I have worked for, the price for a website project was based on the estimate of the number of man-days for the project, and the price of man-day for each profile (integrator, designer, developer,..)
When I was asked to produce estimates in order to make an offer to a customer, I went to see each expert in my team and asked them to estimate the tasks in their domain of expertise, and they delivered an estimate on the number of man-days for the project.
Of course, there was a great inaccuracy in the estimates that I gathered, due to different factors:
- The person who would do the job was perhaps not the one who estimated it
- This person did not always have enough input or time to produce a realistic estimate
With those estimates in hand, the manager could then determine and communicate the cost for the project to the customer.
As the estimates were often wrong, the customer was charged with the wrong price.
If you base the price on the numbers of man-days, this indicates that the customer was just buying “days”. If you spend more or less days than initially planned, it is as if you delivered, let’s say, more or less potatoes than the customer bought.
So, in projects where you spend less days than expected to deliver the project, you should whether work for you customer on other tasks during the remaining days that she paid for, or give him a credit.
If you spend more days than expected to deliver the project, there are two options:
- You have had additional resources to finish the project in due time. In this case, the additional workload should be at your own expense, because the customer did not pay for additional days.
- You just delivered the project late. In this case you may have penalties for delivering late, which is normal.
Building a website, or any software, is not just spending days on it. One day on a very complex piece of code should cost more than one day on a basic html page. There is not only the quantity factor to consider, but also the quality factor.
Delivering a project on time and on budget, but with tons of bugs is not the same than delivering it on time, on budget and with high quality standards. If I order a new book and receive it in poor condition, I am pretty sure that the seller will send me back another copy, or re-credit me. It should be the same for a website.
So if we deliver a website on time and on budget but in poor condition, the customer should not be charged with the price indicated at the beginning.
In the above example, we clearly see that a price based on an estimate of the number of days for the project is absurd.
The cost for the project should be based on criterias like:
- its complexity
- the number of features in the project that are new to you – that is, features you never implemented before and thus imply some uncertainties –
- the difficulties that you will have in testing certain features
If there is some complex new feature that you never implemented before, and you do not know exactly how you will make it and test it, you should not just talk about adding some man-days, because:
- This number of man-days will be hazardous
- In the end you will perhaps find a solution that is brilliant but is fast to implement, or you will discover that there is another feature that would be more relevant and does not take much time…
In everyday life, when we buy some very expensive decorative objects or clothes, we do not estimate if the price is correct by guessing if it took more days to build this article than a cheaper article. We decide if we will pay this price by evaluating the beauty of the article, the popularity of the brand, its reputation for making quality products…
This should be the same when the customer compares the offers made by different vendors for building their project.
She really doesn’t want to spend time checking if this should really take 2 days or 2 hours to implement the social network sharing functionality.
Her choice will more likely be based on the following criterias:
- does the Project Manager seem competent
- do the vendor really understand the project goals and its importance
- is the vendor able to indicate if a feature is really necessary
- and if yes how it should be implemented to be useful
- does the vendor have a reputation of making innovative websites
So my conclusion is that we should stop making estimates just to set the price for a project.
The next question is: what or should we use estimates…I will try to answer this in my next post.